Запуск Jenkins на спот-инстансах AWS

Введение и постановка задачи

Jenkins – это популярная система непрерывной интеграции и непрерывной доставки (CI/CD), которая на текущий момент представляет собой наиболее расширяемое CI/CD-решение на рынке, с огромным количеством плагинов для интеграции со всем на свете. В числе прочего для Jenkins можно найти достаточное число вариантов запуска задач в облаке по запросу (когда виртуальная машина каждый раз запускается под конкретную задачу, а затем уничтожается).

В системе Jenkins испольузются узлы двух типов: master и worker. В базовой конфигурации задачи могут выполняются на master-узле. В более сложном варианте master делегирует выполнение задач worker-узлам, автоматически выбирая наиболее подходящий из них. В отличие от master-узла, на worker-ах запущен не полноценный Jenkins, а т.н. worker agent – программная прослойка, минимально необходимая для запуска задач по запросу.

Применительно к облачным технологиям (и, в частности, AWS) такая архитектура очевидно легко переносится на инстансы по требованию (on-demand instances). Однако в настоящей работе предлагается вариант конфигурации Jenkins, использующий спот-инстансы Amazon EC2.

Spot instances – это такие же вычислительные ресурсы, выделяемые в облаке AWS, как и более традиционные инстансы по требованию. Однако в отличие от последних спот-инстансы доступны с большой скидкой. Ценой этой экономии средств является то, что работа спотов может быть в любой момент прервана со стороны AWS (с уведомлением за две минуты) в случае, если AWS требуются ресурсы.

Сохранение данных master-узла

Первой задачей, необходимой для обеспечения работы master-узла Jenkins в таких условиях, является сохранение данных при уничтожении инстанса и их подгрузка при его перезапуске. Можно выделить два варианта для такого сохраняемого хранилища:

• EFS (Elastic File System) – NFS, который запускается на AWS в 1 клик. Его недостатком является низкое быстродействие, а преимуществом – автоматическое копирование данных между availability zones (независимыми датацентрами в одной локации), это значит что master-узел может быть перезапущен в любой из них.
• EBS (Elastic Block Storage) – диск, который видится внутри инстанса как блочное устройство. Преимущество этого варианта – высокое быстродействие, а недостаток – возможность запуска master-узела только в пределах одного датацентра (availability zone).

В случае EFS при загрузке спота монтируется NFS-директория, и Jenkins получает доступ к базе. В случае EBS, инстанс после загрузки присоединяет к себе нужное независимое блочное устройство через AWS cli.

Запуск и остановка master-узла

Как уже было упомянуто, на старте инстанс с master-узлом монтирует EFS или EBS со всей файловой базой. Затем запускается Java-процесс, в результате чего Jenkins воспринимает ситуацию не как перемещение на другой узел, а как простой перезапуск.

При внеплановой остановке master-узла сохранить состояние помогает двухминутное оповещение. По его получении выполняется остановка Jenkins и размонтируется файловое хранилище. Чтобы была гарантия, что файловая база не окажется в промежуточном (повреждённом) состоянии, используется MAX_SURVIVABILITY режим в Jenkins. Кроме того, задачи не запускаются на master-узле, а только на worker-узлах. Использование исключительно MAX_SURVIVABILITY и pipeline jobs, а также статического IP (Elastic IP) для master позволяет восстанавливать соединение с worker-узлами, и таким образом перезагрузка master-узла в большинстве случаев не сказывается на задачах, выполняющихся в данный момент на worker’ах (разумеется, при рестарте worker-узлов выполнение на них задач завершается неудачей и требует повторного запуска вручную или автоматически при задании опции retry на уровне stage в declarative pipeline).

Запуск worker-узлов

Взаимодействие с Amazon EC2 для запуска инстансов под выполнение задач может осуществляться с помощью двух плагинов Jenkins:

• EC2 Fleet Jenkins Plugin – плагин, написанный для Jenkins сотрудниками Amazon. С его помощью master-узел Jenkins информирует AWS, сколько инстансов для worker-узлов необходимо запустить. Его особенностью является то, что вся конфигурация хранится на стороне AWS, а также работоспособность вне пределов одной availability zone.
• Amazon EC2 plugin – аналогичный плагин, созданный комьюнити. Он является более популярным, однако worker-узлы с одним лейблом можно запускать только в пределах одной availability zone. В качестве его достоинства можно отметить хранение конфигурации непосредственно в Jenkins.

Вместо заключения

Конфигурация, описывающая представленное решение, доступна публично по адресу https://github.com/Percona-Lab/jenkins-pipelines/tree/master/IaC/ps.cd