Jenkins чи ArgoCD? Обираємо оптимальну CI/CD-систему разом

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт! Ми — Володимир Стеценко та Володимир Стародубов, DevOps-інженери компанії Alpacked з багаторічним досвідом роботи у сфері автоматизації. Кожен із нас має свій унікальний підхід до налаштування CI/CD-процесів, і сьогодні ми хочемо поділитися з вами своїми спостереженнями та рекомендаціями щодо цього.

Одна з найчастіших дилем, з якими зіштовхуються компанії під час автоматизації — вибір оптимальної CI/CD-системи. Jenkins та ArgoCD є одними з найпопулярніших інструментів, і часто клієнти звертаються до нас з питаннями саме щодо цього. Як зробити правильний вибір? Чим ці системи відрізняються, і яка підійде для вашого проєкту?

Тож у цій статті ми розберемо:

— Підхід та роль у CI/CD
— Гнучкість встановлення
— Масштабування
— Безпека
— Інтеграція з популярними системами оркестрації контейнерів
— Плагіни/застосунки
— Відновлення після збоїв/вимикання
— Вартість володіння та навчання

Підхід і роль у CI/CD

ArgoCD — це досить сучасний інструмент, який допомагає автоматизувати процеси Continuous Delivery в Kubernetes. ArgoCD відповідає за розгортання застосунків, автоматично синхронізуючи стан кластера з бажаним станом, описаним у Git-репозиторії. Цей підхід спрощує процес розробки та зменшує складність підтримки інфраструктури. У ролі Continuous Integration можна використовувати будь-який зручний для ситуації хмарний (та не дуже) інструмент. Наприклад, GitHub Actions, Bitbucket Pipelines, Travis або GitLab CI, що забезпечує гнучкість у виборі оптимального рішення.

Щодо Jenkins. Це не просто інструмент для автоматизації, це ціла екосистема для будь-яких потреб команди чи продукту. З ним можна побудувати повний CI/CD-процес, що безперервно інтегрує зміни, автоматично запускає тести, генерує артефакти та розгортає застосунки в будь-яке середовище. І хоча Jenkins це універсальний «швейцарський ніж», він вимагає ретельного налаштування та підтримки.

Подейкують, що Jenkins — це про те, щоб руками обирати гілки та деплоїти їх. Але це тільки вершина айсберга. Jenkins — набагато більше. З його допомогою можна створити повноцінний GitOps-підхід, який дає змогу підтримувати оновлення конфігурацій у реальному часі, завдяки чому будь-які зміни в репозиторії автоматично розгортаються в потрібні середовища.

Гнучкість встановлення

Як у відомій загадці про два стільці, так і у Jenkins — є два популярні варіанти деплою: класичний підхід на віртуальних машинах або сучасний Kubernetes.

Jenkins можна розкласти на дві частини: Master та Agent. Master оркеструє процеси CI/CD, а агенти виконують білд-джоби, що допомагає динамічно масштабувати ресурси під навантаження. Як це зобразити:

Jenkins настільки гнучкий, що варіантів його установки безліч. Ось деякі з них:

Один інстанс, на якому є все

Один EC2 інстанс може виконувати роль як мастера, так і агентів. Це підходить навіть для великої команди. Важливо тільки регулярно очищати місце на диску, щоб не отримувати «no space left on device» (так, очищати Jenkins від Docker-образів час від часу необхідно).

Один інстанс для Master та N-інстансів з Agents

EC2 Fleet плагін дозволяє Jenkins динамічно створювати агенти на спотових інстансах, що знижує витрати та забезпечує масштабування.

Один інстанс для Master та N-pod з Agents

Якщо у вас є кластер, підключення Kubernetes плагіна дозволяє динамічно створювати агентів на worker-нодах.

Один Pod для Master та N-pod з Agents

Але якщо ви за тотальну кубернізацію, тоді можна встановити Jenkins через helm, та забути про EC2.

Вибір між EC2 та Kubernetes залежить від потреб у гнучкості й готовності інвестувати в інфраструктуру. Якщо потрібна стабільність, EC2 — надійний варіант. Але якщо в пріоритеті автоматизація і масштабування, Kubernetes виглядає логічним вибором.

P.S. Jenkins на EC2, що ніколи не перезавантажується, важко чимось зламати! :D

ArgoCD працює безпосередньо як частина Kubernetes. Це дає змогу легко розгортати його в кластері за допомогою Helm, Kustomize, або взагалі простим kubectl apply. Що дозволяє досить швидко перейти до процесу розгортання будь-яких ресурсів всередині, на відміну від Jenkins, який за цей час буде тільки розігріватись.

Масштабування

ArgoCD дуже добре масштабується завдяки своїй архітектурі. Більшість маніфестів, які створює Argo, є безпосередньо частиною Kubernetes, завдяки чому можна досить легко та швидко збільшувати кількість replicas у кластері. Для надійності та швидкодії використовується Redis (як комплектний, так і зовнішній), що дозволяє Argo працювати з багатьма кластерами, не викликаючи заторів між різними застосунками у різних кластерах. Так, Argo може працювати не тільки зі своїм рідненьким кластером, а й з будь-яким, до якого зможе дотягнутись.

