На прошлой неделе авторы 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 не нужна?».
Автор: shurup
