Прим. прев.: След последната публикация за методите pull и push в GitOps, видяхме интерес към тази моделна структура, но публикациите на руски по тази тема се оказаха изключително малко (на Хабър почти няма). Затова сме щастливи да предложим вашето внимание превод на друга статия — макар и вече почти годишна! — от компанията Weaveworks, чийто основател измисли термина «GitOps». В текста се обяснява същността на подхода и ключовите различия от вече съществуващите.
Преди година публикувахме . Тогава разказахме как екипът на Weaveworks стартира SaaS, която е изцяло основана на Kubernetes и разработи набор от препоръчителни практики за разгръщане, управление и мониторинг в cloud native среда.
Статията се оказа популярна. Други хора започнаха да говорят за GitOps, започнаха да публикуват нови инструменти за , , , , и т.н. На нашия сайт се появиха публикации и примери за използване на GitOps. Но за някои хора все още останаха въпроси. Какво отличава модела от традиционното и непрекъснатото предоставяне ()? Задължително ли е да се използва Kubernetes?
Скоро осъзнахме, че е необходимо ново описание, което предлага:
- Голям брой примери и истории;
- Конкретно определение на GitOps;
- Сравнение с традиционното непрекъснато предоставяне.
В тази статия се опитахме да обхванем всички тези теми. В нея ще намерите актуализирано въведение в GitOps и поглед към него от страна на разработчиците и CI/CD. Основно се фокусираме върху Kubernetes, макар че моделът може да бъде обобщен.
Запознайте се: GitOps
Представете си Алиса. Тя управлява компанията Family Insurance, предлагаща застрахователни полици за здраве, автомобили, недвижимо имущество и туристическа застраховка на хора, които са твърде заети, за да се справят сами с нюансите на договорите. Нейният бизнес започна като страничен проект, когато Алиса работеше в банка като специалист по данни. Един ден тя осъзна, че може да използва напреднали компютърни алгоритми за по-ефективен анализ на данни и формиране на застрахователни пакети. Инвеститорите финансираха проекта и сега компанията й генерира над 20 милиона долара годишно и бързо нараства. В момента в нея работят 180 души на различни позиции. Между тях е и технологичният екип, който се занимава с разработка, поддръжка на сайта, базата данни и анализ на клиентската база. Eкипът от 60 души се ръководи от Боб — технически директор на компанията.
Eкипът на Боб разгръща production системи в облака. Основните им приложения работят на GKE, възползвайки се от предимствата на Kubernetes в Google Cloud. Освен това, те използват различни инструменти за работа с данни и аналитика.
Family Insurance не планираше да използва контейнери, но бяха заразени от ентусиазма около Docker. Скоро специалистите на компанията откриха, че GKE позволява да се разгръщат клъстери за тестване на нови функции лесно и удобно. Бяха добавени Jenkins за CI и Quay за организиране на контейнерен регистър, написани бяха скриптове за Jenkins, които изпращаха нови контейнери и конфигурации в GKE.
Измина известно време. Алиса и Боб бяха разочаровани от производителността на избрания подход и влиянието му върху бизнеса. Внедряването на контейнери не повиши производителността толкова, колкото екипът се надяваше. Понякога разширенията се разваляха и нямаше яснота дали проблемите се дължат на промени в кода. Освен това, проследяването на промените в конфигурациите се оказа трудно. Често се налагаше да се създава нов клъстер и да се преместят приложенията в него, защото така беше най-лесно да се ликвидира хаосът, в който бе изпаднала системата. Алиса се страхуваше, че ситуацията ще се влоши с развитието на приложението (освен това, назряваше нов проект, основан на машинно обучение). Боб автоматизира голяма част от работата и не разбираше защо пайплайнът все още е нестабилен, лошо се мащабира и периодично изисква ръчна намеса?
Тогава те разбраха за GitOps. Това решение се оказа точно това, от което имаха нужда, за да продължат уверено напред.
Алиса и Боб отдавна слушаха за работни процеси, основани на Git, DevOps и инфраструктура като код. Уникалността на GitOps е, че той въвежда набор от най-добри практики — категорични и нормативни — за реализиране на тези идеи в контекста на Kubernetes. Темата , включително и в .
Family Insurance решава да внедри GitOps. Сега компанията разполага с автоматизирана експлоатационна модела, съвместима с Kubernetes и съчетаваща скоростта с стабилност, тъй като те:
- откриха, че производителността на екипа се е удвоила и никой не е на ръба на лудостта;
- спряха да обслужват скриптове. Вместо това сега могат да се съсредоточат върху нови функции и усъвършенстване на инженерните методи — например, внедряване на канарени разширения и подобряване на тестването;
- усъвършенстваха процеса на разгръщане — сега той рядко се разваля;
- достигнаха способността да възстановяват разширенията след частични сблъсъци без ръчна намеса;
- придобихапо-по-голяма увереност в системите за доставка. Алиса и Боб откриха, че могат да разделят екипа на групи, които се занимават с микросервизи и работят паралелно;
- могат да правят по 30-50 промени в проекта всеки ден с усилията на всяка група и да пробват нови техники;
- лесно привлекат нови разработчици към проекта, които имат възможност да приложат актуализации в продукция чрез pull request-и само след няколко часа;
- лесно преминава одит в рамките на SOC2 (по съответствие на доставчиците на услуги с изискванията за безопасно управление на данните; прочетете повече на например, — забележка на преводача).
Какво се е случило?
GitOps — това са две неща:
- Модел за експлоатация на Kubernetes и облачно оригинално. Той предоставя набор от най-добри практики за внедряване, управление и мониторинг на събрани в контейнери клъстери и приложения. Елегантно определение под формата на от :
- Пътят към създаването на среда, ориентирана към разработчиците за управление на приложения. Прилагаме работен процес 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 качва тагнати изображения в Quay;
- Jenkins качва конфигурацията и Helm-чартовете в мастер хранилище;
- Облачна функция копира конфигурацията и чартовете от мастер хранилището в 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 комитва нова конфигурация за подготовка на deployment-a за актуализации;
- Операторът GitOps обновява клъстера.
Кратко описание на GitOps
- Опишете желаното състояние на цялата система, като използвате декларативни спецификации за всяка среда (в нашата история екипът на Боб определя цялата конфигурация на системата в Git).
- Git хранилището е единственият източник на истината относно желаното състояние на цялата система.
- Всички промени в желаното състояние се извършват чрез комити в Git.
- Всички желани параметри на клъстера също са наблюдаеми в самия клъстер. По този начин можем да определим дали желаното и наблюдаваното състояние са (конвергират, converge) или се различават (дивергират, diverge) желаното и наблюдаваното състояние.
- Ако желаното и наблюдаваното състояние се различават, то:
- Съществува механизъм за конвергенция, който рано или късно автоматично синхронизира целевото и наблюдаваното състояние. Вътре в клъстера това се извършва от Kubernetes.
- Процесът започва незабавно с известие „промяната е комитната“.
- След определен настраиваем интервал от време може да бъде изпратено известие „разлика“, ако състоянията се различават.
- По този начин всички комити в Git предизвикват проверяеми и идемпотентни актуализации в клъстера.
- Отмяната е конвергенция към преди желаното състояние.
- Конвергенцията е окончателна. За нейното настъпване свидетелстват:
- Липса на известия „разлика“ в рамките на определен период от време.
- Известие „конвергирано“ (например, 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 пайплайни. Те включват изграждане, тест, сливане в основния клон и т.н. CI сървърите автоматизират управлението на сложни многостепенни пайплайни. Често срещаното изкушение е да се създаде скрипт за набор от обновления Kubernetes и да се изпълни като елемент от пайплайна за push на промените в клъстера. Наистина, много специалисти постъпват именно така. Обаче, това не е оптимално и ето защо.
CI трябва да се използва за обновления в trunk, а Kubernetes клъстърът трябва да се променя на базата на тези обновления, за да управлява CD "вътрешно". Ние наричаме това , в контекста на CI push-модела. CD е част от runtime-оркестрация.
Защо CI-сървърите не трябва да извършват CD чрез директни обновления в Kubernetes
Не използвайте CI-сървъра за оркестрация на директни обновления в Kubernetes под формата на CI-задачи. Това е антипаттерн, за който ние в нашия блог.
Нека се върнем към Алиса и Боб.
С какви проблеми се сблъскват те? CI-сървърът на Боб прилага промените в клъстъра, но ако по време на процеса той се срине, Боб няма да знае в какво състояние е (или би трябвало да е) клъстърът и как да го поправи. Същото важи и в случай на успех.
Да предположим, че екипът на Боб е изградил нов образ и след това е патчил своите deployment-и, за да разгръща образа (всичко това от CI-пайплайна).
Ако образът се изгради успешно, но пайплайнът се срине, екипът ще трябва да разберe:
- Намали ли се обновлението?
- Стартираме ли нова сборка? Ще доведе ли това до ненужни странични ефекти — с шанс да получим две сборки на един и същи неизменен образ?
- Дали трябва да изчакаме следващото обновление, преди да стартираме сборката?
- Какво точно се обърка? Какви стъпки трябва да се повторят (и кои от тях е безопасно да се повторят)?
Организацията на Git базиран работен процес не гарантира, че екипът на Боб няма да се сблъска с тези проблеми. Те все още могат да сбъркат с push на commit, с таг или с какъвто и да е друг параметър; обаче този подход все пак е много по-близо до ясната все-или-ничто.
В заключение, ето защо CI-сървърите не трябва да се занимават с CD:
- Скриптовете за обновление не винаги са детерминирани; лесно е да се допуснат грешки.
- CI-сървърите не конвергират към декларативна модел на клъстера.
- Трудно е да се гарантира идемпотентност. Потребителите трябва да се справят с дълбоката семантика на системата.
- По-сложно е да се проведе възстановяване след частичен неуспех.
Бележка относно Helm: ако искате да използвате Helm, препоръчваме да го комбинирате с GitOps-оператор, като . Това ще помогне да се осигури конвергенция. Сам по себе си Helm не е нито детерминиран, нито атомарен.
GitOps като най-добрия начин за извършване на Continuous Delivery за Kubernetes
Отборният екип на Алиса и Боб внедрява GitOps и открива, че е значително по-лесно да работи с софтуерни продукти, поддържайки висока производителност и стабилност. Нека завършим тази статия с илюстрации, показващи как изглежда новият им подход. Обърнете внимание, че основно говорим за приложения и услуги, но GitOps може да се използва за управление на цялата платформа.
Модел на експлоатация за Kubernetes
Погледнете следната диаграма. Тя представя Git и хранилището на контейнерни образи като общи ресурси за двата оркестрирани жизнен цикъла:
- Пайплайн за непрекъсната интеграция, който чете и записва файлове в Git и може да обновява хранилището на контейнерни образи.
- Пайплайн Runtime GitOps, съчетаващ деплой с управление и наблюдение. Той чете и записва файлове в Git и може да качва контейнерни образи.
Какви са основните изводи?
- Разделяне на проблемите: Обърнете внимание, че и двата пайплайна могат да обменят данни, само като обновяват Git или хранилището на образи. С други думи, съществува защитна стена между CI и средата за изпълнение. Ние я наричаме «брандмауър на неизменяемостта» (immutability firewall), тъй като всички обновления на хранилищата създават нови версии. За допълнителна информация по темата, моля, запознайте се със слайдовете 72-87. .
- Може да се използва произволен CI и Git сървър: GitOps работи с всякакви компоненти. Можете да продължите да използвате любимите си CI и Git сървъри, хранилища на образи и набори от тестове. Почти всички останали инструменти за непрекъсната доставка на пазара изискват собствен CI/Git сървър или хранилище на образи. Това може да бъде ограничителен фактор в развитието на cloud native. В случая на GitOps можете да използвате познатите инструменти.
- Събитията като инструмент за интеграция: След като данните в Git бъдат обновени, Weave Flux (или операторът Weave Cloud) уведомява за това runtime. Всеки път, когато Kubernetes приеме набор от промени, Git се обновява. Това осигурява проста модел на интеграция за организиране на работните процеси за GitOps, както е показано по-долу.
Заключение
GitOps предоставя значителни гаранции за обновление, необходими на всеки съвременен инструмент CI/CD:
- автоматизация;
- конвергенция;
- идемпотентност;
- детерминизъм.
Това е важно, тъй като предлага модел на експлоатация за разработчици в областта на облачните технологии.
- Традиционните инструменти за управление и наблюдение на системи са свързани с екипи по експлоатация, които действат в рамките на runbook-а. (набор от рутинни процедури и операции — бел. прев.)., свързан с конкретно разгръщане.
- В управлението на облачни системи, инструментите за наблюдение са най-добрият начин за оценка на резултатите от разгръщанията, така че екипът от разработчици да може бързо да реагира.
Представете си множество клъстери, разпръснати из различни облаци и множество услуги с техните собствени екипи и планове за разгръщане. GitOps предлага мащабно-непроменлив модел за управление на цялото това изобилие.
P.S. от преводача
Прочетете също в нашия блог:
- «»;
- «»;
- «».
Само регистрирани потребители могат да участват в анкетата. , моля.
Знаехте ли за GitOps преди тези два превода на Хабре?
Да, знаех всичко.
Само повърхностно.
Не
Гласували са 35 потребители. Воздържали се 10 потребители.
Източник: habr.com