Якщо плавно переходити на масштабність, згадуючи, що Jenkins складається з Master та Agent компонентів, то можна виділити наступне.

Jenkins легко масштабується, особливо коли мова йде про агентів, які можна додавати або видаляти залежно від навантаження. Однак Master, як правило, залишається «вузьким місцем». Розподілене середовище з кількома Master — завдання не з простих, оскільки реалізації HA для Master часто працюють у режимі Active-Passive, де один Master чекає на випадок збою іншого.

Підключення Jenkins до Kubernetes відкриває нові можливості масштабування, як-то можливість запускати білди на worker-нодах, обирати відповідну архітектуру (наприклад, x86 чи ARM64), чи максимально використовувати ресурси кластера.

Безпека

Безпека в Jenkins — це більше, ніж логін і пароль. Це багаторівнева автентифікація, управління правами доступу, збереження секретів та контроль ролей, що працює в комплексі для захисту системи від зовнішніх загроз.

Можна виділити наступні ключові моменти:

1. Автентифікація
   Jenkins підтримує як внутрішні облікові записи, так і інтеграції з зовнішніми сервісами, як-от LDAP, OIDC, SAML, чи навіть GitHub. Це гарантує, що в систему потрапляють лише перевірені користувачі.
2. Авторизація через ролі
   Дотримання принципу найменших привілеїв значно знижує ризик несанкціонованих змін. Розробники мають доступ лише до своїх проєктів, без можливості переглядати або змінювати інші частини CI/CD-середовища.
3. Захист секретів
   Чутливі дані можна зберігати у внутрішньому менеджері або інтегрувати зовнішні сервіси на кшталт AWS Secrets Manager.
4. Безпека плагінів
   Краще за все використовувати лише офіційні плагіни з Plugin Manager та регулярно їх оновлювати. Ненадійні плагіни — це відкриті двері для потенційних вразливостей.

Не дотягуйте свій Jenkins до такого, та вчасно оновлюйте його, щоб пофіксити максимальну кількість вразливостей.

Продовжуючи тему з масштабованістю й ArgoCD, він досить непогано себе почуває і на самоті, у повністю приватному кластері (але достукатись до git-репозиторію йому однаково потрібно, якщо контролюєте й egress-трафік). А доступ всередину (ви ж відключаєте admin юзера після першого запуску, чи не так?) налаштовується через RBAC policy, який може інтегруватись з будь-яким зручним SSO-провайдером завдяки Dex.

Інтеграція з популярними системами оркестрації контейнерів

ArgoCD це Kubernetes-native інструмент, тому він підлаштований під все, що працює як Kubernetes. Як, наприклад, OpenShift або Rancher. Але загалом ніякої Docker оркестрації на домашньому комп’ютері не вийде.

Jenkins, своєю чергою, чудово працює з основними платформами оркестрації, як-от Kubernetes, Docker Swarm, OpenShift, Rancher, Nomad, та багато іншого.

Через плагін Kubernetes динамічно створюються тимчасові агенти для білдів. З Docker Swarm автоматично керуються розподілення контейнерів між нодами. Для OpenShift деплой через ImageStreams та автоматичне створення середовища під кожен комміт.

Якщо існує щось значуще у світі оркестрації контейнерів, Jenkins уже вміє з цим взаємодіяти. Його універсальність дає змогу без зайвих труднощів під’єднати потрібну платформу та зробити її частиною CI/CD-процесу, адаптуючись під специфічні вимоги команди.

Ось вам для настрою Jenkins Worker pod:

Плагіни/застосунки

Справжня сила Jenkins розкривається завдяки плагінам, які дозволяють розширювати функціональність та інтегруватися з різними сервісами.

Зайшовши в Plugin Index, можна натрапити на вражаюче число — понад 1900 плагінів. І так, не всі вони ідеально працюють з новими версіями, але, погодьтеся, 1900+ застосунків — це щось!

Можна знайти як найпопулярніші плагіни, як-то Pipeline, Kubernetes, Docker, Git, Slack, Jira, так і тонну непотрібних для AWS SDK. Що цікаво, плагінів для CDK — немає 🤡

Якщо не знайшли потрібний плагін, не засмучуйтесь — ви завжди можете створити його самостійно. І це не так складно, як здається, особливо коли є вільний доступ до ChatGPT.

З досвіду можемо сказати, що для 99% завдань із Jenkins вистачить наявних плагінів, і більшість із них регулярно оновлюються та підтримуються. І, чесно кажучи, ми б не радили обмазувати Jenkins великою кількістю плагінів, і ось чому: оновлення одного з них може легко спричинити проблеми з іншими. Це класика: оновлюєш застарілий плагін — і раптом десятки інших починають конфліктувати. Те ж саме може трапитись і при увімкненому автооновленні плагінів.

Щодо ArgoCD. Тут маємо класичний джентльменський набір у вигляді Helm та Kustomize, а також ArgoCD досить легко розширюється за допомогою системи Config Management Plugins (CMP), яка може під’єднуватись до основного pod у ролі sidecar. Ви можете написати власний плагін або використовувати готові від спільноти. Але знайти їх складніше ніж в Jenkins, оскільки немає централізованого хабу.

