Shënim. përkth.: Pas një publikimi të fundit në lidhje me metodat e tërheqjes dhe shtytjes në GitOps, ne pamë interes për këtë model në përgjithësi, por kishte shumë pak botime në gjuhën ruse për këtë temë (thjesht nuk ka asnjë në Habré). Prandaj, ne jemi të kënaqur t'ju ofrojmë në vëmendjen tuaj një përkthim të një artikulli tjetër - megjithëse gati një vit më parë! — nga Weaveworks, kreu i së cilës shpiku termin "GitOps". Teksti shpjegon thelbin e qasjes dhe dallimet kryesore nga ato ekzistuese.
Një vit më parë kemi publikuar . Në atë kohë, ne treguam se si ekipi i Weaveworks lançoi një SaaS tërësisht të bazuar në Kubernetes dhe zhvilluam një sërë praktikash më të mira përcaktuese për vendosjen, menaxhimin dhe monitorimin në një mjedis vendas të cloud.
Artikulli doli të ishte popullor. Njerëz të tjerë filluan të flasin për GitOps dhe filluan të publikojnë mjete të reja për , , , , e kështu me radhë. U shfaq në faqen tonë të internetit publikimet dhe rastet e përdorimit të GitOps. Por disa njerëz ende kanë pyetje. Si ndryshon modeli nga ai tradicional? dhe shpërndarje të vazhdueshme ()? A është e nevojshme të përdorni Kubernetes?
Shpejt kuptuam se duhej një përshkrim i ri, duke ofruar:
- Një numër i madh shembujsh dhe tregimesh;
- Përkufizimi specifik i GitOps;
- Krahasimi me shpërndarjen tradicionale të vazhdueshme.
Në këtë artikull ne jemi përpjekur të mbulojmë të gjitha këto tema. Ai ofron një hyrje të përditësuar në GitOps dhe një perspektivë zhvilluesi dhe CI/CD. Ne fokusohemi kryesisht në Kubernetes, megjithëse modeli mund të përgjithësohet.
Njihuni me GitOps
Imagjinoni Alice. Ajo drejton Family Insurance, e cila ofron sigurime shëndetësore, automjetesh, shtëpie dhe udhëtimi për njerëzit që janë shumë të zënë për të kuptuar gjërat e brendshme të kontratave. Biznesi i saj filloi si një projekt anësor kur Alice punonte në një bankë si shkencëtare e të dhënave. Një ditë ajo kuptoi se mund të përdorte algoritme kompjuterike të avancuara për të analizuar në mënyrë më efektive të dhënat dhe për të formuluar paketat e sigurimit. Investitorët financuan projektin dhe tani kompania e saj sjell më shumë se 20 milionë dollarë në vit dhe po rritet me shpejtësi. Aktualisht punëson 180 persona në pozicione të ndryshme. Kjo përfshin një ekip teknologjik që zhvillon, mirëmban faqen e internetit, bazën e të dhënave dhe analizon bazën e klientëve. Ekipi prej 60 personash drejtohet nga Bob, drejtori teknik i kompanisë.
Ekipi i Bobit vendos sisteme prodhimi në re. Aplikacionet e tyre kryesore funksionojnë në GKE, duke përfituar nga Kubernetes në Google Cloud. Përveç kësaj, ata përdorin mjete të ndryshme të dhënash dhe analitike në punën e tyre.
Family Insurance nuk u përpoq të përdorte kontejnerë, por u kap nga entuziazmi i Docker. Kompania shpejt zbuloi se GKE e bëri të lehtë vendosjen e grupimeve për të testuar veçori të reja. Jenkins për CI dhe Quay u shtuan për të organizuar regjistrin e kontejnerëve, skriptet u shkruan për Jenkins që shtynë kontejnerë dhe konfigurime të reja në GKE.
Ka kaluar ca kohë. Alice dhe Bob ishin të zhgënjyer me performancën e qasjes së tyre të zgjedhur dhe ndikimin e saj në biznes. Futja e kontejnerëve nuk e përmirësoi produktivitetin aq sa kishte shpresuar ekipi. Ndonjëherë dislokimet prisheshin dhe ishte e paqartë nëse fajësoheshin ndryshimet e kodit. Gjithashtu doli të ishte e vështirë të gjurmosh ndryshimet e konfigurimit. Shpesh ishte e nevojshme të krijohej një grup i ri dhe të zhvendoseshin aplikacionet në të, pasi kjo ishte mënyra më e lehtë për të eliminuar rrëmujën që ishte bërë sistemi. Alice kishte frikë se situata do të përkeqësohej me zhvillimin e aplikacionit (përveç kësaj, po përgatitej një projekt i ri i bazuar në mësimin e makinerive). Bob kishte automatizuar pjesën më të madhe të punës dhe nuk e kuptonte pse tubacioni ishte ende i paqëndrueshëm, nuk përshkallëzohej mirë dhe kërkonte ndërhyrje manuale periodikisht?
Më pas ata mësuan për GitOps. Ky vendim doli të ishte pikërisht ajo që u duhej për të ecur përpara me besim.
Alice dhe Bob kanë dëgjuar për Git, DevOps dhe infrastrukturën si rrjedhat e punës së kodit për vite me radhë. Ajo që është unike në lidhje me GitOps është se ai sjell një sërë praktikash më të mira—si definitive ashtu edhe normative—për zbatimin e këtyre ideve në kontekstin e Kubernetes. Kjo temë , duke përfshirë në .
Family Insurance vendos të zbatojë GitOps. Kompania tani ka një model të automatizuar funksionimi që është në përputhje me Kubernetes dhe kombinat shpejtësi me stabilitetisepse ata:
- zbuloi se produktiviteti i ekipit u dyfishua pa u çmendur askush;
- ndaloi së shërbyeri skriptet. Në vend të kësaj, ata tani mund të përqendrohen në veçori të reja dhe të përmirësojnë metodat inxhinierike - për shembull, duke futur shpërndarjen e kanarinave dhe duke përmirësuar testimin;
- ne kemi përmirësuar procesin e vendosjes në mënyrë që të prishet rrallë;
- mori mundësinë për të rivendosur vendosjet pas dështimeve të pjesshme pa ndërhyrje manuale;
- te blera te perdoruraоBesim më i madh në sistemet e shpërndarjes. Alice dhe Bob zbuluan se ata mund ta ndanin ekipin në ekipe mikroshërbimesh që punonin paralelisht;
- mund të bëjë 30-50 ndryshime në projekt çdo ditë me përpjekjet e secilit grup dhe të provojë teknika të reja;
- është e lehtë të tërheqësh zhvillues të rinj në projekt, të cilët kanë mundësinë të nxjerrin përditësime në prodhim duke përdorur kërkesa tërheqëse brenda pak orësh;
- kalojnë lehtësisht auditimin brenda kornizës së KOS2 (për pajtueshmërinë e ofruesve të shërbimeve me kërkesat për menaxhimin e sigurt të të dhënave; lexoni më shumë, për shembull, - përafërsisht. përkth.).
Cfare ndodhi?
GitOps është dy gjëra:
- Modeli operacional për Kubernetes dhe vendasin e cloud. Ai siguron një sërë praktikash më të mira për vendosjen, menaxhimin dhe monitorimin e grupimeve dhe aplikacioneve të kontejnerizuara. Përkufizim elegant në formë nga :
- Rruga drejt krijimit të një mjedisi të menaxhimit të aplikacionit me qendër zhvilluesi. Ne aplikojmë rrjedhën e punës Git si për operacionet ashtu edhe për zhvillimin. Ju lutemi vini re se kjo nuk ka të bëjë vetëm me Git push, por me organizimin e të gjithë grupit të mjeteve CI/CD dhe UI/UX.
Disa fjalë për Git
Nëse nuk jeni të njohur me sistemet e kontrollit të versionit dhe rrjedhën e punës të bazuar në Git, ju rekomandojmë shumë të mësoni rreth tyre. Puna me degë dhe kërkesa për tërheqje mund të duket si magji e zezë në fillim, por përfitimet ia vlen përpjekja. Këtu të fillosh.
Si funksionon Kubernetes
Në historinë tonë, Alice dhe Bob iu drejtuan GitOps pasi punuan me Kubernetes për një kohë. Në të vërtetë, GitOps është i lidhur ngushtë me Kubernetes - është një model operacional për infrastrukturën dhe aplikacionet e bazuara në Kubernetes.
Çfarë u jep përdoruesve Kubernetes?
Këtu janë disa karakteristika kryesore:
- Në modelin Kubernetes, gjithçka mund të përshkruhet në formë deklarative.
- Serveri Kubernetes API e merr këtë deklaratë si hyrje dhe më pas përpiqet vazhdimisht ta sjellë grupin në gjendjen e përshkruar në deklaratë.
- Deklaratat janë të mjaftueshme për të përshkruar dhe menaxhuar një shumëllojshmëri të gjerë ngarkesash pune - "aplikacione".
- Si rezultat, ndryshimet në aplikacion dhe grup ndodhin për shkak të:
- ndryshimet në imazhet e kontejnerëve;
- ndryshimet në specifikimet deklarative;
- gabime në mjedis - për shembull, përplasjet e kontejnerëve.
Aftësitë e mëdha të konvergjencës së Kubernetes
Kur një administrator bën ndryshime konfigurimi, orkestratori Kubernetes do t'i zbatojë ato në grup për sa kohë që gjendja e tij është nuk do t'i afrohet konfigurimit të ri. Ky model funksionon për çdo burim Kubernetes dhe është i zgjerueshëm me Përkufizimet e Burimeve të Përshtatshme (CRD). Prandaj, vendosjet e Kubernetes kanë karakteristikat e mëposhtme të mrekullueshme:
- automatizim: Përditësimet e Kubernetes ofrojnë një mekanizëm për të automatizuar procesin e aplikimit të ndryshimeve me hijeshi dhe në kohën e duhur.
- Konvergjenca: Kubernetes do të vazhdojë të provojë përditësimet deri sa të ketë sukses.
- Idempotenca: Zbatimet e përsëritura të konvergjencës çojnë në të njëjtin rezultat.
- Determinizmi: Kur burimet janë të mjaftueshme, gjendja e grupit të përditësuar varet vetëm nga gjendja e dëshiruar.
Si funksionon GitOps
Ne kemi mësuar mjaft për Kubernetes për të shpjeguar se si funksionon GitOps.
Le të kthehemi te ekipet e mikroshërbimeve të Family Insurance. Çfarë duhet të bëjnë zakonisht? Shikoni listën më poshtë (nëse ndonjë artikull në të duket i çuditshëm ose i panjohur, ju lutemi hiqni dorë nga kritikat dhe qëndroni me ne). Këta janë vetëm shembuj të flukseve të punës të bazuara në Jenkins. Ka shumë procese të tjera kur punoni me mjete të tjera.
Gjëja kryesore është që ne shohim që çdo përditësim përfundon me ndryshime në skedarët e konfigurimit dhe depot e Git. Këto ndryshime në Git bëjnë që "operatori GitOps" të përditësojë grupin:
1. Procesi i punës: "Jenkins build - master dega'.
Lista e detyrave:
- Jenkins shtyn imazhet e etiketuara në Quay;
- Jenkins shtyn konfigurimin dhe diagramet Helm në kovën kryesore të ruajtjes;
- Funksioni cloud kopjon konfigurimin dhe grafikët nga kova e ruajtjes kryesore në depo kryesore Git;
- Operatori GitOps përditëson grupin.
2. Ndërtimi i Jenkins - dega e lëshimit ose e rregullimit të nxehtë:
- Jenkins shtyn imazhe të pataguara në Quay;
- Jenkins shtyn konfigurimin dhe diagramet Helm në kovën e ruajtjes së skenës;
- Funksioni i resë kompjuterike kopjon konfigurimin dhe grafikët nga kova e ruajtjes së skenës në depon e Git të skenës;
- Operatori GitOps përditëson grupin.
3. Jenkins ndërto - zhvillo ose shfaq degën:
- Jenkins shtyn imazhe të pataguara në Quay;
- Jenkins shtyn konfigurimin dhe grafikët Helm në kovën e ruajtjes së zhvillimit;
- Funksioni cloud kopjon konfigurimin dhe grafikët nga kova e ruajtjes së zhvillimit në depon e zhvillimit të Git;
- Operatori GitOps përditëson grupin.
4. Shtimi i një klienti të ri:
- Menaxheri ose administratori (LCM/ops) thërret Gradle për të vendosur dhe konfiguruar fillimisht balancuesit e ngarkesës në rrjet (NLB);
- LCM/ops kryen një konfigurim të ri për të përgatitur vendosjen për përditësime;
- Operatori GitOps përditëson grupin.
Përshkrim i shkurtër i GitOps
- Përshkruani gjendjen e dëshiruar të të gjithë sistemit duke përdorur specifikime deklarative për çdo mjedis (në historinë tonë, ekipi i Bob përcakton të gjithë konfigurimin e sistemit në Git).
- Depoja e Git është burimi i vetëm i së vërtetës në lidhje me gjendjen e dëshiruar të të gjithë sistemit.
- Të gjitha ndryshimet në gjendjen e dëshiruar bëhen përmes kryerjeve në Git.
- Të gjithë parametrat e dëshiruar të grupimit janë gjithashtu të vëzhgueshëm në vetë grupimin. Në këtë mënyrë ne mund të përcaktojmë nëse ato përkojnë (konvergojnë, konvergoj) ose ndryshojnë (ndryshojnë, ndryshojnë) gjendjet e dëshiruara dhe të vëzhguara.
- Nëse gjendjet e dëshiruara dhe të vëzhguara ndryshojnë, atëherë:
- Ekziston një mekanizëm konvergjence që herët a vonë sinkronizon automatikisht gjendjen e synuar dhe të vëzhguar. Brenda grupit, Kubernetes e bën këtë.
- Procesi fillon menjëherë me një alarm "ndryshimi i kryer".
- Pas një periudhe kohe të konfigurueshme, mund të dërgohet një alarm "ndryshimi" nëse shtetet janë të ndryshme.
- Në këtë mënyrë, të gjitha kryerjet në Git shkaktojnë përditësime të verifikueshme dhe idempotente në grup.
- Rikthimi është konvergjenca në një gjendje të dëshiruar më parë.
- Konvergjenca është përfundimtare. Shfaqja e tij tregohet nga:
- Nuk ka sinjalizime ndryshimi për një periudhë të caktuar kohe.
- alarm "konverguar" (p.sh. uebhook, ngjarje e kthimit të Git).
Çfarë është divergjenca?
Le të përsërisim përsëri: të gjitha vetitë e dëshiruara të grupimit duhet të jenë të vëzhgueshme në vetë grupimin.
Disa shembuj të divergjencës:
- Ndryshim në skedarin e konfigurimit për shkak të bashkimit të degëve në Git.
- Një ndryshim në skedarin e konfigurimit për shkak të një angazhimi Git të bërë nga klienti GUI.
- Ndryshime të shumta në gjendjen e dëshiruar për shkak të PR në Git të ndjekura nga ndërtimi i imazhit të kontejnerit dhe ndryshimet e konfigurimit.
- Një ndryshim në gjendjen e grupit për shkak të një gabimi, konflikti burimesh që rezulton në "sjellje të keqe" ose thjesht devijime të rastësishme nga gjendja origjinale.
Cili është mekanizmi i konvergjencës?
Disa shembuj:
- Për kontejnerët dhe grupimet, mekanizmi i konvergjencës sigurohet nga Kubernetes.
- I njëjti mekanizëm mund të përdoret për të menaxhuar aplikacionet dhe dizajnet e bazuara në Kubernetes (të tilla si Istio dhe Kubeflow).
- Një mekanizëm për menaxhimin e ndërveprimit operacional midis Kubernetes, depove të imazheve dhe Git ofron , e cila është pjesë .
- Për makineritë bazë, mekanizmi i konvergjencës duhet të jetë deklarativ dhe autonom. Nga përvoja jonë mund të themi se më afër këtij përkufizimi, por ende kërkon kontroll njerëzor. Në këtë kuptim, GitOps zgjeron traditën e Infrastrukturës si Kod.
GitOps kombinon Git me motorin e shkëlqyer të konvergjencës së Kubernetes për të ofruar një model për shfrytëzim.
GitOps na lejon të themi: Vetëm ato sisteme që mund të përshkruhen dhe vëzhgohen mund të automatizohen dhe kontrollohen.
GitOps është menduar për të gjithë grupin vendas të cloud (për shembull, Terraform, etj.)
GitOps nuk është vetëm Kubernetes. Ne duam që i gjithë sistemi të drejtohet në mënyrë deklarative dhe të përdorë konvergjencën. Me të gjithë sistemin nënkuptojmë një koleksion mjedisesh që punojnë me Kubernetes - për shembull, "dev cluster 1", "prodhim", etj. Çdo mjedis përfshin makina, grupe, aplikacione, si dhe ndërfaqe për shërbime të jashtme që ofrojnë të dhëna, monitorim dhe etj.
Vini re se sa i rëndësishëm është Terraform për problemin e bootstrapping në këtë rast. Kubernetes duhet të vendoset diku, dhe përdorimi i Terraform do të thotë që ne mund të aplikojmë të njëjtat flukse pune GitOps për të krijuar shtresën e kontrollit që mbështet Kubernetes dhe aplikacionet. Kjo është një praktikë më e mirë e dobishme.
Ekziston një fokus i fortë në aplikimin e koncepteve GitOps në shtresat në krye të Kubernetes. Për momentin, ka zgjidhje të tipit GitOps për Istio, Helm, Ksonnet, OpenFaaS dhe Kubeflow, si dhe, për shembull, për Pulumi, të cilat krijojnë një shtresë për zhvillimin e aplikacioneve për cloud native.
Kubernetes CI/CD: krahasimi i GitOps me qasje të tjera
Siç u tha, GitOps është dy gjëra:
- Modeli i funksionimit për Kubernetes dhe retë vendase i përshkruar më sipër.
- Rruga drejt një mjedisi të menaxhimit të aplikacionit të përqendruar te zhvilluesi.
Për shumë njerëz, GitOps është kryesisht një rrjedhë pune e bazuar në shtytjet e Git. Edhe neve na pëlqen ai. Por kjo nuk është e gjitha: le të shohim tani tubacionet CI/CD.
GitOps mundëson vendosjen e vazhdueshme (CD) për Kubernetes
GitOps ofron një mekanizëm të vazhdueshëm vendosjeje që eliminon nevojën për "sisteme të menaxhimit të vendosjes". Kubernetes bën të gjithë punën për ju.
- Përditësimi i aplikacionit kërkon përditësim në Git. Ky është një përditësim transaksional në gjendjen e dëshiruar. "Zhvendosja" bëhet më pas brenda grupit nga vetë Kubernetes bazuar në përshkrimin e përditësuar.
- Për shkak të natyrës se si funksionon Kubernetes, këto përditësime janë konvergjente. Kjo siguron një mekanizëm për vendosjen e vazhdueshme në të cilën të gjitha përditësimet janë atomike.
- Shenim: ofron një operator GitOps që integron Git dhe Kubernetes dhe lejon që CD të kryhet duke harmonizuar gjendjen e dëshiruar dhe aktuale të grupit.
Pa kubectl dhe skripta
Ju duhet të shmangni përdorimin e Kubectl për të përditësuar grupin tuaj, dhe veçanërisht të shmangni përdorimin e skripteve për të grupuar komandat kubectl. Në vend të kësaj, me tubacionin GitOps, një përdorues mund të përditësojë grupin e tij Kubernetes përmes Git.
Përfitimet përfshijnë:
- E drejta. Një grup përditësimesh mund të aplikohen, të konvergjohen dhe të vërtetohen përfundimisht, duke na afruar me qëllimin e vendosjes atomike. Në të kundërt, përdorimi i skripteve nuk ofron ndonjë garanci për konvergjencë (më shumë për këtë më poshtë).
- siguri. Kelsey Hightower: "Kufizoni aksesin në grupin tuaj Kubernetes për mjetet e automatizimit dhe administratorët që janë përgjegjës për korrigjimin ose mirëmbajtjen e tij." Shiko gjithashtu për sigurinë dhe respektimin e specifikimeve teknike, si dhe duke vjedhur kredencialet nga një skenar i Jenkins i shkruar pa kujdes.
- Eksperienca e perdoruesit. Kubectl ekspozon mekanikën e modelit të objektit Kubernetes, të cilat janë mjaft komplekse. Në mënyrë ideale, përdoruesit duhet të ndërveprojnë me sistemin në një nivel më të lartë abstraksioni. Këtu do t'i referohem përsëri Kelsey dhe do të rekomandoj ta shikoni .
Dallimi midis CI dhe CD
GitOps përmirëson modelet ekzistuese CI/CD.
Një server modern CI është një mjet orkestrimi. Në veçanti, është një mjet për orkestrimin e tubacioneve CI. Këto përfshijnë ndërtimin, testimin, bashkimin në trunk, etj. Serverët CI automatizojnë menaxhimin e tubacioneve komplekse me shumë hapa. Një tundim i zakonshëm është të skriptoni një grup përditësimesh të Kubernetes dhe ta ekzekutoni atë si pjesë e një tubacioni për të nxitur ndryshimet në grup. Në të vërtetë, kjo është ajo që bëjnë shumë ekspertë. Megjithatë, kjo nuk është optimale, dhe ja pse.
CI duhet të përdoret për të shtyrë përditësimet në trunk, dhe grupi Kubernetes duhet të ndryshojë vetë bazuar në ato përditësime për të menaxhuar CD-në brenda. Ne e quajmë atë , ndryshe nga modeli push CI. CD është pjesë orkestrimi i kohës së ekzekutimit.
Pse serverët CI nuk duhet të bëjnë CD përmes përditësimeve të drejtpërdrejta në Kubernetes
Mos përdorni një server CI për të orkestruar përditësime të drejtpërdrejta në Kubernetes si një grup punësh CI. Ky është anti-modeli për të cilin po flasim në blogun tuaj.
Le të kthehemi te Alice dhe Bob.
Me çfarë problemesh u përballën? Serveri CI i Bob-it zbaton ndryshimet në grup, por nëse ai rrëzohet gjatë procesit, Bob nuk do ta dijë se në çfarë gjendje është (ose duhet të jetë) grupi ose si ta rregullojë atë. E njëjta gjë vlen edhe në rast suksesi.
Le të supozojmë se ekipi i Bobit ndërtoi një imazh të ri dhe më pas rregulloi vendosjet e tyre për të vendosur imazhin (të gjitha nga tubacioni CI).
Nëse imazhi ndërtohet normalisht, por tubacioni dështon, ekipi do të duhet të kuptojë:
- A ka dalë përditësimi?
- A po lançojmë një ndërtim të ri? A do të çojë kjo në efekte anësore të panevojshme - me mundësinë e të pasurit dy ndërtime të të njëjtit imazh të pandryshueshëm?
- A duhet të presim për përditësimin tjetër përpara se të ekzekutojmë ndërtimin?
- Çfarë saktësisht shkoi keq? Cilët hapa duhet të përsëriten (dhe cilët janë të sigurt për t'u përsëritur)?
Krijimi i një fluksi pune të bazuar në Git nuk garanton që ekipi i Bob nuk do të hasë në këto probleme. Ata ende mund të bëjnë një gabim me shtytjen e kryerjes, etiketën ose ndonjë parametër tjetër; megjithatë, kjo qasje është ende shumë më afër një qasjeje të qartë gjithçka ose asgjë.
Për ta përmbledhur, ja pse serverët CI nuk duhet të merren me CD:
- Skriptet e përditësimit nuk janë gjithmonë përcaktues; Është e lehtë të bësh gabime në to.
- Serverët CI nuk konvergojnë me modelin e grupit deklarativ.
- Është e vështirë të garantosh idempotencë. Përdoruesit duhet të kuptojnë semantikën e thellë të sistemit.
- Është më e vështirë të rikuperosh nga një dështim i pjesshëm.
Shënim për Helm: Nëse dëshironi të përdorni Helm, ju rekomandojmë ta kombinoni me një operator GitOps si p.sh. . Kjo do të ndihmojë në sigurimin e konvergjencës. Vetë helmi nuk është as determinist dhe as atomik.
GitOps si mënyra më e mirë për të zbatuar Dorëzimin e Vazhdueshëm për Kubernetes
Ekipi i Alice dhe Bob zbaton GitOps dhe zbulon se është bërë shumë më e lehtë të punosh me produkte softuerësh, të ruash performancën dhe stabilitetin e lartë. Le ta përfundojmë këtë artikull me një ilustrim që tregon se si duket qasja e tyre e re. Mbani në mend se ne po flasim kryesisht për aplikacione dhe shërbime, por GitOps mund të përdoret për të menaxhuar një platformë të tërë.
Modeli operativ për Kubernetes
Shikoni diagramin e mëposhtëm. Ai paraqet Git dhe depon e imazheve të kontejnerit si burime të përbashkëta për dy cikle jete të orkestruara:
- Një tubacion i vazhdueshëm integrimi që lexon dhe shkruan skedarë në Git dhe mund të përditësojë një depo të imazheve të kontejnerëve.
- Një tubacion Runtime GitOps që kombinon vendosjen me menaxhimin dhe vëzhgimin. Ai lexon dhe shkruan skedarë në Git dhe mund të shkarkojë imazhe të kontejnerit.
Cilat janë gjetjet kryesore?
- Ndarja e shqetësimeve: Ju lutemi vini re se të dy tubacionet mund të komunikojnë vetëm duke përditësuar Git ose depon e imazheve. Me fjalë të tjera, ekziston një mur zjarri midis CI dhe mjedisit të ekzekutimit. Ne e quajmë atë "firewall i pandryshueshmërisë" (firewall i pandryshueshmërisë), pasi të gjitha përditësimet e depove krijojnë versione të reja. Për më shumë informacion mbi këtë temë, referojuni rrëshqitjeve 72-87 .
- Ju mund të përdorni çdo server CI dhe Git: GitOps punon me çdo komponent. Mund të vazhdoni të përdorni serverët tuaj të preferuar CI dhe Git, depot e imazheve dhe paketat e testimit. Pothuajse të gjitha mjetet e tjera të shpërndarjes së vazhdueshme në treg kërkojnë serverin e tyre CI/Git ose depon e imazheve. Ky mund të bëhet një faktor kufizues në zhvillimin e reve vendase. Me GitOps, mund të përdorni mjete të njohura.
- Ngjarjet si një mjet integrimi: Sapo të dhënat në Git përditësohen, Weave Flux (ose operatori Weave Cloud) njofton kohën e ekzekutimit. Sa herë që Kubernetes pranon një grup ndryshimesh, Git përditësohet. Kjo siguron një model të thjeshtë integrimi për organizimin e flukseve të punës për GitOps, siç tregohet më poshtë.
Përfundim
GitOps ofron garancitë e forta të përditësimit të kërkuara nga çdo mjet modern CI/CD:
- automatizimi;
- konvergjenca;
- idempotencë;
- determinizmi.
Kjo është e rëndësishme sepse ofron një model operacional për zhvilluesit vendas të cloud.
- Mjetet tradicionale për menaxhimin dhe monitorimin e sistemeve janë të lidhura me ekipet e operacioneve që veprojnë brenda një libri (një grup procedurash dhe operacionesh rutinë - përafërsisht përkth.), i lidhur me një vendosje specifike.
- Në menaxhimin vendas të cloud, mjetet e vëzhgimit janë mënyra më e mirë për të matur rezultatet e vendosjeve në mënyrë që ekipi i zhvillimit të mund të përgjigjet shpejt.
Imagjinoni shumë grupime të shpërndara nëpër re të ndryshme dhe shumë shërbime me ekipet e tyre dhe planet e vendosjes. GitOps ofron një model të pandryshueshëm në shkallë për të menaxhuar gjithë këtë bollëk.
PS nga përkthyesi
Lexoni edhe në blogun tonë:
- «"?
- «"?
- «'.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , te lutem
A dinit për GitOps përpara se këto dy përkthime të shfaqeshin në Habré?
-
Po, dija gjithçka
-
Vetëm sipërfaqësisht
-
Jo
35 përdorues votuan. 10 përdorues abstenuan.
Burimi: www.habr.com