GitOps: še ena modna beseda ali preboj v avtomatizaciji?

Večina nas, ko opazi še en nov izraz v IT blogosferi ali na konferenci, prej ali slej zastavi podobno vprašanje: »Kaj je to? Samo še ena modna beseda, »močna beseda« ali nekaj resnično vrednega natančne pozornosti, študija in obljube novih obzorij?« Enako se mi je zgodilo s terminom GitOps nekaj časa nazaj. Oborožen s številnimi obstoječimi članki, pa tudi z znanjem kolegov iz podjetja GitLab, sem poskušal ugotoviti, kakšna zver je to in kakšna bi lahko bila njena uporaba v praksi.

Mimogrede, o novosti izraza GitOps Tudi naša nedavna raziskava pravi: več kot polovica anketiranih še ni začela delati po njenih načelih.

Problem upravljanja infrastrukture torej ni nov. Številni ponudniki oblakov so širši javnosti na voljo že dober ducat let in zdi se, da bi morali poenostaviti in poenostaviti delo ekip, odgovornih za infrastrukturo. Vendar pa v primerjavi s procesom razvoja aplikacij (kjer avtomatizacija dosega vedno nove ravni) infrastrukturni projekti še vedno pogosto vključujejo številna ročna opravila in zahtevajo specializirano znanje in strokovnost, zlasti glede na današnje zahteve glede tolerance napak, fleksibilnosti, razširljivosti in elastičnosti.

Oblačne storitve so te zahteve zelo uspešno izpolnile in prav te so dale pomemben zagon razvoju pristopa IaC. To je razumljivo. Navsezadnje so omogočili konfiguracijo popolnoma virtualnega podatkovnega centra: ni fizičnih strežnikov, regalov ali omrežnih komponent, celotno infrastrukturo je mogoče opisati s skripti in konfiguracijskimi datotekami.

Kakšna je torej razlika? GitOps od IaC? S tem vprašanjem sem začel svoje raziskovanje. Po pogovoru s kolegi sem lahko prišel do naslednje primerjave:

GitOps

IaC

Vsa koda je shranjena v repozitoriju git

Različica kode ni obvezna

Deklarativna koda Opis / Idempotenca

Sprejemljivi so tako deklarativni kot nujni opisi

Spremembe stopijo v veljavo z uporabo mehanizmov zahteve za združitev/povleka

Dogovor, odobritev in sodelovanje niso obvezni

Postopek uvedbe posodobitve je avtomatiziran

Postopek uvedbe posodobitve ni standardiziran (samodejno, ročno, kopiranje datotek, uporaba ukazne vrstice itd.)

Z drugimi besedami GitOps se je rodil prav z uporabo načel IaC. Prvič, infrastrukturo in konfiguracije je zdaj mogoče shranjevati na enak način kot aplikacije. Kodo je enostavno shraniti, deliti, primerjati in uporabljati zmožnosti različic. Različice, veje, zgodovina. In vse to na mestu, ki je javno dostopno celotni ekipi. Zato je uporaba sistemov za nadzor različic postala povsem naraven razvoj. Predvsem git, kot najbolj priljubljen.

Po drugi strani pa je postalo mogoče avtomatizirati procese upravljanja infrastrukture. Zdaj je to mogoče narediti hitreje, zanesljiveje in ceneje. Poleg tega so bila načela CI/CD že poznana in priljubljena med razvijalci programske opreme. Treba je bilo le prenesti in uporabiti že znana znanja in veščine na novo področje. Te prakse pa so presegle standardno definicijo infrastrukture kot kode, torej koncepta GitOps.

Radovednost GitOps, seveda tudi v dejstvu, da ne gre za izdelek, vtičnik ali platformo, povezano s katerim koli prodajalcem. Je bolj paradigma in niz načel, podobno drugemu izrazu, ki ga poznamo: DevOps.

Podjetje GitLab razvili smo dve definiciji tega novega pojma: teoretično in praktično. Začnimo s teoretičnim:

GitOps je metodologija, ki vzame najboljša načela DevOps, ki se uporabljajo za razvoj aplikacij, kot so nadzor različic, sodelovanje, orkestracija, CI/CD, in jih uporabi za izzive avtomatizacije upravljanja infrastrukture.

Vsi procesi GitOps Delam z obstoječimi orodji. Vsa infrastrukturna koda je shranjena v že znanem repozitoriju git, spremembe gredo skozi isti postopek odobritve kot katera koli druga programska koda, postopek uvajanja pa je avtomatiziran, kar nam omogoča, da minimiziramo človeške napake, povečamo zanesljivost in ponovljivost.

S praktičnega vidika opisujemo GitOps kot sledi:

O infrastrukturi kot kodi kot eni ključnih komponent te formule smo že razpravljali. Predstavimo še ostale udeležence.

Zahteva za združitev (alternativno ime Zahteva za vlečenje). V smislu postopka je MR zahteva za uporabo sprememb kode in nato združitev vej. Toda v smislu orodij, ki jih uporabljamo, je to bolj priložnost, da dobimo popolno sliko vseh izvedenih sprememb: ne samo razlike kode, zbrane iz določenega števila potrditev, ampak tudi kontekst, rezultate testov in končni pričakovani rezultat. Če govorimo o infrastrukturni kodi, potem nas zanima, kako natančno se bo infrastruktura spremenila, koliko novih virov bo dodanih ali odstranjenih, spremenjenih. Po možnosti v kakšni bolj priročni in lahko berljivi obliki. Za ponudnike storitev v oblaku je dobro vedeti, kakšen bo finančni učinek te spremembe.

Toda MR je tudi sredstvo sodelovanja, interakcije in komunikacije. Kraj, kjer pride v poštev sistem zavor in ravnotežij. Od preprostih komentarjev do formalnih odobritev in odobritev.

No, zadnja komponenta: CI/CD, kot že vemo, omogoča avtomatizacijo procesa spreminjanja infrastrukture in testiranja (od preprostega preverjanja sintakse do kompleksnejše statične analize kode). In tudi pri kasnejšem odkrivanju drifta: razlike med realnim in želenim stanjem sistema. Na primer zaradi nepooblaščenih ročnih sprememb ali okvare sistema.

Da, izraz GitOps ne uvaja v nič povsem novega, ne izumlja kolesa na novo, ampak zgolj aplicira že nabrane izkušnje na novem področju. A prav v tem je njegova moč.

In če vas nenadoma začne zanimati, kako vse skupaj izgleda v praksi, vas vabim, da si ogledate našo mojstrski razred, v katerem vam korak za korakom povem, kako uporabljati GitLab:

• Implementirajte osnovna načela GitOps

• Ustvarite in spremenite infrastrukturo v oblaku (na primeru Yandex Cloud)

• Avtomatsko zaznavanje premika sistema iz želenega stanja z uporabo aktivnega nadzora

https://bit.ly/34tRpwZ

Vir: www.habr.com