Какво е GitOps?

Забележка. превод: След скорошна публикация материал относно методите за изтегляне и натискане в GitOps, видяхме интерес към този модел като цяло, но имаше много малко публикации на руски език по тази тема (просто няма такива на Habré). Затова имаме удоволствието да предложим на вашето внимание превод на друга статия – макар и преди почти година! — от Weaveworks, ръководителят на който измисли термина „GitOps“. Текстът обяснява същността на подхода и основните разлики от съществуващите.

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

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

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

1. Голям брой примери и истории;
2. Специфична дефиниция на GitOps;
3. Сравнение с традиционната непрекъсната доставка.

В тази статия сме се опитали да обхванем всички тези теми. Той предоставя актуализирано въведение в GitOps и перспектива за разработчици и CI/CD. Основно се фокусираме върху Kubernetes, въпреки че моделът може да бъде обобщен.

Запознайте се с GitOps

Представете си Алис. Тя управлява Family Insurance, която предлага здравни, автомобилни, жилищни и туристически застраховки на хора, които са твърде заети, за да разберат сами тънкостите на договорите. Нейният бизнес започва като страничен проект, когато Алис работи в банка като специалист по данни. Един ден тя осъзна, че може да използва усъвършенствани компютърни алгоритми за по-ефективен анализ на данни и формулиране на застрахователни пакети. Инвеститорите финансираха проекта и сега нейната компания носи повече от 20 милиона долара годишно и се разраства бързо. В момента в него работят 180 души на различни позиции. Това включва технологичен екип, който разработва, поддържа уебсайта, базата данни и анализира клиентската база. Екипът от 60 души се ръководи от Боб, технически директор на компанията.

Екипът на Боб внедрява производствени системи в облака. Техните основни приложения работят на GKE, като се възползват от Kubernetes в Google Cloud. Освен това те използват различни инструменти за данни и анализи в работата си.

Family Insurance не си постави за цел да използва контейнери, но беше увлечена от ентусиазма на Docker. Компанията скоро откри, че GKE улеснява внедряването на клъстери за тестване на нови функции. Дженкинс за CI и Quay бяха добавени за организиране на регистъра на контейнерите, написани бяха скриптове за Дженкинс, които избутаха нови контейнери и конфигурации към GKE.

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

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

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

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

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

Какво стана?

GitOps е две неща:

1. Оперативен модел за Kubernetes и нативния облак. Той предоставя набор от най-добри практики за внедряване, управление и наблюдение на контейнеризирани клъстери и приложения. Елегантна дефиниция във формата един слайд от Луис Фасейра:
2. Пътят към създаване на ориентирана към разработчиците среда за управление на приложения. Ние прилагаме работния процес на Git както за операции, така и за разработка. Моля, имайте предвид, че не става дума само за Git push, а за организиране на целия набор от CI/CD и UI/UX инструменти.

Няколко думи за Git

Ако не сте запознати със системите за контрол на версиите и базирания на Git работен процес, силно препоръчваме да научите повече за тях. Работата с клонове и заявки за изтегляне може да изглежда като черна магия в началото, но ползите си заслужават усилието. Тук добра статия да започна.

Как работи Kubernetes

В нашата история Алис и Боб се обърнаха към GitOps, след като работиха известно време с Kubernetes. Всъщност GitOps е тясно свързан с Kubernetes - това е оперативен модел за инфраструктура и приложения, базирани на Kubernetes.

Какво дава Kubernetes на потребителите?

Ето някои основни функции:

1. В модела Kubernetes всичко може да бъде описано в декларативна форма.
2. API сървърът на Kubernetes приема тази декларация като вход и след това непрекъснато се опитва да приведе клъстера в състоянието, описано в декларацията.
3. Декларациите са достатъчни, за да опишат и управляват голямо разнообразие от работни натоварвания — „приложения“.
4. В резултат на това настъпват промени в приложението и клъстера поради:
   • промени в изображенията на контейнери;
   • промени в декларативната спецификация;
   • грешки в средата - например сривове на контейнери.

Страхотните възможности за конвергенция на Kubernetes

