Запуск Jenkins на спот-инстансах AWS (Николай Маржан, LVEE-2018)
Материал из 0x1.tv
- Докладчик
- Николай Маржан
A case of Jenkins CI/CD system in AWS cloud is reviewed, featuring use of spot instances, which are extemely cheap but are affected with arbitrary shutdowns in any time by the cloud provider. An approach to run Jenkins master on spot instances in AWS with fault tolerance and automatic fault recovery is proposed. Comparison of plugins which allow to run worker nodes on spot instances on-demand is presented.
Содержание
Видео
Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.
Презентация
Thesis
Введение и постановка задачи
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
Примечания и ссылки
Plays:72 Comments:1