Как правильно производить деплой с gitlab ci/cd?

Question

[Igor Karachentsev]

Добрый день. Имеется группа проекта в gitlab, в ней несколько репозиториев:

1. api на symfony
   
2. frontend для админки
   
3. frontend для публичной части
   

Как правильно организовать деплой такого приложения на stage сервер, и на prod соответственно. Для локальной разработки накидал docker-compose.yaml, в котором сервисы с php-fpm, nginx, postgres. Но так как я сам не devops не могу понять как правильно организовать уже непосредственно процесс сборки и доставки на сервер из нескольких репозиториев. В целом для прода я предполагаю что надо собирать имеджи проектов и уже их доставлять, но как быть со стейджом? Как правильно хранить основной docker-compose.yaml, который и будет уже на сервере собирать и запускать все в кучу? Да и нужен ли он вообще? На какой стадии надо собирать имеджи? Их[имеджи] должен уже сам gitlab средствами ci/cd, или это должен делать разработчки и отправлять их в container registry? Ну и куча подобных вопросов. Devops я стать не хочу, но интересно разобраться в этой теме)

Answer 1

[Vitaly Karasik]

Удобнее разделять CI (юнит тесты, static code analyzer, security scanner, ...) и CD (деплой).
Типичный пример:
- при каждом коммит прогоняются тесты, строится docker image и кладется в registry
- при коммит в ветку staging дополнительно запускается деплой на stage, при коммит в master (на что имеет права только начальник или release manager) - деплой на прод.

Уточнение насчет разделять - обычно это может быть один pipeline, просто разные триггеры\фильтры для CI CD.

Comments

[Igor Karachentsev]

Ну с этим вроде как понимание есть. Не могу понять только как это все правильно организовать и по репам раскидать. Вот у меня есть репозитории с проектами, там у них свои docker-compose.yaml и Dockerfile, чего достаточно для разработки локально. При пуше в определенную ветку будет билдиться image - ок, понятно. Только вот, например, для того же php требуются всякие php.ini, и прочие конфиги. Вот они должны лежать в тоже репе что и проект? Но тогда этих конфигов будет куча, так как локально нужны одни конфиги, на проде другие. Далее, если я правильно понимаю, мне надо завести репу, например, docker, где и будет лежать, скажем так, "мастер" docker-compose.yaml, и конфиги, которые будут тащиться уже непосредственно на сервер. И получается, что если у меня собрался образ, в определенной ветке, то этот образ уже улетает на сервер и там разворачивается? Но тут еще возникает вопрос, как быть с миграциями?

[Vitaly Karasik]

Только вот, например, для того же php требуются всякие php.ini, и прочие конфиги. Вот они должны лежать в тоже репе что и проект?

ИМХО, да - в том же репо. Начет разных environments - в идеальном мире (https://12factor.net/) нет разных конфигов и разных images, все параметры получаются из окружения.
Или держать разные файлы, типа php.ini-${ENVIRONMENT}, или использовать что-то для template с параметрами.

как быть с миграциями?

А в чем разница с локальным деплой? Вам так или иначе нужно что-то для управления миграциями.