Let wel. vertaal.: In die Kubernetes-gemeenskap kry 'n neiging genaamd GitOps duidelike gewildheid, soos ons persoonlik gesien het, KubeCon Europe 2019. Hierdie kwartaal was relatief onlangs deur die hoof van Weaveworks - Alexis Richardson - en beteken die gebruik van gereedskap wat aan ontwikkelaars bekend is (hoofsaaklik Git, vandaar die naam) om operasionele probleme op te los. Ons praat veral oor die werking van Kubernetes deur die konfigurasies daarvan in Git te stoor en outomaties veranderinge aan die groep uit te voer. Matthias Jg praat in hierdie artikel oor twee benaderings tot hierdie uitrol.
Verlede jaar, (trouens, dit het formeel in Augustus 2017 gebeur - ongeveer vertaal.) Daar is 'n nuwe benadering om toepassings in Kubernetes te ontplooi. Dit word GitOps genoem, en dit is gebaseer op die basiese idee dat implementeringsweergawes in die veilige omgewing van 'n Git-bewaarplek nagespoor word.
Die belangrikste voordele van hierdie benadering is soos volg::
- Ontplooiing weergawe en verandering geskiedenis. Die toestand van die hele groepering word in 'n Git-bewaarplek gestoor, en ontplooiings word slegs deur commits opgedateer. Daarbenewens kan alle veranderinge nagespoor word met behulp van die commit geskiedenis.
- Terugdraai met behulp van bekende Git-opdragte. Eenvoudig
git resetlaat jou toe om veranderinge in ontplooiings terug te stel; vorige state is altyd beskikbaar. - Gereed toegangsbeheer. Tipies bevat 'n Git-stelsel baie sensitiewe data, so die meeste maatskappye gee spesiale aandag daaraan om dit te beskerm. Gevolglik is hierdie beskerming ook van toepassing op bedrywighede met ontplooiings.
- Beleide vir Ontplooiings. Die meeste Git-stelsels ondersteun inheems tak-vir-tak-beleide - byvoorbeeld, net trekversoeke kan meester bywerk, en veranderinge moet deur 'n ander spanlid hersien en aanvaar word. Soos met toegangsbeheer, geld dieselfde beleide vir ontplooiingsopdaterings.
Soos u kan sien, is daar baie voordele aan die GitOps-metode. Die afgelope jaar het twee benaderings veral gewild geword. Een is stoot gebaseer, die ander is trek gebaseer. Voordat ons daarna kyk, kom ons kyk eers hoe tipiese Kubernetes-ontplooiings lyk.
Ontplooiingsmetodes
In onlangse jare het Kubernetes verskeie metodes en gereedskap vir implementering gevestig:
- Gebaseer op inheemse Kubernetes/Customize-sjablone. Dit is die maklikste manier om toepassings op Kubernetes te ontplooi. Die ontwikkelaar skep die basiese YAML-lêers en pas dit toe. Om ontslae te raak van die voortdurende herskryf van dieselfde sjablone, is Kustomize ontwikkel (dit verander Kubernetes-sjablone in modules). Let wel. vertaal.: Kustomize is geïntegreer in kubectl met .
- Roerkaarte. Roerkaarte laat jou toe om stelle sjablone, inithouers, sykarre, ens. te skep, wat gebruik word om toepassings te ontplooi met meer buigsame aanpassingsopsies as in 'n sjabloongebaseerde benadering. Hierdie metode is gebaseer op sjabloon YAML-lêers. Helm vul hulle met verskeie parameters en stuur dit dan na Tiller, 'n cluster-komponent wat hulle na die cluster ontplooi en opdaterings en terugskrywings toelaat. Die belangrikste ding is dat Helm in wese net die gewenste waardes in die sjablone invoeg en dit dan toepas op dieselfde manier as wat dit in die tradisionele benadering gedoen word. (lees meer oor hoe dit alles werk en hoe jy dit kan gebruik in ons - ongeveer. vertaal.). Daar is 'n wye verskeidenheid gereedgemaakte Helm-kaarte wat 'n wye reeks take dek.
- Alternatiewe gereedskap. Daar is baie alternatiewe gereedskap. Wat hulle almal gemeen het, is dat hulle sommige sjabloonlêers in Kubernetes-leesbare YAML-lêers verander en dit dan gebruik.
In ons werk gebruik ons voortdurend Helm-kaarte vir belangrike gereedskap (aangesien hulle reeds baie dinge gereed het, wat die lewe baie makliker maak) en "suiwer" Kubernetes YAML-lêers om ons eie toepassings te ontplooi.
Trek druk
In een van my onlangse blogplasings het ek die instrument bekendgestel , wat jou toelaat om sjablone na die Git-bewaarplek te verbind en die ontplooiing op te dateer na elke commit of stoot van die houer. My ervaring toon dat hierdie instrument een van die belangrikstes is in die bevordering van die trekbenadering, so ek sal dikwels daarna verwys. As jy meer wil weet oor hoe om dit te gebruik, hier .
NB! Al die voordele van die gebruik van GitOps bly dieselfde vir beide benaderings.
Trek-gebaseerde benadering
Die trekbenadering is gebaseer op die feit dat alle veranderinge van binne die groepering toegepas word. Daar is 'n operateur in die groep wat gereeld die geassosieerde Git- en Docker-registerbewaarplekke nagaan. As enige veranderinge aan hulle voorkom, word die toestand van die groep intern opgedateer. Hierdie proses word oor die algemeen as baie veilig beskou, aangesien geen eksterne kliënt toegang tot groepadministrateurregte het nie.
Pros:
- Geen eksterne kliënt het regte om veranderinge aan die groepering aan te bring nie; alle opdaterings word van binne ontplooi.
- Sommige instrumente laat jou ook toe om Helm-kaartopdaterings te sinchroniseer en dit aan die groep te koppel.
- Docker Registry kan vir nuwe weergawes geskandeer word. As 'n nuwe prent beskikbaar is, word die Git-bewaarplek en -ontplooiing opgedateer na die nuwe weergawe.
- Treknutsgoed kan oor verskillende naamruimtes versprei word met verskillende Git-bewaarplekke en -toestemmings. Danksy dit kan 'n multitenant-model gebruik word. Byvoorbeeld, span A kan naamruimte A gebruik, span B kan naamruimte B gebruik, en die infrastruktuurspan kan globale ruimte gebruik.
- As 'n reël is die gereedskap baie liggewig.
- Gekombineer met gereedskap soos operateur , kan geheime geïnkripteer in 'n Git-bewaarplek gestoor word en binne die cluster herwin word.
- Daar is geen verbinding met CD-pyplyne nie aangesien ontplooiings binne die groepering plaasvind.
Nadele:
- Die bestuur van ontplooiingsgeheime vanaf Helm-kaarte is moeiliker as gewones, aangesien dit eers gegenereer moet word in die vorm van, sê, verseëlde geheime, dan deur 'n interne operateur gedekripteer word, en eers daarna word dit beskikbaar vir die trekinstrument. Dan kan jy die vrystelling in Helm laat loop met die waardes in die reeds ontplooide geheime. Die maklikste manier is om 'n geheim te skep met al die Helm-waardes wat vir ontplooiing gebruik word, dit te dekripteer en dit aan Git te verbind.
- Wanneer jy 'n trekbenadering volg, raak jy vasgebind aan trekgereedskap. Dit beperk die vermoë om die ontplooiingsproses in 'n groep aan te pas. Kustomize word byvoorbeeld gekompliseer deur die feit dat dit moet loop voordat die finale sjablone aan Git verbind word. Ek sê nie jy kan nie selfstandige gereedskap gebruik nie, maar dit is moeiliker om in jou ontplooiingsproses te integreer.
Stootgebaseerde benadering
In die stootbenadering begin 'n eksterne stelsel (hoofsaaklik CD-pypleidings) ontplooiings na die groepering na 'n toewysing na die Git-bewaarplek of as die vorige CI-pyplyn suksesvol is. In hierdie benadering het die stelsel toegang tot die groepering.
Pros:
- Sekuriteit word bepaal deur die Git-bewaarplek en boupyplyn.
- Die implementering van Helm-kaarte is makliker en ondersteun Helm-inproppe.
- Geheime is makliker om te bestuur omdat geheime in pyplyne gebruik kan word en ook geïnkripteer in Git gestoor kan word (na gelang van die gebruiker se voorkeure).
- Daar is geen verband met 'n spesifieke instrument nie, aangesien enige tipe gebruik kan word.
- Houerweergawe-opdaterings kan deur die boupyplyn geïnisieer word.
Nadele:
- Die groeptoegangsdata is binne die boustelsel.
- Die opdatering van ontplooiingshouers is steeds makliker met 'n trekproses.
- Swaar afhanklikheid van die CD-stelsel, aangesien die pyplyne wat ons nodig het oorspronklik vir Gitlab Runners geskryf is, en dan besluit die span om na Azure DevOps of Jenkins te skuif ... en sal 'n groot aantal boupyplyne moet migreer.
Resultate: Druk of trek?
Soos gewoonlik die geval is, het elke benadering sy voor- en nadele. Sommige take is makliker om met een uit te voer en moeiliker met 'n ander. Ek het eers met die hand ontplooiing gedoen, maar nadat ek op 'n paar artikels oor Weave Flux afgekom het, het ek besluit om GitOps-prosesse vir alle projekte te implementeer. Vir basiese sjablone was dit maklik, maar toe begin ek probleme ondervind met Helm-kaarte. Destyds het Weave Flux slegs 'n rudimentêre weergawe van die Helm Chart Operator aangebied, maar selfs nou is sommige take moeiliker as gevolg van die behoefte om geheime handmatig te skep en dit toe te pas. Jy kan argumenteer dat die trek-benadering baie veiliger is omdat die cluster se geloofsbriewe nie buite die cluster toeganklik is nie, wat dit soveel veiliger maak dat dit die ekstra moeite werd is.
Na 'n bietjie nagedink het ek tot die onverwagte gevolgtrekking gekom dat dit nie so is nie. As ons praat oor komponente wat maksimum beskerming benodig, sal hierdie lys geheime berging, CI/CD-stelsels en Git-bewaarplekke insluit. Die inligting binne hulle is baie kwesbaar en benodig maksimum beskerming. Boonop, as iemand in jou Git-bewaarplek kom en kode daarheen kan druk, kan hulle ontplooi wat hulle wil (of dit trek of druk is) en die groeperingstelsels infiltreer. Die belangrikste komponente wat dus beskerm moet word, is die Git-bewaarplek en CI/CD-stelsels, nie die cluster-geloofsbriewe nie. As jy goed gekonfigureerde beleide en sekuriteitskontroles vir hierdie tipe stelsels het, en cluster geloofsbriewe word slegs as geheime in pyplyne onttrek, is die bykomende sekuriteit van 'n trekbenadering dalk nie so waardevol as wat oorspronklik gedink is nie.
Dus, as die trekbenadering meer arbeidsintensief is en nie 'n sekuriteitsvoordeel bied nie, is dit nie logies om slegs die drukbenadering te gebruik nie? Maar iemand kan argumenteer dat jy in die stootbenadering te gebonde is aan die CD-stelsel en miskien is dit beter om dit nie te doen nie, sodat dit makliker sal wees om migrasies in die toekoms uit te voer.
Na my mening (soos altyd), moet jy gebruik wat die geskikste is vir 'n spesifieke geval of kombineer. Persoonlik gebruik ek albei benaderings: Weave Flux vir trek-gebaseerde ontplooiings wat meestal ons eie dienste insluit, en 'n stootbenadering met Helm en inproppe, wat dit maklik maak om Helm-kaarte op die cluster toe te pas en jou toelaat om geheime naatloos te skep. Ek dink daar sal nooit 'n enkele oplossing wees wat vir alle gevalle geskik is nie, want daar is altyd baie nuanses en dit hang af van die spesifieke toepassing. Dit gesê, ek beveel GitOps sterk aan - dit maak die lewe baie makliker en verbeter sekuriteit.
Ek hoop dat my ervaring oor hierdie onderwerp jou sal help om te besluit watter metode meer geskik is vir jou tipe ontplooiing, en ek sal bly wees om jou mening te hoor.
NS Nota van die vertaler
Die nadeel van die trekmodel is dat dit moeilik is om gelewerde manifeste in Git te plaas, maar daar is geen nadeel dat die CD-pyplyn in die trekmodel apart van die uitrol leef en in wese 'n kategorie-pyplyn word Deurlopend Dien toe. Daarom sal selfs meer moeite vereis word om hul status van alle ontplooiings te versamel en op een of ander manier toegang tot logs/status te verskaf, verkieslik met verwysing na die CD-stelsel.
In hierdie sin stel die stootmodel ons in staat om ten minste 'n paar waarborge van ontplooiing te verskaf, omdat die leeftyd van die pyplyn gelyk gemaak kan word aan die leeftyd van die ontplooiing.
Ons het albei modelle probeer en tot dieselfde gevolgtrekkings gekom as die skrywer van die artikel:
- Die trekmodel is geskik vir ons om opdaterings van stelselkomponente op 'n groot aantal groepe te organiseer (sien. ).
- Die stootmodel gebaseer op GitLab CI is goed geskik vir die uitrol van toepassings met behulp van Helm-kaarte. Terselfdertyd word die ontplooiing van ontplooiings binne pypleidings gemonitor met behulp van die instrument . Terloops, in die konteks van hierdie projek van ons, het ons die konstante "GitOps" gehoor toe ons die dringende probleme van DevOps-ingenieurs by ons stalletjie by KubeCon Europe'19 bespreek het.
PPS van vertaler
Lees ook op ons blog:
- «»;
- «»;
- «»;
- «".
Slegs geregistreerde gebruikers kan aan die opname deelneem. , asseblief.
Gebruik jy GitOps?
-
Ja, trek benadering
-
Ja, druk
-
Ja, trek + druk
-
Ja, iets anders
-
Geen
30 gebruikers het gestem. 10 gebruikers het buite stemming gebly.
Bron: will.com