Максим Штернберг
Senior DevOps Engineer (AWS)
Раніше я довго працював адміном. Адмінський підхід до організації роботи виглядає так: у нас є певний сервер, у нас є певний адмін, який колись давним-давно його налаштовував, і, поки сервер не ламається, його краще не чіпати, тому що ніхто не знає, ким, коли і як саме він був налаштований.
Cаме відмова від цієї концепції мотивувала мене перейти в 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 теж дуже часто мається на увазі де-факто – тому що це зручно.
ЛАЙФХАКИ ДЛЯ РОБОТИ З CLOUDFORMATION
Чому на зміну 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.
Чи справиться з автооновленнями Jenkins X при випуску нової версії Kubernetes?
Kubernetes доведеться оновлювати вручну. Або, якщо вони оновляються в хмарі – це все-таки не заточено під те, щоб використовувати це one demand, це більше хмарний провайдер, а вони овлюються самі. Jenkins X, як і будь-який додаток на Kubernetes, або справиться з цим, або ні, залишається лише молитися. Тут все залежить від стабільності кубових, а не від Jenkins X. У випадку JX його можна оновити руками через консоль або налаштувати автооновлення. Враховуючи загальну сирість проєкту, я б не рекомендував оновлювати його автоматично.
Для яких проєктів Jenkins X був би актуальним зараз в його теперішньому вигляді. Коли його краще не використовувати?
Jenkins X краще не використовувати там, де важлива стабільність – у банківській сфері, на найбільших проєктах або з нервовими замовниками. Але його сповна можна застосовувати для внутрішніх проєктів. Він ідеально підходить для невеликих вебсайтів. Jenkins X стане відмінним рішенням для додатків на Scala або Python. На внутрішніх проєктах часто не хочеться витрачати багато часу, а JX якраз дозволить розгортати все просто і швидко. Але потрібно мати на увазі, що доведеться витратити час на те, щоб спершу поставити і задеплоїти його. Зате далі цсе буде, як по маслу.
Практичний кейс: невеличке демо на Jenkins X
Для управління Jenkins X існує дуже корисна утиліта, яка називається JX. Я рекомендую зайти на офіційний сайт і ознайомитись з інструкціями. Там багато детальних мануалів, описів, як працює Jenkins X і як працює JX, зокрема, є детальна довідка, так що користуватися цим дуже комфортно.
Jenkins X – ще досить сирий продукт, деякі функції у нього ще недостатньо реалізовані. На момент підготовки матеріалу, я зіткнувся з помилкою, і ця проблема – створення сервера на MiniKube. Це можна зрозуміти, ймовірно, мало хто використовує MiniKube, мало хто тестує на цьому, і це не настільки критично, щоб виправляти це негайно. Мені довелося шукати рішення. На GitHub у нас заведена issue. Мені виділили 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 варто вже зараз.
