Автоматизация развертывания крупной распределенной клиент-серверной части CI / CD

Для одного из наших приложений мы пытаемся автоматизировать процесс развертывания. Мы реализовали непрерывную интеграцию (Build/Test/Package/Report) для этого приложения. Сейчас мы пытаемся внедрить автоматизированное развертывание. Это приложение необходимо развернуть на 2000 серверах и по 50 клиентов на каждом сервере. Некоторые из компонентов будут установлены на сервере, а некоторые из них будут установлены на клиенте.
Инструменты, используемые для CI: Jenkins, Github, msbuild, nunit, specflow, wix.

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

В большинстве статей в сети объясняется, как мы можем автоматизировать часть развертывания при дальнейшей доставке / развертывании на одном из серверов (DEV/Staging/Preproduction/production). Ни в одной статье не говорится о развертывании приложения на большом количестве серверов и клиентов.

Теперь мои вопросы: 1) Развертывание приложения на 2000+ серверах и клиентах является частью непрерывного развертывания, или оно должно быть выполнено из CI/CD? 2) Если это может быть обработано в CI / CD, то как мне смоделировать это в конвейере доставки Jenkins и запустить развертывание для всех серверов из инструмента CI? 3) Есть ли какой-нибудь инструмент, который я могу интегрировать с инструментом CI для автоматизации развертывания?

Спасибо

Источник

2 ответа

Решение

Я бы держал отдельно эти 2 аспекта:

  1. развертывание на большом количестве серверов (не имеет значения, исходят ли артефакты для развертывания от CI или нет)
  2. подключить такое развертывание в CI для выполнения CD

Для #1 - я уверен, что есть профессиональные ИТ-инструменты, которые можно использовать. Проверьте с вашим отделом ИТ. Если для развертывания не требуются разрешения суперпользователя или если у вас есть такие привилегии (и знания), вы также можете написать свои собственные инструменты развертывания / управления.

Для #2 - CD на самом деле не указывает, следует ли развертывать на одном сервере, определенном проценте ваших производственных серверов или на всех них). Ваш выбор должен быть основан на том, что имеет смысл или более подходит для вашего конкретного контекста. Как именно это делается, если вы решили пойти по этому пути? Это действительно зависит от #1 - вам просто нужно запустить процесс от вашего CI. Должно быть проще с пользовательским инструментом развертывания:)

Источник
  1. Ключевое требование (IMHO) в Continuous Deployment - это оркестровка процесса, jenkins не идеальный инструмент для этого, но вы можете написать собственную обертку для скриптов groovy или вызывать задания удаленно из другого инструмента оркестровки. Еще одна проблема Дженкинса, по крайней мере для меня, заключается в сложности отслеживания прогресса.

  2. Я бы смоделировал это следующим образом:

    • Разделите процесс развертывания на логические уровни, например, Центры обработки данных-> Приложения-> Пулы, и создайте оболочку для каждого уровня. Это позволит вам увидеть прогресс на самом высоком уровне в главной оболочке и развернуть в случае необходимости, как вы хотите
    • Каждая обертка должна заканчиваться как SUCCESS только если ВСЕ последующие работы были SUCCESSFULиначе должно быть UNSTABLE или же FAILURE, В этом случае нет никаких шансов, что вы что-то упустите на низкоуровневой работе.
    • 1 работа за 1 на каждый продукт / приложение / пакет
    • 1 задание для управления одиночным запуском последовательности. Например, я бы использовал mcollective для запуска задания установки последовательно / параллельно на выбранных серверах.
    • 1 задание на каждый логический уровень

  3. Я хотел бы использовать:

    • mcollective - как указано выше
    • бригадир, чтобы запросить puppet выбрать список серверов для каждого запуска последовательности
    • Установка пакета / приложения / артефакта на сервер, который я предпочел бы делать с программным обеспечением собственной ОС, например yum на linuxслужит. Это позволит вам положиться на их механизм проверки установки

Я уверен, что что-то пропустил, но я надеюсь, что это даст вам приемлемую отправную точку

Источник
Другие вопросы по тегам