GitOps: nog 'n gonswoord of 'n deurbraak in outomatisering?

Die meeste van ons, wat nog 'n nuwe term in die IT-blogsfeer of konferensie opmerk, vra vroeër of later 'n soortgelyke vraag: “Wat is dit? Net nog 'n gonswoord, 'n "gonswoord" of iets wat werklik aandag, studie en belofte van nuwe horisonne verdien? Dieselfde ding het met my gebeur met die term GitOps 'n tyd gelede. Gewapen met baie bestaande artikels, sowel as die kennis van kollegas van die maatskappy GitLab, Ek het probeer uitvind watter soort dier dit is, en hoe die gebruik daarvan in die praktyk kan lyk.

Terloops, oor die nuwigheid van die term GitOps Ons onlangse opname sê ook: meer as die helfte van diegene wat ondervra is, het nog nie met die beginsels daarvan begin werk nie.

Die probleem van infrastruktuurbestuur is dus nie nuut nie. Baie wolkverskaffers is al 'n goeie dosyn jaar vir die algemene publiek beskikbaar en, dit wil voorkom, moes die werk van die spanne wat vir die infrastruktuur verantwoordelik is eenvoudig en reguit gemaak het. In vergelyking met die toepassingsontwikkelingsproses (waar outomatisering steeds nuwe vlakke bereik), behels infrastruktuurprojekte egter steeds baie handtake en vereis gespesialiseerde kennis en kundigheid, veral gegewe vandag se vereistes vir fouttoleransie, buigsaamheid, skaalbaarheid en elastisiteit.

Wolkdienste het baie suksesvol aan hierdie vereistes voldoen en dit was hulle wat 'n beduidende stukrag aan die ontwikkeling van die benadering gegee het IaC. Dit is verstaanbaar. Hulle het dit immers moontlik gemaak om 'n heeltemal virtuele datasentrum op te stel: daar is geen fisiese bedieners, rakke of netwerkkomponente nie; die hele infrastruktuur kan beskryf word met skrifte en konfigurasielêers.

So wat presies is die verskil GitOps van IaC? Dit was met hierdie vraag dat ek my ondersoek begin het. Nadat ek met kollegas gepraat het, kon ek met die volgende vergelyking vorendag kom:

GitOps

IaC

Alle kode word in 'n git-bewaarplek gestoor

Kodeweergawe is opsioneel

Verklarende Kode Beskrywing / Idempotensie

Beide verklarende en imperatiewe beskrywings is aanvaarbaar

Veranderinge tree in werking deur gebruik te maak van die samevoegingversoek / trekversoekmeganismes

Ooreenkoms, goedkeuring en samewerking is opsioneel

Die opdaterings-ontplooiingsproses is outomaties

Die opdaterings-ontplooiingsproses is nie gestandaardiseer nie (outomaties, handmatig, kopieer lêers, gebruik die opdragreël, ens.)

Met ander woorde GitOps is juis gebore deur die toepassing van die beginsels IaC. Eerstens kan infrastruktuur en konfigurasies nou op dieselfde manier as toepassings gestoor word. Die kode is maklik om te stoor, maklik om te deel, te vergelyk en weergawe-vermoëns te gebruik. Weergawes, takke, geskiedenis. En dit alles op 'n plek wat publiek toeganklik is vir die hele span. Daarom het die gebruik van weergawebeheerstelsels 'n heeltemal natuurlike ontwikkeling geword. In die besonder, git, as die gewildste.

Aan die ander kant het dit moontlik geword om infrastruktuurbestuursprosesse te outomatiseer. Nou kan dit vinniger, meer betroubaar en goedkoper gedoen word. Boonop was die beginsels van CI / CD reeds bekend en gewild onder sagteware-ontwikkelaars. Dit was slegs nodig om reeds bekende kennis en vaardighede op 'n nuwe gebied oor te dra en toe te pas. Hierdie praktyke het egter verder gegaan as die standaarddefinisie van Infrastruktuur as kode, vandaar die konsep GitOps.

