Здесь нет единственного ответа «серебряной пули», и все это будет в значительной степени зависеть от деталей.
Прежде всего, я считаю, что рекомендуется отделять весь исходный код от конфигурации в отдельном репозитории.Итак, исходный код остается исходным кодом, но его установка или развертывание (с настройкой, паролями и т. Д.) - это совсем другое.Таким образом, вы будете жестко отделять задачи разработчиков от задач системных администраторов и в конечном итоге сможете собрать 2 отдельные команды, которые будут делать то, что у них хорошо получается.
Когда у вас есть отдельный репозиторий исходного кода + репозиторий развертывания, ваша лучшая следующая ставкарассматривает варианты развертывания.Лучший способ, который я вижу здесь, - это использование процедур развертывания, типичных для выбранной ОС (то есть создание автономных пакетов для выбранной ОС так, как это делают сопровождающие ОС).
Например, процедуры упаковки в Red Hat или Debian обычно означают захватархив программного обеспечения с внешнего сайта (который будет экспортировать исходные коды из вашего исходного кода VCS), распаковывать его, компилировать и готовить пакеты, готовые к развертыванию.Само развертывание в идеале должно означать простую и быструю команду, которая установит пакеты, такие как rpm -U package.rpm, dpkg --install package.deb или apt-get dist-upgrade (учитывая, что ваши собранные пакеты идут в хранилище, где apt-get сможет найтиих).
Очевидно, чтобы заставить его работать таким образом, вам нужно будет предоставить все файлы конфигурации для всех компонентов системы в полностью рабочем состоянии, включая все адреса и учетные данные.
Чтобы получить более краткие сведения, давайте рассмотрим типичную ситуацию с «небольшим сервисом»: одно приложение PHP развернуто на n серверах приложений, работающих под управлением apache / mod_php, и обращающихся к m серверам MySQL.Все эти серверы (или виртуальные контейнеры, что на самом деле не имеет значения) находятся в защищенной частной сети.Чтобы упростить этот пример, давайте предположим, что все реальные интернет-соединения находятся в кластере из k http ускорителей / обратных прокси (таких как nginx / lighttpd / apache), которые имеют очень простую настройку (только внутренние IP-адреса длявперед).
Что у нас есть для того, чтобы они были подключены и полностью работали?
- Серверы MySQL: настройка IP-адресов / имен хостов, настройка баз данных, предоставление логинов и паролей
- PHP-приложение: настройте IP-адреса / имена хостов, создайте файл конфигурации, в котором будут указаны IP-адреса, логины, пароли и базы данных серверов MySQL
Обратите внимание, что здесь есть 2 разных «типа» информации: IPs / hostnames - это что-то фиксированное, вы, вероятно, захотите назначить их раз и навсегда.С другой стороны, логины и пароли (и даже имена баз данных) предназначены исключительно для целей подключения - чтобы убедиться, что для MySQL это действительно наше PHP-приложение, подключающееся к нему.Итак, мои рекомендации здесь будут разделять эти 2 «типа»:
- «Постоянная» информация, такая как IP, должна храниться в некоторых VCS (отличных от исходного кода VCS)
- «Временная» информация, такая как пароли между двумя приложениями, никогда не должна храниться, но должна генерироваться во время генерации пакетов развертывания.
Последний и самый сложный вопрос здесь остается: как создавать пакеты развертывания?Доступно несколько методов, 2 основных способа:
- Экспортированный исходный код из VCS1 + «постоянная» конфигурация из VCS2 + сценарий сборки из VCS3 = пакетов
- Исходный код находится в VCS1;VCS2 - это распределенный контроль версий (например, git или hg), который по существу содержит «вилки» VCS1 + информация о конфигурации + сценарии сборки, которые могут генерироваться.Мне лично этот подход нравится больше, он намного короче и в конечном итоге проще в использовании, но кривая обучения может быть немного круче, особенно для администраторов, которым для этого придется освоить git или hg.
Для примера выше я бы создал пакеты типа:
my-application-php - который будет зависеть от mod_php, apache и будет содержать сгенерированный файл, такой как /etc/my-php-application/config.inc.php, который будет содержать IP-адреса / имена хостов базы данных MySQL и логин / пароль, сгенерированные как md5(current source code revision + salt). Этот пакет будет установлен на каждом из n серверов приложений. В идеале он должен иметь возможность установки на чисто установленную ОС и сделать полностью работающий узел кластера приложений без каких-либо ручных действий. my-application-mysql - который будет зависеть от MySQL-сервера и будет включать в себя скрипт после установки, который:
- запускает сервер MySQL и обеспечивает автоматический запуск при запуске ОС
- подключается к серверу MySQL
- проверяет, существует ли необходимая база данных
- если нет - создает базу данных, загружает ее с содержимым и создает логин с паролем (те же логины и пароли, которые были сгенерированы в
/etc/my-php-application/config.inc.php с использованием алгоритма md5)
- если да - подключается к базе данных, применяет миграции, чтобы привести ее к новой версии, убивает все старые логины / пароли и воссоздает новую пару логин / пароль (опять же, сгенерированную методом md5 (revision + salt))
В конечном счете, это должно принести выгоду от обновления вашего развертывания с помощью одной команды, такой как generate-packages && ssh-all apt-get dist-upgrade. Кроме того, вы нигде не храните пароли между приложениями, и они обновляются при каждом обновлении.
Этот довольно простой пример иллюстрирует множество методов, которые вы можете использовать здесь - но, в конечном счете, вам решать, какое решение лучше здесь, а какое - излишним. Если вы укажете подробности здесь или в качестве отдельного вопроса, я с удовольствием постараюсь вникнуть в подробности.