Greg Young — винахідник CQRS вже 17 жовтня на Highload fwdays онлайн конференції
×Закрыть

Make your life easier with Jenkins X

Меня зовут Максим, я работаю DevOps-ом в компании Intellias.

Ранее я долго работал админом. Админский подход к организации работы выглядит следующим образом: у нас есть какой-то сервер, у нас есть какой-то админ, который его когда-то давным-давно настраивал, и, пока сервер не ломается, его лучше не трогать, потому что никто не знает, кем, когда и как именно он был настроен.

Собственно, именно отказ от этой концепции мотивировал меня перейти в DevOps. Потому что это очень классно, когда мы можем подготавливать конфиги, контролировать, что и где происходит — все упорядоченно, все задокументировано, все работает.

В этой статье мы разберем некоторые теоретические аспекты работы с Jenkins X, а затем, в практической части, посмотрим небольшое демо на Jenkins X.

Что такое Jenkins X?

Jenkins X — это относительно новая утилита, которая появилась в конце 2018 года, но все еще активно развивается и все еще сыровата. Но именно она продвигает идею DevOps-а еще дальше: она продвигает нас к GitOps-у. Чуть дальше я расскажу, почему GitOps — это круто и почему это, возможно, один из вариантов нашего будущего.

Jenkins X разворачивается на Kubernetes, он очень любит облачных провайдеров, и, чем больше облачных провайдеров, тем лучше. Он поддерживает почти всех провайдеров, которые так или иначе представляют Kubernetes — AWS, Google Cloud и т.д. Можно развернуть Jenkins X в MiniKube, что мы и будем делать сегодня, в практической части. В целом, возможностей по использованию Jenkins X очень много — это зависит от ваших потребностей, желаний и т.п.

Типы использования Jenkins X

Первое, что нужно сказать — это то, что Jenkins X не равно Jenkins в кластере. Это не то же самое, что развернуть Jenkins в кубах, подключить к нему jnlp агенты и считать, что это Jenkins X. Jenkins X — это целый набор распределенных компонентов. Это микросервисное приложение со множеством зависимостей, которое может даже не использовать ядро Jenkins — ту большую Java машину, которая есть у нас в стандартном Jenkins.

Есть два типа использования Jenkins X:

Stateless Jenkins — по факту, он очень близок к тому, что было раньше: Jenkins master, развернутый в Kubernetes, плюс ряд компонентов, которые взаимодействуют с ним: собирают вебхуки, отвечают за версионирование и т.п., плюс агенты, сборщик, анализатор. Это уже не совсем Jenkins, но он все еще имеет веб-интерфейс, и на него все еще можно зайти. Работать с ним, если вы работали с Jenkins, достаточно просто, т.к. многое из того, что вы знаете о Jenkins, вы сможете использовать в Stateless Jenkins X.

Безсерверный Jenkins X — тут все гораздо сложнее и гораздо круче, есть много взаимосвязанных компонентов, которые развернуты в Kubernetes, огромный список различных служб, и нет никакого веб-интерфейса. Есть попытки этот интерфейс создать, но они довольно вялые: очевидно, что это никому не нужно, т.к. идет вразрез с методологией GitOps, о которой мы сейчас поговорим.

Что такое GitOps?

GitOps — это одно из ключевых понятий для Jenkins X. Без GitOps Jenkins X просто не имеет смысла. Тому, кто хочет разобраться, что такое GitOps, нужно понимать — Jenkins X является практически эталоном использования этой методологии.

В целом, GitOps — это почти то же самое, что DevOps, но с одним отличием. «Сердцем» этой методологии выступает Git. Вся конфигурация, все настройки, весь код лежат в Git. Первая заповедь GitOps: Git — это единственный источник правды о системе.

Представьте ситуацию: вы приходите на работу, там есть какой-то Jenkins. Этот Jenkins был развернут 2-3 года назад, и к нему даже есть документация — устаревшая примерно настолько же. На этом Jenkins завязана куча всего, и у вас есть 15-страничный мануал о том, как его не уронить, в какие фазы Луны лучше деплоиться, какие пайплайны можно трогать, а какие — нет. Есть один админ, который знает, как это все работает, а все остальные владеют только фрагментарной информацией.

GitOps призван избавить вас от этого. Вся конфигурация должна храниться в Git. Все изменения делаются только через Git. И это, собственно, является вторым правилом GitOps. Git является единственным местом, где производятся любые манипуляции с любыми environments. Создание, удаление, обновление — абсолютно все делается через Git.

Что это дает? Все становится очень наглядно, все структурировано, для любого внесенного изменения мы можем увидеть кто, когда и почему это сделал. И откатиться назад тоже становится гораздо проще.

