Што е GitOps?

Забелешка. превод.: По неодамнешното објавување материјал за методите на влечење и туркање во GitOps, видовме интерес за овој модел воопшто, но имаше многу малку публикации на руски јазик на оваа тема (едноставно нема такви на Habré). Затоа, со задоволство ви нудиме превод на друга статија - иако пред речиси една година! — од Weaveworks, чија глава го измисли терминот „GitOps“. Текстот ја објаснува суштината на пристапот и клучните разлики од постоечките.

Пред една година објавивме вовед во GitOps. Тогаш, споделивме како тимот на Weaveworks лансираше SaaS целосно заснован на Kubernetes и разви збир на пропишани најдобри практики за распоредување, управување и следење во домашна средина на облак.

Статијата се покажа популарна. Други луѓе почнаа да зборуваат за GitOps и почнаа да објавуваат нови алатки за git push, развој на, тајни, функции, континуирана интеграција и така натаму. Се појави на нашата веб-страница голем број на публикации и случаи на употреба на GitOps. Но, некои луѓе сè уште имаат прашања. Како моделот се разликува од традиционалниот? инфраструктура како код и континуирана испорака (континуирана испорака)? Дали е неопходно да се користи Kubernetes?

Наскоро сфативме дека е потребен нов опис, нудејќи:

1. Голем број примери и приказни;
2. Специфична дефиниција за GitOps;
3. Споредба со традиционалната континуирана испорака.

Во оваа статија се обидовме да ги покриеме сите овие теми. Обезбедува ажуриран вовед во GitOps и перспектива за развивачи и CI/CD. Ние првенствено се фокусираме на Kubernetes, иако моделот може да се генерализира.

Запознајте го GitOps

Замислете ја Алис. Таа раководи со семејното осигурување, кое нуди здравствено, автомобилско, дом и патничко осигурување на луѓе кои се премногу зафатени за да ги сфатат самите детали за договорите. Нејзиниот бизнис започна како спореден проект кога Алис работеше во банка како научник за податоци. Еден ден сфатила дека може да користи напредни компјутерски алгоритми за поефикасно да ги анализира податоците и да формулира пакети за осигурување. Инвеститорите го финансираа проектот, а сега нејзината компанија носи повеќе од 20 милиони долари годишно и рапидно расте. Во моментов вработува 180 луѓе на различни позиции. Ова вклучува технолошки тим кој ја развива, одржува веб-страницата, базата на податоци и ја анализира базата на клиенти. Тимот од 60 луѓе го предводи Боб, техничкиот директор на компанијата.

Тимот на Боб распоредува производствени системи во облакот. Нивните основни апликации работат на GKE, искористувајќи ги предностите на Kubernetes на Google Cloud. Покрај тоа, тие користат различни алатки за податоци и аналитика во нивната работа.

Семејното осигурување не се обиде да користи контејнери, но се зафати со ентузијазмот на Докер. Компанијата наскоро откри дека GKE го олесни и без напор распоредувањето кластери за тестирање на нови функции. Џенкинс за CI и Кеј беа додадени за да се организира регистарот на контејнери, за Џенкинс беа напишани скрипти кои туркаа нови контејнери и конфигурации на GKE.

Помина некое време. Алис и Боб беа разочарани од перформансите на нивниот избран пристап и неговото влијание врз бизнисот. Воведувањето на контејнери не ја подобри продуктивноста колку што се надеваше тимот. Понекогаш распоредувањата се прекинуваа и не беше јасно дали се виновни промените на кодот. Исто така, се покажа дека е тешко да се следат промените во конфигурацијата. Честопати беше неопходно да се создаде нов кластер и да се префрлат апликациите во него, бидејќи ова беше најлесниот начин да се елиминира нередот што го направи системот. Алис се плашеше дека ситуацијата ќе се влоши како што се развиваше апликацијата (покрај тоа, се подготвуваше нов проект заснован на машинско учење). Боб го автоматизираше поголемиот дел од работата и не разбираше зошто гасоводот е сè уште нестабилен, не се размери добро и периодично бара рачна интервенција?

