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

Question

[swelf]

Приветствую, не уверен разаботка это или администрирование, но пусть будет так. В интернете полно статей как настроить 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?

Answer 1

[Saboteur]

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

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

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

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

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

Откат

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

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

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

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

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

Comments

[swelf]

Спасибо за развернутый ответ.
Хочу уточнить, касательно конфига сервиса, в нем всеже хранить указание на конкретную версию
image:1.1.107, которую cicd будет проставлять при удачной сборке образа
или на обобщенный тег типа
image:latest
а управлять что будет крутиться на сервере мы уже будем вешая этот тег на ту или иную версию образа, опять же по умолсанию через cicd

И конфиги и секреты можно маунтить и как файлы и как переменные окружения.

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

[Saboteur]

Маунтим секрет my-app-secrets как volume my_secret_directory внутри контейнера, и все что есть в нашем секрете будет в виде файлов в /opt/myapp/secrets. Тут можно в принципе и только отдельные значения замаунтить, но кадое будет в виде отдельного файла в этой директории.

spec:
  containers:
    volumeMounts:
    - name: my_secret_directory
      mountPath: "/opt/myapp/secrets"
      readOnly: true
  volumes:
  - name: my_secret_directory
    secret:
      secretName: my-app-secrets

Маунтим конкретный ключ database_password из секрета my-app-secrets в env переменную DBPASSWORD которая будет доступна внутри контейнера.

spec:
  containers:
    env:
      - name: DBPASSWORD
        valueFrom:
          secretKeyRef:
            name: my-app-secrets
            key: database_password

[Saboteur]

Хочу уточнить, касательно конфига сервиса, в нем всеже хранить указание на конкретную версию
image:1.1.107, которую cicd будет проставлять при удачной сборке образа
или на обобщенный тег типа
image:latest

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