Какова наилучшая практика для рабочего процесса Docker CD/CI?

Question

Я довольно новичок в docker worlflow, и мне интересно, что лучше всего подходит для рабочего процесса docker CD/CI ... большинство статей, выпущенных прямо сейчас, похоже, действительно не говорят о «развертывании» части докера , только регистрация.

Что я хочу сделать:

1. сделать некоторые изменения кода
2. Нажмите на Git
3. Test Дженкинс Unit/EE тест
4. Дженкинс строит Docker изображение
5. магазин Docker изображение в реестре
6. Запуск изображения докеров на сервере.

Для достижения шагов 1-5 у меня есть нижний стек.

Пользователь нажимает на gitlab -> Gitlab webhook уведомляет jenkins -> jenkins создает проект -> Сохраняет изображение в реестре докеры gitlab.

Я использую Rancher для развертывания изображений докеров ... Мне очень нравится распределение Ранчера. i.e я могу указать изображение докера, которое будет запускаться, и rancher заботится о том, какой сервер развертывает мой контейнер.

В идеале я хотел бы шаг # 6, чтобы быть «распределены» (то есть я не хочу, чтобы SSH на сервер и запустить docker run {imagename}) и имеют некоторые службы быть авторитетом для развертывания

есть что-нибудь подобное в настоящее время, что позволит мне это достичь?

Answer 1

Существует так много разных подходов для достижения этого.

Одним из самых простых является использование инструмента управления конфигурацией для . Разверните новые изображения, используя. Ansible - хороший выбор, но другие, такие как марионетка или шеф-повар, тоже прекрасны. Эти инструменты дадут вам полный контроль над тем, что должно быть развернуто там. Вы можете легко выполнить обновление без прерывания трафика, как описано в этом документе example.

Другой подход заключается в том, чтобы полагаться на сам кластер, чтобы автоматически развертывать службы. Этот подход обычно называют хореографией. Хорошим выбором являются такие инструменты, как кубернеты или недавний рой докеров с некоторыми магами.

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

Answer 2

Что касается последнего шага, учитывая пример Rancher (многие другие предоставляют аналогичные API REST), вы можете позволить Jenkins вызвать API Rancher для обновления службы, при условии, что вам нужно определить свой собственный стек в каталог пользовательских сервисов Rancher.

Я также ищу легкие решения и с удовольствием узнаю альтернативы.