Прим. перев.: Після недавньої публікації про методи pull і push у GitOps ми побачили інтерес до цієї моделі в цілому, проте російськомовних публікацій на цю тему виявилося зовсім мало (на хабрі їх просто немає). Тому раді запропонувати вашій увазі переклад іншої статті — нехай уже майже річної давності! — від компанії Weaveworks, голова якої вигадала термін «GitOps». У тексті пояснюється суть підходу та ключові відмінності від існуючих.
Рік тому ми опублікували . Тоді ми розповіли, як команда Weaveworks запустила SaaS, повністю засновану на Kubernetes, та розробила набір наказуючих кращих практик для розгортання, управління та моніторингу у середовищі cloud native.
Стаття виявилася популярною. Інші люди заговорили про GitOps, стали публікувати нові інструменти для , , , , і т.п. На нашому сайті з'явилося публікацій та варіантів використання GitOps. Але в деяких людей все ж таки залишилися питання. Чим модель відрізняється від традиційної та безперервного постачання ()? Чи обов'язково використовувати Kubernetes?
Незабаром ми зрозуміли, що потрібний новий опис, що пропонує:
- Велика кількість прикладів та історій;
- Конкретне визначення GitOps;
- Порівняння з традиційною continuous delivery.
У цій статті ми спробували охопити усі ці теми. У ній ви знайдете оновлене введення в GitOps та погляд на нього з боку розробників та CI/CD. Ми переважно орієнтуємося на Kubernetes, хоча модель цілком можна узагальнити.
Знайомтесь: GitOps
Уявіть Алісу. Вона управляє компанією Family Insurance, що пропонує поліси зі страхування здоров'я, автомобілів, нерухомості та туристичну страховку людям, які надто зайняті, щоб розбиратися в нюансах контрактів самостійно. Її бізнес починався як сторонній проект, коли Аліса працювала у банку як data scientist. Якось вона зрозуміла, що може використовувати передові комп'ютерні алгоритми для більш ефективного аналізу даних та формування страхових пакетів. Інвестори профінансували проект, і тепер її компанія приносить понад 20 млн. доларів на рік і стрімко зростає. На даний момент у ній на різних посадах працюють 180 осіб. У тому числі технологічна команда, яка займається розробкою, обслуговуванням сайту, бази даних та аналізом клієнтської бази. Команду із 60 осіб очолює Боб – технічний директор компанії.
Команда Боба розгортає production-системи у хмарі. Їхні основні програми працюють на GKE, користуючись перевагами Kubernetes у Google Cloud. Крім того, вони використовують у роботі різні інструменти для роботи з даними та аналітики.
Family Insurance не збиралася використовувати контейнери, але заразилася ентузіазмом довкола Docker. Незабаром фахівці компанії виявили, що GKE дозволяє розгортати кластери для тестування нових функцій легко та невимушено. Були додані Jenkins для CI та Quay для організації реєстру контейнерів, написані скрипти для Jenkins, які push'или нові контейнери та конфігурації у GKE.
Пройшов деякий час. Аліса та Боб розчарувалися у продуктивності обраного підходу та його впливі на бізнес. Використання контейнерів не підвищило продуктивність настільки, наскільки сподівалася команда. Іноді deployment'и ламалися, і було незрозуміло, чи винні у цьому зміни коду. Також було важко відслідковувати зміни конфігів. Часто доводилося створювати новий кластер і переміщати до нього програми, оскільки так було найпростіше ліквідувати той бардак, на який перетворилася система. Аліса боялася, що ситуація погіршиться у міру розвитку програми (крім того, назрівав новий проект на основі машинного навчання). Боб автоматизував більшу частину роботи і не розумів, чому пайплайн, як і раніше, нестійкий, погано масштабується і періодично потребує ручного втручання?
Потім вони довідалися про GitOps. Це рішення виявилося саме тим, що їм було потрібне для впевненого руху вперед.
Аліса та Боб вже не один рік чули про робочі процеси на основі Git, DevOps та infrastructure as code. Унікальність GitOps у тому, що він привносить низку кращих практик — категоричних та нормативних — щодо реалізації цих ідей у контексті Kubernetes. Ця тема , у тому числі і в .
Family Insurance вирішує запровадити GitOps. Тепер компанія має автоматизовану модель експлуатації, сумісну з Kubernetes і поєднує швидкість зі стабільністю, оскільки вони:
- виявили, що у команди вдвічі зросла продуктивність і ніхто при цьому не божеволіє;
- перестали обслуговувати скрипти. Натомість тепер вони можуть концентруватися на нових функціях та вдосконалювати інженерні методи — наприклад, впровадити канаркові викати та покращити тестування;
- удосконалили процес розгортання – тепер він рідко ламається;
- отримали можливість відновлювати deployment'и після часткових збоїв без ручного втручання;
- придбали бобільшу впевненість у системах постачання. Аліса та Боб виявили, що можна розділити команду на групи, що займаються мікросервісами та працюють паралельно;
- можуть вносити по 30-50 змін до проекту щодня зусиллями кожної групи та пробувати нові техніки;
- легко залучають до проекту нових розробників, які мають можливість накочувати оновлення на production за допомогою pull request'ів вже за кілька годин;
- легко проходять аудит у рамках SOC2 (на відповідність постачальників послуг вимогам щодо безпечного управління даними; докладніше читайте, наприклад, - прим. перев.).
Що сталося?
GitOps – це дві речі:
- Модель експлуатації для Kubernetes та cloud native. Вона надає набір кращих практик для розгортання, управління та моніторингу зібраних у контейнери кластерів та додатків. Елегантне визначення у вигляді від :
- Шлях до створення орієнтованого на розробників оточення для управління програмами. Ми застосовуємо робочий процес Git як до експлуатації, так і розробки. Зверніть увагу, що йдеться не просто про Git push, а про організацію всього набору інструментів CI/CD та UI/UX.
Пара слів про Git
Якщо ви не знайомі з системами контролю версій і заснованим на Git робочим процесом, ми рекомендуємо вивчити їх. Спочатку робота з гілками та pull request'ами може здатися чорною магією, але плюси коштують витрачених зусиль. Ось для початку.
Як працює Kubernetes
У нашій історії Аліса та Боб звернулися до GitOps, якийсь час пропрацювавши з Kubernetes. Дійсно, GitOps тісно пов'язаний з Kubernetes - це модель експлуатації для інфраструктури та програм, заснованих на Kubernetes.
Що Kubernetes дає користувачам?
Ось деякі основні можливості:
- У моделі Kubernetes все можна описувати у декларативній формі.
- API-сервер Kubernetes приймає таку декларацію як вступні дані, а потім постійно намагається привести кластер у стан, описаний у декларації.
- Декларації достатні для опису та управління великою різноманітністю робочих навантажень – «додатків».
- В результаті, внесення змін до додатку та кластеру відбувається через:
- змін у образах контейнерів;
- змін до декларативної специфікації;
- помилок у середовищі - наприклад, падіння контейнерів.
Прекрасні здібності Kubernetes за конвергенцією
Коли адміністратор вносить зміни до конфігурації, оркестратор Kubernetes буде застосовувати їх до кластера, поки його стан не наблизиться до нової конфігурації. Ця модель працює для будь-якого ресурсу Kubernetes та розширюється за допомогою Custom Resource Definitions (CRDs). Тому deployment'и Kubernetes мають наступні чудові властивості:
- Автоматизація: оновлення Kubernetes надають механізм для автоматизації процесу застосування змін коректно та своєчасно.
- Конвергенція: Kubernetes продовжуватиме спроби оновлень до досягнення успіху
- ідемпотентність: повторні застосування конвергенції призводять до результату.
- детермінізм: при достатності ресурсів стан оновленого кластера залежить лише від бажаного стану.
Як працює GitOps
Ми довідалися про Kubernetes, щоб пояснити принципи роботи GitOps.
Повернімося до команд Family Insurance, пов'язаних з мікросервісами. Чим їм зазвичай доводиться займатись? Подивіться на перелік нижче (якщо якісь пункти в ньому видадуться дивними чи незнайомими — будь ласка, почекайте з критикою і залишайтеся з нами). Це лише приклади робочих процесів на основі Jenkins. Існує і безліч інших процесів під час роботи з іншими інструментами.
Головне — бачимо, що кожне оновлення закінчується внесенням змін до конфігураційних файлів і репозиторії Git. Ці зміни в Git призводять до того, що «оператор GitOps» оновлює кластер:
1. Робочий процес: «Складання Jenkins - гілка master».
Список завдань:
- Jenkins push'іт теговані образи у Quay;
- Jenkins push'іт конфіг та Helm-чарти у бакет master-сховища;
- Хмарна функція копіює конфіг та чарти з бакета master-сховища в Git-репозиторій master;
- Оператор GitOps оновлює кластер.
2. Складання Jenkins - гілка release або hotfix:
- Jenkins push'іт нетеговані образи у Quay;
- Jenkins push'іт конфіг та Helm-чарти у бакет staging-сховища;
- Хмарна функція копіює конфіг та чарти з бакета staging-сховища у Git-репозиторій staging;
- Оператор GitOps оновлює кластер.
3. Складання Jenkins - гілка develop або feature:
- Jenkins push'іт нетеговані образи у Quay;
- Jenkins push'іт конфіг та Helm-чарти у бакет develop-сховища;
- Хмарна функція копіює конфіг та чарти з бакета develop-сховища у Git-репозиторій develop;
- Оператор GitOps оновлює кластер.
4. Додавання нового клієнта:
- Менеджер або адміністратор (LCM/ops) викликає Gradle для початкового розгортання та налаштування мережевих балансувальників навантаження (NLB);
- LCM/ops комітить новий конфіг для підготовки deployment'а до оновлень;
- Оператор GitOps оновлює кластер.
Короткий опис GitOps
- Опишіть бажаний стан усієї системи, використовуючи декларативні специфікації для кожного оточення (у нашій історії команда Боба визначає всю конфігурацію системи у Git).
- Git-репозиторій є єдиним джерелом істини щодо бажаного стану всієї системи.
- Усі зміни у бажаний стан здійснюються шляхом коммітів у Git.
- Усі бажані параметри кластера також спостерігаються у самому кластері. Таким чином ми можемо визначити, збігаються (конвергують, сходяться) або відрізняються (дивергують, розходяться) бажаний і спостережуваний стан.
- Якщо бажаний і спостережуваний стан відрізняються, то:
- Існує механізм конвергенції, який рано чи пізно автоматично синхронізує цільовий та спостережуваний стан. Усередині кластера цим займається Kubernetes.
- Процес запускається негайно з оповіщенням "change committed".
- Через деякий проміжок часу, що настроюється, може бути надіслано оповіщення «diff», якщо стани відрізняються.
- Таким чином, всі комміти в Git викликають перевірки та ідемпотентні оновлення в кластері.
- Відкат - це конвергенція до раніше бажаного стану.
- Конвергенція є остаточною. Про її настання свідчать:
- Відсутність оповіщень diff протягом певного проміжку часу.
- Оповіщення "converged" (наприклад, webhook, подія Git writeback).
Що таке дивергенція?
Повторимо ще раз: всі бажані властивості кластера повинні бути спостерігаються в самому кластері.
Декілька прикладів дивергенції:
- Зміна у файлі конфігурації через злиття гілок Git.
- Зміна у файлі конфігурації через коміт у Git, зроблений GUI-клієнтом.
- Множинні зміни у бажаному стані через PR у Git з подальшим складанням образу контейнера та змінами конфігу.
- Зміна стану кластера через помилку, конфлікт ресурсів, що призводить до «поганої поведінки», або просто випадкового відхилення від оригінального стану.
Що таке механізм конвергенції?
Кілька прикладів:
- Для контейнерів та кластерів механізм конвергенції надає Kubernetes.
- Той самий механізм можна використовувати для керування додатками та конструкціями на основі Kubernetes (наприклад, Istio та Kubeflow).
- Механізм для управління робочою взаємодією між Kubernetes, репозиторіями образів та Git'ом надає , що є частиною .
- Для базових машин механізм конвергенції має бути декларативним та автономним. За своїм досвідом можемо сказати, що найближче до цього визначення, проте потребує контролю з боку людини. У цьому сенсі GitOps розширює традиції Infrastructure as Code.
GitOps поєднує Git із чудовим механізмом конвергенції Kubernetes, пропонуючи модель для експлуатації.
GitOps дозволяє нам заявити: автоматизації та контролю піддаються тільки ті системи, які можна описувати та спостерігати.
GitOps призначений для всього cloud native-стеку (наприклад, Terraform і т.п.)
GitOps – це не тільки Kubernetes. Ми хочемо, щоб вся система керувалася декларативно та використовувала конвергенцію. Під усією системою ми маємо на увазі сукупність середовищ, що працюють з Kubernetes — наприклад, «dev cluster 1», «production» і т.п. т.п.
Зверніть увагу, наскільки в даному випадку Terraform важливий для проблеми bootstrapping'а. Kubernetes має бути десь розгорнутий, і використання Terraform означає, що ми можемо застосувати ті самі робочі процеси GitOps для створення керуючого шару, що лежить в основі Kubernetes та додатків. Це корисна найкраща практика.
Велика увага приділяється застосуванню концепцій GitOps до шарів над Kubernetes. На даний момент є рішення GitOps-типу для Istio, Helm, Ksonnet, OpenFaaS і Kubeflow, а також для Pulumi, що створюють шар для розробки додатків під cloud native.
Kubernetes CI/CD: порівняння GitOps з іншими підходами
Як говорилося, GitOps – це дві речі:
- Модель експлуатації для Kubernetes та cloud native, описана вище.
- Шлях до організації орієнтованої на розробників середовища для управління програмами.
Для багатьох GitOps — це насамперед робочий процес на основі Git push'ів. Нам він також подобається. Але це не все: тепер подивимося на CI/CD-пайплайни.
GitOps забезпечує безперервне розгортання (CD) під Kubernetes
GitOps пропонує механізм безперервного розгортання, що усуває потребу в окремих «системах управління розгортаннями». Всю роботу за вас виконує Kubernetes.
- Оновлення програми потребує оновлення в Git'і. Це транзакційне оновлення до бажаного стану. "Розгортання" потім здійснюється всередині кластера самим Kubernetes на основі оновленого опису.
- Через специфіку роботи Kubernetes ці оновлення конвергентні. Так забезпечується механізм для безперервного розгортання, де всі оновлення атомарні.
- Примітка: пропонує GitOps-оператор, що інтегрує Git та Kubernetes і дозволяє виконувати CD шляхом узгодження бажаного та поточного стану кластера.
Без kubectl та скриптів
Слід уникати використання Kubectl для оновлення кластера, а особливо скриптів для групування команд kubectl. Натомість, за допомогою GitOps-пайплайну користувач може оновити свій кластер Kubernetes через Git.
Переваги включають:
- правильність. Групу оновлень можна застосувати, конвергувати та нарешті валідувати, що наближає нас до мети атомарного розгортання. Навпаки, використання скриптів не дає жодних гарантій конвергенції (докладніше звідси нижче).
- Безпека. Kelsey Hightower: «Обмежте доступ до кластера Kubernetes інструментам автоматизації та адміністраторам, в обов'язки яких входить його налагодження або підтримка працездатності». Див. також про безпеку та відповідність технічним умовам, а також шляхом розкрадання облікових даних з недбало складеного Jenkins-скрипту.
- Призначений для користувача досвід. Kubectl оголює механіку об'єктної моделі Kubernetes, яка дуже складна. В ідеалі користувачі повинні взаємодіяти із системою на вищому рівні абстракції. Тут я знову пошлюся на Kelsey і рекомендую подивитися .
Різниця між CI та CD
GitOps покращує існуючі CI/CD-моделі.
Сучасний CI-сервер є інструментом для оркестрації. Зокрема, це інструмент для оркестрації CI-пайплайнів. Вони включають build, test, merge to trunk і т. д. CI-сервери автоматизують управління складними багатокроковими пайплайнами. Поширена спокуса полягає в тому, щоб створити скрипт для набору оновлень Kubernetes і виконати його як елемент пайплайну для push'а змін до кластера. Справді, так роблять багато фахівців. Однак це неоптимально, і ось чому.
CI повинна використовуватися для внесення оновлень у trunk, а кластер Kubernetes повинен змінювати себе на основі цих оновлень, щоб керувати CD внутрішньо. Ми називаємо це на відміну від CI push-моделі. CD є частиною runtime-оркестрації.
Чому CI-сервери не повинні робити CD через прямі оновлення в Kubernetes
Не використовуйте CI-сервер для оркестрації прямих оновлень у Kubernetes у вигляді набору CI-завдань. Це анти-патерн, про який ми у своєму блозі.
Повернімося до Аліси і Боба.
З якими проблемами вони зіткнулися? CI-сервер Боба застосовує зміни до кластера, але якщо в процесі він впаде, Боб не знатиме, в якому стані знаходиться (або має бути) кластер і як його виправити. Те саме справедливо і у разі успіху.
Припустімо, що команда Боба зібрала новий образ і потім пропатчила свої deployment'и, щоб розгорнути образ (все це з CI-пайплайну).
Якщо образ збереться нормально, але пайплайн впаде, команді доведеться з'ясовувати:
- Чи розгорнулося оновлення?
- Чи запускаємо ми нове збирання? Чи призведе це до непотрібних побічних ефектів — з можливістю отримати дві збірки того самого незмінного образу?
- Чи варто нам дочекатися чергового поновлення, перш ніж запустити збірку?
- Що саме пішло не так? Які кроки потрібно повторити (і які безпечно повторювати)?
Організація заснованого на Git'і робочого процесу не гарантує, що команда Боба не зіткнеться із цими проблемами. Вони, як і раніше, можуть помилитися з push'ом комміту, з тегом або будь-яким іншим параметром; Однак цей підхід все ж таки набагато ближче до явного все-чи-нічого.
Підсумовуючи, ось чому CI-сервери не повинні займатися CD:
- Скрипти поновлення не завжди детерміновані; у них легко наробити помилок.
- CI-сервери не конвергують до декларативної моделі кластеру.
- Важко гарантувати ідемопотентність. Користувачі повинні розумітися на глибокій семантиці системи.
- Складніше провести відновлення після часткового збою.
Примітка про Helm'e: якщо ви хочете використовувати Helm, ми рекомендуємо об'єднати його з GitOps-оператором, таким як . Це допоможе забезпечити конвергентність. Сам собою Helm перестав бути ні детермінованим, ні атомарним.
GitOps як найкращий спосіб здійснювати Continuous Delivery для Kubernetes
Команда Аліси та Боба впроваджує GitOps і виявляє, що стало набагато простіше працювати з програмними продуктами, підтримувати високу продуктивність та стабільність. Давайте закінчимо цю статтю ілюстраціями, які показують, як виглядає їх новий підхід. Врахуйте, що ми в основному говоримо про програми та сервіси, однак GitOps можна використовувати для керування всією платформою.
Модель експлуатації для Kubernetes
Подивіться наступну діаграму. Вона представляє Git та сховище образів контейнерів як загальні ресурси для двох оркестрованих життєвих циклів:
- Пайплайна безперервної інтеграції, який зчитує та записує файли у Git та може оновлювати репозиторій контейнерних образів.
- Пайплайна Runtime GitOps, що поєднує деплою з керуванням та спостерігальністю. Він зчитує та записує файли у Git і може завантажувати образи контейнерів.
Які основні висновки?
- Поділ проблем: Зверніть увагу, що обидва пайплайни можуть обмінюватися даними лише оновлюючи Git або репозиторій образів. Іншими словами, існує мережевий екран між CI та runtime-середовищем. Ми називаємо його «брандмауером незмінності» (Immutability firewall)оскільки всі оновлення репозиторіїв створюють нові версії. Для отримання додаткової інформації з цієї теми зверніться до слайдів 72-87 .
- Можна використовувати будь-який CI- та Git-сервер: GitOps працює з будь-якими компонентами Ви можете продовжувати використовувати свої улюблені CI- та Git-сервери, репозиторії образів та набори тестів. Майже всі інші інструменти Continuous Delivery на ринку вимагають власного CI-/Git-сервера або сховища образів. Це може стати обмежуючим фактором у розвитку cloud native. У разі GitOps можна використовувати звичні інструменти.
- Події як інструмент інтеграції: Як тільки дані в Git оновлюються, Weave Flux (або оператор Weave Cloud) повідомляє про це runtime. Щоразу, коли Kubernetes приймає набір змін, Git оновлюється. Це забезпечує просту модель інтеграції для організації робочих процесів для GitOps, як показано нижче.
Висновок
GitOps надає вагомі гарантії оновлення, необхідні будь-якому сучасному інструменту CI/CD:
- автоматизація;
- конвергенція;
- ідемпотентність;
- детермінізм.
Це важливо, оскільки він пропонує модель експлуатації для розробників у галузі cloud native.
- Традиційні інструменти для управління та моніторингу систем пов'язані з командами експлуатації, що діють у рамках runbook'а (набору рутинних процедур та операцій - прим. перекл.), прив'язаного до конкретного deployment'у.
- В управлінні cloud native-системами інструментарій для спостереження є найкращим способом оцінки результатів розгортань, щоб команда розробників змогла оперативно реагувати на них.
Уявіть безліч кластерів, розкиданих по різних хмарах та безліч сервісів зі своїми власними командами та планами розгортань. GitOps пропонує масштабно-інваріантну модель для керування всім цим достатком.
PS від перекладача
Читайте також у нашому блозі:
- «»;
- «»;
- «».
Тільки зареєстровані користувачі можуть брати участь в опитуванні. , будь ласка.
Ви знали про GitOps до появи цих двох перекладів на хабрі?
-
Так, все знав(а)
-
Лише поверхнево
-
Ні
Проголосували 35 користувачів. Утрималися 10 користувачів.
Джерело: habr.com