GitOps: një tjetër term në modë apo një hap i madh përpara në automatizim?

Shumica e nesh, duke vënë re një term të ri në bloget IT ose konferencat, njëherë ose tjetër, nganjëherë pyesin: “Çfarë është kjo? Një fjalë e modës, “buzzword” apo vërtet diçka që meriton vëmendje të veçantë, studim dhe premton horizon të ri?” Kështu më ndodhi edhe mua me termin GitOps disa kohë më parë. I armatosur me shumë artikuj tashmë ekzistues, si dhe njohurinë e kolegëve nga kompania GitLab, përpiqesha të kuptoja se çfarë loje ishte kjo dhe si do të dukej aplikimi i saj në praktikë.

Sidoqoftë, për freskinë e terminit GitOps tregon gjithashtu një anketë të zhvilluar kohët e fundit nga ne: më shumë se gjysma e të anketuarve ende nuk kanë filluar të punojnë me parimet e tij.

Pra, problemi i menaxhimit të infrastrukturës nuk është i ri. Shumë ofrues të shërbimeve në re janë në dispozicion për publikun e gjerë për më shumë se një dekadë dhe, duke dukej, duhet të kishin bërë punën e ekipeve përgjegjëse për infrastrukturën të thjeshtë dhe pa probleme. Megjithatë, kur krahasohet me procesin e zhvillimit të aplikacioneve (ku niveli i automatizimit arrin horizonte gjithnjë e më të reja), projektet infrastrukturale ende shpesh përfshijnë shumë detyra manuale dhe kërkojnë njohuri dhe specialistë të veçantë, sidomos në përputhje me kërkesat moderne për qëndrueshmërinë, fleksibilitetin, shkallëzimin dhe elastikën.

Shërbimet në re i kanë përmbushur këto kërkesa me sukses dhe ato i dhanë një shtysë të madhe zhvillimit të qasjes IaC. Edhe e kuptueshme. Sepse ato dhanë mundësinë për të konfiguruar një qendër të plotë virtuale të përpunimit të të dhënave: nuk ka serverë fizikë, raftesh, komponentësh rrjetërore, e gjithë infrastruktura mund të përshkruhet duke përdorur skenarë dhe skedarë konfigurimi.

Pra, çfarë është vërtet ndryshimi GitOps nga IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:

GitOps

IaC

I gjithë kodi ruhet në një depo git

Versionimi i kodit nuk është i detyrueshëm

Përshkrimi deklarativ i kodit / Idempotentësi

Si deklarativ ashtu edhe përshkrimi imperativ është i pranueshëm

Ndryshimet hyjnë në fuqi duke përdorur mekanizmat e Merge Request / Pull Request

Miratimi, miratimi dhe bashkëpunimi nuk janë të detyrueshme

Procesi i nxjerrjes së përditësimeve është automatizuar

Procesi i nxjerrjes së përditësimeve nuk është i rregulluar (automatike, manuale, kopjim skedarësh, duke përdorur komandën e linjës etj.)

Me fjalë të tjera GitOps lindi pikërisht falë aplikimit të parimeve IaC. Së pari, infrastruktura dhe konfigurimet tani mund të ruhen pikërisht si aplikacionet. Kodi është lehtësisht i ruajtur, i ndarë, krahasuar dhe përdor mundësitë e versioneve. Versionet, degët, historia. Dhe gjithçka ndodhet në një vend publik për të gjithë ekipin. Prandaj, përdorimi i sistemeve të kontrollit të versioneve u zhvillua në mënyrë të natyrshme. Në veçanti, git, si më i popullarizuari.

Nga ana tjetër, u mundësua automatizimi i proceseve të menaxhimit të infrastrukturës. Tani kjo mund të bëhet më shpejt, më besueshëm dhe më lirë. Aq më tepër, parimet CI / CD ishin tashmë të njohura dhe të popullarizuara mes zhvilluesve të softuerit. Duhej vetëm të transferoheshin dhe aplikohej njohuritë dhe aftësitë e njohura në një fushë të re. Këto praktika, megjithatë, kalonin përtej përkufizimit standard të Infrastrukturës si Kod, dhe kështu lindi koncepti. GitOps.