Когато администратор направи промени в конфигурацията, оркестраторът на Kubernetes ще ги приложи към клъстера, докато състоянието му е няма да се доближи до новата конфигурация. Този модел работи за всеки ресурс на Kubernetes и е разширим с персонализирани дефиниции на ресурси (CRD). Следователно внедряванията на Kubernetes имат следните прекрасни свойства:

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

Как работи GitOps

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

Да се ​​върнем към екипите за микроуслуги на Family Insurance. Какво обикновено трябва да правят? Вижте списъка по-долу (ако някои елементи в него изглеждат странни или непознати, моля, спрете да критикувате и останете с нас). Това са само примери за базирани на Jenkins работни процеси. Има много други процеси при работа с други инструменти.

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

1. Работен процес: "Jenkins build - главен клон".
Списък със задачи:

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

2. Изграждане на Дженкинс - клон за освобождаване или актуална корекция:

• Дженкинс изпраща немаркирани изображения на Quay;
• Дженкинс избутва конфигурацията и диаграмите на Helm в кофата за съхранение;
• Функцията в облака копира конфигурацията и диаграмите от кофата за съхранение на етапи в хранилището на Git за етапи;
• Операторът GitOps актуализира клъстера.

3. Изграждане на Jenkins - разработка или разклонение на характеристиките:

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

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

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

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

1. Опишете желаното състояние на цялата система, като използвате декларативни спецификации за всяка среда (в нашата история екипът на Боб дефинира цялата системна конфигурация в Git).
   • Хранилището на Git е единственият източник на истина относно желаното състояние на цялата система.
   • Всички промени в желаното състояние се правят чрез ангажименти в Git.
   • Всички желани параметри на клъстера също могат да се наблюдават в самия клъстер. По този начин можем да определим дали те съвпадат (конвергират, клоня) или се различават (разминават се, разминават се) желани и наблюдавани състояния.
2. Ако желаните и наблюдаваните състояния се различават, тогава:
   • Има механизъм за конвергенция, който рано или късно автоматично синхронизира целевото и наблюдаваното състояние. Вътре в клъстера Kubernetes прави това.
   • Процесът започва незабавно с предупреждение „извършена промяна“.
   • След известен конфигурируем период от време може да бъде изпратено предупреждение за „разлика“, ако състоянията са различни.
3. По този начин всички ангажименти в Git причиняват проверими и идемпотентни актуализации на клъстера.
   • Връщане назад е конвергенция към предварително желано състояние.
4. Сближаването е окончателно. Появата му се показва от:
   • Без сигнали за разлика за определен период от време.
   • "конвергентен" сигнал (напр. webhook, събитие за обратно записване на Git).

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

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

Някои примери за разминаване:

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

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

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

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

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

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

GitOps е предназначен за целия естествен стек в облака (например Terraform и т.н.)

GitOps не е само Kubernetes. Искаме цялата система да се управлява декларативно и да използва конвергенция. Под цялата система имаме предвид колекция от среди, работещи с Kubernetes - например „dev cluster 1“, „production“ и т.н. Всяка среда включва машини, клъстери, приложения, както и интерфейси за външни услуги, които предоставят данни, мониторинг и т.н.

Забележете колко важен е Terraform за проблема с стартирането в този случай. Kubernetes трябва да бъде разгърнат някъде и използването на Terraform означава, че можем да приложим същите работни процеси на GitOps, за да създадем контролния слой, който е в основата на Kubernetes и приложенията. Това е полезна най-добра практика.

Има силен фокус върху прилагането на концепции на GitOps към слоеве върху Kubernetes. В момента има решения от типа GitOps за Istio, Helm, Ksonnet, OpenFaaS и Kubeflow, както и например за Pulumi, които създават слой за разработване на приложения за облачен натив.

Kubernetes CI/CD: сравняване на GitOps с други подходи

Както беше посочено, GitOps е две неща:

1. Оперативният модел за Kubernetes и нативния облак, описан по-горе.
2. Пътят към ориентирана към разработчиците среда за управление на приложения.

За мнозина 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.

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

