🥇Какво е GitOps?

Прим. прев.: След последната публикация на материали за методите pull и push в GitOps, ние видяхме интерес към тази модел, но рускоязычните публикации по темата са много малко (в Хабр просто ги няма). Затова с радост предлагаме на вашето внимание превод на друга статия — макар и почти година стара! — от компанията Weaveworks, чийто основател измисли термина „GitOps“. В текста се обяснява същността на подхода и ключовите му различия от вече съществуващите.

Преди година публикувахме въведение в GitOps. Тогава разказахме как екипът на Weaveworks стартира SaaS услуга, напълно базирана на Kubernetes, и разработи набор от предписващи най-добри практики за внедряване, управление и мониторинг в среда cloud native.

Статията се оказа популярна. Други хора започнаха да говорят за GitOps, станаха популярни нови инструменти за git push, разработка, на тайни, функции, непрекъсната интеграция и др. На нашия сайт се появи голямо количество публикации и примери за използване на GitOps. Но при някои хора все пак останаха въпроси. С какво моделът се различава от традиционната инфраструктура като код и непрекъсната доставка (непрекъсната доставка)? Задължително ли е да се използва Kubernetes?

Скоро осъзнахме, че е необходимо ново описание, предлагащо:

Много примери и истории;
Конкретно определение на GitOps;
Сравнение с традиционната непрекъсната доставка.

В тази статия се опитахме да обхванем всички тези теми. В нея ще намерите обновено въведение в 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.

Премина известно време. Алиса и Боб се разочароваха от производителността на избрания подход и влиянието му върху бизнеса. Внедряването на контейнери не увеличи производителността толкова, колкото екипът се надяваше. Понякога внедряванията се проваляха, и не беше ясно дали вината е в промените в кода. Също така се оказа трудно да се проследят промените в конфигурацията. Често се налагаше да се създаде нов клъстер и да се преместят приложенията в него, тъй като така беше най-лесно да се оправи хаосът, в който се беше трансформирала системата. Алиса се страхуваше, че ситуацията ще се влоши с развитието на приложението (в допълнение, се появяваше нов проект на основата на машинното обучение). Боб автоматизира голяма част от работата и не разбираше защо пайплайнът все още е нестабилен, слабо мащабируем и периодично изисква ръчно намеса?

След това те научиха за GitOps. Това решение се оказа точно това, от което се нуждаеха, за да тръгнат уверено напред.

Алиса и Боб вече от години чуха за работните потоци, базирани на Git, DevOps и инфраструктура като код. Уникалността на GitOps е, че той въвежда редица най-добри практики - категорични и нормативни - за реализиране на тези идеи в контекста на Kubernetes. Тема, която често беше повдигана, включително и в блога на Weaveworks.

Family Insurance решава да внедри GitOps. Сега компанията разполага с автоматизирана експлоатационна модел, съвместима с Kubernetes и комбинираща скорост с със стабилност, тъй като те:

откриха, че производителността на екипа е нараснала два пъти и никой не полудява;
спряха да обслужват скриптовете. Вместо това сега могат да се фокусират върху нови функции и да усъвършенстват инженерните методи - например, да внедрят канарейкови версии и да подобрят тестването;
усъвършенстваха процеса на развертка - сега той рядко се проваля;
получиха възможността да възстановяват внедрявания след частични неизправности без ръчно намеса;
придобиха боолша увереност в системите за доставка. Алиса и Боб откриха, че могат да разделят екипа на групи, занимаващи се с микроуслуги и работещи паралелно;
могат да извършват по 30-50 промени в проекта всеки ден, благодарение на усилията на всяка група и да опитват нови техники;
лесно привлекат нови разработчици към проекта, които имат възможност да внедряват обновления на production с помощта на pull request-ове само след няколко часа;
леко преминават одита в рамките на SOC2 (съгласно изискванията на доставчиците на услуги за безопасно управление на данни; прочетете повече например, тук — бел. ред.).

Какво се случи?

GitOps — това е две неща:

Модел на експлоатация за Kubernetes и cloud native. Той предлага набор от най-добри практики за разгръщане, управление и мониторинг на кластери и приложения, опаковани в контейнери. Елегантно определение в форма на един слайд от Luis Faceira:
Пътят към създаването на разработваща се среда за управление на приложения. Ние прилагаме работен процес 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). Следователно, разгръщанията на Kubernetes имат следните невероятни свойства:

Автоматизацията: актуализациите на Kubernetes предоставят механизъм за автоматизиране на процеса на прилагане на промените правилно и навременно.
Конвергенция: Kubernetes ще продължава да прави опити за актуализации до постигане на успех.
Идемпотентност: повторното прилагане на конвергенцията води до същия резултат.
Детерминизъм: при достатъчно ресурси, състоянието на актуализирания клъстер зависи само от желаното състояние.

Как работи GitOps

Ние научихме достатъчно за Kubernetes, за да обясним принципите на работа на GitOps.

Нека се върнем на екипите на Family Insurance, свързани с микросервизи. Какво обикновено им се налага да правят? Вижте списъка по-долу (ако някои точки в него изглеждат странни или непознати — моля, почакайте с критиката и останете с нас). Това са само примери за работни процеси на базата на Jenkins. Съществуват и много други процеси при работа с различни инструменти.