Kureshtja GitOps, sigurisht, është gjithashtu se nuk është një produkt, plugin ose platformë që lidhet me ndonjë ofrues. Kjo është më tepër një paradigëm dhe një grup parimesh, e ngjashme me termin tjetër të njohur për ne: DevOps.

At the company GitLab Ne kemi formuluar dy përkufizime të këtij termi të ri: teorike dhe praktike. Le të fillojmë me atë teorike:

GitOps është një metodologji që përdor parimet e avancuara të DevOps, të përdorura për zhvillimin e aplikacioneve, si kontrolli i versioneve, interoperabiliteti, miratimi, CI/CD, dhe i aplikon ato për të zgjidhur detyrat e automatizimit të menaxhimit të infrastrukturës.

Të gjitha proceset GitOps punojnë duke përdorur mjetet ekzistuese. I gjithë kodi infrastrukturor ruhet në një depo git që është e njohur, ndryshimet kalojnë të njëjtin proces miratimi si cilido kod tjetër programimi, dhe procesi i shpërndarjes është i automatizuar, duke minimizuar gabimet njerëzore, përmirësuar besueshmërinë dhe riprodhueshmërinë.

Nga pikëpamja praktike, ne përshkruajmë GitOps në mënyrë të tillë:

Infrastruktura si kod e kemi diskutuar tashmë si një nga komponentët kryesorë të kësaj formule. Le të imagjinojmë pjesëmarrësit e tjerë.

Merge Request (emri alternativ i Pull Request). Në planin e procesit, MR është një kërkesë për zbatimin e ndryshimeve në kod dhe bashkimin e degëve. Por në planin e mjeteve që përdorim, kjo është më shumë një mundësi për të pasur një pamje të plotë të të gjitha ndryshimeve të propozuara: jo vetëm diferencën e kodit, e cila është e grumbulluar nga një sasi e caktuar commit-esh, por gjithashtu konteksti, rezultatet e testeve dhe rezultati përfundimtar i pritur. Nëse flasim për kodin e infrastrukturës, na intereson si do të ndryshojë infrastruktura, sa burime të reja do të shtohen apo hiqen, ose do të ndryshojnë. Preferohet të jetë në një format më të rehatshëm dhe të lexueshëm. Në rastin e ofruesve të shërbimeve në cloud, do të ishte mirë të dinim se cilat janë pasojat financiare që do të sjellë ky ndryshim.

Por MR është gjithashtu një mjet bashkëpunimi, ndërveprimi, komunikimit. Ajo është vendi ku aktivizohet sistemi i kontrolleve dhe balancave. Nga komentet e thjeshta deri te miratimet formale dhe konfirmimet.

Dhe komponenti i fundit: CI/CD, siç e dimë tashmë, jep mundësinë për të automatizuar procesin e bërjes së ndryshimeve në infrastrukturë, testimin (nga kontrolli i thjeshtë i sintaksës deri te analiza më komplekse statike e kodit). Gjithashtu, në vazhduim, zbulimin e drifts: dallimet midis gjendjes reale dhe asaj të dëshiruar të sistemit. Për shembull, si rezultat i ndryshimeve manuale të paautorizuara ose të dështimit të sistemeve.

Po, termi GitOps nuk na prezanton me asgjë krejtësisht të re, nuk shpik një biçikletë të re, por thjesht aplikon përvojën e grumbulluar në një fushë të re. Por në këtë qëndron fuqia e tij.

Dhe nëse ndonjëherë jeni të interesuar për mënyrën se si duket e gjithë kjo në praktikë, ju ftoj të shikoni masterclass-in tonë, në të cilin hapat e mia ju tregoj se si me ndihmën e GitLab:

• Të realizoni parimet themelore të GitOps

• Të krijoni dhe bëni ndryshime në infrastrukturën cloud (për shembull Rrjeti Yandex)

• Të automatizoni zbulimin e drifts të sistemit nga gjendja e dëshiruar përmes monitorimit aktiv

https://bit.ly/34tRpwZ

Burimi: habr.com