Потоа дознаа за GitOps. Оваа одлука се покажа токму она што им требаше за самоуверено да продолжат напред.

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

Семејното осигурување одлучува да го имплементира GitOps. Компанијата сега има автоматизиран модел на работа кој е компатибилен со Kubernetes и комбајни брзина со стабилностбидејќи тие:

• откриле дека продуктивноста на тимот се удвоила без никој да полуди;
• престана да служи скрипти. Наместо тоа, тие сега можат да се фокусираат на нови функции и да ги подобрат инженерските методи - на пример, воведување на канаринци и подобрување на тестирањето;
• го подобривме процесот на распоредување, така што тој ретко се распаѓа;
• доби можност да ги врати распоредите по делумни неуспеси без рачна интервенција;
• купена користенаоПоголема доверба во системите за испорака. Алис и Боб открија дека можат да го поделат тимот на тимови за микросервис кои работат паралелно;
• може да направи 30-50 промени во проектот секој ден преку напорите на секоја група и да проба нови техники;
• лесно е да се привлечат нови програмери во проектот, кои имаат можност да воведат ажурирања на производството користејќи барања за повлекување во рок од неколку часа;
• лесно поминува ревизија во рамките на SOC2 (за усогласеност на давателите на услуги со барањата за безбедно управување со податоци; прочитајте повеќе, на пример, тука - прибл. превод.).

Што се случи?

GitOps е две работи:

1. Оперативен модел за Kubernetes и мајчин облак. Обезбедува збир на најдобри практики за распоредување, управување и следење на контејнеризирани кластери и апликации. Елегантна дефиниција во форма еден слајд од Луис Фасеира:
2. Патот до создавање средина за управување со апликации насочена кон развивачите. Го применуваме работниот тек на Git и за операции и за развој. Ве молиме имајте предвид дека ова не е само за Git push, туку и за организирање на целиот сет на алатки за CI/CD и UI/UX.

Неколку зборови за Git

Ако не сте запознаени со системите за контрола на верзии и работниот тек базиран на Git, топло ви препорачуваме да научите за нив. Работата со гранки и барањата за повлекување можеби на почетокот изгледаат како црна магија, но придобивките вредат за трудот. Еве добра статија да започне.

Како функционира Kubernetes

Во нашата приказна, Алис и Боб се свртеа кон GitOps откако работеа со Kubernetes некое време. Навистина, GitOps е тесно поврзан со Kubernetes - тоа е оперативен модел за инфраструктура и апликации базирани на Kubernetes.

Што им дава Kubernetes на корисниците?

Еве неколку главни карактеристики:

1. Во моделот Кубернетес, сè може да се опише во декларативна форма.
2. Серверот Kubernetes API ја зема оваа декларација како влез и потоа постојано се обидува да го доведе кластерот во состојбата опишана во декларацијата.
3. Декларациите се доволни за опишување и управување со широк спектар на оптоварувања - „апликации“.
4. Како резултат на тоа, промените во апликацијата и кластерот се случуваат поради:
   • промени во сликите на контејнерите;
   • промени во декларативната спецификација;
   • грешки во околината - на пример, паѓа контејнер.

Големите способности за конвергенција на Кубернетес

Кога администраторот прави промени во конфигурацијата, оркестраторот на Kubernetes ќе ги примени во кластерот се додека неговата состојба е нема да се приближи до новата конфигурација. Овој модел работи за секој ресурс на Кубернетес и може да се прошири со прилагодени дефиниции на ресурси (CRD). Затоа, распоредувањата на Kubernetes ги имаат следниве прекрасни својства:

• Автоматизација: Ажурирањата на Kubernetes обезбедуваат механизам за автоматизирање на процесот на благодатно и навремено примена на промените.
• Конвергенција: Kubernetes ќе продолжи да се обидува со ажурирања додека не успее.
• Идемпотенција: Повторените апликации на конвергенција доведуваат до истиот резултат.
• Детерминизам: Кога ресурсите се доволни, состојбата на ажурираниот кластер зависи само од посакуваната состојба.

Како функционира GitOps

Доволно научивме за Kubernetes за да објасниме како функционира GitOps.

