GitOps: järjekordne moesõna või läbimurre automatiseerimises?

Enamik meist, märgates IT-blogosfääris või konverentsil järjekordset uut terminit, esitab varem või hiljem sarnase küsimuse: “Mis see on? Kas lihtsalt üks moesõna, "moesõna" või midagi, mis väärib tõsist tähelepanu, uurimist ja uute horisontide lubamist? Sama juhtus minuga terminiga GitOps mõni aeg tagasi. Relvastatud paljude olemasolevate artiklite ja ka ettevõtte kolleegide teadmistega GitLab, püüdsin aru saada, mis metsaline see on ja kuidas selle kasutamine praktikas välja näeb.

Muide, termini uudsusest GitOps Ka meie värske uuring ütleb: üle poole küsitletutest pole selle põhimõtetega veel tööle hakanud.

Seega ei ole infrastruktuuri haldamise probleem uus. Paljud pilveteenuse pakkujad on olnud laiemale avalikkusele kättesaadavad juba tubli tosin aastat ning näib, et oleks pidanud taristu eest vastutavate meeskondade töö lihtsaks ja arusaadavaks tegema. Võrreldes aga rakenduste arendusprotsessiga (kus automatiseerimine jõuab üha uuele tasemele), hõlmavad taristuprojektid endiselt sageli palju käsitsi ülesandeid ning nõuavad eriteadmisi ja -teadmisi, eriti arvestades tänapäevaseid rikketaluvuse, paindlikkuse, mastaapsuse ja elastsuse nõudeid.

Pilveteenused täitsid need nõuded väga edukalt ja just need andsid lähenemise arengule olulise tõuke IaC. See on arusaadav. Lõppude lõpuks võimaldasid need konfigureerida täiesti virtuaalset andmekeskust: puuduvad füüsilised serverid, nagid ega võrgukomponendid, kogu infrastruktuuri saab kirjeldada skriptide ja konfiguratsioonifailide abil.

Mis vahe siis täpselt on? GitOps pärit IaC? Selle küsimusega alustasin uurimist. Pärast kolleegidega rääkimist suutsin välja tuua järgmise võrdluse:

GitOps

IaC

Kogu kood salvestatakse git-hoidlasse

Koodi versioonide loomine on valikuline

Deklaratiivne kood Kirjeldus / Idempotentsus

Vastuvõetavad on nii deklaratiivsed kui ka imperatiivsed kirjeldused

Muudatused jõustuvad ühendamistaotluse / tõmbamistaotluse mehhanismide abil

Kokkulepe, heakskiit ja koostöö on valikulised

Värskenduste levitamise protsess on automatiseeritud

Värskenduste levitamise protsess ei ole standardiseeritud (automaatne, käsitsi, failide kopeerimine, käsurea kasutamine jne)

Teisisõnu GitOps sündis just põhimõtete rakendamise kaudu IaC. Esiteks saab nüüd infrastruktuuri ja konfiguratsioone salvestada samamoodi nagu rakendusi. Koodi on lihtne salvestada, seda on lihtne jagada, võrrelda ja kasutada versioonide loomise võimalusi. Versioonid, harud, ajalugu. Ja seda kõike kogu meeskonnale avalikult ligipääsetavas kohas. Seetõttu muutus versioonikontrollisüsteemide kasutamine täiesti loomulikuks arenguks. Eelkõige git kui kõige populaarsem.

Teisest küljest sai võimalikuks taristu haldamise protsesside automatiseerimine. Nüüd saab seda teha kiiremini, usaldusväärsemalt ja odavamalt. Pealegi olid CI / CD põhimõtted tarkvaraarendajate seas juba tuntud ja populaarsed. Vaja oli vaid juba teadaolevaid teadmisi ja oskusi uuele alale üle kanda ja rakendada. Need tavad läksid aga kaugemale taristu kui koodi standardmääratlusest, seega ka mõistest GitOps.

Uudishimu GitOps, muidugi ka selles, et tegemist ei ole ühegi müüjaga seotud toote, pistikprogrammi ega platvormiga. See on pigem paradigma ja põhimõtete kogum, mis on sarnane teisele meile tuttavale terminile: DevOps.

Ettevõte GitLab oleme selle uue termini jaoks välja töötanud kaks definitsiooni: teoreetiline ja praktiline. Alustame teoreetilisest:

GitOps on metoodika, mis kasutab parimaid rakenduste arendamiseks kasutatavaid DevOpsi põhimõtteid, nagu versioonikontroll, koostöö, orkestreerimine, CI/CD, ning rakendab neid infrastruktuurihalduse automatiseerimise väljakutsetele.

Kõik protsessid GitOps Töötan olemasolevate tööriistadega. Kogu taristu kood salvestatakse juba tuttavasse giti hoidlasse, muudatused läbivad sama heakskiitmisprotsessi nagu iga teine ​​programmikood ning juurutamise protsess on automatiseeritud, mis võimaldab meil minimeerida inimlikke vigu, suurendada töökindlust ja reprodutseeritavust.

Praktilisest vaatenurgast kirjeldame GitOps järgmiselt:

Oleme juba arutanud infrastruktuuri kui koodi selle valemi ühe põhikomponendina. Tutvustame ülejäänud osalejaid.

Ühendamistaotlus (alternatiivne nimi Tõmbetaotlus). Protsessi mõistes on MR taotlus koodimuudatuste rakendamiseks ja seejärel harude ühendamiseks. Kuid meie kasutatavate tööriistade osas on see pigem võimalus saada täielikku ülevaadet kõigist tehtavatest muudatustest: mitte ainult teatud arvu sisseviidude põhjal kogutud koodide erinevus, vaid ka kontekst, testitulemused ja lõplik oodatav tulemus. Kui me räägime infrastruktuuri koodist, siis meid huvitab, kuidas infrastruktuur täpselt muutub, kui palju uusi ressursse lisandub või eemaldatakse, muudetakse. Soovitavalt mõnes mugavamas ja hõlpsamini loetavas vormingus. Pilvepakkujate jaoks on hea mõte teada, milline on selle muudatuse rahaline mõju.

Kuid MR on ka koostöö, suhtlemise ja suhtlemise vahend. Koht, kus tuleb mängu kontrolli ja tasakaalu süsteem. Alates lihtsatest kommentaaridest kuni ametlike kooskõlastuste ja kooskõlastusteni.

Noh, viimane komponent: CI/CD, nagu me juba teame, võimaldab automatiseerida infrastruktuuri muudatuste tegemise ja testimise protsessi (alates lihtsast süntaksi kontrollimisest kuni keerukama staatilise koodi analüüsini). Ja ka hilisemas triivi tuvastamises: erinevused süsteemi tegeliku ja soovitud oleku vahel. Näiteks volitamata käsitsi tehtud muudatuste või süsteemirikke tagajärjel.

Jah, termin GitOps ei tutvusta meile midagi täiesti uut, ei leiuta jalgratast uuesti, vaid lihtsalt rakendab juba kogutud kogemusi uuel alal. Kuid siin peitubki tema jõud.

Ja kui teil tekib järsku huvi selle vastu, kuidas see kõik praktikas välja näeb, siis kutsun teid vaatama meie lehte meistriklass, milles räägin teile samm-sammult, kuidas GitLabi kasutada:

• Rakendage GitOpsi põhiprintsiipe

• Pilve infrastruktuuri loomine ja muutmine (Yandex Cloudi näitel)

• Automatiseerige süsteemi triivimise tuvastamine soovitud olekust aktiivse jälgimise abil

https://bit.ly/34tRpwZ

Allikas: www.habr.com