Основното е, че виждаме, че всяка актуализация завършва с внасяне на промени в конфигурационни файлове и репозитории Git. Тези промени в Git водят до това, че «операторът GitOps» актуализира клъстера:

1. Работен процес: «Сборка Jenkins — клон master».
Списък със задачи:

Jenkins публикува тагирани изображения в Quay;
Jenkins публикува конфигурация и Helm-чартове в кофата на master хранилището;
Облачна функция копира конфигурацията и чартовете от кофата на master хранилището в Git репозитория master;
Операторът GitOps актуализира клъстера.

2. Сборка Jenkins — клон release или hotfix:

Jenkins публикува нетагирани изображения в Quay;
Jenkins публикува конфигурация и Helm-чартове в кофата на staging хранилището;
Облачна функция копира конфигурацията и чартовете от кофата на staging хранилището в Git репозитория staging;
Операторът GitOps актуализира клъстера.

3. Сборка Jenkins — клон develop или feature:

Jenkins публикува нетагирани изображения в Quay;
Jenkins публикува конфигурация и Helm-чартове в кофата на develop хранилището;
Облачна функция копира конфигурацията и чартовете от кофата на develop хранилището в Git репозитория develop;
Операторът GitOps актуализира клъстера.

4. Добавяне на нов клиент:

Мениджър или администратор (LCM/ops) извиква Gradle за първоначално разгръщане и настройка на мрежови балансировчици на натоварването (NLB);
LCM/ops комитва нова конфигурация, за да подготви разгръщането за актуализации;
Операторът GitOps актуализира клъстера.

Кратко описание на GitOps

Опишете желаното състояние на цялата система, използвайки декларативни спецификации за всяка среда (в нашата история екипът на Боб определя цялата конфигурация на системата в Git).
- Git репозиторият е единственият източник на истина относно желаното състояние на цялата система.
- Всички промени в желаното състояние се осъществяват чрез комити в Git.
- Всички желани параметри на клъстера също са наблюдаемите в самия клъстер. Така можем да определим, съвпадат (конвергират, converge) или се различават (дивергират, diverge) желаното и наблюдаваното състояние.
Ако желаното и наблюдаваното състояния се различават, то:
- Има механизъм за конвергенция, който рано или късно автоматично синхронизира целевото и наблюдаваното състояние. Вътре в клъстера това се извършва от Kubernetes.
- Процесът стартира незабавно с уведомление "промяна ангажирана".
- След известно настраиваемо време може да бъде изпратено уведомление "разлики", ако състоянията се различават.
Така че, всички комити в Git предизвикват проверими и идемпотентни обновления в клъстера.
- Откатът е конвергенция към предходно желаното състояние.
Конвергенцията е окончателна. За нея свидетелстват:
- Липсата на уведомления "разлики" за определен период от време.
- Уведомление "конвергирало" (например, webhook, събитие за запис в Git).

Какво е дивергенция?

Нека повторим отново: всички желани свойства на клъстера трябва да бъдат наблюдаеми в самия клъстер.

Няколко примера за дивергенция:

Промени в конфигурационен файл поради сливане на клонове в Git.
Промени в конфигурационен файл поради комит в Git, извършен от GUI клиент.
Множество промени в желаното състояние поради PR в Git с последващо изграждане на контейнерен образ и промени в конфигурацията.
Промяна на състоянието на клъстера поради грешка, конфликт на ресурси, водещ до "лошо поведение", или просто случайно отклонение от оригиналното състояние.

Какво представлява механизмът на конвергенция?

Няколко примера:

За контейнери и клъстери механизмът на конвергенция осигурява Kubernetes.
Същият механизъм може да се използва за управление на приложения и конструкции на базата на Kubernetes (например, Istio и Kubeflow).
Механизм за управление на работното взаимодействие между Kubernetes, репозитории на образи и Git предоставя GitOps-оператор Weave Flux, който е част от Weave Cloud.
За базови машини механизмът на конвергенция трябва да бъде декларативен и автономен. По наш опит можем да кажем, че Terraform най-близо до това определение, но все пак изисква контрол от страна на човека. В този смисъл GitOps разширява традициите на Infrastructure as Code.

GitOps съчетава Git с отличен механизъм за конвергенция на Kubernetes, предлагайки модел за експлоатация.

GitOps ни позволява да заявим: автоматизацията и контролът могат да се прилагат само за системи, които могат да бъдат описвани и наблюдавани.

GitOps е предназначен за целия cloud native стек (например, Terraform и т.н.)

GitOps не е само Kubernetes. Ние искаме цялата система да се управлява декларативно и да използва конвергенция. Под цялата система разбираме набор от среди, работещи с Kubernetes – например, "dev кластер 1", "продукция" и т.н. Във всяка среда влизат машини, клъстери, приложения, както и интерфейси за външни услуги, осигуряващи данни, мониторинг и т.н.

