На прошлой неделе авторы Open Source-проекта Jenkins представили своё новое детище, «расширяющее экосистему Jenkins» и предназначенное специально для непрерывной интеграции/доставки приложений в рамках кластеров Kubernetes. Решение получило название Jenkins X. Что же оно делает?

Предыстория и суть

Появлению Jenkins X способствовали растущие потребности разработчиков в удобном решении вопросов CI/CD — таком, что было бы изначально ориентировано на применение в облачных окружениях, автоматизацию и лучшие DevOps-практики. Этому, в свою очередь, способствовали изменения в ИТ-индустрии, к которым причисляют активное использование неизменяемых образов контейнеров для распространения ПО, массовый выбор Kubernetes для управления контейнерами в публичных и гибридных облачных окружениях, рост популярности микросервисов и приложений категории cloud native (где CI/CD нужен большому числу компонентов и с большой регулярностью релизов), улучшения в практиках DevOps (последнее подтверждается результатами исследования 2017 State of DevOps Report от Puppet). Разработка Jenkins X (по крайней мере, публичная) ведётся 2,5 месяца.

Основная идея, стоящая за Jenkins X, глобально не нова и заключается в том, чтобы максимально автоматизировать всё «стороннее», чем в данном случае является упаковка приложений в Docker-образы, создание базовых YAML-конфигураций для Kubernetes, подготовка дополнительных окружений (контуров, площадок… — называемых просто Environments), настройка типовых пайплайнов для CI/CD. В общем, как говорят сами авторы, «сосредоточьтесь на создании ценности» [вместо необходимой рутины]. Что для этого предлагается?

Возможности Jenkins X

Концептуальная модель Jenkins X представляется следующим образом:



Основная работа с происходит через консольную утилиту jx, список доступных команд в которой описан в документации. Сама же работа по существу начинается с создания пайплайнов CI/CD, для чего подготовлены специальные комплекты из предварительно описанных простых приложений, с которых было бы проще начинать свой проект. Они называются quickstarts, размещаются в отдельных Git-репозиториях (пример для Go) и, конечно же, могут быть созданы самостоятельно.

Особое внимание уделено проектам на Spring Boot, для которых реализован отдельный импорт (для уже существующих) и упрощённая процедура создания (для новых). Наконец, есть и общий импорт существующего исходного кода, использующего отличные от Spring Boot технологии.

«Магия» же заключается в том, что для любого из этих вариантов Jenkins X создаст Jenkinsfile (для определения пайплайнов), Dockerfile (для упаковывания приложения в образ контейнера) и Helm chart (для деплоя и запуска приложения в Kubernetes), а также интегрирует всё это с Git: проверит наличие webhooks для срабатывания пайплайна при событиях push, обеспечит деплой pull-запросов (со сборкой приложения и запуском тестов) на демонстрационной площадке, а при merge'ах с мастером будет создавать новые релизы и запускать их на нужных площадках.

Примечание: Выбор Helm (и Draft) в качестве метода взаимодействия с Kubernetes сами авторы объясняют своим стремлением следовать принципу «configuration as code». Пакеты Helm — charts — основываются на шаблонах и выглядят предпочтительнее (логичнее), чем «классический» метод (т.е. ручная работа с YAML-документами и их передача в kubectl).

По умолчанию предусмотрены две площадки: Staging и Production, — но это легко изменить под свои задачи. Каждой из них выдаётся отдельное пространство имён в Kubernetes, так что они функционируют и управляются изолированно. Выкатывание релизов на площадки может быть ручным или автоматическим.

В отдельную категорию вынесены демонстрационные площадки (Preview Environments), идея функционирования которых заключается в автоматическом срабатывании на pull-запросах (впрочем, не исключает и ручного запуска), чтобы быстро показать коллегам ссылку с приложением, где применены внесённые изменения.

И важное обещание, которое дают авторы: «Jenkins X ничего не прячет; вы всегда можете вручную изменить Jenkinsfile или Helm charts для своих приложений и их окружений — все они версионируются в Git с остальным исходным кодом и полным CI/CD».

В целом жизненный цикл кода, обслуживаемого с помощью Jenkins X, выглядит так:



Наконец, предусмотрена поддержка дополнений, расширяющих возможности Jenkins X (например, для получения поддержки Git-сервера Gitea достаточно выполнить команду jx create addon gitea).

Jenkins X построен на базе Jenkins и предполагается его включение в качестве подпроекта (уже создан JEP — Jenkins Enhancement Proposals — подномером 400), расширяющего возможности самого Jenkins с помощью выбранной модели разработки с Git, инфраструктуры с Kubernetes и вспомогательных Open Source-инструментов (Helm, Nexus/Artifactory и других).

Знакомство

Для наглядной демонстрации основных возможностей Jenkins X подготовлено 10-минутное видео, автор которого выполняет основные команды в консоли и проверяет результат в Git-репозиториях и веб-браузере.

Код основной утилиты Jenkins X — jx — написан на языке Go (распространяется под свободной лицензией Apache License v2). Так что его установка тривиальна — в случае Linux сводится к:

curl -L https://github.com/jenkins-x/jx/releases/download/v1.1.10/jx-linux-amd64.tar.gz | tar xzv 
sudo mv jx /usr/local/bin

Дальнейший шаг для возможности её использования — создание кластера Kubernetes (или использование уже существующего). Поддерживаются версии K8s 1.8 и выше, а требования к конфигурации заключаются во включённом RBAC и поддержке небезопасных реестров Docker. Необходимые операции для этого тоже весьма просты и описаны здесь. Официально поддерживаемые окружения Kubernetes на сегодня — это AWS (поддержка AWS EKS ожидается в скором времени), Google (GKE), Azure AKS и Minikube.

Когда Jenkins X развёрнут в кластере, остаётся только добавить приложения (одним из описанных способов: quickstarts, команды для Spring Boot, общий импорт кода) — после этого инструмент готов к использованию. Посмотреть на него в действии можно с помощью команд jx get pipelines, jx get activities, jx get applications и подобных, а после первых пробных релизов — и через веб-интерфейс управления Git-репозиториями (GitHub):

Планы развития

Релизы Jenkins X собираются каждый день (а иногда — даже чаще), однако, анонсируя этот продукт, авторы напоминают, что проект ещё «очень молод».

Имеется таблица с дорожной картой его развития, из которой можно увидеть, например, что прямо сейчас идёт работа над поддержкой OpenShift, Skaffold, Gitea и BitBucket, а поддержка GitLab пока только «запланирована».

P.S.

Читайте также в нашем блоге:

• «Официально представляем dapp — DevOps-утилиту для сопровождения CI/CD»;
• «Сборка и дeплой приложений в Kubernetes с помощью dapp и GitLab CI»;
• «Лучшие практики CI/CD с Kubernetes и GitLab (обзор и видео доклада)»;
• «Собираем Docker-образы для CI/CD быстро и удобно вместе с dapp (обзор и видео доклада)»;
• «Путеводитель CNCF по решениям Open Source (и не только) для cloud native»;
• «Сколько разработчиков думают, что Continuous Integration не нужна?».