Continuous Integration и Continuous Delivery в GitOps

Эту схему многие devOps-ы прекрасно помнят. Это стандартная схема того, как происходит работа с Continuous Integration и Continuous Delivery в DevOps методологии. Единственное важное отличие здесь — Git, который является сердцем всего.

Как я уже говорил, все проходит через Git: все изменения, все pool requests — только через мерджи, только через Git. Любые изменения в environments вносятся так или иначе через Git.

Хорошей практикой при следовании методологии GitOps является то, что и у разработчиков, и у многих DevOps-ов в принципе может не быть доступа к Kubernetes и к остальным компонентам среды.

Стоит отметить, что когда мы говорим о GitOps, Kubernetes тоже очень часто подразумевается де-факто — потому что это удобно.

Почему на смену Jenkins пришел Jenkins X?

Почему мы не используем для GitOps старый, добрый, проверенный Jenkins? Почему его возможностей стало не хватать?

Первая проблема заключается в том, что изначально Jenkins очень трудно настроить. После того, как мы его установим, необходимо поставить нужные плагины, настроить пайплайны, подключить репозитории, настроить разные среды. Затем настоить деплойменты на эти среды, настроить хранение артефактов — Docker images, Helm образы и т.п. Настроить версионирование, которое тоже является важной частью и должно проходить автоматически. Набирается немало мелочей, на которых все базируется — из-за них на первоначальную настройку Jenkins тратится много времени.

Не факт, что эту же самую конфигурацию на Jenkins X удастся быстро поднять во второй раз. Возможно, Jenkins был настолько сложен и настолько нагружен, что поднять его тоже окажется тяжело.

Кроме того, что Jenkins сложен в изначальной настройке и его проблематично поднять заново, его еще и сложно держать в виде просто кода, без какого-либо ручного вмешательства.

Конечно, если вы опытный DevOps или работаете в команде, можно разворачивать это Helm пакетом или держать Jenkins Configuration as code, т.е. добиться того, что автоматизировано будет почти все. Но на это уходит много времени, которое можно потратить более продуктивно. Если существует уже готовое решение, то лучше воспользоваться им. Тем более, что большинство проектов — плюс-минус однотипные, и даже дефолтных настроек Jenkins X для них будет хватать за глаза. Jenkins X постарается отдать вам «из коробки» все, что только возможно. Хорошо это или плохо — не знаю, но это факт.

Еще один довод в пользу Jenkins X — его отказоустойчивость. Очевидно, что монолитное приложение, коим является Jenkins — это круто. Но встает вопрос о его надежности. При использовании Jenkins, если он на протяжении определенного времени не пересоздавался автоматически или вручную, если он уже нагружен и на нем уже хранится много артефактов, добавленных вручную, нам становится все страшнее его потерять. GitOps помогает решить эту проблему, и Jenkins X, как утилита GitOps, эту цель также преследует.

И последняя проблема с Jenkins — не самая важная, но тоже заслуживающая внимания. Jenkins — это достаточно старый монолит, со старой системой управления. С каждым годом в него все сложнее имплементировать новые фичи и все труднее сделать это так, чтобы не сломать в Jenkins что-то другое.

В Jenkins X c этим проще, и это круто. Однако, как мы с вами увидели, часть функционала в нем еще не работает — мы увидим это ниже, в разборе практического кейса. Тут пока счет 1:0 в пользу старого доброго Jenkins.

Как все устроено в Jenkins X?

У нас есть три уровня. Все крутится в Kubernetes. Это круто, интересно и масштабируемо.

Следующий уровень — это Jenkins X, который установлен на упомянутом Kubernetes. Jenkins X следит за тем, чтобы все, что мы установим на Git, было записано в кубах.

Третий уровень — это непосредственно Git, ключевой элемент и «сердце» проекта в GitOps. Здесь можно увидеть Jenkins файл, Helm пакет и Docker файл. Docker файлы нам нужны для того, чтобы подготавливать соответствующие Docker образы, которые будут в дальнейшем разворачиваться в Kubernetes. Helm пакет создается изначально и отвечает за то, чтобы доставлять наше ПО до кубов. Его можно разворачивать и на других кластерах, в зависимости от потребности — это достаточно гибкое и продуманное решение. Ну и, наконец, Jenkins файл, который говорит, что именно билдить, тестить и т.п.

Теперь перейдем к Jenkins X. Как я уже сказал, он следит за тем, чтобы информация, которая у нас была в Kubernetes, соответствовала тому, что декларировано в Git. Есть службы, которые отдельно следят за вебхуками, есть службы, которые проверяют версии, есть службы, которые контролируют, чтобы все было поднято. В общем, используются все механизмы Kubernetes по обеспечению стабильности и надежности.

