Çfarë është GitOps i bazuar në agjentë dhe si ndryshon nga CI/CD?
GitOps është një metodologji zhvillimi që mbron përdorimin e skedarëve të versionuar në depot e kontrollit të burimit për të përcaktuar dhe menaxhuar infrastrukturën tuaj. Shprehja e arkitekturës suaj si skedarë deklarativë ofron një mënyrë për të inspektuar konfigurimin aktual të sistemit tuaj, për të bashkuar ndryshimet nga shumë kontribues dhe për të rikthyer në një gjendje të mëparshme.
Deri më tani kjo qasje tingëllon e ngjashme me Infrastrukturën si Kodi (IaC). Megjithatë, GitOps është më shumë se thjesht IaC: një zbatim i suksesshëm do të përfshijë një mekanizëm të automatizuar për të aplikuar skedarët tuaj të konfigurimit në komponentët e infrastrukturës së drejtpërdrejtë. Ndryshimet e bashkimit duhet të bëjnë që gjendja e infrastrukturës suaj të kalojë drejt asaj të përshkruar nga përmbajtja e rishikuar e depove.
Kjo kërkon një urë ndërmjet platformës suaj të kontrollit të burimit dhe ofruesit tuaj të infrastrukturës, duke lejuar që gjendja aktuale të komunikohet midis të dyve. Ka mënyra të ndryshme në të cilat kjo urë mund të zbatohet, secila duke vendosur një grup unik përgjegjësish në platformat e përfshira. Në këtë artikull ne do të shikojmë modelin e vendosjes së bazuar në agjent (ose të bazuar në tërheqje), më pas do ta krahasojmë atë me një qasje të bazuar në Push.
Çfarë është një agjent?
GitOps i bazuar në agjentë i referohet drejtimit të një procesi brenda infrastrukturës suaj që lehtëson vendosjet tuaja. Procesi është përgjegjës për ruajtjen e komunikimit me platformën e kontrollit të burimit që pret skedarët tuaj IaC.
Një agjent është një pjesë aktive e infrastrukturës suaj. Ai do të lidhet periodikisht me depon tuaj të Git, do të kontrollojë për ndryshime dhe do të tërheqë angazhime të reja në mjedisin tuaj të vendosjes. Agjenti më pas do të ndërmarrë veprime për të zbatuar ndryshimet e marra në rrethinën e tij, duke shkaktuar tranzicionin e duhur të gjendjes.
Agjentët mund të ofrojnë veçori shtesë të tilla si monitorimi i integruar i vendosjes, regjistrimi dhe sinjalizimi. Këto ju mbajnë të informuar vazhdimisht për aktivitetin brenda infrastrukturës suaj. Agjenti trajton integrimin me mjetet tuaja ekzistuese për të shfaqur informacionin përkatës në vendet e duhura.
Modeli i agjentit ndryshon nga pamja konvencionale e Integrimit të Vazhdueshëm dhe Vendosjes së Vazhdueshme (CI/CD) duke hequr konceptin e tubacionit të lidhur me këmbëzën. Në vend të kësaj, ekziston një lak i automatizuar i pajtimit që merr ndryshimet kur ato bëhen të disponueshme. Përkushtimet dhe bashkimet e reja vetëm indirekt nxisin një ndryshim në infrastrukturën tuaj. Mund të kalojë pak kohë përpara se agjenti të marrë të dhënat e reja.
Disa shitës ofrojnë agjentë që mund të përdoren për të zbatuar rrjedhat e punës GitOps. GitLab tani mbron qasjen si mënyrën e tij të preferuar për t'u vendosur në Kubernetes, nëpërmjet Agjentit GitLab për Kubernetes. Agjenti lidhet me një shembull GitLab nga brenda grupit tuaj, më pas lehtëson komunikimin e dyanshëm për të vendosur ndryshimet dhe për të dërguar informacionin përsëri në depot tuaja.
Flux by Weaveworks është një tjetër opsion që funksionon me çdo depo Git dhe përfshin aftësi sinjalizuese. Flux tani është një projekt inkubator brenda Cloud Native Computing Foundation (CNCF). Ai funksionon si një operator Kubernetes që merr ndryshimet e bëra në depot tuaja të lidhura Git.
Avantazhet e agjentit
GitOps i bazuar në agjentë ka përparësi të shumta që e bëjnë atë tërheqës për një sërë palësh të interesuara. Së pari, ekziston dallimi i qartë midis përgjegjësive: platforma juaj e kontrollit të burimit është e pandryshuar dhe nuk ka nevojë të merret me lidhjet me infrastrukturën tuaj. Agjenti duhet të pajiset me kredencialet e depove, por përndryshe është i vetë-mjaftueshëm. Pasi të funksionojë, fokusohet ngushtë në zbulimin dhe zbatimin e ndryshimeve.
Kjo ndarje e shqetësimeve mund t'ju ndihmojë të identifikoni problemet dhe të arsyetoni për dështimet e vendosjes. Në përgjithësi, mund ta hidhni menjëherë platformën e kontrollit të burimit. Nëse është ngritur dhe dega juaj kryesore përmban ndryshimet e sakta, mospërputhjet në gjendjen aktuale të infrastrukturës suaj duhet të jenë për shkak të një problemi të sinkronizimit të agjentëve.
Agjentët gjithashtu ofrojnë një shkallë më të lartë automatizimi sesa GitOps me bazë Push. Për të miratuar me sukses një rrjedhë të bazuar në Push, do t'ju duhet të konfiguroni depon tuaj me kredencialet për infrastrukturën tuaj dhe të krijoni tubacione CI që ekzekutojnë skriptet e duhura për të transmetuar ndryshimet tuaja. Ato skripte do të duhet të kopjohen në të gjitha projektet tuaja, të mirëmbahen me kalimin e kohës dhe të trajtohen me kujdes për të mbrojtur kredencialet tuaja të ndjeshme.
Sistemet e bazuara në agjentë vijnë pa këto shqetësime. Pasi të instalohet një agjent, ju përfitoni nga një model i fuqishëm vendosjeje që është më pak i ndjeshëm ndaj ndryshimit. Ka shumë më pak variabla në lidhje me lidhjen me një depo Git sesa aksesi i suksesshëm në një mjedis prodhimi si një grup Kubernetes. Prandaj, ka kuptim që të tërheqim ndryshimet nga sistemi më i thjeshtë në atë më kompleks.
Një përfitim tjetër është ndikimi pozitiv në siguri i agjentëve. Ata funksionojnë brenda infrastrukturës suaj, në mënyrë që të shmangni hapjen e saj për akses nga jashtë. Ndërsa do t'ju duhet të ekspozoni depon tuaj të Git, kjo është shumë më pak e rrezikshme sesa sigurimi i një dere në mjedisin tuaj të prodhimit. Ekspozimi i një tokeni të projektit GitHub ka të ngjarë të zbulojë vetëm kodin burimor dhe skedarët tuaj IaC – një dukuri serioze, por që zbehet në krahasim me mendimin për të humbur një token të prodhimit të llogarisë Kubernetes. Kjo mund të çojë në vjedhje të të dhënave, zhvatje të mëvonshme dhe kompromis të pakthyeshëm të sistemit.
Po GitOps me bazë Push?
Strategjia alternative është modeli i bazuar në Push, ku ndryshimet ushqehen në infrastrukturën tuaj nga platforma juaj e kontrollit të burimit ose një sistem ndërmjetës. Komunikimi inicohet nga diçka që funksionon jashtë mjedisit të vendosjes. Shtytje detyrojnë infrastrukturën të marrë një gjendje të re nga serveri kontrollues.
GitOps i bazuar në shtytje zakonisht zbatohet brenda tubacioneve tuaja CI. Po e përdorni këtë model nëse keni një tubacion që është konfiguruar me një lidhje grupi Kubernetes dhe përdorni kubectl application
për të krijuar vendosje. Një shembull tjetër është një tubacion që ekzekuton rsync
për të sinkronizuar përmbajtjen e depove tuaja me një host të largët.
Kufizimet e kësaj qasjeje qëndrojnë në paaftësinë e saj për të ofruar avantazhet e lidhura me agjentët që trajtuam më sipër. Ju duhet të konfiguroni manualisht çdo depo me një lidhje të përshtatshme infrastrukturore, të hapni mjediset tuaja për akses të jashtëm dhe të merrni përgjegjësinë për mirëmbajtjen e skripteve tuaja të vendosjes me kalimin e kohës.
Megjithatë, GitOps i bazuar në Push ka ende disa përfitime unike. Një faktor i rëndësishëm është familjariteti i tij i natyrshëm: ju mund të vazhdoni të përdorni mjetet që tashmë i njihni dhe në të cilat mbështeteni në zhvillim, të tilla si kubectl
, helm
dhe docker. Kjo ndihmon për të minimizuar dallimet midis vendosjeve lokale dhe atyre të drejtpërdrejta.
Trajtimi i gabimeve mund të jetë gjithashtu më i thjeshtë. Qasjet e bazuara në shtytje priren të ndihen më sinkron, gjë që mund të jetë e dobishme në identifikimin e sekuencës së ngjarjeve që çojnë në një dështim. Ndërsa agjentët ju japin një pikënisje të qartë (vetë agjenti), ju lihet të filtroni nëpër ngjarjet që korrespondojnë me aktivitetet e atij agjenti. Këto ngjarje mund të mbulojnë dhjetëra projekte të ndryshme dhe cikle pajtimi. Prandaj, aftësia për të filluar nga një drejtim specifik i tubacionit CI mund të jetë e dobishme për të ofruar reagime të menjëhershme gjatë korrigjimit.
Së fundi, ekziston një argument se modeli i bazuar në Push është në të vërtetë më i përshtatshëm për ndryshimet e ardhshme të infrastrukturës. Adoptimi i Pulls do të thotë që po e lidhni sistemin tuaj me pritshmëritë specifike të agjentit tuaj të zgjedhur. Kjo mund t'i komplikojë shpejt gjërat nëse ju duhet të vendosni në një platformë të re ku ai agjent nuk mbështetet. Një qasje e bazuar në shtytje e shkruar është më fleksibël këtu. Kjo ju lejon të kujdeseni për mjedise të shumta të ndryshme duke përfshirë logjikën e kushtëzuar që kryen veprimet e duhura për platformën e synuar.
Përmbledhje
GitOps i bazuar në agjentë i referohet ekzekutimit të një komponenti aktiv brenda infrastrukturës suaj që arrin te depoja juaj e burimit për të marrë dhe aplikuar ndryshime. Kjo përmbys modelin e bazuar në Push ku ekzekutoni skriptet brenda tubacioneve CI për të krijuar vendosje dhe për të aplikuar ndryshimet e gjendjes.
Rrjedha e punës Push është e zakonshme, e kuptueshme lehtë dhe përmban disa tërheqje të rëndësishme. Sidoqoftë, tërheqjet e drejtuara nga agjentët po fitojnë më shumë vëmendje në të gjithë ekosistemin e reve kompjuterike pasi shitësit dhe zhvilluesit arrijnë të njohin përfitimet e tyre.
Miratimi i një qasjeje të bazuar në tërheqje mund të reduktojë mirëmbajtjen me kalimin e kohës, të përmirësojë sigurinë e mjediseve tuaja dhe t'ju ndihmojë të identifikoni dështimet kur ndryshimet nuk po zbatohen. Agjentët gjithashtu mund të thjeshtojnë konfigurimin e veçorive periferike si grumbullimi i sinjalizimeve dhe matjeve, duke përshpejtuar rrugën e miratimit të DevOps pa bashkuar manualisht skriptet komplekse CI.