Да се ​​вратиме на микросервисните тимови на Family Insurance. Што обично треба да прават? Погледнете ја листата подолу (ако некои ставки во него изгледаат чудни или непознати, ве молиме воздржете се да критикувате и останете со нас). Ова се само примери на работни текови базирани на Џенкинс. Има многу други процеси при работа со други алатки.

Главната работа е што гледаме дека секое ажурирање завршува со промени во конфигурациските датотеки и складиштата на Git. Овие промени на Git предизвикуваат „операторот GitOps“ да го ажурира кластерот:

1. Работен процес:Џенкинс изгради - господар гранка".
Список со задачи:

• Џенкинс ги турка означените слики на Кејот;
• Џенкинс ги турка конфигурациските графикони и Helm графиконите до главната кофа за складирање;
• Функцијата облак ги копира конфигурацијата и графиконите од главната кофа за складирање во главниот складиште Git;
• Операторот GitOps го ажурира кластерот.

2. Џенкинс изгради - гранка за ослободување или жешка поправка:

• Џенкинс ги турка неозначените слики на Кејот;
• Џенкинс ги турка конфигурациските графикони и Helm графиконите во кофата за складирање на сцена;
• Функцијата облак ги копира конфигурацијата и графиконите од кофата за складирање на сцена во складиштето за поставување на Git;
• Операторот GitOps го ажурира кластерот.

3. Џенкинс изгради - развива или прикажува гранка:

• Џенкинс ги турка неозначените слики на Кејот;
• Џенкинс ги турка графиконите за конфигурација и Helm во кофата за складирање развој;
• Функцијата облак ги копира конфигурацијата и графиконите од кофата за развој на складирање во складиштето за развој на Git;
• Операторот GitOps го ажурира кластерот.

4. Додавање нов клиент:

• Менаџерот или администраторот (LCM/ops) го повикува Gradle првично да ги распореди и конфигурира мрежните балансери на оптоварување (NLB);
• LCM/ops извршува нова конфигурација за да го подготви распоредувањето за ажурирања;
• Операторот GitOps го ажурира кластерот.

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

1. Опишете ја саканата состојба на целиот систем користејќи декларативни спецификации за секоја средина (во нашата приказна, тимот на Боб ја дефинира целата конфигурација на системот во Git).
   • Репозиториумот Git е единствениот извор на вистината во однос на посакуваната состојба на целиот систем.
   • Сите промени во посакуваната состојба се прават преку заложби во Git.
   • Сите посакувани параметри на кластерот исто така се набљудуваат во самиот кластер. На овој начин можеме да утврдиме дали тие се совпаѓаат (конвергираат, конвергираат) или се разликуваат (разминуваат, се разминуваат) посакуваните и набљудуваните состојби.
2. Ако посакуваните и набљудуваните состојби се разликуваат, тогаш:
   • Постои механизам за конвергенција кој порано или подоцна автоматски ги синхронизира целните и набљудуваните состојби. Внатре во кластерот, Кубернетес го прави ова.
   • Процесот започнува веднаш со предупредување „површена промена“.
   • По одреден временски период што може да се конфигурира, може да се испрати предупредување „разлика“ доколку состојбите се различни.
3. На овој начин, сите обврски во Git предизвикуваат проверливи и немоќни ажурирања на кластерот.
   • Враќање е конвергенција кон претходно посакуваната состојба.
4. Конвергенцијата е конечна. Неговата појава е означена со:
   • Нема предупредувања за разлика за одреден временски период.
   • „конвергирана“ тревога (на пр. webhook, настан за враќање на Git).

Што е дивергенција?

Да повториме уште еднаш: сите посакувани својства на кластерот мора да бидат забележливи во самиот кластер.

Некои примери на дивергенција:

• Промена во конфигурациската датотека поради спојување гранки во Git.
• Промена во конфигурациската датотека поради Git commit направен од клиентот GUI.
• Повеќекратни промени во саканата состојба поради PR во Git проследени со градење на сликата на контејнерот и промени во конфигурацијата.
• Промена во состојбата на кластерот поради грешка, конфликт со ресурси што резултира со „лошо однесување“ или едноставно случајно отстапување од првобитната состојба.

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