Обърнете внимание колко важен е 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 тези актуализации са конвергентни. Това осигурява механизъм за непрекъснато разгръщане, при който всички обновления са атомарни.
Забележка: Weave Cloud предлага GitOps оператор, интегриращ Git и Kubernetes и позволяващ изпълнение на CD чрез съгласуване на желаното и текущото състояние на кластера.

Без kubectl и скриптове

Трябва да се избягва използването на Kubectl за актуализиране на кластера, особено скриптове за групиране на команди kubectl. Вместо това, чрез GitOps потока, потребителят може да обнови своя Kubernetes клъстер чрез Git.

Предимствата включват:

Коректност. Група актуализации може да бъде приложена, конвергенция и накрая валидирана, което ни приближава до целта на атомарното разгръщане. От друга страна, използването на скриптове не дава никакви гаранции за конвергенция (повече за това по-долу).
Сигурност. Цитирайки Kelsey Hightower: «Ограничете достъпа до Kubernetes клъстера само до инструментите за автоматизация и администраторите, чиято работа е свързана с отстраняване на неизправности или поддържане на работоспособността». Вижте също моята публикация за безопасността и съответствието с техническите изисквания, а също и статията за хакване на Homebrew чрез кражба на идентификационни данни от небрежно написан Jenkins скрипт.
Потребителски опит. Kubectl разкрива механиката на обектния модел на Kubernetes, който е доста сложен. Идеално, потребителите трябва да взаимодействат със системата на по-високо ниво на абстракция. Тук отново се позовавам на Kelsey и препоръчвам да се види такова резюме.

Разликата между CI и CD

GitOps подобрява съществуващите CI/CD модели.

Съвременният CI сървър е инструмент за оркестрация. В частност, това е инструмент за оркестрация на CI потоци. Те включват build, test, merge to trunk и т.н. CI сървърите автоматизират управлението на сложни многостъпкови потоци. Разпространеното изкушение е да се създаде скрипт за набор от актуализации на Kubernetes и да се изпълни като елемент от потока за пушване на промените в кластера. Всъщност, много специалисти постъпват така. Въпреки това, това не е оптимално, и ето защо.

CI трябва да се използва за актуализации в trunk, а Kubernetes клъстерът трябва да се адаптира въз основа на тези актуализации, за да управлява CD "вътрешно". Ние го наричаме pull-модел за CD, в контекста на модела push на CI. CD е част от runtime-оркестрацията.

Защо CI-сървърите не трябва да правят CD чрез директни актуализации в Kubernetes

Не използвайте CI-сървъра за оркестрация на директни актуализации в Kubernetes под формата на набор от CI-задачи. Това е анти-патерн, за който вече говорихме в блога си.

Нека се върнем към Алиса и Боб.

С какви предизвикателства се сблъскват те? CI-сървърът на Боб прилага изменения към клъстера, но ако по време на процеса той се срине, Боб няма да знае в какво състояние е (или трябва да бъде) клъстерът и как да го поправи. Същото важи и при успех.

Да предположим, че екипът на Боб е построил нов образ и след това е направил пачове на своите deployment-и, за да разгръща образа (всичко това от CI-пайплайна).

Ако образът се събере нормално, но пайплайнът се срине, на екипа ще се наложи да разбере:

Пусна ли се актуализацията?
Пускаме ли новата сборка? Ще доведе ли това до нежелани странични ефекти — с вероятността да получим две сборки на един и същ неизменен образ?
Трябва ли да изчакаме следващата актуализация, преди да пуснем сборката?
Какво точно не беше наред? Какви стъпки трябва да се повторят (и кои от тях са безопасни за повторение)?

Организацията на работния процес, основана на Git, не гарантира, че екипът на Боб няма да срещне тези проблеми. Те все още могат да сгрешат при push на комит, таг или някой друг параметър; обаче този подход все пак е много по-близо до явния принцип "всичко или нищо".

В обобщение, ето защо CI-сървърите не трябва да се занимават с CD:

Скриптовете за актуализация не винаги са детерминирани; лесно е да се допуснат грешки.
CI-сървърите не конвергират към декларативен модел на клъстера.
Трудно е да се гарантира идемпотентност. Потребителите трябва да разбират дълбоката семантика на системата.
По-трудно е да се извърши възстановяване след частичен неуспех.

Бележка относно Helm: ако искате да използвате Helm, препоръчваме да го комбинирате с GitOps-оператор, като Flux-Helm. Това ще помогне за осигуряване на конвергенция. Сам по себе си 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:

автоматизация;
конвергенция;
идемпотентност;
детерминизъм.

Това е важно, защото предлага модел на експлоатация за разработчиците в облачната среда.

Традиционните инструменти за управление и наблюдение на системи са свързани с екипи, които действат в рамките на runbook-а (набор от рутинни процедури и операции — прим. прев.), свързан с конкретно разгръщане.
В управлението на cloud native системи инструментите за наблюдение са най-добрият начин за оценка на резултатите от разгръщанията, за да може екипът на разработчиците да реагира бързо.

Представете си множество клъстери, разпределени из различни облаци, и множество услуги със свои собствени екипи и планове за разгръщане. GitOps предлага мащабно инвариантен модел за управление на всичкото това изобилие.