Enamik meist, märkates järjekordset uut terminit IT-blogides või konverentsidel, küsib ennem või hiljem sarnase küsimuse: "Mis see on? Järjekordne moesõna või tõeliselt midagi, mis väärib tähelepanu, uurimist ja lubab uusi horisonte?" Samamoodi juhtus minuga termini GitOps mõni aeg tagasi. Varustatuna rohkete olemasolevate artiklite ja kolleegide teadmisest ettevõttes, püüdsin ma välja selgitada, mis loom see on, ja kuidas selle rakendamine praktikas välja näeb.
Muide, termini uuenduslikkust GitOps tõendab ka hiljuti tehtud küsitlus: enam kui pooled vastanutest pole veel hakanud töötama selle põhimõtetega.
Seega, infrastruktuuri haldamise probleem ei ole uus. Paljud pilveteenuse pakkujad on olnud avalikkusele kergesti kätte saadavad juba üle kümne aasta ja tundub, et nad peaksid olema teinud infrastruktuuri meeskondade töö lihtsaks ja probleemivabaks. Siiski, rakenduste arendamise protsessiga võrreldes (kus automatiseerimise tase saavutab pidevalt uusi horisonte) sisaldavad infrastruktuuri projektid endiselt sageli mitmeid käsitsi teostatavaid ülesandeid ning nõuavad eriteadmisi ja spetsialiste, eriti arvestades kaasaegseid nõudmisi töökindluse, paindlikkuse, skaleeritavuse ja elastsete lahenduste osas.
Pilveteenused on edukalt täitnud neid nõudmisi ja just nemad on andnud märkimisväärse tõuke lähenemise arengule IaC. See on arusaadav. Just nemad on võimaldanud konfigureerida täielikult virtuaalse andmekeskuse: puuduvad füüsilised serverid, riiulid, võrgu komponente, kogu infrastruktuuri saab kirjeldada skriptide ja konfiguratsioonifailide abil.
Mis siis täpselt on erinevus GitOps alates IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Kogu kood hoitakse git-repositooriumis
Koodi versioonimine ei ole kohustuslik
Deklaratiivne koodi kirjeldamine / Idempotentsus
Lubatud on nii deklaratiivne kui ka imperatiivne kirjeldamine
Muutused jõustuvad Merge Requesti / Pull Requesti mehhanismide abil
Sünni, kinnitamise ja koostöö tegemine ei ole kohustuslik
Uuenduste rakendamise protsess on automatiseeritud
Uuenduste rakendamise protsess ei ole reguleeritud (automaatne, käsitsi, failide kopeerimine, käsurea kasutamine jne)
Teisisõnu GitOps sai alguse just nn põhimõtete rakendamise kaudu IaC. Esiteks, infrastruktuure ja konfigureerimisi sai nüüd salvestada samamoodi nagu rakendusi. Koodi on lihtne salvestada, jagada, võrrelda ja kasutada versioonihalduse võimalusi. Versioonid, harud, ajalugu. Ja kõik see koht on kogu meeskonnale avatud. Seetõttu oli täiesti loomulik, et hakkasid kasutama versioonikontrollisüsteeme. Eelkõige git, kuna see on kõige populaarsem.
Teiselt poolt on tekinud võimalus automatiseerida infrastruktuuri haldamise protsesse. Nüüd saab seda teha kiiremini, usaldusväärsemalt ja odavamalt. Eriti kuna CI/CD põhimõtted on juba tuntud ja populaarsed tarkvaraarendajate seas. Oli vajalik vaid teadaolevad teadmised ja oskused uude valdkonda üle kanda ja rakendada. Need praktikad ületavad siiski tavapärast arusaama infrastruktuurist kui koodist, seetõttu tekkis mõisted. GitOps.
Uudishimu GitOps, muidugi, on ka selles, et see ei ole toode, plugin või platvorm, mis oleks seotud mingi tootjaga. See on pigem paradigmainimes ja põhimõtete kogum, sarnane teisele tuttavale terminile: DevOps.
Ettevõttes Oleme välja töötanud kaks määratlust selle uue termini jaoks: teoreetiline ja praktiline. Alustame teoreetilisest:
GitOps on metodoloogia, mis kasutab arenguga seotud DevOps'i juhtpõhimõtteid, nagu versioonihaldus, koostöö, kooskõlastamine, CI/CD ja rakendab neid infrastruktuuri haldamise automatiseerimisülesannete lahendamiseks.
Kõik protsessid GitOps Töötan juba olemasolevaid tööriistu kasutades. Kogu infrastruktuuri kood salvestatakse tuttavasse git-repositti, muudatused läbivad sama kooskõlastamisprotsessi nagu iga teine programmikood, ning juurutamisprotsess on automatiseeritud, mis võimaldab minimeerida inimfaktorist tingitud vigu, suurendades usaldusväärsust ja reprodutseeritavust.
Praktilisest vaatenurgast kirjeldame GitOps järgmiselt:
Infrastruktuuri kui koodi oleme juba arutanud kui ühe selle valemi põhikomponendi. Kujutame nüüd ette teisi osalejaid.
Merge Request (alternatiivne nimi Pull Request). MR-i protsessi mõttes on see koodimuudatuste rakendamise ja harude sulandumise taotlemine. Ent tööriistade vaatest on see pigem võimalus saada täielik ülevaade kõigist muudatustest: mitte ainult koodide erinevus, mis on komponeeritud mitmest commit’ist, vaid ka kontekst, testitulemused ja oodatav lõpptulemus. Kui räägime infrastruktuuri koodist, siis on oluline teada, kuidas see infrastruktuur täpselt muutub, kui palju uusi ressursse lisatakse, eemaldatakse või muudetakse. Soovitav oleks see esitada mingisuguses mugavas ja kergesti loetavas formaadis. Pilveteenuse pakkujate puhul oleks hea teada, millised rahalised tagajärjed kaasnevad selle muudatusega.
Aga MR on ka koostöö, suhtlemise ja interaktsiooni vahend. See on koht, kus töötab tasakaalusüsteem. Alates lihtsatest kommentaaridest kuni ametlike heakskiidudeni ja kinnitusteni.
Ja viimane komponent: CI/CD, nagu juba teame, võimaldab automatiseerida infrastruktuuri muudatuste, testimise (lihtsast süntaksi kontrollist keerukamate staatiliste koodianalüüsideni) käiku. Ja samuti avastada hiljem süsteemi tegelikku ja soovitud seisundi erinevusi. Näiteks tulemuseks võib olla volitamata käsitsi muudatused või süsteemi rike.
Jah, termin GitOps ei tutvusta meid absoluutselt uuega, ega leiuta jalgratast, vaid rakendab juba kogutud kogemust uuel alal. Kuid just selles peitub tema jõud.
Ja kui teile juhtub huvi pakkuma, kuidas see kõik praktikas välja näeb, siis kutsun teid vaatama meie , kus ma samm-sammult räägin, kuidas GitLabi abil:
Rakendada GitOpsi põhialuseid
Luua ja teha muudatusi pilvi infrastruktuuris (Yandex Cloudi näitel)
Automatiseerida süsteemi soovitud olekust kõrvalekallete avastamine aktiivse jälgimise abil
https://bit.ly/34tRpwZ
Allikas: habr.com