Неколку примери:

• За контејнери и кластери, механизмот за конвергенција е обезбеден од Kubernetes.
• Истиот механизам може да се користи за управување со апликации и дизајни базирани на Kubernetes (како што се Istio и Kubeflow).
• Обезбедува механизам за управување со оперативната интеракција помеѓу Kubernetes, складишта за слики и Git GitOps оператор Weave Flux, кој е дел Ткаат облак.
• За основните машини, механизмот за конвергенција мора да биде декларативен и автономен. Од сопственото искуство можеме да го кажеме тоа Terraform најблиску до оваа дефиниција, но сепак бара човечка контрола. Во оваа смисла, GitOps ја проширува традицијата на Infrastructure as Code.

GitOps го комбинира Git со одличниот мотор за конвергенција на Kubernetes за да обезбеди модел за експлоатација.

GitOps ни овозможува да кажеме: Само оние системи што можат да се опишат и набљудуваат може да се автоматизираат и контролираат.

GitOps е наменет за целиот магацин на облак (на пример, Terraform, итн.)

GitOps не е само Kubernetes. Сакаме целиот систем да се вози декларативно и да користи конвергенција. Под целиот систем подразбираме збирка средини кои работат со Kubernetes - на пример, „dev кластер 1“, „производство“ итн. Секоја средина вклучува машини, кластери, апликации, како и интерфејси за надворешни услуги кои обезбедуваат податоци, мониторинг и сл.

Забележете колку Terraform е важен за проблемот со подигање во овој случај. Kubernetes мора да се распореди некаде, а користењето на Terraform значи дека можеме да ги примениме истите работни текови на GitOps за да создадеме контролен слој што ги потпира Kubernetes и апликациите. Ова е корисна најдобра практика.

Има силен фокус на примена на концептите на GitOps на слоеви на врвот на Кубернет. Во моментов, постојат решенија од типот GitOps за Istio, Helm, Ksonnet, OpenFaaS и Kubeflow, како и, на пример, за Pulumi, кои создаваат слој за развој на апликации за cloud native.

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

Како што е наведено, GitOps е две работи:

1. Моделот на работа за Kubernetes и мајчин облак опишан погоре.
2. Патот до опкружување за управување со апликации насочени кон развивачите.

За многумина, GitOps е првенствено работен тек заснован на Git pushs. И тој ни се допаѓа. Но, тоа не е сè: ајде сега да ги погледнеме цевководите CI/CD.

GitOps овозможува континуирано распоредување (ЦД) за Kubernetes

GitOps нуди механизам за континуирано распоредување што ја елиминира потребата од посебни „системи за управување со распоредувањето“. Kubernetes ја врши целата работа за вас.

• Ажурирањето на апликацијата бара ажурирање во Git. Ова е трансакциско ажурирање до посакуваната состојба. „Распоредувањето“ потоа се врши во кластерот од самиот Кубернетес врз основа на ажурираниот опис.
• Поради природата на тоа како функционира Kubernetes, овие ажурирања се конвергентни. Ова обезбедува механизам за континуирано распоредување во кое сите ажурирања се атомски.
• Забелешка: Ткаат облак нуди GitOps оператор кој ги интегрира Git и Kubernetes и дозволува ЦД да се изведува со усогласување на саканата и моменталната состојба на кластерот.

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

Треба да избегнувате користење на Kubectl за ажурирање на вашиот кластер, а особено избегнувајте користење скрипти за групирање на команди на kubectl. Наместо тоа, со гасоводот GitOps, корисникот може да го ажурира својот кластер Kubernetes преку Git.

Придобивките вклучуваат:

