company_banner

Представлен Jenkins X для CI/CD облачных приложений в Kubernetes



    На прошлой неделе авторы 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.


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

    Флант
    DevOps-as-a-Service, Kubernetes, обслуживание 24×7

    Комментарии 12

      0
      Вопрос к гуру Dev Ops: у меня есть проект на С++, для которого я хочу организовать CI на Windows, macOS и Linux на одном и том же физическом сервере. Пока что я плохо понимаю, как этого вообще можно добиться, не считая тупой вариации с тремя виртуальными машинами, в каждой из которых крутится свой Jenkins.
      Jenkins X и Docker как-то помогут мне в решении этой задачи, или Docker не предоставляет достаточную степень виртуализации, чтоб на одном хосте запускать все три перечисленные ОС?
        0
        Из под linux без всякой вертуализации при помощи mxe, можно кросскомпилить под windows(если вас устраивает сборка под mingw).
        Про mac нечего не могу сказать.
          +1
          Я не гуру. Но, скорее всего, нужно собрать пайплайн со сборкой внутри трех разных докер контейнеров. У каждого базовый образ — нужная операционка, а сверху следующим слоем ставятся все девтулсы, вытаскивается волюм, куда кидаются исходники или настраивается сеть для их автоматического выкачивания по переданным в контейнер при запуске параметрам. Наверное можно даже параллельно запускать.
            +2
            Так как официально Mac OS можно запускать только на их железе, то что бы запустить Mac OS на своем сервере, потребуется пропатченный ESXi или VMWare Player ну или хакинтош.
            Запустить Windows в Docker контейнере можно только под Windows Server 2016 или Windows 10 Pro/Enterpise (И это будет Windows Server минимальный так что не уверен что там будет удобно делать сборку)
            Так что наверно самый простой способ это поднять 3 виртуальные машины и поставить на них build агентов. Настроить pipeline который будет собирать на всех трех машинах параллельно. И Docker вам для этого не нужен.
              0
              Спасибо за отличный совет. Уже собирался ставить три отдельных независимых сервера Jenkins на три виртуалки, а вот о том, что можно так, как вы сказали, не знал.
            0

            Внутри докера linux ( и вроде windows с недавних пор). Поэтому если цель — проверить, собирается ли проект на всех трёх платформах, то только виртуалки, если нужна макось.

              0
              Докер точно не предоставляет макось и не предоставляет винду и никсы на одном хосте. Так что только виртуалки.
                0

                Помоему вы путаете виртуализацию и контейнеризацию.


                По поводу виртуалок уточнение — внутри них крутится не Jenkins Master, а Jenkins Slave. А "управляете" вы с одного дженкинса.

                  0
                  Конечно, путаю. Даже на самом сайте Docker нет нормального объяснения, что оно такое на самом деле, сколько ни гуглил объяснения — всё запутанно. Но постепенно начинаю понимать.
                    0
                    Если очень грубо docker это образ в котором упаковано все зависимости которые нужны для приложения которое вы запускаете в контейнере, когда вы запускаете контейнер запускается 1 приложение, которое использует все зависимости именно из контейнера.
                    С первого взгляда можно подумать что контейнеры это продвинутый chroot хотя это и не так, но с chroot общего больше чем с виртуалками
                  0
                  Лично я использую VirtualBox виртуалки + buildbot. Для уменьшения хаоса управления этими виртуалками можно использовать vagrant. Скорее всего есть варианты получше. Тема CI для desktop приложений раскрыта куда менее обширно, чем CI для web
                    0
                    Да не нужен вам тут докер. Классика — три vm с разными ОС — слейвы Jenkins, еще одна VM на линуксе — мастер. Если стоит задача тестировать развертывание — присмотритесь к Vagrant, поддержку win они вроде обещали. У докера она в зачаточной стадии пока, и да, требует win-хоста, а еще нормально не заработает в винде внутри VM. Что делать с макосью — не уверен. На вашем месте я бы городил гибридное решение — на линуксовой версии тестировал бы максимально чисто, тут докер может принести пользу, винды — классика (обычный слейв) или решение на Vagrant'е, мак — классика (ну или поискать, может есть специфичные решения — зачатки контейнеризации в ядре вроде есть, может есть уже удобный софт на этот случай). Всё это хозяйство может управляться одним мастером Jenkins достаточно удобно

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое