Белешка. трансл.: Након недавне публикације о методама повлачења и гурања у ГитОпс-у, видели смо интересовање за овај модел уопште, али је било врло мало публикација на руском језику на ову тему (једноставно их нема на Хабре). Стога нам је задовољство понудити вашој пажњи превод још једног чланка - иако пре скоро годину дана! — из Веавеворкс-а, чији је шеф сковао термин „ГитОпс“. Текст објашњава суштину приступа и кључне разлике од постојећих.
Пре годину дана објавили смо . Тада смо поделили како је тим Веавеворкс-а покренуо СааС у потпуности заснован на Кубернетес-у и развио скуп прописаних најбољих пракси за примену, управљање и надгледање у природном окружењу у облаку.
Испоставило се да је чланак популаран. Други људи су почели да причају о ГитОпс-у и почели да објављују нове алате за , , , , и тако даље. Појавио се на нашој веб страници публикације и случајеви коришћења ГитОпс-а. Али неки људи и даље имају питања. По чему се модел разликује од традиционалног? и континуирана испорука ()? Да ли је потребно користити Кубернетес?
Убрзо смо схватили да је потребан нови опис, који нуди:
- Велики број примера и прича;
- Специфична дефиниција ГитОпс-а;
- Поређење са традиционалном континуираном испоруком.
У овом чланку смо покушали да покријемо све ове теме. Пружа ажурирани увод у ГитОпс и перспективу програмера и ЦИ/ЦД-а. Ми се првенствено фокусирамо на Кубернетес, иако се модел може генерализовати.
Упознајте ГитОпс
Замисли Алице. Она води породично осигурање, које нуди здравствено, аутомобилско, кућно и путно осигурање људима који су превише заузети да би сами схватили све недостатке уговора. Њен посао је почео као споредни пројекат када је Алис радила у банци као научник за податке. Једног дана је схватила да може да користи напредне компјутерске алгоритме за ефикаснију анализу података и формулисање пакета осигурања. Инвеститори су финансирали пројекат, а сада њена компанија доноси више од 20 милиона долара годишње и брзо расте. Тренутно запошљава 180 људи на различитим позицијама. Ово укључује технолошки тим који развија, одржава веб локацију, базу података и анализира базу клијената. Тим од 60 људи предводи Боб, технички директор компаније.
Бобов тим поставља производне системе у облаку. Њихове основне апликације раде на ГКЕ-у, користећи предности Кубернетес-а на Гоогле Цлоуд-у. Осим тога, у свом раду користе различите алате за податке и аналитику.
Породично осигурање није намеравало да користи контејнере, али је било ухваћено у Доцкер ентузијазам. Компанија је убрзо открила да је ГКЕ олакшао постављање кластера за тестирање нових функција. Јенкинс за ЦИ и Куаи су додати да би се организовао регистар контејнера, скрипте су написане за Јенкинс које су гурнуле нове контејнере и конфигурације у ГКЕ.
Прошло је неко време. Алис и Боб су били разочарани учинком свог изабраног приступа и његовим утицајем на пословање. Увођење контејнера није побољшало продуктивност онолико колико се тим надао. Понекад би се имплементације поквариле и није било јасно да ли су за то криве промене кода. Такође се показало да је тешко пратити промене у конфигурацији. Често је било потребно направити нови кластер и преместити апликације у њега, јер је то био најлакши начин да се елиминише неред који је систем постао. Алис се плашила да ће се ситуација погоршати како се апликација развија (поред тога, спремао се нови пројекат заснован на машинском учењу). Боб је аутоматизовао већину посла и није разумео зашто је цевовод још увек нестабилан, није добро скалирао и захтевао је повремено ручну интервенцију?
Онда су сазнали за ГитОпс. Испоставило се да је ова одлука била управо оно што им је било потребно да самоуверено иду напред.
Алис и Боб су годинама слушали о Гиту, ДевОпс-у и инфраструктури као токовима посла кода. Оно што је јединствено у вези са ГитОпс-ом је то што доноси скуп најбољих пракси — и дефинитивних и нормативних — за примену ових идеја у контексту Кубернетеса. Ова тема , укључујући у .
Породично осигурање одлучује да примени ГитОпс. Компанија сада има модел аутоматизованог рада који је компатибилан са Кубернетес-ом и комбајнима брзина са стабилностзато што они:
- открили да се продуктивност тима удвостручила, а да нико није полудео;
- престао да сервира скрипте. Уместо тога, сада се могу фокусирати на нове функције и побољшати инжењерске методе – на пример, увођење канаринца и побољшање тестирања;
- побољшали смо процес распоређивања тако да се ретко квари;
- добили прилику да поврате распоређивање након делимичних отказа без ручне интервенције;
- купљен половниоВеће поверење у системе испоруке. Алис и Боб су открили да могу да поделе тим на микросервисне тимове који раде паралелно;
- може да направи 30-50 промена на пројекту сваког дана кроз напоре сваке групе и испроба нове технике;
- лако је привући нове програмере у пројекат, који имају прилику да унесу ажурирања за производњу користећи захтеве за повлачење у року од неколико сати;
- лако проћи ревизију у оквиру СОЦ2 (за усаглашеност добављача услуга са захтевима за безбедно управљање подацима; прочитајте више, нпр. — прибл. превод).
Шта се десило?
ГитОпс су две ствари:
- Оперативни модел за Кубернетес и изворни облак. Пружа скуп најбољих пракси за примену, управљање и надгледање контејнерских кластера и апликација. Елегантна дефиниција у форми из :
- Пут ка стварању окружења за управљање апликацијама усмереног на програмере. Гит ток рада примењујемо и на операције и на развој. Имајте на уму да се не ради само о Гит пусху, већ о организовању читавог скупа ЦИ/ЦД и УИ/УКС алата.
Неколико речи о Гиту
Ако нисте упознати са системима контроле верзија и током рада заснованим на Гит-у, топло препоручујемо да научите о њима. Рад са гранама и захтевима за повлачење може у почетку изгледати као црна магија, али предности су вредне труда. Ево за почетак.
Како функционише Кубернетес
У нашој причи, Алице и Боб су се окренули ГитОпс-у након што су неко време радили са Кубернетес-ом. Заиста, ГитОпс је блиско повезан са Кубернетес-ом – то је оперативни модел за инфраструктуру и апликације засноване на Кубернетес-у.
Шта Кубернетес даје корисницима?
Ево неких главних карактеристика:
- У Кубернетес моделу све се може описати у декларативном облику.
- Кубернетес АПИ сервер узима ову декларацију као улаз и затим непрестано покушава да доведе кластер у стање описано у декларацији.
- Декларације су довољне да опишу и управљају широким спектром радних оптерећења — „апликација“.
- Као резултат тога, промене у апликацији и кластеру настају због:
- промене у сликама контејнера;
- измене декларативне спецификације;
- грешке у окружењу - на пример, пад контејнера.
Кубернетесове велике могућности конвергенције
Када администратор изврши промене конфигурације, Кубернетес оркестратор ће их применити на кластер све док је његово стање неће се приближити новој конфигурацији. Овај модел ради за било који Кубернетес ресурс и проширив је са прилагођеним дефиницијама ресурса (ЦРД). Стога, Кубернетес имплементације имају следећа дивна својства:
- Аутоматизација: Кубернетес ажурирања обезбеђују механизам за аутоматизацију процеса примене промена на грациозан и благовремен начин.
- Конвергенција: Кубернетес ће наставити да покушава да ажурира све док не успе.
- Идемпотенција: Поновљене примене конвергенције доводе до истог резултата.
- Детерминизам: Када су ресурси довољни, стање ажурираног кластера зависи само од жељеног стања.
Како функционише ГитОпс
Научили смо довољно о Кубернетесу да објаснимо како ГитОпс функционише.
Вратимо се тимовима микросервиса Породичног осигурања. Шта обично морају да раде? Погледајте листу испод (ако вам се било која ставка у њој чини чудном или непознатом, молимо вас да престанете да критикујете и останите са нама). Ово су само примери токова рада заснованих на Џенкинсу. Постоји много других процеса када радите са другим алатима.
Главна ствар је да видимо да се свако ажурирање завршава променама у конфигурационим датотекама и Гит репозиторијумима. Ове промене у Гиту узрокују да „ГитОпс оператор“ ажурира кластер:
1. Процес рада: "Јенкинс буилд - мастер грана'.
Листа задатака:
- Џенкинс гура означене слике на Кеј;
- Џенкинс гура конфигурационе и Хелм графиконе у главну корпу за складиштење;
- Функција облака копира конфигурацију и графиконе из главног складишта у главно Гит спремиште;
- ГитОпс оператер ажурира кластер.
2. Јенкинс буилд - издање или грана хитне исправке:
- Џенкинс гура неозначене слике на Кеј;
- Џенкинс гура конфигурационе и Хелм графиконе у сценографски део за складиштење;
- Функција облака копира конфигурацију и графиконе из стадијума за складиштење у пробно Гит спремиште;
- ГитОпс оператер ажурира кластер.
3. Јенкинс гради - развија или представља грану:
- Џенкинс гура неозначене слике на Кеј;
- Џенкинс гура конфигурационе и Хелм графиконе у развојну канту за складиштење;
- Функција облака копира конфигурацију и графиконе из развојног простора за складиштење у развојно Гит спремиште;
- ГитОпс оператер ажурира кластер.
4. Додавање новог клијента:
- Менаџер или администратор (ЛЦМ/опс) позива Градле да иницијално постави и конфигурише балансере мрежног оптерећења (НЛБ);
- ЛЦМ/опс урезује нову конфигурацију да би припремио примену за ажурирања;
- ГитОпс оператер ажурира кластер.
Кратак опис ГитОпс-а
- Опишите жељено стање целог система користећи декларативне спецификације за свако окружење (у нашој причи, Бобов тим дефинише целу конфигурацију система у Гиту).
- Гит репозиторијум је једини извор истине у вези са жељеним стањем целог система.
- Све промене у жељено стање се врше путем урезивања у Гиту.
- Сви жељени параметри кластера су такође видљиви у самом кластеру. На тај начин можемо утврдити да ли се поклапају (конвергирају, тежити заједничком резултату) или се разликују (разилазе се, диверге) жељена и посматрана стања.
- Ако се жељена и посматрана стања разликују, онда:
- Постоји механизам конвергенције који пре или касније аутоматски синхронизује циљно и посматрано стање. Унутар кластера, Кубернетес то ради.
- Процес почиње одмах са упозорењем „измена извршена“.
- Након одређеног временског периода који се може подесити, може се послати упозорење „дифф“ ако су стања различита.
- На овај начин, сва урезивања у Гиту изазивају проверљива и идемпотентна ажурирања кластера.
- Враћање је конвергенција у претходно жељено стање.
- Конвергенција је коначна. На њену појаву указује:
- Нема упозорења о разликама током одређеног временског периода.
- „конвергентно“ упозорење (нпр. вебхоок, Гит догађај повратног уписивања).
Шта је дивергенција?
Поновимо поново: сва жељена својства кластера морају бити видљива у самом кластеру.
Неки примери дивергенције:
- Промена конфигурационе датотеке због спајања грана у Гиту.
- Промена у конфигурационој датотеци због Гит урезивања коју је направио ГУИ клијент.
- Вишеструке промене у жељено стање због ПР-а у Гиту праћене изградњом слике контејнера и променама конфигурације.
- Промена стања кластера услед грешке, конфликт ресурса који резултира „лошим понашањем“, или једноставно насумично одступање од првобитног стања.
Који је механизам конвергенције?
Неколико примера:
- За контејнере и кластере, механизам конвергенције обезбеђује Кубернетес.
- Исти механизам се може користити за управљање апликацијама и дизајном заснованим на Кубернетес-у (као што су Истио и Кубефлов).
- Обезбеђује механизам за управљање оперативном интеракцијом између Кубернетеса, складишта слика и Гита , што је део .
- За основне машине, механизам конвергенције мора бити декларативан и аутономан. Из сопственог искуства то можемо рећи најближе овој дефиницији, али ипак захтева људску контролу. У том смислу, ГитОпс проширује традицију инфраструктуре као кода.
ГитОпс комбинује Гит са одличним механизмом за конвергенцију Кубернетес-а да би обезбедио модел за експлоатацију.
ГитОпс нам омогућава да кажемо: Само они системи који се могу описати и посматрати могу се аутоматизовати и контролисати.
ГитОпс је намењен за цео нативни стек облака (на пример, Терраформ, итд.)
ГитОпс није само Кубернетес. Желимо да цео систем буде вођен декларативно и да користи конвергенцију. Под целим системом подразумевамо колекцију окружења која раде са Кубернетес-ом – на пример, „дев кластер 1“, „производња“ итд. Свако окружење укључује машине, кластере, апликације, као и интерфејсе за спољне сервисе који обезбеђују податке, праћење и сл.
Обратите пажњу на то колико је Терраформ важан за проблем покретања у овом случају. Кубернетес се негде мора применити, а коришћење Терраформа значи да можемо применити исте ГитОпс токове рада да бисмо креирали контролни слој који подупире Кубернетес и апликације. Ово је корисна најбоља пракса.
Снажан фокус је на примени ГитОпс концепата на слојеве на врху Кубернетеса. Тренутно постоје решења типа ГитОпс за Истио, Хелм, Ксоннет, ОпенФааС и Кубефлов, као и, на пример, за Пулуми, који стварају слој за развој апликација за нативе цлоуд.
Кубернетес ЦИ/ЦД: поређење ГитОпс-а са другим приступима
Као што је речено, ГитОпс су две ствари:
- Оперативни модел за Кубернетес и Цлоуд изворно описан горе.
- Пут до окружења за управљање апликацијама усмереног на програмере.
За многе, ГитОпс је првенствено ток посла заснован на Гит пусху. И нама се свиђа. Али то није све: хајде да сада погледамо ЦИ/ЦД цевоводе.
ГитОпс омогућава континуирано примену (ЦД) за Кубернетес
ГитОпс нуди континуирани механизам за примену који елиминише потребу за одвојеним „системима за управљање применом“. Кубернетес ради сав посао за вас.
- Ажурирање апликације захтева ажурирање у Гиту. Ово је трансакцијско ажурирање до жељеног стања. „Распоређивање“ затим врши сам Кубернетес унутар кластера на основу ажурираног описа.
- Због природе начина на који Кубернетес функционише, ова ажурирања су конвергентна. Ово обезбеђује механизам за континуирано примену у коме су сва ажурирања атомска.
- Напомена: нуди ГитОпс оператор који интегрише Гит и Кубернетес и омогућава извођење ЦД-а усклађивањем жељеног и тренутног стања кластера.
Без кубецтла и скрипти
Требало би да избегавате коришћење Кубецтл-а за ажурирање кластера, а посебно избегавајте коришћење скрипти за груписање кубецтл команди. Уместо тога, са ГитОпс цевоводом, корисник може да ажурира свој Кубернетес кластер преко Гита.
Предности укључују:
- Јел тако. Група ажурирања се може применити, конвергирати и коначно потврдити, приближавајући нас циљу атомске примене. Насупрот томе, коришћење скрипти не даје никакву гаранцију конвергенције (више о томе у наставку).
- безбедност. Келсеи Хигхтовер: „Ограничите приступ вашем Кубернетес кластеру на алате за аутоматизацију и администраторе који су одговорни за његово отклањање грешака или одржавање.“ такође видети о безбедности и усклађености са техничким спецификацијама, као и крађом акредитива из немарно написаног Џенкинсовог сценарија.
- Корисничко искуство. Кубецтл излаже механику Кубернетес објектног модела, која је прилично сложена. У идеалном случају, корисници би требало да комуницирају са системом на вишем нивоу апстракције. Овде ћу се поново осврнути на Келсеи и препоручити гледање .
Разлика између ЦИ и ЦД-а
ГитОпс побољшава постојеће ЦИ/ЦД моделе.
Савремени ЦИ сервер је оркестарски алат. Конкретно, то је алат за оркестрирање ЦИ цевовода. То укључује прављење, тестирање, спајање у трунк, итд. ЦИ сервери аутоматизују управљање сложеним цевоводима у више корака. Уобичајено искушење је да скриптујете скуп Кубернетес ажурирања и покренете га као део цевовода да бисте унели промене у кластер. Заиста, то је оно што многи стручњаци раде. Међутим, ово није оптимално, а ево зашто.
ЦИ би требало да се користи за пребацивање ажурирања у трунк, а Кубернетес кластер би требало да се мења на основу тих ажурирања да би интерно управљао ЦД-ом. Ми то зовемо , за разлику од ЦИ пусх модела. ЦД је део рунтиме оркестрација.
Зашто ЦИ сервери не би требало да праве ЦД-ове путем директних ажурирања у Кубернетесу
Немојте користити ЦИ сервер за оркестрирање директних ажурирања Кубернетес-а као скупа ЦИ послова. Ово је анти-образац о коме говоримо на свом блогу.
Вратимо се Алис и Бобу.
Са каквим су се проблемима суочили? Бобов ЦИ сервер примењује промене на кластер, али ако дође до пада у процесу, Боб неће знати у ком је стању (или би требало да буде) кластер нити како да то поправи. Исто важи и за случај успеха.
Претпоставимо да је Бобов тим направио нову слику, а затим закрпио своје примене да би поставио слику (све из ЦИ цевовода).
Ако се слика нормално гради, али цевовод не успе, тим ће морати да схвати:
- Да ли је ажурирање објављено?
- Да ли покрећемо нову изградњу? Да ли ће то довести до непотребних нуспојава - са могућношћу да имате две верзије исте непроменљиве слике?
- Да ли треба да сачекамо следеће ажурирање пре него што покренемо градњу?
- Шта је тачно пошло наопако? Које кораке треба поновити (и који су сигурни за понављање)?
Успостављање тока рада заснованог на Гиту не гарантује да се Бобов тим неће сусрести са овим проблемима. Они и даље могу да погреше са притиском на урезивање, ознаком или неким другим параметром; међутим, овај приступ је и даље много ближи експлицитном приступу на све или ништа.
Да резимирамо, ево зашто ЦИ сервери не би требало да се баве ЦД-ом:
- Скрипте за ажурирање нису увек детерминистичке; У њима је лако погрешити.
- ЦИ сервери се не приближавају декларативном моделу кластера.
- Тешко је гарантовати идемпотенцију. Корисници морају разумети дубоку семантику система.
- Теже је опоравити се од делимичног неуспеха.
Напомена о Хелм-у: Ако желите да користите Хелм, препоручујемо да га комбинујете са ГитОпс оператором као што је . Ово ће помоћи да се обезбеди конвергенција. Сам Хелм није ни детерминистички ни атомски.
ГитОпс као најбољи начин за имплементацију континуиране испоруке за Кубернетес
Алис и Бобов тим имплементира ГитОпс и открива да је постало много лакше радити са софтверским производима, одржавати високе перформансе и стабилност. Завршимо овај чланак илустрацијом која показује како изгледа њихов нови приступ. Имајте на уму да углавном говоримо о апликацијама и услугама, али ГитОпс се може користити за управљање читавом платформом.
Оперативни модел за Кубернетес
Погледајте следећи дијаграм. Он представља Гит и складиште слика контејнера као дељене ресурсе за два оркестрирана животна циклуса:
- Континуирани цевовод за интеграцију који чита и уписује датотеке у Гит и може ажурирати спремиште слика контејнера.
- Рунтиме ГитОпс цевовод који комбинује примену са управљањем и видљивошћу. Чита и уписује датотеке у Гит и може да преузима слике контејнера.
Који су главни налази?
- Одвајање од забринутости: Имајте на уму да оба цевовода могу да комуницирају само ажурирањем Гита или спремишта слика. Другим речима, постоји заштитни зид између ЦИ и окружења за извршавање. Ми то зовемо „заштитни зид непроменљивости“ (заштитни зид непроменљивости), пошто сва ажурирања спремишта стварају нове верзије. За више информација о овој теми погледајте слајдове 72-87 .
- Можете користити било који ЦИ и Гит сервер: ГитОпс ради са било којом компонентом. Можете наставити да користите своје омиљене ЦИ и Гит сервере, спремишта слика и тестне пакете. Скоро сви остали алати за континуирану испоруку на тржишту захтевају сопствени ЦИ/Гит сервер или спремиште слика. Ово може постати ограничавајући фактор у развоју изворног облака. Уз ГитОпс, можете користити познате алате.
- Догађаји као средство интеграције: Чим се подаци у Гиту ажурирају, Веаве Флук (или оператер Веаве Цлоуд) обавештава време извођења. Кад год Кубернетес прихвати скуп промена, Гит се ажурира. Ово обезбеђује једноставан модел интеграције за организовање токова посла за ГитОпс, као што је приказано у наставку.
Закључак
ГитОпс пружа снажне гаранције ажурирања које захтева сваки савремени ЦИ/ЦД алат:
- аутоматизација;
- конвергенција;
- идемпотенција;
- детерминизам.
Ово је важно јер нуди оперативни модел за програмере који се налазе у облаку.
- Традиционални алати за управљање и праћење система су повезани са оперативним тимовима који раде у оквиру рунбоок-а (скуп рутинских процедура и операција – прибл. прев.), везано за конкретну примену.
- У изворном управљању у облаку, алати за посматрање су најбољи начин за мерење резултата имплементације тако да развојни тим може брзо да реагује.
Замислите много кластера разбацаних по различитим облацима и многим услугама са сопственим тимовима и плановима примене. ГитОпс нуди модел непроменљивог размера за управљање свим овим обиљем.
ПС од преводиоца
Прочитајте и на нашем блогу:
- «";
- «";
- «'.
Само регистровани корисници могу учествовати у анкети. , Добродошао си.
Да ли сте знали за ГитОпс пре него што су се ова два превода појавила на Хабре?
-
Да, знао сам све
-
Само површно
-
Не
Гласало је 35 корисника. Уздржано је било 10 корисника.
Извор: ввв.хабр.цом