Непрерывная доставка - выпуск / контроль версий микросервисов

Мы разрабатываем микросервисы с использованием Spring Boot, которые затем упаковываются в Helm Charts и развертываются в кластере Kubernetes. У каждой службы есть файл Jenkins, и ниже мы выпускаем каждую службу индивидуально:

  • Сервис A -> Сборка -> Пакет -> Контроль качества -> Подготовка -> Производство
  • Сервис B -> Сборка -> Пакет -> Контроль качества -> Постановка -> Производство
  • Сервис C -> Сборка -> Пакет -> Контроль качества -> Постановка -> Производство

Этот подход довольно прост, но на самом деле он не дает вам готовых артефактов, и вы получаете несоответствия.

Что мы хотели бы сделать, так это сгруппировать выпуск, используя зонтичную диаграмму Helm, показанную ниже (родительский элемент A):

  • Parent A --> Build --> Package --> QA --> Staging --> Production
    • Service A
    • Услуга B
    • Услуга C

Я изо всех сил пытаюсь придумать способ сделать это без необходимости вручную выпускать каждую службу, а затем обновлять версии в родительской диаграмме. Кто-нибудь делает это автоматически?


docker jenkins kubernetes-helm microservices continuous-delivery
person Jack    schedule 27.04.2018    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Я могу поделиться упрощенным взглядом на то, как мы отправляем код Codefresh:

  • у каждого микросервиса есть собственный репозиторий git и диаграмма управления.
  • кодовая база каждой службы имеет версии (независимо от диаграммы), например, в package.json.
  • каждая диаграмма руля также имеет версии.
  • Когда разработчики обновляют сервисы, они должны поднять версию в коде.
  • У нас также есть одна убер-диаграмма Helm, в которой все диаграммы микросервисов перечислены в виде требования к диаграмме.
  • Конвейер CI в репозитории кода создает образ докера (помеченный версией кода) и диаграмму управления (помеченный версией кода). Это еще ничего не развертывает.
  • Если разработчик хочет развернуть, он редактирует файл требований в uber-диаграмме, требуя новую версию.
  • Конвейер CD на убер-чарте обновляет штурвал.

Это очень упрощенное описание. На самом деле конвейер также делает такие вещи, как:

  • автоматическая обработка релизов npm и github
  • ворота на основе объема обновления
  • автоматическая инициализация специальных сред в PR / ветке (разверните новую среду, чтобы протестировать / поделиться своими изменениями)
  • секретное управление

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

person itaysk    schedule 03.05.2018
comment
По сути, это тот же подход, который мы выбрали. Я (пытаюсь) рассматривать это как преимущество - у вас есть точное и точное отслеживание того, что развернуто, потому что вам нужно вручную обновить версии поддиаграммы в вашей uber-диаграмме и перестроить ее. - person BostonHiker; 07.05.2018
comment
Таким образом, в основном каждая мс имеет свою собственную диаграмму, поэтому каждый раз, когда мс изменяется, вы обновляете версию ms и версию диаграммы. Я по-прежнему считаю, что выпуск с одной диаграммой - это путь для многих подобных микросервисов. Но я согласен, что это теоретически. Я также ищу способ сделать последнее. - person Kat Lim Ruiz; 10.06.2021

arrow_upward
0
arrow_downward

Если я хорошо понимаю вашу проблему, вы можете решить ее с помощью плагина Jenkins multijob. И без обновления вашей текущей существующей работы.

Ваш рабочий процесс будет выглядеть так:

Parent Job
    Service A --> Build --> Package --> QA --> Staging --> Production
    Service B --> Build --> Package --> QA --> Staging --> Production
    Service C --> Build --> Package --> QA --> Staging --> Production

Где ваша родительская работа запускает все ваши дочерние рабочие места.

Я видел, как подобным образом решается аналогичная проблема. Также иногда ваша дочерняя служба должна быть выпущена вместе, или одна из ваших служб всегда должна быть впереди (сервер). Вы можете добавить несколько сценариев проверки python / shell в свою родительскую работу, чтобы убедиться, что ваш конечный продукт всегда доступен для выпуска.

https://wiki.jenkins.io/display/JENKINS/Multijob+Plugin

person Luc    schedule 27.04.2018