Што е GitOps базиран на агенти и како се разликува од CI/CD?

GitOps е развојна методологија која се залага за користење верзии на датотеки во складишта за контрола на изворот за дефинирање и управување со вашата инфраструктура. Изразувањето на вашата архитектура како декларативни датотеки обезбедува начин да се испита моменталната конфигурација на вашиот систем, да се спојат промените од повеќе придонесувачи и да се вратите во претходната состојба.

Досега овој пристап звучи слично на Infrastructure as Code (IaC). Сепак, GitOps е повеќе од обична IaC: успешната имплементација ќе инкорпорира автоматизиран механизам за примена на вашите конфигурациски датотеки во живи инфраструктурни компоненти. Спојувањето на промените треба да предизвика состојбата на вашата инфраструктура да премине кон онаа опишана во ревидираната содржина на складиштето.

Ова бара мост помеѓу вашата платформа за контрола на изворот и вашиот добавувач на инфраструктура, со што ќе се овозможи моменталната состојба да се комуницира меѓу двете. Постојат различни начини на кои овој мост може да се имплементира, при што секој поставува уникатен сет на одговорности на вклучените платформи. Во оваа статија ќе го разгледаме моделот на распоредување базиран на агент (или заснован на повлекување), а потоа ќе го споредиме со пристап базиран на Push.

Што е агент?

GitOps базиран на агенти се однесува на водење процес во вашата инфраструктура што го олеснува вашето распоредување. Процесот е одговорен за одржување на комуникација со платформата за контрола на изворот што ги хостира вашите IaC датотеки.

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

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

Моделот на агентот се разликува од конвенционалниот приказ на континуирана интеграција и континуирано распоредување (CI/CD) со отсекување на концептот на гасоводот поврзан со активирањето. Наместо тоа, постои автоматска јамка за помирување што ги презема промените кога ќе станат достапни. Новите обврзувања и спојувања само индиректно поттикнуваат промена на вашата инфраструктура. Може да помине некое време пред агентот да ги добие новите податоци.

Неколку продавачи нудат агенти кои можат да се користат за имплементација на работните текови на GitOps. GitLab сега го застапува пристапот како нејзин префериран начин за распоредување на Kubernetes, преку GitLab Agent за Kubernetes. Агентот се поврзува со примерот на GitLab од вашиот кластер, а потоа ја олеснува двонасочната комуникација за да се воведат промените и да се испраќаат информации назад во вашите складишта.

Flux by Weaveworks е уште една опција која работи со кое било складиште на Git и вклучува можности за предупредување. Flux сега е проект за инкубатор во рамките на Cloud Native Computing Foundation (CNCF). Работи како оператор на Kubernetes кој ги зема промените направени во вашите поврзани складишта на Git.

Предности на агентот

GitOps базиран на агенти има повеќе предности што го прават привлечен за различни засегнати страни. Прво, постои јасна разлика помеѓу одговорностите: вашата платформа за контрола на изворот е непроменета и не треба да се грижи за врските со вашата инфраструктура. Агентот треба да биде снабден со ингеренциите за складиштето, но инаку е самодоволен. Откако ќе се активира, тесно е фокусиран на откривање и примена на промени.

Оваа поделба на грижи може да ви помогне да ги лоцирате проблемите и причините за неуспесите на распоредувањето. Општо земено, можете веднаш да ја отфрлите платформата за контрола на изворот. Ако е горе и вашата главна филијала ги содржи точните промени, несогласувањата во вистинската состојба на вашата инфраструктура мора да се должат на проблем со синхронизацијата на агентите.

Агентите исто така нудат повисок степен на автоматизација од GitOps базирани на Push. За успешно усвојување на проток базиран на Push, ќе треба да го конфигурирате вашето складиште со акредитиви за вашата инфраструктура и да креирате CI цевки што ги извршуваат точните скрипти за да ги пренесат вашите промени. Тие скрипти ќе треба да се копираат низ сите ваши проекти, да се одржуваат со текот на времето и внимателно да се ракуваат за да се заштитат вашите чувствителни ингеренции.

Системите базирани на агенти доаѓаат без овие грижи. Откако ќе се инсталира агентот, имате корист од робусниот модел на распоредување кој е помалку подложен на промени. Има многу помалку променливи во врска со поврзувањето со складиштето Git отколку успешен пристап до производствена средина како кластерот Kubernetes. Оттука, има смисла да се повлечат промените од поедноставниот систем во покомплексниот.

