LINUX.ORG.RU

как делать ci/cd нескольких сервисов(docker swarm, gitlab ci cd)

 , ,


0

5

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

Вопросы следующие

  1. Где и в каком виде хранится конфиг кластера
  2. Монорепа/мультирепа
  3. Версионирование артифактов
  4. Как происходит откат
  5. Как обновить 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?


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

tz4678 ★★ ()

1. Ты хочешь GitOps как я понял? Вообще подумай надо или оно тебе, например Thoughtworks против такого подхода: https://www.thoughtworks.com/radar/techniques/gitops

2. Основной плюс монорепы в том, что можно шарить код. Например дефиниции protobuf. Если оно тебе не нужно, забей. Еще монорепу делают для «распределенного монолита», когда все сервисы вместе деплоят. Если это не нужно, тоже забей. Сделай у каждого сервиса свой пайплайн и кати. Только подумай про E2E тестирование. Можно глянуть на pact

3. Насчет версии. Если хочешь gitops, то да, лучше тегать руками и прописывать тег в деплой репе. Но я не фанат gitops, поэтому бы делал git sha всегда, а деплой в прод либо по коммиту в мастер (идеальный вариант) или промоушен из staging

4. Не забудь про обратную совместимость

5. Это вопрос E2E тестирования. Можешь катить все вначале на стейджинг и гнать E2E тест. Или катить в прод но как canary и смотреть совместим ли сервис

dizza ★★★★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.