Развертывание новой версии в контейнерах

Я запускаю кластер CoreOS на AWS. На каждом экземпляре в AWS я запускаю док-контейнер. Например, у меня есть 2 экземпляра с именем API, которые запускают образ докера с нашей последней версией программного обеспечения.

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

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

Он создает новый образ докера для API и процессоров. Он загружает новый обновленный образ в dockerhub. Затем он подключается к экземплярам AWS и выдает извлечение докера для только что загруженного образа. В конце концов он запускает контейнеры с новыми извлеченными изображениями.

Именно так я сейчас контролирую развертывание своей версии.

Проблемы:

  1. это занимает много времени
  2. иногда выходит из строя по разным причинам
  3. это не гибко (мне нужно жестко закодировать конкретную ветку, чтобы слушать на github и извлекать файлы)

Есть ли у вас какие-либо другие предложения\инструменты для выполнения этой работы? Иногда мне нужно обновить 3 машины, а иногда 7, и мне нужно что-то масштабируемое.


git docker amazon-web-services ansible go-cd
person Gal Gibli    schedule 04.02.2016    source источник
comment
Вы когда-нибудь смотрели на ткань (fabfile.org)?   -  person otaviofcs    schedule 04.02.2016
comment
Это похоже на использование ansible, просто другой синтаксис.   -  person Gal Gibli    schedule 04.02.2016

Ответы (2)


arrow_upward
1
arrow_downward

Я не использую git в своей среде, но использовал перехватчики SVN после фиксации, которые запускают рабочие процессы развертывания Jenkins. Добавьте в Jenkins плагин Build Pipeline, чтобы вы могли возобновить работу после сбоев. вместо перезапуска с самого начала. Тем не менее, проверьте, поддерживает ли GoCD такие вещи, нет смысла переключать инструменты, если они не нужны.

Я бы предложил следующие изменения:

  1. Разбейте ansible playbook на отдельные шаги в вашем инструменте развертывания. Это позволит перезапускаться ближе к сбою, тратя меньше времени.

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

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

person Dave Snigier    schedule 04.02.2016

arrow_upward
0
arrow_downward

Начиная с проблемы № 3, вы можете подумать, хотите ли вы выпускать код из разных веток. GoCD, являющийся инструментом непрерывной доставки, лучше всего работает при разработке на основе магистрали, то есть всегда выпускает из мастера.

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

Что касается проблемы № 2, вы можете захотеть иметь больше шагов в GoCD, чтобы вы могли следить за потоком в веб-интерфейсе Go, получать уведомления по электронной почте о сбоях и возобновлять с точек, где произошел сбой, и т. д.

Что касается № 1, вы должны рассказать нам, что медленно, и какие у вас ожидания в отношении времени. GoCD не молниеносно приступает к работе. Я думаю, что он опрашивает репозитории GIT раз в минуту, а бездействующие агенты через определенные промежутки времени связываются с сервером, чтобы узнать, есть ли работа. Хотя в основном это фиксированная задержка. Он не станет медленнее только потому, что у вас есть 100 хостов для обновления, если только вы не создадите задание GoCD для каждого экземпляра (и это, вероятно, не очень хорошая идея).

Похоже, что docker compose и docker swarm могут быть лучшими инструментами для работы, для которой вы используете Ansible.

person Magnus Lyckå    schedule 17.02.2016