Что такое приемлемое производственное развертывание для веб-приложения, которое может иметь небольшие различия в конфигурации между экземплярами на разных серверах

Question

Так что сейчас мы используем Git в качестве контроля версий. Мы также используем docker compose для управления развертыванием

Я хочу учесть тот факт, что у нас есть клиенты, которым нужна собственная версия сайта с небольшими различиями в docker-compose.yml (например, переменная окружения, определенная docker). Это заставляет git pull беспокоиться о незафиксированных изменениях в файле docker-compose.yml.

Я думаю, что я могу открыть ветку от мастера и затем извлекать изменения из мастера со временем, так что нам не нужно беспокоиться об изменениях для конкретных файлов конфигурации.

Конечно, я могу что-то упустить, и существует простое решение для всего этого.

Answer 1

Стандартный способ git - это создание ветки и ее частое обновление с master. Это очень распространенный подход.

Фактически, большинство проектов с открытым исходным кодом используют очень похожую технику, при которой вилка берется из основного репозитория, а пользовательские изменения вносятся в разветвленный репозиторий.

Как небольшое замечание, лучше поддерживать переменную окружения в файле env_file, так как значения env, вероятно, будут отличаться от клиента. Таким образом у вас будет меньше ручных слияний в файле docker-compose.

Обновить

Еще одна идея, которую стоит оценить, - это git submodules. По сути, вы можете поместить вещи, которые должны отличаться, в подмодуль git и оставить родительский модуль одинаковым между вашим репо и репо клиента. Таким образом, клиент указывает на свой собственный подмодуль, и нет необходимости в поддержке отдельных веток.

Answer 2

Мы используем этот простой подход: у нас есть один репозиторий, содержащий все конфигурации для всех экземпляров. Наша структура каталогов:

/base
   docke-compose.yml
   .env
/test
   docker-compose.override.yml
   .env
/production
    docker-compose.override.yml
   .env

Это позволяет нам не дублировать некоторые базовые вещи в каждом docker-compose.yml Также это позволяет нам использовать git branches для некоторых новых функций / исправлений.