Відновлення після збоїв/вимикання

ArgoCD має механізми відновлення після збоїв. Наприклад, ви можете легко зробити rollback змін в Git і ArgoCD автоматично синхронізує кластер до попереднього стану. Це робить процес відновлення дуже зрозумілим навіть для тих, хто не має доступу до кластера.

Крім того, ArgoCD підтримує зберігання історії змін конфігурацій (але тільки якщо ви використовуєте єдине джерело для Argo Application), що дає змогу детально відстежувати всі зміни та забезпечувати стабільність системи. Кожна зміна має свою історію, завдяки чому розробники та адміністратори можуть легко знайти й виправити проблему. Якщо виникає помилка, можна швидко повернути інфраструктуру до попередньої стабільної версії, мінімізуючи простої й зменшуючи ризик втрат даних.

Ну що ж, хіба можна говорити про Jenkins і не згадати про бекапи? Ніколи не знаєш, коли Jenkins вирішить «впасти» і прихопити з собою твої улюблені джоби. Але не хвилюйтесь: відновлення з бекапу простіше, ніж здається — якщо тільки не переборщити з плагінами.

Для резервного копіювання Jenkins є два основні підходи, які залежать від того, де ви розгорнули свій Jenkins:

• EBS volume snapshot: зберігають всю систему в момент часу, дозволяючи легко повернутися до попереднього стану.
• Резервні копії на EFS: зручний варіант для постійного зберігання конфігурацій Jenkins, хоча іноді потребує додаткових налаштувань, але для куберу — маст хев.

На що звернути увагу:

1. Плагіни. Деякі плагіни можуть створити непередбачувані проблеми під час відновлення: вони раптом починають конфліктувати або заважати один одному, навіть якщо раніше працювали коректно.
2. Регулярні бекапи. Автоматичний бекап хоча б раз на день заощадить час та нерви. І навіть якщо система здається ідеальною, тестуйте відновлення, оскільки несподіванки трапляються часто.
3. Документація процесу. Покрокова інструкція для відновлення допоможе згадати, як це правильно робити, щоб нічого ненароком не зіпсувати.
4. Автоматизація відновлення. Щоб відновлювати Jenkins швидше, можна автоматизувати цей процес. Наприклад, у нас на одному проєкті було налаштовано Lambda-функцію, яка брала останній EBS снепшот, створювала AMI, підіймала інстанс з Jenkins та оновлювала запис у Route 53.

Загалом, якщо у вас під рукою є регулярні резервні копії та ви уникаєте конфліктних плагінів, відновлення Jenkins стає передбачуваним процесом. Дотримуйтесь регулярних бекапів і час від часу тестуйте їх. Так навіть у разі збою ви зможете швидко повернути систему до роботи.

Вартість володіння та навчання

Знання Jenkins не входить до «базового набору» DevOps-інженера. Це швидше навичка, здобута на практиці — коли все працює чудово... Поки не трапляється перший серйозний збій. Jenkins справді може стати викликом: тисячі плагінів, Groovy-скрипти, конфігурація Master-ноди та управління агентами. Здається, він вміє все, але й вимагає постійної уваги.

Кожен новий плагін трохи підвищує рівень технічного боргу, а підтримка системи стає складнішою з часом, особливо якщо плагіни починають конфліктувати. Jenkins потребує регулярних оновлень, моніторингу безпеки та налаштування доступів. Головна проблема — захист, бо застарілі плагіни або невдала конфігурація легко створюють слабкі місця.

Якщо у вас є інженер, який розбирається у Kubernetes, то загалом ArgoCD відповідає принципу «easy to learn — hard to master». Його можна легко впровадити та швидко почати використовувати для автоматизації розгортання. Проте для того, щоб використовувати всі можливості цього інструменту, необхідно глибше розуміння Kubernetes та GitOps. ArgoCD інтегрується з Kubernetes на багатьох рівнях, тому базові знання цієї платформи є обов’язковими для ефективної роботи.

То яку ж систему краще обрати

Отже, Jenkins має високий поріг входу, але тим, хто готовий пройти всі випробування, він дарує величезну силу для CI/CD-процесів. Jenkins підходить тим, хто готовий зануритися в його можливості й навчитися працювати з цим потужним, але непростим інструментом автоматизації.

На противагу йому ArgoCD — досить непоганий інструмент, якщо ви використовуєте в якості CI щось вже готове. Але він не може покрити весь цикл CI/CD повністю, особливо якщо ви не збираєтесь розгортати Kubernetes. Він є більш спеціалізованим, ніж Jenkins, тому його й простіше опанувати та підтримувати невеликій команді інженерів. Обираючи між Jenkins та ArgoCD, важливо орієнтуватися на специфічні потреби вашого проєкту та команди, важливо зважити всі «за» та «проти».

А що думаєте ви? Поділіться своєю думкою в коментарях — який інструмент, на вашу думку, кращий для CI/CD, Jenkins чи ArgoCD?