Let wel. vertaal.: Na 'n onlangse publikasie oor trek-en-stoot-metodes in GitOps, het ons belangstelling in hierdie model in die algemeen gesien, maar daar was baie min Russiestalige publikasies oor hierdie onderwerp (daar is eenvoudig geen op Habré nie). Daarom bied ons graag 'n vertaling van 'n ander artikel aan u aandag - al is dit amper 'n jaar gelede! - van Weaveworks, waarvan die hoof die term "GitOps" geskep het. Die teks verduidelik die kern van die benadering en sleutelverskille van bestaandes.
'n Jaar gelede het ons gepubliseer . Destyds het ons gedeel hoe die Weaveworks-span 'n SaaS van stapel gestuur het wat geheel en al op Kubernetes gebaseer is en 'n stel voorskriftelike beste praktyke ontwikkel het vir die implementering, bestuur en monitering in 'n wolk-inheemse omgewing.
Die artikel het geblyk gewild te wees. Ander mense het oor GitOps begin praat en nuwe nutsgoed begin publiseer vir , , , , en so aan. Op ons webwerf verskyn publikasies en GitOps gebruik gevalle. Maar sommige mense het nog vrae. Hoe verskil die model van die tradisionele een? en deurlopende aflewering ()? Is dit nodig om Kubernetes te gebruik?
Ons het gou besef dat 'n nuwe beskrywing nodig was, wat die volgende bied:
- 'n Groot aantal voorbeelde en stories;
- Spesifieke definisie van GitOps;
- Vergelyking met tradisionele deurlopende aflewering.
In hierdie artikel het ons probeer om al hierdie onderwerpe te dek. Dit bied 'n bygewerkte inleiding tot GitOps en 'n ontwikkelaar- en CI/CD-perspektief. Ons fokus hoofsaaklik op Kubernetes, hoewel die model veralgemeen kan word.
Ontmoet GitOps
Stel jou Alice voor. Sy bestuur Family Insurance, wat gesondheids-, motor-, huis- en reisversekering bied aan mense wat te besig is om self die ins en outs van kontrakte uit te vind. Haar besigheid het as 'n byprojek begin toe Alice as 'n datawetenskaplike by 'n bank gewerk het. Eendag het sy besef dat sy gevorderde rekenaaralgoritmes kan gebruik om data meer effektief te ontleed en versekeringspakkette te formuleer. Beleggers het die projek gefinansier, en nou bring haar maatskappy meer as $20 miljoen per jaar in en groei dit vinnig. Tans het dit 180 mense in verskeie poste in diens. Dit sluit 'n tegnologiespan in wat die webwerf, databasis ontwikkel, onderhou en die kliëntebasis ontleed. Die span van 60 mense word gelei deur Bob, die maatskappy se tegniese direkteur.
Bob se span ontplooi produksiestelsels in die wolk. Hul kerntoepassings loop op GKE, en trek voordeel uit Kubernetes op Google Cloud. Daarbenewens gebruik hulle verskeie data- en ontledingsinstrumente in hul werk.
Family Insurance het nie daarop gemik om houers te gebruik nie, maar het vasgevang in die Docker-entoesiasme. Die maatskappy het gou ontdek dat GKE dit maklik en moeiteloos gemaak het om groepe te ontplooi om nuwe funksies te toets. Jenkins vir CI en Quay is bygevoeg om die houerregister te organiseer, skrifte is vir Jenkins geskryf wat nuwe houers en konfigurasies na GKE gestoot het.
’n Tyd het verbygegaan. Alice en Bob was teleurgesteld met die prestasie van hul gekose benadering en die impak daarvan op die besigheid. Die bekendstelling van houers het nie produktiwiteit soveel verbeter as wat die span gehoop het nie. Soms sou ontplooiings breek, en dit was onduidelik of kodeveranderinge te blameer was. Dit blyk ook moeilik te wees om konfigurasieveranderinge op te spoor. Dikwels was dit nodig om 'n nuwe groepering te skep en toepassings daarna te skuif, aangesien dit die maklikste manier was om die gemors wat die stelsel geword het uit te skakel. Alice was bang dat die situasie erger sou word soos die toepassing ontwikkel (daarby was 'n nuwe projek gebaseer op masjienleer aan die broei). Bob het die meeste van die werk geoutomatiseer en het nie verstaan hoekom die pyplyn steeds onstabiel was nie, nie goed geskaal het nie en periodiek handmatige ingryping vereis het?
Toe het hulle van GitOps geleer. Hierdie besluit het geblyk te wees presies wat hulle nodig gehad het om met selfvertroue vorentoe te beweeg.
Alice en Bob hoor al jare van Git, DevOps en infrastruktuur as kode-werkvloei. Wat uniek is aan GitOps, is dat dit 'n stel beste praktyke bring - beide definitief en normatief - vir die implementering van hierdie idees in die konteks van Kubernetes. Hierdie tema , insluitend in .
Family Insurance besluit om GitOps te implementeer. Die maatskappy het nou 'n outomatiese bedryfsmodel wat versoenbaar is met Kubernetes en kombineers spoed met stabiliteitomdat hulle:
- gevind dat die span se produktiwiteit verdubbel het sonder dat iemand mal geword het;
- opgehou om skrifte te bedien. In plaas daarvan kan hulle nou fokus op nuwe kenmerke en ingenieursmetodes verbeter - byvoorbeeld die bekendstelling van kanarie-ontplooiings en die verbetering van toetsing;
- ons het die ontplooiingsproses verbeter sodat dit selde breek;
- die geleentheid gekry om ontplooiings te herstel na gedeeltelike mislukkings sonder handmatige ingryping;
- gebruik gekoopоGroter vertroue in afleweringstelsels. Alice en Bob het ontdek dat hulle die span kon verdeel in mikrodiensspanne wat parallel werk;
- kan elke dag 30-50 veranderinge aan die projek maak deur die pogings van elke groep en nuwe tegnieke probeer;
- dit is maklik om nuwe ontwikkelaars na die projek te lok, wat die geleentheid het om opdaterings na produksie uit te voer deur gebruik te maak van trekversoeke binne 'n paar uur;
- oudit maklik binne die raamwerk van SOC2 slaag (vir voldoening van diensverskaffers aan vereistes vir veilige databestuur; lees meer, byvoorbeeld, - ongeveer. vertaal.).
Wat het gebeur?
GitOps is twee dinge:
- Operasionele model vir Kubernetes en wolk-inheems. Dit bied 'n stel beste praktyke vir die ontplooiing, bestuur en monitering van houergroepe en toepassings. Elegante definisie in die vorm van :
- Die pad na die skep van 'n ontwikkelaargesentreerde toepassingbestuursomgewing. Ons pas die Git-werkvloei toe op beide bedrywighede en ontwikkeling. Neem asseblief kennis dat dit nie net gaan oor Git push nie, maar om die hele stel CI/CD en UI/UX-nutsgoed te organiseer.
'n Paar woorde oor Git
As jy nie vertroud is met weergawebeheerstelsels en Git-gebaseerde werkvloei nie, beveel ons sterk aan om daaroor te leer. Om met takke en trekversoeke te werk, kan aanvanklik soos swart magie lyk, maar die voordele is die moeite werd. Hier te begin.
Hoe Kubernetes werk
In ons storie het Alice en Bob na GitOps gewend nadat hulle 'n rukkie met Kubernetes gewerk het. Inderdaad, GitOps is nou verwant aan Kubernetes - dit is 'n operasionele model vir infrastruktuur en toepassings gebaseer op Kubernetes.
Wat gee Kubernetes aan gebruikers?
Hier is 'n paar hoofkenmerke:
- In die Kubernetes-model kan alles in verklarende vorm beskryf word.
- Die Kubernetes API-bediener neem hierdie verklaring as invoer en probeer dan voortdurend om die groepering in die toestand te bring wat in die verklaring beskryf word.
- Verklarings is voldoende om 'n wye verskeidenheid werkladings - "toepassings" te beskryf en te bestuur.
- As gevolg hiervan vind veranderinge aan die toepassing en groep plaas as gevolg van:
- veranderinge in houerbeelde;
- veranderinge aan die verklarende spesifikasie;
- foute in die omgewing - byvoorbeeld houerbotsings.
Kubernetes se groot konvergensie-vermoëns
Wanneer 'n administrateur konfigurasieveranderinge maak, sal die Kubernetes-orkeseerder dit op die groepering toepas solank die toestand daarvan is sal nie naby die nuwe konfigurasie kom nie. Hierdie model werk vir enige Kubernetes-hulpbron en is uit te brei met Custom Resource Definitions (CRD's). Daarom het Kubernetes-ontplooiings die volgende wonderlike eienskappe:
- outomatisering: Kubernetes-opdaterings verskaf 'n meganisme om die proses om veranderinge grasieus en betyds toe te pas, te outomatiseer.
- Konvergensie: Kubernetes sal voortgaan om opdaterings te probeer totdat dit suksesvol is.
- Idempotensie: Herhaalde toepassings van konvergensie lei tot dieselfde resultaat.
- Determinisme: Wanneer hulpbronne voldoende is, hang die toestand van die opgedateerde groep slegs af van die verlangde toestand.
Hoe GitOps werk
Ons het genoeg oor Kubernetes geleer om te verduidelik hoe GitOps werk.
Kom ons keer terug na Family Insurance se mikrodienste-spanne. Wat moet hulle gewoonlik doen? Kyk na die lys hieronder (as enige items daarin vreemd of onbekend lyk, wag asseblief op kritiek en bly by ons). Hierdie is slegs voorbeelde van Jenkins-gebaseerde werkstrome. Daar is baie ander prosesse wanneer jy met ander gereedskap werk.
Die belangrikste ding is dat ons sien dat elke opdatering eindig met veranderinge aan die konfigurasielêers en Git-bewaarplekke. Hierdie veranderinge aan Git veroorsaak dat die "GitOps-operateur" die groep opdateer:
1. Werksproses: "Jenkins bou - meester tak".
Taaklys:
- Jenkins stoot gemerkte beelde na Quay;
- Jenkins stoot config- en Helm-kaarte na die meesterbergingemmer;
- Die wolkfunksie kopieer die konfigurasie en kaarte van die meesterbergingemmer na die meester Git-bewaarplek;
- Die GitOps-operateur werk die groepering op.
2. Jenkins bou - vrystelling of hotfix tak:
- Jenkins stoot ongemerkte beelde na Quay;
- Jenkins stoot config- en Helm-kaarte na die opbergemmer;
- Die wolkfunksie kopieer die konfigurasie en kaarte van die staging-bergingemmer na die staging Git-bewaarplek;
- Die GitOps-operateur werk die groepering op.
3. Jenkins bou - ontwikkel of kenmerk tak:
- Jenkins stoot ongemerkte beelde na Quay;
- Jenkins stoot config en Helm kaarte in die ontwikkel stoor emmer;
- Die wolkfunksie kopieer die konfigurasie en kaarte van die ontwikkel-berging-emmer na die ontwikkel Git-bewaarplek;
- Die GitOps-operateur werk die groepering op.
4. Voeg 'n nuwe kliënt by:
- Die bestuurder of administrateur (LCM/ops) roep Gradle om aanvanklik netwerklasbalanseerders (NLB's) te ontplooi en op te stel;
- LCM/ops verbind 'n nuwe konfigurasie om die ontplooiing voor te berei vir opdaterings;
- Die GitOps-operateur werk die groepering op.
Kort beskrywing van GitOps
- Beskryf die verlangde toestand van die hele stelsel deur gebruik te maak van verklarende spesifikasies vir elke omgewing (in ons storie definieer Bob se span die hele stelselkonfigurasie in Git).
- Die Git-bewaarplek is die enkele bron van waarheid rakende die verlangde toestand van die hele stelsel.
- Alle veranderinge aan die verlangde toestand word gemaak deur commits in Git.
- Alle gewenste groepparameters is ook waarneembaar in die groepie self. Op hierdie manier kan ons bepaal of hulle saamval (konvergeer, konvergeer) of verskil (divergeer, divergeer) gewenste en waargenome toestande.
- As die verlangde en waargenome toestande verskil, dan:
- Daar is 'n konvergensiemeganisme wat vroeër of later outomaties die teiken en waargenome toestande sinchroniseer. Binne die groep doen Kubernetes dit.
- Die proses begin onmiddellik met 'n "verandering gepleeg" waarskuwing.
- Na 'n konfigureerbare tydperk kan 'n "verskil" waarskuwing gestuur word as die toestande verskil.
- Op hierdie manier veroorsaak alle commits in Git verifieerbare en idempotente opdaterings aan die cluster.
- Terugrol is konvergensie na 'n voorheen gewenste toestand.
- Die konvergensie is finaal. Die voorkoms daarvan word aangedui deur:
- Geen verskilwaarskuwings vir 'n sekere tydperk nie.
- "gekonvergeerde" waarskuwing (bv. webhook, Git-terugskryfgebeurtenis).
Wat is divergensie?
Kom ons herhaal dit weer: alle gewenste tros-eienskappe moet in die tros self waarneembaar wees.
Enkele voorbeelde van divergensie:
- Verandering in konfigurasielêer as gevolg van samesmelting van takke in Git.
- 'n Verandering in die konfigurasielêer as gevolg van 'n Git-commit wat deur die GUI-kliënt gemaak is.
- Veelvuldige veranderinge aan die verlangde toestand as gevolg van PR in Git, gevolg deur die bou van die houerbeeld en konfigurasieveranderinge.
- 'n Verandering in die toestand van die groepering as gevolg van 'n fout, hulpbronkonflik wat lei tot "slegte gedrag", of bloot toevallige afwyking van die oorspronklike toestand.
Wat is die meganisme van konvergensie?
'N Paar voorbeelde:
- Vir houers en trosse word die konvergensiemeganisme deur Kubernetes verskaf.
- Dieselfde meganisme kan gebruik word om Kubernetes-gebaseerde toepassings en ontwerpe (soos Istio en Kubeflow) te bestuur.
- 'n Meganisme vir die bestuur van die operasionele interaksie tussen Kubernetes, beeldbewaarplekke en Git bied , wat deel is .
- Vir basismasjiene moet die konvergensiemeganisme verklarend en outonoom wees. Uit eie ervaring kan ons dit sê naaste aan hierdie definisie, maar vereis steeds menslike beheer. In hierdie sin brei GitOps die tradisie van Infrastruktuur as Kode uit.
GitOps kombineer Git met die uitstekende konvergensie-enjin van Kubernetes om 'n model vir uitbuiting te verskaf.
GitOps laat ons toe om te sê: Slegs daardie stelsels wat beskryf en waargeneem kan word, kan geoutomatiseer en beheer word.
GitOps is bedoel vir die hele wolk-inheemse stapel (byvoorbeeld Terraform, ens.)
GitOps is nie net Kubernetes nie. Ons wil hê dat die hele stelsel verklarend gedryf moet word en konvergensie gebruik. Met die hele stelsel bedoel ons 'n versameling omgewings wat met Kubernetes werk - byvoorbeeld, "dev cluster 1", "produksie", ens. Elke omgewing sluit masjiene, clusters, toepassings in, sowel as koppelvlakke vir eksterne dienste wat data verskaf, monitering en ens.
Let op hoe belangrik Terraform is vir die selflaaiprobleem in hierdie geval. Kubernetes moet iewers ontplooi word, en die gebruik van Terraform beteken dat ons dieselfde GitOps-werkvloei kan toepas om die beheerlaag te skep wat Kubernetes en toepassings onderlê. Dit is 'n nuttige beste praktyk.
Daar is 'n sterk fokus op die toepassing van GitOps-konsepte op lae bo-op Kubernetes. Op die oomblik is daar GitOps-tipe oplossings vir Istio, Helm, Ksonnet, OpenFaaS en Kubeflow, sowel as, byvoorbeeld, vir Pulumi, wat 'n laag skep vir die ontwikkeling van toepassings vir cloud native.
Kubernetes CI/CD: vergelyk GitOps met ander benaderings
Soos gesê, is GitOps twee dinge:
- Die bedryfsmodel vir Kubernetes en cloud native hierbo beskryf.
- Die pad na 'n ontwikkelaargesentreerde toepassingbestuursomgewing.
Vir baie is GitOps hoofsaaklik 'n werkvloei gebaseer op Git-stoot. Ons hou ook van hom. Maar dit is nie al nie: kom ons kyk nou na CI/CD pyplyne.
GitOps maak deurlopende ontplooiing (CD) vir Kubernetes moontlik
GitOps bied 'n deurlopende ontplooiingsmeganisme wat die behoefte aan aparte "ontplooiingsbestuurstelsels" uitskakel. Kubernetes doen al die werk vir jou.
- Die opdatering van die toepassing vereis opdatering in Git. Dit is 'n transaksionele opdatering na die verlangde toestand. "Ontplooiing" word dan binne die groepering deur Kubernetes self gedoen op grond van die opgedateerde beskrywing.
- As gevolg van die aard van hoe Kubernetes werk, is hierdie opdaterings konvergent. Dit bied 'n meganisme vir deurlopende ontplooiing waarin alle opdaterings atoom is.
- Let wel: bied 'n GitOps-operateur wat Git en Kubernetes integreer en toelaat dat CD uitgevoer word deur die verlangde en huidige toestand van die groep te versoen.
Sonder kubectl en skrifte
U moet vermy om Kubectl te gebruik om u groepering op te dateer, en veral vermy om skrifte te gebruik om kubectl-opdragte te groepeer. In plaas daarvan, met die GitOps-pyplyn, kan 'n gebruiker hul Kubernetes-kluster via Git opdateer.
Voordele sluit in:
- Reg. 'n Groep opdaterings kan toegepas, saamgevloei en uiteindelik bekragtig word, wat ons nader aan die doelwit van atoomontplooiing bring. In teenstelling hiermee bied die gebruik van skrifte geen waarborg van konvergensie nie (meer hieroor hieronder).
- sekuriteit. Kelsey Hightower: "Beperk toegang tot jou Kubernetes-kluster tot outomatiseringsnutsmiddels en administrateurs wat verantwoordelik is vir die ontfouting of instandhouding daarvan." sien ook oor veiligheid en voldoening aan tegniese spesifikasies, asook deur geloofsbriewe uit 'n sorgeloos geskrewe Jenkins-skrif te steel.
- Gebruikersondervinding. Kubectl ontbloot die meganika van die Kubernetes-objekmodel, wat redelik kompleks is. Ideaal gesproke behoort gebruikers op 'n hoër vlak van abstraksie met die stelsel te kommunikeer. Hier sal ek weer na Kelsey verwys en aanbeveel om te kyk .
Verskil tussen CI en CD
GitOps verbeter bestaande CI/CD-modelle.
'n Moderne CI-bediener is 'n orkestrasie-instrument. Dit is veral 'n instrument om CI-pyplyne te orkestreer. Dit sluit in bou, toets, saamsmelt na stam, ens. CI-bedieners outomatiseer die bestuur van komplekse multi-stap pyplyne. 'n Algemene versoeking is om 'n stel Kubernetes-opdaterings te skryf en dit as deel van 'n pyplyn uit te voer om veranderinge aan die groepering te stoot. Inderdaad, dit is wat baie kenners doen. Dit is egter nie optimaal nie, en hier is hoekom.
CI moet gebruik word om opdaterings na die stam te stoot, en die Kubernetes-kluster moet homself verander op grond van daardie opdaterings om die CD intern te bestuur. Ons noem dit , anders as die CI-stootmodel. CD is deel runtime orkestrasie.
Waarom CI-bedieners nie CD's via direkte opdaterings in Kubernetes moet doen nie
Moenie 'n CI-bediener gebruik om direkte opdaterings aan Kubernetes as 'n stel CI-take te orkestreer nie. Dit is die anti-patroon waarvan ons praat op jou blog.
Kom ons gaan terug na Alice en Bob.
Watter probleme het hulle in die gesig gestaar? Bob se CI-bediener pas die veranderinge op die cluster toe, maar as dit in die proses ineenstort, sal Bob nie weet in watter toestand die cluster is (of behoort te wees) of hoe om dit reg te stel nie. Dieselfde geld in die geval van sukses.
Kom ons neem aan dat Bob se span 'n nuwe prent gebou het en dan hul ontplooiings gelap het om die prent te ontplooi (alles vanaf die CI-pyplyn).
As die beeld normaal bou, maar die pyplyn misluk, sal die span moet uitvind:
- Het die opdatering ontplooi?
- Begin ons 'n nuwe gebou? Sal dit lei tot onnodige newe-effekte - met die moontlikheid om twee bouwerk van dieselfde onveranderlike beeld te hê?
- Moet ons wag vir die volgende opdatering voordat ons die bou uitvoer?
- Wat presies het verkeerd geloop? Watter stappe moet herhaal word (en watter is veilig om te herhaal)?
Die vestiging van 'n Git-gebaseerde werkvloei waarborg nie dat Bob se span nie hierdie probleme sal teëkom nie. Hulle kan steeds 'n fout maak met die commit push, die merker of 'n ander parameter; hierdie benadering is egter steeds baie nader aan 'n eksplisiete alles-of-niks-benadering.
Om op te som, hier is hoekom CI-bedieners nie CD's moet hanteer nie:
- Opdateringsskrifte is nie altyd deterministies nie; Dit is maklik om foute in hulle te maak.
- CI-bedieners konvergeer nie na die verklarende klustermodel nie.
- Dit is moeilik om idempotensie te waarborg. Gebruikers moet die diep semantiek van die stelsel verstaan.
- Dit is moeiliker om te herstel van 'n gedeeltelike mislukking.
Nota oor Helm: As jy Helm wil gebruik, beveel ons aan dat jy dit kombineer met 'n GitOps-operateur soos bv. . Dit sal help om konvergensie te verseker. Roer self is nie deterministies of atoom nie.
GitOps as die beste manier om deurlopende aflewering vir Kubernetes te implementeer
Alice en Bob se span implementeer GitOps en ontdek dat dit baie makliker geword het om met sagtewareprodukte te werk, hoë werkverrigting en stabiliteit te handhaaf. Kom ons eindig hierdie artikel met 'n illustrasie wat wys hoe hul nuwe benadering lyk. Hou in gedagte dat ons meestal oor toepassings en dienste praat, maar GitOps kan gebruik word om 'n hele platform te bestuur.
Bedryfsmodel vir Kubernetes
Kyk na die volgende diagram. Dit bied Git en die houerbeeldbewaarplek as gedeelde hulpbronne vir twee georkestreerde lewensiklusse:
- 'n Deurlopende integrasiepyplyn wat lêers na Git lees en skryf en 'n bewaarplek van houerbeelde kan opdateer.
- 'n Runtime GitOps-pyplyn wat ontplooiing kombineer met bestuur en waarneembaarheid. Dit lees en skryf lêers na Git en kan houerbeelde aflaai.
Wat is die belangrikste bevindings?
- Skeiding van bekommernisse: Neem asseblief kennis dat beide pyplyne slegs kan kommunikeer deur Git of die beeldbewaarplek op te dateer. Met ander woorde, daar is 'n firewall tussen CI en die runtime-omgewing. Ons noem dit die "onveranderlike firewall" (onveranderbaarheid firewall), aangesien alle bewaarplekopdaterings nuwe weergawes skep. Vir meer inligting oor hierdie onderwerp, verwys na skyfies 72-87 .
- U kan enige CI- en Git-bediener gebruik: GitOps werk met enige komponent. U kan voortgaan om u gunsteling CI- en Git-bedieners, beeldbewaarplekke en toetssuites te gebruik. Byna alle ander nutsmiddels vir voortdurende aflewering op die mark benodig hul eie CI/Git-bediener of beeldbewaarplek. Dit kan 'n beperkende faktor word in die ontwikkeling van wolkinheemse. Met GitOps kan jy bekende gereedskap gebruik.
- Gebeurtenisse as 'n integrasie-instrument: Sodra data in Git opgedateer word, stel Weave Flux (of die Weave Cloud-operateur) looptyd in kennis. Wanneer Kubernetes 'n veranderingstel aanvaar, word Git opgedateer. Dit bied 'n eenvoudige integrasiemodel vir die organisering van werkvloeie vir GitOps, soos hieronder getoon.
Gevolgtrekking
GitOps bied die sterk opdateringswaarborge wat deur enige moderne CI/CD-instrument vereis word:
- outomatisering;
- konvergensie;
- idempotensie;
- determinisme.
Dit is belangrik omdat dit 'n operasionele model vir wolk-inheemse ontwikkelaars bied.
- Tradisionele gereedskap vir die bestuur en monitering van stelsels word geassosieer met operasionele spanne wat binne 'n runbook werk ('n stel roetine prosedures en operasies - ongeveer vertaal.), gekoppel aan 'n spesifieke ontplooiing.
- In wolk-inheemse bestuur is waarneembaarheidsinstrumente die beste manier om die resultate van ontplooiings te meet sodat die ontwikkelingspan vinnig kan reageer.
Stel jou voor dat baie groepe oor verskillende wolke en baie dienste versprei is met hul eie spanne en ontplooiingsplanne. GitOps bied 'n skaal-onveranderlike model om al hierdie oorvloed te bestuur.
PS van vertaler
Lees ook op ons blog:
- «»;
- «»;
- «".
Slegs geregistreerde gebruikers kan aan die opname deelneem. , asseblief.
Het jy geweet van GitOps voordat hierdie twee vertalings op Habré verskyn het?
-
Ja, ek het alles geweet
-
Slegs oppervlakkig
-
Geen
35 gebruikers het gestem. 10 gebruikers het buite stemming gebly.
Bron: will.com