Непосредственно в Kubernetes каждая версия — это отдельный namespace, со своей версией. Скажем, staging отличается от production на одну версию — думаю, вполне понятно, почему.

Внесение изменений

Разберемся, что происходит, когда мы добавляем какие-либо изменения.

Мы создаем проект, импортируем новый или вносим изменения. Все деплоится на stage. Система ожидает, пока мы создадим новую ветку в проекте, внесем какие-то изменения и сделаем pull request в master на этом приложении. Или можно использовать такую команду, как jx preview. Это очень крутая фича — уверен, она понравится большинству девелоперов, которые еще не знают о ней. В чем ее суть?

Мы внесли какие-либо изменения и, до того, как отправить их на stage и тем более на prod, было бы классно проверить, как это работает. Для этого и существует команда jx preview, которая развернет полную копию нашего environment, и мы сможем посмотреть вживую, как все работает. Поддерживается также работа со многими IDE, в частности, есть поддержка Visual Studio Code, так что можно прямо из IDE в пару кликов создать себе полную копию среды и посмотреть, как она работает.

Или же можно просто сделать pull request:

Нажимаем Compare pull request, проверяем, все ли нас устраивает, если да — жмем на Create pull request. На этом все, больше никаких действий не требуется. В истории Git осталась информация о том, что именно было добавлено в код. Скоро этот код попадет на stage.

Что происходит, когда мы проверили код и запулили его, смерджили с master-ом? Далее этот код упаковывается в helm пакет и деплоится на stage. Затем, когда в stage все проверено, прогнаны integration test и т.п., мы убедились в том, что нас все устраивает, мы можем залить это на production среду с помощью jx promote.

Общая теоретическая часть на этом завершена, но я хотел бы раскрыть еще несколько вопросов, которые возникают при работе с Jenkins X.

Как импортировать существующий Jenkins в проект?

Это можно сделать с помощью jx import. Это достаточно просто: существующий jenkins файл идеально подойдет для нового app, который у нас уже есть. У нас есть вкладка Code. По факту, это тот же самый декларативный pipeline, который мы используем и в обычном Jenkins — за исключением нескольких деталей, которые можно легко скопировать.

Можно ли прогнозировать, когда JX станет мейнстримом?

Я бы очень хотел, чтобы это уже произошло, потому что работать с ним действительно удобно. Видно, что его разработчики очень постарались. К сожалению, пока существует целый ряд багов, и они сильно тормозят распространение Jenkins X. Я надеюсь, что ему понадобиться примерно год, чтобы стать пригодным для регулярного использования в проектах.

Ну и не стоит забывать, что, хотя Jenkins X — программа очень крутая, GitOps не ограничивается им одним. Если JX не будет развиваться, другие подхватят эту эстафету, и мы, так или иначе, получим наш GitOps, и все будет проходить через Git. Уже сегодня через GitLab и подобные программы можно использовать пайплайны прямо там — и это очень близко к тому, чтобы называть это GitOps-ом.

Совместим ли Jenkins X с любой Git средой?

С Jenkins X можно использовать GitLab и, в принципе, любой Git. Jenkins X больше заточен под GitHub, но, тем не менее, везде, где можно создать токены и Git репозитории, он будет работать. Я надеюсь, в дальнейшем в нем появится более наглядная поддержка этого, но уже сейчас его можно использовать с любой Git средой. С Gerrit, я думаю, тоже.

Если Jenkins X еще сырой, то что можно использовать как GitOps, не считая самого Jenkins?

Можно использовать любые Git среды с нативной поддержкой пайплайнов, если нам не нужно будет что-либо вносить руками, т.е. чтобы весь код хранился на Git-е. К примеру, GitLab это все поддерживает. Мы можем настроить GitLab ci pipeline, который будет все выполнять. Придется немного с этим помучиться, но от этого мы не избавлены и в Jenkins X. В случае GitLab ci — это будет вполне себе GitOps.

С Azure pipeline я тоже сталкивался — они понравились мне даже меньше, чем GitLab, но, тем не менее, их тоже можно использовать. Пока что Jenkins мне импонирует больше всех, но, как я уже сказал, это не совсем GitOps, так что можно использовать или GitLab, или Azure pipeline. Об остальных я говорить не буду, т.к. я их не пробовал. Знаю, что GitHub тоже внедрил свои пайплайны, и даже у Gerrit что-то есть.

Еще один пример — Git от AWS. У них интегрировано почти все, и на нем тоже вполне можно использовать GitOps методологию.

