A legtöbben, ha egy újabb új kifejezést észlelünk az IT blogszférában vagy konferencián, előbb-utóbb feltesznek egy hasonló kérdést: „Mi ez? Csak egy újabb divatszó, egy „hírszó”, vagy valami igazán érdemes odafigyelni, tanulmányozni, és új távlatokat ígérni? Ugyanez történt velem a kifejezéssel GitOps Kis idővel ezelött. Felfegyverkezve számos meglévő cikkel, valamint a cég munkatársainak tudásával , próbáltam kitalálni, hogy ez milyen vadállat, és hogyan nézhet ki a gyakorlatban a felhasználása.
Egyébként a kifejezés újdonságáról GitOps Friss felmérésünk is azt mondja: a megkérdezettek több mint fele még nem kezdett el az elveivel dolgozni.
Tehát az infrastruktúra-kezelés problémája nem új keletű. Sok felhőszolgáltató bő tucat éve elérhető a nagyközönség számára, és úgy tűnik, egyszerűvé és egyértelművé kellett volna tenniük az infrastruktúráért felelős csapatok munkáját. Azonban az alkalmazásfejlesztési folyamathoz képest (ahol az automatizálás egyre új szintre lép) az infrastrukturális projektek még mindig gyakran sok manuális feladatot igényelnek, és speciális ismereteket és szakértelmet igényelnek, különösen a mai hibatűrés, rugalmasság, skálázhatóság és rugalmasság követelményei miatt.
A felhőszolgáltatások nagyon sikeresen teljesítették ezeket a követelményeket, és ők adtak jelentős lökést a szemlélet kialakításához IaC. Ez érthető. Végül is lehetővé tették egy teljesen virtuális adatközpont konfigurálását: nincsenek fizikai szerverek, rackek, hálózati összetevők, a teljes infrastruktúra leírható szkriptekkel és konfigurációs fájlokkal.
Tehát mi a különbség pontosan? GitOps -tól IaC? Ezzel a kérdéssel kezdtem a nyomozást. A kollégákkal való beszélgetés után a következő összehasonlítást tudtam kihozni:
GitOps
IaC
Az összes kódot egy git tárolóban tárolják
A kód verziószámítása opcionális
Deklaratív kód Leírás / Idempotencia
Mind a deklaratív, mind a kötelező jellegű leírások elfogadhatók
A változtatások az Egyesítési kérelem / Lehívási kérelem mechanizmusok használatával lépnek érvénybe
A megállapodás, a jóváhagyás és az együttműködés nem kötelező
A frissítési folyamat automatikus
A frissítési folyamat nem szabványos (automatikus, kézi, fájlok másolása, parancssor használata stb.)
Más szavakkal GitOps éppen az elvek alkalmazása révén született meg IaC. Először is, az infrastruktúra és a konfigurációk ugyanúgy tárolhatók, mint az alkalmazások. A kód könnyen tárolható, könnyen megosztható, összehasonlítható és használható a verziókezelési képességek. Verziók, ágak, előzmények. És mindezt az egész csapat számára nyilvánosan elérhető helyen. Ezért teljesen természetes fejlõdéssé vált a verziókövetõ rendszerek alkalmazása. Különösen a git, mint a legnépszerűbb.
Másrészt lehetővé vált az infrastruktúra-kezelési folyamatok automatizálása. Most ez gyorsabban, megbízhatóbban és olcsóbban megtehető. Sőt, a CI / CD alapelvei már ismertek és népszerűek voltak a szoftverfejlesztők körében. Csak át kellett vinni és alkalmazni a már ismert ismereteket és készségeket egy új területre. Ezek a gyakorlatok azonban túlmutattak az infrastruktúra kódként szokásos definícióján, innen ered a koncepció GitOps.
Kíváncsiság GitOps, persze abban is, hogy nem egy gyártóhoz kapcsolódó termékről, bővítményről vagy platformról van szó. Ez inkább egy paradigma és alapelvek halmaza, hasonlóan egy másik, általunk ismert kifejezéshez: DevOps.
A vállalat ennek az új kifejezésnek két definícióját dolgoztuk ki: elméleti és gyakorlati. Kezdjük az elméletivel:
A GitOps egy olyan módszertan, amely az alkalmazásfejlesztéshez használt legjobb DevOps-elveket veszi alapul, mint például a verziókezelés, az együttműködés, a hangszerelés, a CI/CD, és alkalmazza azokat az infrastruktúra-kezelés automatizálásának kihívásaira.
Minden folyamat GitOps Meglévő eszközökkel dolgozom. Az összes infrastruktúra kód a már megszokott git repository-ban van tárolva, a változtatások ugyanazon a jóváhagyási folyamaton mennek keresztül, mint bármely más programkód, a bevezetési folyamat pedig automatizált, ami lehetővé teszi az emberi hibák minimalizálását, a megbízhatóság és a reprodukálhatóság növelését.
Gyakorlati szempontból leírjuk GitOps az alábbiak szerint:
Már tárgyaltuk az infrastruktúrát mint kódot, mint ennek a képletnek az egyik kulcsfontosságú összetevőjét. Mutassuk be a többi résztvevőt.
Egyesítési kérelem (alternatív név Pull Request). A folyamat szempontjából az MR kódmódosítások alkalmazására, majd ágak egyesítésére irányuló kérés. De ami az általunk használt eszközöket illeti, ez inkább egy lehetőség arra, hogy teljes képet kapjunk az összes végrehajtott változtatásról: nemcsak a bizonyos számú véglegesítésből összegyűjtött kóddiff, hanem a kontextus, a teszteredmények és a várható végső eredmény. Ha infrastruktúra kódról beszélünk, akkor az érdekel, hogy pontosan hogyan fog megváltozni az infrastruktúra, mennyi új erőforrást adnak hozzá vagy távolítanak el, változtatnak. Lehetőleg valami kényelmesebb és könnyebben olvasható formátumban. A felhőszolgáltatók számára érdemes tudni, hogy ennek a változásnak milyen pénzügyi hatásai lesznek.
De az MR az együttműködés, az interakció és a kommunikáció eszköze is. Az a hely, ahol a fékek és ellensúlyok rendszere lép működésbe. Az egyszerű megjegyzésektől a hivatalos jóváhagyásokig és jóváhagyásokig.
Nos, az utolsó komponens: a CI/CD, mint már tudjuk, lehetővé teszi az infrastruktúra-módosítások és tesztelések folyamatának automatizálását (az egyszerű szintaktikai ellenőrzéstől a bonyolultabb statikus kódelemzésig). És a drift későbbi észlelésében is: különbségek a rendszer valós és kívánt állapota között. Például jogosulatlan kézi változtatások vagy rendszerhiba következtében.
Igen, a kifejezés GitOps nem ismertet meg minket semmi teljesen újjal, nem találja fel újra a kereket, hanem egyszerűen egy új területen alkalmazza a már felhalmozott tapasztalatokat. De ebben rejlik az ereje.
És ha hirtelen felkeltette az érdeklődését, hogy mindez hogyan néz ki a gyakorlatban, akkor megkérem, tekintse meg a mi oldalunkat , amelyben lépésről lépésre elmondom a GitLab használatáról:
-
Valósítsa meg a GitOps alapelveit
-
A felhő infrastruktúrájának létrehozása és módosítása (a Yandex Cloud példájával)
-
Automatizálja a rendszer eltolódásának észlelését a kívánt állapotból az aktív figyeléssel
https://bit.ly/34tRpwZ
Forrás: will.com