Shumica prej nesh, duke vënë re një termin të ri në blogosferën IT ose në një konferencë, herë pas here, pyesim veten: “Çfarë është kjo? Një fjalë tjetër trendy, “buzzword” apo vërtet diçka që meritohet vëmendjen, studimin dhe që premton horizonte të reja?” Po ashtu, këtë pyetje pata për termin GitOps për një kohë të shkurtër më parë. E pajisur me shumë artikuj ekzistues, si dhe me njohuritë e kolegëve nga kompania , unë përpiqesha të kuptoja se çfarë ishte ky term, dhe si mund të dukej aplikimi i tij në praktikë.
Tani për tani, për risinë e termit GitOps po ashtu tregon një anketë e fundit që ne realizuam: 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ë asgjë e re. Shumë ofrues të cloud kanë qenë të disponueshëm për publikun për më shumë se një dekadë dhe, duket se, duhet të kenë bërë punën e ekipeve përgjegjëse për infrastrukturën të thjeshtë dhe pa mundim. Megjithatë, kur krahasohet me procesin e zhvillimit të aplikacioneve (ku niveli i automatizimit arrin horizonte gjithnjë e më të reja), projektet e infrastrukturës shpesh përfshijnë ende shumë detyra që kryhen manualisht dhe kërkojnë njohuri dhe specialistë të veçantë, veçanërisht duke marrë parasysh kërkesat moderne për qëndrueshmëri, fleksibilitet, shkallëzim dhe elastikë.
Shërbimet cloud e përmbushën shumë me sukses këto kërkesa dhe pikërisht ato dhanë një shtysë të konsiderueshme për zhvillimin e qasjes. IaCKjo është e qartë. Ato, gjithashtu, ofruan mundësinë për të konfiguruar një qendër të plotë të përpunimit virtual të të dhënave: nuk ka serverë fizikë, raftesh, komponentësh rrjetesh, e gjithë infrastruktura mund të përshkruhet përmes skripteve dhe skedarëve të konfigurimit.
Pra, cili është 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 / Idempotencë
Të dy përshkrime deklarative dhe imperative janë të pranuara
Ndryshimet hyjnë në fuqi duke përdorur mekanizmat e Merge Request / Pull Request
Koordinimi, miratimi dhe bashkëpunimi janë të panevojshme
Procesi i lançimit të përditësimeve është automatizuar
Procesi i lançimit të përditësimeve nuk është i standardizuar (automatike, manuale, kopjimi i skedarëve, përdorimi i komandës dhe kështu me radhë)
Në fjalë të tjera GitOps u shfaq pikërisht falë aplikimit të principeve IaC. Së pari, infrastruktura dhe konfigurimet tani mund të ruhen njësoj si aplikacionet. Kodi është i lehtë për t'u ruajtur, i lehtë për t'u ndarë, për të krahasuar, për të përfituar nga mundësitë e versionimit. Versionet, degët, historia. Dhe gjithçka në një vend të hapur për të gjithë ekipin. Prandaj, përdorimi i sistemeve të kontrollit të versionit u bë një evolucion krejtësisht i natyrshëm. Sidomos git, si më i njohur.
Nga ana tjetër, u krijua mundësia për të automatizuar proceset e menaxhimit të infrastrukturës. Tani kjo mund të bëhet më shpejt, më të besueshëm dhe më lirë. Për më tepër, parimet CI/CD kishin qenë tashmë të njohura dhe të popullarizuara midis zhvilluesve të softuerit. Nevojitej vetëm të transferoheshin dhe aplikoheshin njohuritë dhe aftësitë e njohura në një fushë të re. Megjithatë, këto praktika kalonin përtej pë定义standard të Infrastrukturës si Kod, dhe kështu lindi ky koncept. GitOps.
Kureshtja GitOps, sigurisht, qëndron gjithashtu në faktin se nuk është një produkt, plugin apo platformë e lidhur me ndonjë forcë shitëse. Kjo është më tepër një paradigmë dhe një grup parimesh, ngjashëm me një term tjetër të njohur për ne: DevOps.
Në kompani ne kemi formuluar dy përkufizime të këtij termi të ri: teorik dhe praktik. Të fillojmë me teorinë:
GitOps është një metodologji që përdor parime përparimtare të DevOps, të përdorura për zhvillimin e aplikacioneve, siç janë kontrolli i versioneve, bashkëpunimi, konsensusi, CI/CD, dhe i aplikon ato për të zgjidhur detyrat e automatizimit të menaxhimit të infrastrukturës.
Të gjitha proceset GitOps punoj me mjete që janë tashmë në dispozicion. I gjithë kodi infrastrukturor ruhet në një depo git të njohur, ndryshimet ndjekin të njëjtin proces miratimi si çdo kod tjetër programimi, dhe procesi i implementimit është automatizuar, duke ulur gabimet e faktorëve njerëzorë, rritur besueshmërinë dhe riprodhueshmërinë.
Nga këndvështrimi praktik, ne përshkruajmë GitOps si nga:
Infrastruktura si kod e kemi diskutuar tashmë si një nga komponentët kyç të kësaj formule. Le të imagjinojmë pjesëmarrësit e tjerë.
Kërkesa për Bashkim (emri alternativ për Kërkesën e Tërheqjes). Në planin e procesit MR — është një kërkesë për të aplikuar ndryshimet në kod dhe për të bashkuar degët. Por në planin e mjeteve që përdorim — kjo është më shumë mundësia për të marrë një pamje të plotë të të gjitha ndryshimeve të bëra: jo vetëm ndryshimi i kodit, i mbledhur nga një numër 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 se si do të ndryshojë infrastruktura, sa burime të reja do të shtohen ose hiqen, të ndryshohen. Preferohet në një format më të përshtatshëm dhe lehtësisht të lexueshëm. Në rastin e ofruesve të shërbimeve cloud, do të ishte mirë të dinim se cilat pasoja financiare do të sjellë ky ndryshim.
Por MR — është gjithashtu një mjet bashkëpunimi, ndërveprimi, komunikimi. Vendi ku hyn në veprim sistemi i ndalesave dhe balancave. Nga komentet e thjeshta deri te miratimet dhe konfirmimet formale.
Dhe komponenta e fundit: CI/CD, siç e dimë tashmë, ofron mundësinë për të automatizuar procesin e ndryshimeve në infrastrukturë, testimit (nga kontrolli i thjeshtë i sintaksës deri te analiza më e komplikuar statike e kodit). Gjithashtu, ajo ndihmon në zbulimin e drifteve: ndryshimeve midis gjendjes reale dhe asaj të dëshiruar të sistemit. Për shembull, si rezultat i ndryshimeve të paautorizuara manuale ose dështimit të sistemeve.
Po, termi GitOps nuk na prezanton me asgjë krejt të re, nuk shpInventon biçikletën, por thjesht aplikon përvojën e grumbulluar në një fushë të re. Por kjo është fuqia e tij.
Dhe nëse keni ndonjëherë kuriozitet se si duket kjo në praktikë, ju ftoj të shikoni , në të cilin unë shpjegoj hap pas hapi se si me ndihmën e GitLab:
Të realizojmë parimet themelore të GitOps
Të krijojmë dhe bëjmë ndryshime në infrastrukturën cloud (në shembujt e Yandex Cloud)
Të automatizojmë zbulimin e drifteve të sistemit nga gjendja e dëshiruar duke përdorur monitorimin aktiv.
https://bit.ly/34tRpwZ
Burimi: habr.com