Nuuskierigheid GitOps, natuurlik ook in die feit dat dit nie 'n produk, inprop of platform is wat met enige verkoper geassosieer word nie. Dit is meer 'n paradigma en 'n stel beginsels, soortgelyk aan 'n ander term waarmee ons bekend is: DevOps.

Die maatskappy GitLab ons het twee definisies van hierdie nuwe term ontwikkel: teoreties en prakties. Kom ons begin met die teoretiese:

GitOps is 'n metodologie wat die beste DevOps-beginsels wat vir toepassingsontwikkeling gebruik word, soos weergawebeheer, samewerking, orkestrasie, CI/CD neem en dit toepas op die uitdagings van die outomatisering van infrastruktuurbestuur.

Alle prosesse GitOps Ek werk met behulp van bestaande gereedskap. Alle infrastruktuurkode word in die reeds bekende git-bewaarplek gestoor, veranderinge gaan deur dieselfde goedkeuringsproses as enige ander programkode, en die ontplooiingsproses is outomaties, wat ons in staat stel om menslike foute te minimaliseer, betroubaarheid en reproduceerbaarheid te verhoog.

Uit 'n praktiese oogpunt beskryf ons GitOps soos volg:

Ons het reeds infrastruktuur as kode as een van die sleutelkomponente van hierdie formule bespreek. Kom ons stel die res van die deelnemers voor.

Voeg Versoek saam (alternatiewe naam Trek Versoek). In prosesterme is MR 'n versoek om kodeveranderings toe te pas en dan takke saam te smelt. Maar in terme van die gereedskap wat ons gebruik, is dit meer 'n geleentheid om 'n volledige prentjie te kry van al die veranderinge wat gemaak word: nie net die kodeverskil wat van 'n sekere aantal commits ingesamel is nie, maar ook die konteks, toetsresultate, en die finale verwagte resultaat. As ons van infrastruktuurkode praat, dan stel ons belang in hoe presies die infrastruktuur sal verander, hoeveel nuwe hulpbronne bygevoeg of verwyder sal word, verander sal word. Verkieslik in 'n meer gerieflike en maklik leesbare formaat. Vir wolkverskaffers is dit 'n goeie idee om te weet wat die finansiële impak van hierdie verandering sal wees.

Maar MR is ook 'n manier van samewerking, interaksie en kommunikasie. Die plek waar die stelsel van tjeks en saldo's ter sprake kom. Van eenvoudige kommentaar tot formele goedkeurings en goedkeurings.

Wel, die laaste komponent: CI/CD, soos ons reeds weet, maak dit moontlik om die proses van die maak van infrastruktuurveranderinge en -toetsing te outomatiseer (van eenvoudige sintaksiskontrolering tot meer komplekse statiese kode-analise). En ook in die daaropvolgende opsporing van drif: verskille tussen die werklike en gewenste toestand van die stelsel. Byvoorbeeld, as gevolg van ongemagtigde handleiding veranderinge of stelsel mislukking.

Ja, die term GitOps stel ons nie voor aan enigiets heeltemal nuuts nie, vind nie die wiel weer uit nie, maar pas bloot die reeds opgehoopte ervaring in 'n nuwe area toe. Maar dit is waar sy krag lê.

En as jy skielik belangstel in hoe dit alles in die praktyk lyk, dan nooi ek jou uit om na ons meestersklas, waarin ek jou stap vir stap vertel hoe om GitLab te gebruik:

• Implementeer die basiese beginsels van GitOps

• Skep en maak veranderinge aan die wolkinfrastruktuur (met die voorbeeld van Yandex Cloud)

• Outomatiseer opsporing van stelseldrywing vanaf 'n gewenste toestand deur aktiewe monitering te gebruik

https://bit.ly/34tRpwZ

Bron: will.com