1. вярно. Група от актуализации могат да бъдат приложени, обединени и накрая валидирани, което ни доближава до целта за атомно внедряване. Обратно, използването на скриптове не осигурява никаква гаранция за конвергенция (повече за това по-долу).
2. сигурност. цитиране Келси Хайтауър: „Ограничете достъпа до вашия клъстер Kubernetes до инструменти за автоматизация и администратори, които отговарят за отстраняването на грешки или поддръжката му.“ Вижте също моята публикация относно безопасността и съответствието с техническите спецификации, както и статия за хакването на Homebrew чрез кражба на идентификационни данни от небрежно написан скрипт на Дженкинс.
3. Потребителски опит. Kubectl разкрива механиката на обектния модел Kubernetes, която е доста сложна. В идеалния случай потребителите трябва да взаимодействат със системата на по-високо ниво на абстракция. Тук отново ще се позова на Келси и ще препоръчам гледане такава автобиография.

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

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

Модерният CI сървър е инструмент за оркестрация. По-специално, това е инструмент за оркестриране на CI тръбопроводи. Те включват изграждане, тестване, сливане към ствол и т.н. CI сървърите автоматизират управлението на сложни многоетапни конвейери. Често срещано изкушение е да се напише набор от актуализации на Kubernetes и да се изпълни като част от конвейер, за да се прокарат промени в клъстера. Всъщност това е, което много експерти правят. Това обаче не е оптимално и ето защо.

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

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

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

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

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

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

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

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

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

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

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

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

GitOps като най-добрият начин за прилагане на непрекъсната доставка за Kubernetes

Екипът на Алис и Боб внедрява GitOps и открива, че е станало много по-лесно да се работи със софтуерни продукти, да се поддържа висока производителност и стабилност. Нека завършим тази статия с илюстрация, показваща как изглежда новият им подход. Имайте предвид, че говорим предимно за приложения и услуги, но GitOps може да се използва за управление на цяла платформа.

Операционен модел за Kubernetes

Вижте следната диаграма. Той представя Git и хранилището за изображения на контейнери като споделени ресурси за два оркестрирани жизнени цикъла:

• Конвейер за непрекъсната интеграция, който чете и записва файлове в Git и може да актуализира хранилище на изображения на контейнери.
• Runtime GitOps тръбопровод, който съчетава внедряване с управление и възможност за наблюдение. Той чете и записва файлове в Git и може да изтегля изображения на контейнери.

Какви са основните констатации?

1. Разделяне на грижите: Моля, имайте предвид, че и двата канала могат да комуникират само чрез актуализиране на Git или хранилището на изображения. С други думи, има защитна стена между CI и средата за изпълнение. Ние го наричаме "неизменна защитна стена" (неизменна защитна стена), тъй като всички актуализации на хранилището създават нови версии. За повече информация по тази тема вижте слайдове 72-87 тази презентация.
2. Можете да използвате всеки CI и Git сървър: GitOps работи с всеки компонент. Можете да продължите да използвате любимите си CI и Git сървъри, хранилища за изображения и тестови пакети. Почти всички други инструменти за непрекъсната доставка на пазара изискват собствен CI/Git сървър или хранилище за изображения. Това може да се превърне в ограничаващ фактор в развитието на нативния облак. С GitOps можете да използвате познати инструменти.
3. Събитията като инструмент за интеграция: Веднага щом данните в Git се актуализират, Weave Flux (или операторът Weave Cloud) уведомява времето за изпълнение. Всеки път, когато Kubernetes приеме набор от промени, Git се актуализира. Това осигурява прост интеграционен модел за организиране на работни потоци за GitOps, както е показано по-долу.

Заключение

GitOps предоставя силните гаранции за актуализиране, изисквани от всеки модерен CI/CD инструмент:

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

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

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

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

PS от преводача

Прочетете също в нашия блог:

• «GitOps: Сравнение на методите Pull и Push»;
• «Представяме ви kubedog, библиотека за проследяване на ресурси на Kubernetes»;
• «Разширяване и допълване на Kubernetes (преглед и видео отчет)".

В анкетата могат да участват само регистрирани потребители. Впиши се, Моля те.

Знаете ли за GitOps преди тези два превода да се появят на Habré?

• Да, знаех всичко

• Само повърхностно

• Не

35 потребители гласуваха. 10 потребители се въздържаха.

Източник: www.habr.com