При релизе новой версии Kubernetes справится ли Jenkins X с автообновлениями или это нужно будет делать вручную?

Kubernetes придется обновлять вручную. Или, если они обновляются в облаке — это все-таки не заточено под то, чтобы использовать это on demand, это больше облачный провайдер, а облачные провайдеры обновятся сами. Jenkins X, как и любое приложение на Kubernetes, либо справится с этим, либо нет, остается только молиться. Тут все в большей мере зависит от стабильности кубов, а не от Jenkins X. В случае JX — его можно обновить через консоль руками или настроить автообновление. Учитывая общую сырость проекта, я бы не рекомендовал обновлять его автоматически — здесь нужен взвешенный подход.

Для каких проектов Jenkins X был бы актуальным прямо сейчас, в том виде, в котором он существует в данный момент? И где его пока лучше не использовать?

Jenkins X лучше не использовать там, где важна стабильность — в банковской сфере, на крупных проектах или с нервными заказчиками. Но его вполне можно применять для внутренних проектов. Он идеален для небольших веб-сайтов. Jenkins X станет отличным решением для приложений на Scala или Python. На внутренние проекты зачастую не хочется тратить много времени, а JX как раз позволит разворачивать все просто и быстро. Но нужно иметь в виду, что придется потратить некоторое время на то, чтобы поставить и раздеплоить его в первый раз. Зато дальше все как по маслу.

Практический кейс: небольшое демо на Jenkins X

Перейдем к практической части:

Для управления Jenkins X есть очень полезная утилита, которая называется JX. Я рекомендую зайти на официальный сайт и ознакомиться с howto — там много подробных мануалов, описаний того, как работает Jenkins X и как работает JX в частности, есть подробный help, так что пользоваться этим очень комфортно.

Jenkins X — еще достаточно сырой продукт, некоторые функции у него еще недостаточно реализованы. На момент подготовки материала, я столкнулся с ошибкой, и эта проблема — создание сервера на MiniKube. Это можно понять — вероятно, немногие используют MiniKube, мало кто тестирует на том, и это не настолько критично, чтобы фиксить это немедленно. Мне пришлось искать решение, на GitHub у нас есть заведенная issue. Мне выделили AWS аккаунт для того, чтобы можно было развернуть все на нем, и, увы, на AWS тоже есть проблема с созданием сервера на MiniKube. В данный момент там кластер не создается. Мне выделили AWS аккаунт для того, чтобы можно было развернуть все на нем, и, увы, на AWS тоже есть проблема с созданием сервера на MiniKube. В данный момент там кластер не создается.

Прошу обратить внимание, что в демо используется skaffold — это отдельная утилита от Google, которая позволяет автоматизировать развертывание приложения. Интегрируется с огромным количеством сторонних приложенией типа Helm, Kaniko и т.д. В общем, очень крутая утилита, которая заслуживает отдельной презентации.

Может возникнуть вопрос — соответствуют ли brunch и master проду? Каждый репозиторий является независимым. У нас три отдельных репозитория: production, staging и myapp — для нашего приложения. В каждом из них есть master, и он соответствует тому, что развернуто нами в Kubernetes, в соответствующем namespace. Но здесь нет деления на dev, prod и т.п.

При работе с Jenkins X всегда нужно учитывать, что первый билд проходит долго, с этим ничего не поделаешь.

В завершение статьи еще раз акцентирую внимание читателей на том, что, хотя Jenkins X пока еще не готов для использования на крупных проектах, это — олицетворение подхода GitOps, который уже сейчас приходит на смену привычному нам DevOps. Поэтому начинать разбираться и работать с Jenkins X стоит уже сейчас.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ненавижу Jenkins. Давно пора на помойку его выкинуть.

Что именно не нравится?
Альтернативы?

Их туча, gitlab, circle, bitbucket, github actions и иже с ними.

Названные средства не являются просто отдельным организатором действий (Jenkins позволяет, например, использовать его как крон с мордой — и это реально используется).

Причины вы так и не назвали. Повторяю вопрос.

Любой другой CI умеет так же, в чем вопрос?

в чем вопрос?

Причина ненависти именно к Jenkins?

Перевага Jenkins X над Gitlab CI в тому що він може окрему гілку задеплоїти в кубернетіс, а з Gitlab CI доведеться це самому писати в скріпті?

Працюю з гітлаб CI. Кожна гілка проекту автоматом деплоїться в кубер в окремий неймспейс (превю енв). Описано це в пайплайні. Гадаю що в jenkinsX теж щось таке треба буде описати

Подписаться на комментарии