Daugelis iš mūsų, pastebėję dar vieną naują terminą IT blogosferoje ar konferencijoje, anksčiau ar vėliau užduodame panašų klausimą: „Kas tai? Tiesiog dar vienas madingas žodis, „madingas žodis“ ar kažkas, kas tikrai verta dėmesio, tyrinėjimo ir naujų horizontų pažado? Tas pats nutiko ir man su terminu „GitOps“ prieš kažkiek laiko. Apsiginklavęs daugybe esamų straipsnių, taip pat kolegų iš įmonės žiniomis , bandžiau išsiaiškinti, koks tai žvėris ir kaip jo panaudojimas galėtų atrodyti praktiškai.
Beje, apie termino naujumą „GitOps“ Mūsų neseniai atlikta apklausa taip pat sako: daugiau nei pusė apklaustųjų dar nepradėjo dirbti pagal jos principus.
Taigi infrastruktūros valdymo problema nėra nauja. Daugelis debesų paslaugų teikėjų buvo prieinami plačiajai visuomenei gerą tuziną metų ir, atrodytų, už infrastruktūrą atsakingų komandų darbą turėjo padaryti paprastą ir nesudėtingą. Tačiau, lyginant su taikomųjų programų kūrimo procesu (kai automatizavimas pasiekia vis naujus lygius), infrastruktūros projektai vis dar dažnai apima daug rankinių užduočių ir reikalauja specialių žinių bei kompetencijos, ypač atsižvelgiant į šiandienos reikalavimus dėl atsparumo gedimams, lankstumo, mastelio ir elastingumo.
Debesijos paslaugos šiuos reikalavimus įvykdė labai sėkmingai ir būtent jos davė didelį postūmį metodo plėtrai TAC. Tai suprantama. Juk jie leido sukonfigūruoti visiškai virtualų duomenų centrą: nėra fizinių serverių, stelažų ar tinklo komponentų, visą infrastruktūrą galima apibūdinti naudojant scenarijus ir konfigūracijos failus.
Taigi, koks tiksliai yra skirtumas? „GitOps“ nuo TAC? Būtent su šiuo klausimu pradėjau savo tyrimą. Po pokalbio su kolegomis galėjau pateikti tokį palyginimą:
„GitOps“
TAC
Visas kodas saugomas git saugykloje
Kodo versijų nustatymas yra neprivalomas
Deklaratyvus kodas Aprašymas / Idempotencija
Priimtini tiek deklaratyvūs, tiek imperatyvūs apibūdinimai
Pakeitimai įsigalioja naudojant sujungimo užklausos / ištraukimo užklausos mechanizmus
Susitarimas, patvirtinimas ir bendradarbiavimas yra neprivalomi
Atnaujinimo diegimo procesas yra automatizuotas
Atnaujinimo diegimo procesas nėra standartizuotas (automatinis, rankinis, failų kopijavimas, komandų eilutės naudojimas ir kt.)
Kitaip tariant „GitOps“ gimė būtent taikant principus TAC. Pirma, infrastruktūra ir konfigūracijos dabar gali būti saugomos taip pat, kaip ir programos. Kodą lengva saugoti, jį lengva bendrinti, palyginti ir naudoti versijų kūrimo galimybes. Versijos, šakos, istorija. Ir visa tai viešai visai komandai prieinamoje vietoje. Todėl versijų valdymo sistemų naudojimas tapo visiškai natūraliu vystymusi. Visų pirma, git, kaip populiariausias.
Kita vertus, atsirado galimybė automatizuoti infrastruktūros valdymo procesus. Dabar tai galima padaryti greičiau, patikimiau ir pigiau. Be to, CI / CD principai jau buvo žinomi ir populiarūs tarp programinės įrangos kūrėjų. Tereikėjo jau žinomas žinias ir įgūdžius perkelti ir pritaikyti į naują sritį. Tačiau ši praktika peržengė standartinį infrastruktūros kaip kodo apibrėžimą, taigi ir sąvoką „GitOps“.
Smalsumas „GitOps“, žinoma, ir tai, kad tai nėra produktas, papildinys ar platforma, susijusi su kokiu nors pardavėju. Tai daugiau paradigma ir principų rinkinys, panašus į kitą mums pažįstamą terminą: „DevOps“.
Įmonė sukūrėme du šio naujo termino apibrėžimus: teorinį ir praktinį. Pradėkime nuo teorinės:
„GitOps“ yra metodika, kuri perima geriausius „DevOps“ principus, naudojamus kuriant programas, tokias kaip versijų valdymas, bendradarbiavimas, orkestravimas, CI/CD, ir pritaiko juos infrastruktūros valdymo automatizavimo iššūkiams.
Visi procesai „GitOps“ Dirbu naudodamas esamas priemones. Visas infrastruktūros kodas saugomas jau pažįstamoje git saugykloje, pakeitimai vyksta per tą patį patvirtinimo procesą kaip ir bet kuris kitas programos kodas, o diegimo procesas yra automatizuotas, o tai leidžia sumažinti žmogiškąsias klaidas, padidinti patikimumą ir atkuriamumą.
Praktiniu požiūriu aprašome „GitOps“ taip:
Mes jau aptarėme infrastruktūrą kaip kodą kaip vieną iš pagrindinių šios formulės komponentų. Pristatykime likusius dalyvius.
Sujungti užklausą (alternatyvus pavadinimas Pull Request). Kalbant apie procesą, MR yra prašymas pritaikyti kodo pakeitimus ir tada sujungti šakas. Tačiau kalbant apie mūsų naudojamus įrankius, tai yra labiau galimybė susidaryti išsamų visų atliekamų pakeitimų vaizdą: ne tik kodo skirtumai, surinkti iš tam tikro skaičiaus įsipareigojimų, bet ir kontekstas, bandymų rezultatai ir galutinis laukiamas rezultatas. Jei kalbame apie infrastruktūros kodą, tai mums įdomu, kaip tiksliai keisis infrastruktūra, kiek naujų resursų bus pridėta ar pašalinta, pakeista. Pageidautina kokiu nors patogesniu ir lengviau skaitomu formatu. Debesijos paslaugų teikėjams naudinga žinoti, koks bus finansinis šio pakeitimo poveikis.
Tačiau MR taip pat yra bendradarbiavimo, sąveikos ir bendravimo priemonė. Vieta, kur įsijungia stabdžių ir atsvarų sistema. Nuo paprastų komentarų iki oficialių patvirtinimų ir patvirtinimų.
Na, o paskutinis komponentas: CI/CD, kaip jau žinome, leidžia automatizuoti infrastruktūros pakeitimų ir testavimo procesą (nuo paprasto sintaksės tikrinimo iki sudėtingesnės statinio kodo analizės). Taip pat ir vėlesniame dreifo aptikime: skirtumai tarp tikrosios ir norimos sistemos būsenos. Pavyzdžiui, dėl neteisėtų rankinių pakeitimų arba sistemos gedimo.
Taip, terminas „GitOps“ nesupažindina mūsų su niekuo visiškai nauja, neišradinėja dviračio iš naujo, o tiesiog pritaiko jau sukauptą patirtį naujoje srityje. Bet čia slypi jo stiprybė.
Ir jei staiga susidomėsite, kaip visa tai atrodo praktiškai, kviečiu pažiūrėti mūsų , kuriame žingsnis po žingsnio pasakoju, kaip naudoti „GitLab“:
-
Įdiekite pagrindinius GitOps principus
-
Kurkite ir keiskite debesų infrastruktūrą (naudojant „Yandex Cloud“ pavyzdį)
-
Automatizuokite sistemos nukrypimo nuo norimos būsenos aptikimą naudodami aktyvų stebėjimą
https://bit.ly/34tRpwZ
Šaltinis: www.habr.com