Друга придобивка е позитивното безбедносно влијание на агентите. Тие работат внатре во вашата инфраструктура за да можете да избегнете нејзино отворање за надворешен пристап. Иако ќе треба да го изложите вашето складиште на Git, ова е многу помалку ризично отколку да обезбедите врата во вашата производна средина. Изложеноста на токен на проектот GitHub е веројатно само да протече изворен код и вашите IaC датотеки - сериозна појава, но таква што бледа во споредба со помислата за губење на производниот токен на сметката Kubernetes. Тоа може да доведе до кражба на податоци, последователна изнуда и неповратен компромис на системот.

Што е со GitOps базирани на притискање?

Алтернативната стратегија е моделот базиран на Push каде што промените се внесуваат во вашата инфраструктура преку вашата платформа за контрола на изворот или посреднички систем. Комуникацијата е иницирана од нешто што работи надвор од околината за распоредување. Притискањата ја принудуваат инфраструктурата да добие нова состојба од контролниот сервер.

GitOps базирани на притисни обично се имплементираат во вашите CI цевки. Го користите овој модел ако имате цевковод што е конфигуриран со врска со кластерот Kubernetes и користите kubectl apply за да креирате распоредувања. Друг пример е цевка која работи rsync за да ја синхронизира содржината на вашето складиште со оддалечен домаќин.

Ограничувањата на овој пристап лежат во неговата неможност да ги понуди предностите поврзани со агентите кои ги опфативме погоре. Треба рачно да го конфигурирате секое складиште со соодветна инфраструктурна врска, да ги отворите вашите околини за надворешен пристап и да преземете одговорност за одржување на вашите скрипти за распоредување со текот на времето.

Сепак, GitOps базиран на Push има некои уникатни придобивки. Еден значаен фактор е неговата вродена блискост: можете да продолжите да ги користите алатките што веќе ги знаете и на кои се потпирате во развојот, како што се kubectl, helm и docker. Ова помага да се минимизираат разликите помеѓу локалното и директното распоредување.

Ракувањето со грешки може да биде и поедноставно. Пристапите засновани на притискање имаат тенденција да се чувствуваат посинхрони што може да биде корисно за идентификување на низата на настани што доведуваат до неуспех. Додека агентите ви даваат јасна почетна точка (самиот агент), тогаш останува да ги филтрирате настаните што одговараат на активностите на тој агент. Тие настани може да опфатат десетици различни проекти и циклуси на помирување. Можноста да се започне од одредено пуштање на гасоводот CI може да биде корисно во обезбедувањето итни повратни информации при дебагирање.

Конечно, постои аргумент дека моделот базиран на Push е всушност поприлагодлив на идните инфраструктурни промени. Усвојувањето на Pulls значи дека го поврзувате вашиот систем со специфичните очекувања на избраниот агент. Ова може брзо да ги комплицира работите ако треба да се распоредите на нова платформа каде што тој агент не е поддржан. Овде е пофлексибилен приодот заснован на притисни скрипти. Тоа ви овозможува да се грижите за повеќе различни средини со инкорпорирање на условна логика што ги презема правилните дејства за целната платформа.

Резиме

GitOps базиран на агенти се однесува на водење активна компонента во вашата инфраструктура која допира до вашето изворно складиште за да преземе и примени промени. Ова го превртува моделот базиран на Push каде што извршувате скрипти во рамките на CI цевките за да креирате распоредувања и да ги примените промените на состојбата.

Работниот тек на Push е вообичаен, лесно разбирлив и содржи некои значајни атракции. Сепак, „повлекувањата“ водени од агенти добиваат поголемо внимание низ екосистемот на облакот, бидејќи продавачите и програмерите ги препознаваат нивните придобивки.

Усвојувањето на пристап базиран на влечење може да го намали одржувањето со текот на времето, да ја подобри безбедноста на вашите средини и да ви помогне да идентификувате неуспеси кога промените не се применуваат. Агентите исто така може да го поедностават поставувањето на периферните функции како што се предупредувања и агрегација на метрика, забрзувајќи ја вашата патека на усвојување на DevOps без рачно спојување сложени CI скрипти.