Shumica prej nesh, duke vënë re një term tjetër të ri në blogosferën apo konferencën e IT, herët a vonë bëjnë një pyetje të ngjashme: “Çfarë është kjo? Thjesht një fjalë e re, një "fjalë kryesore" apo diçka vërtet e denjë për vëmendje, studim dhe premtim për horizonte të reja?" E njëjta gjë më ndodhi me termin GitOps disa kohë më parë. Armatosur me shumë artikuj ekzistues, si dhe njohuritë e kolegëve nga kompania , u përpoqa të kuptoja se çfarë lloj bishe është kjo dhe si mund të duket përdorimi i saj në praktikë.
Nga rruga, për risinë e termit GitOps Sondazhi ynë i fundit thotë gjithashtu: më shumë se gjysma e të anketuarve nuk kanë filluar ende të punojnë me parimet e tij.
Pra, problemi i menaxhimit të infrastrukturës nuk është i ri. Shumë ofrues të cloud kanë qenë të disponueshëm për publikun e gjerë për një duzinë të mirë dhe, me sa duket, duhet ta kishin bërë punën e ekipeve përgjegjëse për infrastrukturën të thjeshtë dhe të drejtpërdrejtë. Megjithatë, kur krahasohen me procesin e zhvillimit të aplikacioneve (ku automatizimi po arrin nivele gjithnjë e më të reja), projektet e infrastrukturës ende shpesh përfshijnë shumë detyra manuale dhe kërkojnë njohuri dhe ekspertizë të specializuar, veçanërisht duke pasur parasysh kërkesat e sotme për tolerancën e gabimeve, fleksibilitetin, shkallëzueshmërinë dhe elasticitetin.
Shërbimet e cloud i përmbushën këto kërkesa me shumë sukses dhe ishin ata që i dhanë një shtysë të konsiderueshme zhvillimit të qasjes IaC. Kjo është e kuptueshme. Në fund të fundit, ata bënë të mundur konfigurimin e një qendre të dhënash plotësisht virtuale: nuk ka serverë fizikë, rafte ose komponentë rrjeti; e gjithë infrastruktura mund të përshkruhet duke përdorur skriptet dhe skedarët e konfigurimit.
Pra, cili është saktësisht ndryshimi? GitOps nga IaC? Pikërisht me këtë pyetje fillova hetimin tim. Pasi bisedova me kolegët, arrita të dal me krahasimin e mëposhtëm:
GitOps
IaC
I gjithë kodi ruhet në një depo git
Versionimi i kodit është opsional
Përshkrimi i Kodit Deklarativ / Idempotenca
Të dy përshkrimet deklarative dhe imperative janë të pranueshme
Ndryshimet hyjnë në fuqi duke përdorur mekanizmat Kërkesë për Bashkim / Kërkesë tërheqjeje
Marrëveshja, miratimi dhe bashkëpunimi janë fakultative
Procesi i paraqitjes së përditësimeve është i automatizuar
Procesi i paraqitjes së përditësimeve nuk është i standardizuar (automatik, manual, kopjimi i skedarëve, përdorimi i linjës së komandës, etj.)
Me fjale te tjera GitOps lindi pikërisht nëpërmjet zbatimit të parimeve IaC. Së pari, infrastruktura dhe konfigurimet tani mund të ruhen në të njëjtën mënyrë si aplikacionet. Kodi është i lehtë për t'u ruajtur, i lehtë për t'u ndarë, krahasuar dhe përdorur aftësitë e versionimit. Versione, degë, histori. Dhe e gjithë kjo në një vend të aksesueshëm publikisht për të gjithë ekipin. Prandaj, përdorimi i sistemeve të kontrollit të versioneve u bë një zhvillim krejtësisht i natyrshëm. Në veçanti, git, si më i popullarizuari.
Nga ana tjetër, u bë i mundur automatizimi i proceseve të menaxhimit të infrastrukturës. Tani kjo mund të bëhet më shpejt, më e besueshme dhe më lirë. Për më tepër, parimet e CI / CD ishin tashmë të njohura dhe të njohura në mesin e zhvilluesve të softuerit. Ishte e nevojshme vetëm transferimi dhe zbatimi i njohurive dhe aftësive tashmë të njohura në një fushë të re. Megjithatë, këto praktika shkuan përtej përkufizimit standard të Infrastrukturës si kod, pra koncepti GitOps.
Kuriozitet GitOps, sigurisht, edhe në faktin se nuk është një produkt, plugin ose platformë e lidhur me ndonjë shitës. Është më shumë një paradigmë dhe një grup parimesh, i ngjashëm me një term tjetër me të cilin jemi njohur: DevOps.
Në kompani ne kemi zhvilluar dy përkufizime të këtij termi të ri: teorik dhe praktik. Le të fillojmë me teorinë:
GitOps është një metodologji që merr parimet më të mira të DevOps të përdorura për zhvillimin e aplikacioneve, si kontrolli i versionit, bashkëpunimi, orkestrimi, CI/CD dhe i zbaton ato në sfidat e automatizimit të menaxhimit të infrastrukturës.
Të gjitha proceset GitOps Unë punoj duke përdorur mjetet ekzistuese. I gjithë kodi i infrastrukturës ruhet në depon tashmë të njohur të git, ndryshimet kalojnë në të njëjtin proces miratimi si çdo kod tjetër programi dhe procesi i prezantimit është i automatizuar, gjë që na lejon të minimizojmë gabimet njerëzore, të rrisim besueshmërinë dhe riprodhueshmërinë.
Nga pikëpamja praktike, ne përshkruajmë GitOps si më poshtë:
Ne kemi diskutuar tashmë infrastrukturën si kod si një nga komponentët kryesorë të kësaj formule. Le të prezantojmë pjesën tjetër të pjesëmarrësve.
Kërkesa për bashkim (emri alternativ Kërkesë për tërheqje). Në terma të procesit, MR është një kërkesë për të aplikuar ndryshimet e kodit dhe më pas për të bashkuar degët. Por për sa i përket mjeteve që përdorim, kjo është më shumë një mundësi për të marrë një pamje të plotë të të gjitha ndryshimeve që po bëhen: jo vetëm ndryshimi i kodit të mbledhur nga një numër i caktuar detyrimesh, por edhe konteksti, rezultatet e testimit dhe rezultati përfundimtar i pritur. Nëse po flasim për kodin e infrastrukturës, atëherë na intereson se si do të ndryshojë saktësisht infrastruktura, sa burime të reja do të shtohen apo hiqen, do të ndryshohen. Mundësisht në ndonjë format më të përshtatshëm dhe më të lehtë për t'u lexuar. Për ofruesit e cloud, është një ide e mirë të dinë se cili do të jetë ndikimi financiar i këtij ndryshimi.
Por MR është gjithashtu një mjet bashkëpunimi, ndërveprimi dhe komunikimi. Vendi ku hyn në lojë sistemi i kontrolleve dhe balancave. Nga komentet e thjeshta deri te miratimet dhe miratimet formale.
Epo, komponenti i fundit: CI/CD, siç e dimë tashmë, bën të mundur automatizimin e procesit të ndryshimit të infrastrukturës dhe testimit (nga kontrollimi i thjeshtë i sintaksës deri tek analiza më komplekse e kodit statik). Dhe gjithashtu në zbulimin e mëvonshëm të lëvizjes: dallimet midis gjendjes reale dhe të dëshiruar të sistemit. Për shembull, si rezultat i ndryshimeve manuale të paautorizuara ose dështimit të sistemit.
Po, termi GitOps nuk na prezanton me asgjë krejtësisht të re, nuk rishpik rrotën, por thjesht zbaton përvojën e akumuluar tashmë në një fushë të re. Por këtu qëndron forca e tij.
Dhe nëse befas interesoheni se si duket e gjithë kjo në praktikë, atëherë ju ftoj të shikoni tonën , në të cilën unë ju tregoj hap pas hapi se si të përdorni GitLab:
-
Zbatoni parimet bazë të GitOps
-
Krijoni dhe bëni ndryshime në infrastrukturën cloud (duke përdorur shembullin e Yandex Cloud)
-
Automatizoni zbulimin e zhvendosjes së sistemit nga një gjendje e dëshiruar duke përdorur monitorimin aktiv
https://bit.ly/34tRpwZ
Burimi: www.habr.com