Я думаю, что нормальным подходом было бы использование среды CI / CD.
Git хранит исходный код вашего проекта. Каждый коммит (или любое другое событие) запускает процесс непрерывной интеграции и компилирует исходный код по мере необходимости. В случае указанной ветви c (master / production) процесс CI / CD создает артефакт, который упакован в образ Docker и передан в реестр. Все это не выполняется на сервере - но на другом компьютере - не используйте производственную машину Ubuntu для компиляции веб-приложения ...
Тогда процесс CI / CD может запустить публикацию sh обработайте это, выполнив это непосредственно на удаленном компьютере или вызвав ansible playbook (например, для создания настроек ReverseProxy) Итак, вы полностью отсоединили процесс компиляции от конфигурации. Сборник пьес может стать частью проекта.
Существует несколько примеров для Gitlab и Jenkins - посмотрите, например, https://docs.gitlab.com/ee/ci/docker/using_docker_build.html.
Каждый проект имеет свой собственный файл Docker, описывающий сам сервис. И есть общий проект с файлом Docker -Compose и, возможно, Ansible сценариями для генерации производственной среды (как правило). Конфигурация для каждой услуги выполняется с помощью Playbooks для проекта SCM.
Изменение файла в одном проекте приведет к воссозданию образа Docker. Вам нужно всего лишь вызвать docker -compose pull & up -d (возможно, вам не нужно повторно запускать полный процесс docker -compose-Create). Другая задача может выполняться автоматически или при любых изменениях. Я думаю, хитрость заключается в том, чтобы использовать Docker контейнер вместо Ansible скрипта здесь, потому что вы уже используете docker -композитную среду - используйте ее полностью.
Итак, у вас есть (для пример)
- хост для разработки
- контейнер Gitlab вместе с контейнером Gitlab-Runner
- для каждого проекта, есть конфигурация CI для дескрипции задач из источника артефакт (см. .gitlab-ci.yml)
- Dockerfile для описания образа и его конфигурации / startup / healthcheck
- и, возможно, playbook под управлением .gitlab-ci.yml настроить ReverseProxy et c.
- один другой проект с инвентарем и универсальными c playbooks для создания настройки по умолчанию для вашей среды (в моем случае pu sh для этого проекта вызывает AWX REST API для перечитывания SCM и запуска playbook site.yml).
- , возможно, Docker Registry
- , возможно, перед этим ReverseProxy.
- и вы товар ионная машина
- ReverseProxy
- несколько Docker -компонованных сред с docker -изображениями из вашего реестра
Хорошая вещь это - вместе с AWX и некоторыми другими хостами вы можете создать промежуточную область для разных веток и новых проектов и использовать развертывание на основе времени.
Конечно, замените Gitlab на то, что вы хотите.