1. Во право. Група ажурирања може да се применат, конвергираат и конечно да се потврдат, што нè доближува до целта за атомско распоредување. Спротивно на тоа, користењето скрипти не дава никаква гаранција за конвергенција (повеќе за ова подолу).
2. безбедност. Цитирање Келси Хајтауер: „Ограничете го пристапот до вашиот кластер Kubernetes на алатките за автоматизација и администраторите кои се одговорни за дебагирање или одржување“. исто така види мојата публикација за безбедноста и усогласеноста со техничките спецификации, како и статија за хакирање на Homebrew со кражба на ингеренциите од невнимателно напишаното сценарио на Џенкинс.
3. Корисничко искуство. Кубектл ја изложува механиката на моделот на објекти Кубернетес, кои се доста сложени. Идеално, корисниците треба да комуницираат со системот на повисоко ниво на апстракција. Тука повторно ќе се осврнам на Келси и ќе препорачам да гледате таква биографија.

Разлика помеѓу CI и CD

GitOps ги подобрува постоечките модели CI/CD.

Модерен CI сервер е оркестрациона алатка. Особено, тоа е алатка за оркестрирање на цевководи CI. Тие вклучуваат изградба, тестирање, спојување во багажникот итн. CI серверите го автоматизираат управувањето со сложени повеќестепени цевководи. Вообичаено искушение е да се скриптира збир на ажурирања на Kubernetes и да се изврши како дел од гасоводот за да се поттикнат промените во кластерот. Навистина, тоа е она што го прават многу експерти. Сепак, ова не е оптимално, а еве зошто.

CI треба да се користи за притискање на ажурирањата до багажникот, а кластерот Kubernetes треба да се промени самиот врз основа на тие ажурирања за да управува со ЦД-то внатрешно. Ние го нарекуваме влече модел за ЦД, за разлика од моделот CI push. ЦД-то е дел траење оркестрација.

Зошто CI серверите не треба да прават ЦД-а преку директни ажурирања во Kubernetes

Не користете CI сервер за оркестрирање на директни ажурирања на Kubernetes како збир на CI задачи. Ова е анти-шаблонот за кој зборуваме веќе кажано на вашиот блог.

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

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

Да претпоставиме дека тимот на Боб изградил нова слика и потоа ги закрпила нивните распоредувања за да ја распоредат сликата (сите од гасоводот CI).

Ако сликата се изгради нормално, но гасоводот не успее, тимот ќе мора да открие:

• Дали излезе ажурирањето?
• Дали лансираме нова градба? Дали ова ќе доведе до непотребни нуспојави - со можност да има две градби со иста непроменлива слика?
• Дали треба да го чекаме следното ажурирање пред да ја извршиме изградбата?
• Што точно тргна наопаку? Кои чекори треба да се повторат (и кои се безбедни за повторување)?

Воспоставувањето на работен тек заснован на Git не гарантира дека тимот на Боб нема да се соочи со овие проблеми. Тие сè уште можат да направат грешка со притискањето за извршување, ознаката или некој друг параметар; сепак, овој пристап е сè уште многу поблиску до експлицитен пристап „се или ништо“.

Да резимираме, еве зошто CI серверите не треба да се занимаваат со ЦД:

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

Забелешка за Helm: Ако сакате да го користите Helm, препорачуваме да го комбинирате со GitOps оператор како на пр. Флукс-Хелм. Ова ќе помогне да се обезбеди конвергенција. Самиот шлем не е ниту детерминистички ниту атомски.

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 алатка:

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

Ова е важно затоа што нуди оперативен модел за родните развивачи на облак.

• Традиционалните алатки за управување и следење на системите се поврзани со оперативните тимови кои работат во рамките на книгата (збир на рутински процедури и операции - прибл. превод.), врзани за одредено распоредување.
• Во управувањето со мајчин облак, алатките за набљудување се најдобриот начин за мерење на резултатите од распоредувањата, така што тимот за развој може брзо да реагира.

Замислете многу кластери расфрлани низ различни облаци и многу услуги со свои тимови и планови за распоредување. GitOps нуди непроменлив модел за управување со сето ова изобилство.

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

Прочитајте и на нашиот блог:

• «GitOps: Споредба на методите за повлекување и туркање";
• «Воведување на kubedog, библиотека за следење на ресурсите на Kubernetes";
• «Проширување и дополнување на Kubernetes (преглед и видео извештај)".

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

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

• Да, знаев сè

• Само површно

• Не

Гласаа 35 корисници. 10 корисници беа воздржани.

Извор: www.habr.com