@swelf

Как делать ci/cd нескольких сервисов?

Приветствую, не уверен разаботка это или администрирование, но пусть будет так. В интернете полно статей как настроить ci cd на примере одного сервиса. Но не совсем понятно как это сделать с группой сервисов.

Вопросы следующие
1) Где и в каком виде хранится конфиг кластера
2) Монорепа/мультирепа
3) Версионирование артифактов
4) Как происходит откат
5) Как обновить 2+ сервиса одновременно.

Какие мысли

Сервисов у меня не много, основной и 3 сателита, пока все в разных репах.

1) Конфиг
Если это монорепа, то и конфиг хранится в ней же. Но, в каком виде в нем прописаны версии docker образов.
  1. CI/CD записывает туда последнюю собранную версию 1.1.111, после чего конфиг посылается на кластер
    • Плюсы:
      • прям из конфига видно какая версия образа должна быть задеплоена(но нужно ли это)


    • Минусы:
      • сложно заморозить версию пакета, ci/cd все время жаждет ее обновить






  2. конфиг статичный, руками задаем номер версии, типа: 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?
  • Вопрос задан
  • 105 просмотров
Решения вопроса 1
saboteur_kiev
@saboteur_kiev
software engineer
У каждого сервиса свой репо, свои джобы, свои деплои, зачастую не связанные друг с другом.

Монорепа/мультирепа

Это вопрос для девелоперов, как вам удобнее. Монорепа используется обычно тогда, когда у ваших сервисов реально есть общий код. Если же нет, то проще в отдельных репозиториях.
Многие CI/CD можно настроить на пуш в определенные подкаталоги, и тогда разные сервисы в монорепе будут триггерить свои собственные джобы (teamcity например)

Версионирование

На усмотрение разработчиков. В мейвене есть плагины для автоматического semantic версионирования. Или можно руками. Самое простое - это мажорную версию проставляешь руками, а ci просто номер билда дописывает и/или хеш коммита в версию.

Откат

В случае с кубером/опенщифтом для этой задачи существуют healthcheck пробы, которые настраиваешь и все. Если приложение не прошло хелсчек при поднятии, то деполй фейлится и все - предыдущая версия автоматом будет продолжать работать. В случае баз данных и других вещей - разработчики должны писать скрипты для наката/отката, или если база маленькая можно делать бэкапы или снепшоты. Тут зависит от архитектуры

Как обновить 2+ сервиса одновременно.

Все верно. Либо у вас порядок деплоя сервисов предуказан в процессах, либо наполовину руками выводить. Но по хорошему такие несовместимости не должны приводить к крешу сервиса. Ну не будет временно работать фича Б в сервисе, потому что недоступен другой, и все. Поднимется этот другой сервис и все заработает. Это правильный и идеальный вариант, не мешающий деплойменту. Деплоймент проводится в небизнес время и никого не аффектит. Как минимум, подобные ситуации должны встречаться не так часто, поэтому вполне можно найти промежуток времени для таких нестандартных деплоев.

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

И конфиги и секреты можно маунтить и как файлы и как переменные окружения. Дочитайте документацию.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы