Приветствую, не уверен разаботка это или администрирование, но пусть будет так. В интернете полно статей как настроить ci cd на примере одного сервиса. Но не совсем понятно как это сделать с группой сервисов.
Вопросы следующие
- Где и в каком виде хранится конфиг кластера
- Монорепа/мультирепа
- Версионирование артифактов
- Как происходит откат
- Как обновить 2+ сервиса одновременно.
Какие мысли
Сервисов у меня не много, основной и 3 сателита, пока все в разных репах.
1) Конфиг
Если это монорепа, то и конфиг хранится в ней же. Но, в каком виде в нем прописаны версии docker образов.
CI/CD записывает туда последнюю собранную версию 1.1.111, после чего конфиг посылается на кластер
Плюсы:
- прям из конфига видно какая версия образа должна быть задеплоена(но нужно ли это)
Минусы:
- сложно заморозить версию пакета, ci/cd все время жаждет ее обновить
конфиг статичный, руками задаем номер версии, типа: latest
Плюсы:
- Легко заморозить версию пакета, для продакшена конфиг с тегами latest, для тестов в ветке feat-25 у нас версии feat-25
- Для отката с 1.1.111 до 1.1.107 удалем из хранилища докера образ 1.1.111 и вешаем тег latest на 1.1.107
Минусы: из конфига может быть не понятно, какая версия должна быть в работе(нужно ли?)
Есть ощущение что держать статичный конфиг и управлять версиями сервисов через теги образов удобней и правильней.
2) Монорепа/мультирепа
Монорепа
Обычно в минус монорепе записывают огромный репозиторий в котором работает тысяча человек, клонируется он пол дня
Это не мой случай, репы маленькие, работаю с ними я один
Плюсы что я вижу, все в одном месте, обновил общий код, обновились все сервисы от него зависящие. gitlab cicd позволят в пайплайнах определять какие файлы в каких директориях поменялись и на основе этого пересобирать только нужные пакеты. Конфиг кластера тоже лежит здесь же.
Мультирепа
- Кажется сложней в управлении при связывании в кластер.
- Конфиг кластера будет лежать в отдельной репе deploy_cluster
3) Версионирование.
Версионировать каждую версию руками грустно, надо чтоб это делала ci/cd. Пока мысль такая, вешать git tag major.minor изредка руками а патч вычислять на ci/cd.
tag=$(git describe --tags --abbrev=0)
patch$(git rev-list ${tag}..HEAD --count)
Нужно ли его средствами ci/cd вешать на гит репу(надо немного поправить алгоритм вычисления патча), или использовать только для версионирования образов
В случае с монорепой, нужно ли тегировать новой версией образы которые не пересобирались, например с целью простоты отката всего кластера на версию 1.1.107, у некоторых образов может просто не быть настоящей версии 1.1.107
4) Откат
Вроде бы частично рассмотрен в пункте про конфиг
5) Как обновить 2+ сервиса одновременно.
Это необходимо для того чтобы не выкатить сервис A который хочет новую фичу от сервиса B, а сервис B еще не выкачен.
Ну тут магии вроде бы нет, просто надо выкатить сначала B, а потом A. А даже если A выкатится раньше, он просто не должен подниматься, сответственно кластер не переключит на него трафик.
Бонусный вопрос, где хранить env variables в docker stack/swarm. У него есть такие понятия как конфиг и секрет, но они монтируются в образ как файлы, что не всегда удобно.
Что могут рассказать взрослые devops?
