Mindenki, aki észlel egy újabb új kifejezést az IT blogszférában vagy konferencián, előbb-utóbb felteszi a kérdést: "Mi ez? Egy újabb divatos szó, buzzword, vagy valóban valami, ami érdemes a figyelemre, a tanulmányozásra, és új horizontokat ígér?" Én is így voltam a kifejezéssel GitOps egy ideje. Megannyi már létező cikk és a cégen belüli munkatársaim tudása birtokában , próbáltam kideríteni, mi is ez a dolog, és hogyan nézhet ki a használata a gyakorlatban.
Egyébként a kifejezés újdonságát GitOps az is mutatja, hogy a közelmúltban végzett felmérésünk szerint a megkérdezettek több mint fele még nem kezdett el dolgozni ennek elveivel.
Tehát az infrastruktúra kezelése nem új probléma. Számos felhőszolgáltató már több mint tíz éve elérhető a nagyközönség számára, és úgy tűnt, hogy egyszerűbbé kellett volna tenniük az infrastruktúráért felelős csapatok munkáját. Azonban az alkalmazásfejlesztés folyamatához képest (ahol az automatizálás szintje egyre újabb és újabb horizontokat ér el), az infrastruktúra projektek gyakran még mindig számos manuális feladatot tartalmaznak, és külön szaktudást és szakembereket igényelnek, különösen a modern követelmények figyelembevételével, mint például az elérhetőség, a rugalmasság, a skálázhatóság és az elasticitás.
A felhőszolgáltatások nagyon sikeresen megfeleltek ezeknek a követelményeknek, és éppen ők adtak jelentős impulzust a megközelítés fejlődésének IaC. Ez érthető is, hiszen ők adták lehetőséget egy teljesen virtuális adatközport konfigurálására: nincsenek fizikai szerverek, állványok, hálózati elemek, az egész infrastruktúra leírható szkriptek és konfigurációs fájlok révén.
Tehát mi az alapvető különbség GitOps tól IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Minden kód git háttértárolóban van tárolva
A kód verziója nem kötelező
Deklaratív kódleírás / Idempotencia
Mind a deklaratív, mind az imperatív leírás elfogadható
A változtatások érvénybe lépnek a Merge Request / Pull Request mechanizmusok használatával
A jóváhagyás, az elfogadás és az együttműködés nem kötelező
A frissítések kiadásának folyamata automatizált
A frissítések kiadásának folyamata nem szabályozott (automatikus, manuális, fájlok másolása, parancssor használatával stb.)
Más szavakkal GitOps a fény világra jött a elvek alkalmazásának köszönhetően IaC. Először is, az infrastruktúrák és konfigurációk mostantól éppúgy tárolhatók, mint az alkalmazások. A kódot könnyű tárolni, megosztani, összehasonlítani, és kihasználni a verziókezelés lehetőségeit. Verziók, ágak, történet. És mindez egy nyilvános helyen, amely a csapat minden tagja számára elérhető. Ezért várható volt, hogy elterjednek a verziókezelő rendszerek. Különösen a git, mint a legnépszerűbb.
Másrészt lehetőség nyílt az infrastruktúra kezelési folyamatainak automatizálására. Mostantól ezt gyorsabban, megbízhatóbban és olcsóbban lehet megtenni. Ráadásul a CI/CD elvek már ismertek és népszerűek voltak a szoftverfejlesztők körében. Csak annyira volt szükség, hogy a már meglévő tudást és készségeket átvigyék és alkalmazzák az új területen. Ezek a gyakorlatok azonban túllépték a standard Infrastructure as Code (Infrastruktúra mint kód) meghatározását, és ezáltal megszületett a fogalom. GitOps.
Kíváncsiság GitOps, természetesen abban is rejlik, hogy ez nem egy termék, plugin vagy platform, amely bármilyen beszállítóval lenne összefüggésben. Ez inkább egy paradigmát és elvek gyűjteményét képviseli, hasonlóan más, számunkra ismerős terminushoz: DevOps.
A cégnél Két definíciót alakítottunk ki erről az új kifejezésről: elméleti és gyakorlati. Kezdjük az elméletivel:
A GitOps egy olyan metodológia, amely a DevOps legjobban bevált elveit használja, amelyeket alkalmazások fejlesztésére alkalmaznak, mint például verziókezelés, együttműködés, összehangolás, CI/CD, és alkalmazza ezeket az infrastruktúra kezelésének automatizálására.
Minden folyamat GitOps a már meglévő eszközök használatával működik. Az összes infrastruktúra kód a már ismert git tárolóban található, a változtatások ugyanazon az összehangolási folyamaton mennek keresztül, mint bármely más programkód, és a telepítési folyamat automatizált, ami minimalizálja az emberi hibák lehetőségét, növeli a megbízhatóságot és a reprodukálhatóságot.
Gyakorlati szempontból pedig GitOps így:
Már megbeszéltük az infrastruktúrát mint kódot, mint ennek a formulának az egyik kulcsfontosságú összetevőjét. Nézzük meg a többi résztvevőt.
Merge Request (alternatív megnevezése Pull Request). A MR folyamat szempontjából egy kódváltoztatási kérelem és ágak későbbi egyesítése. Ám a használt eszközök szempontjából inkább egy lehetőség, hogy átfogó képet kapjunk a végrehajtott változtatásokról: nem csupán a kóddiff, amely több elkötelezett változtatásból áll, hanem a kontextus, a tesztek eredményei és a várt végeredmény. Ha az infrastruktúrakódra gondolunk, érdekes, hogy pontosan hogyan változik meg az infrastruktúra, hány új erőforrás fog hozzáadódni vagy eltávolításra kerülni, és milyen módosítások történnek. Ideális esetben mindezt egy kényelmesebb és könnyen olvasható formátumban. Felhőszolgáltatók esetében jó tudni, milyen pénzügyi következményei lesznek ennek a változásnak.
De a MR egyben az együttműködés, interakció és kommunikáció eszköze is. Az a hely, ahol érvényesül a fékek és ellensúlyozás rendszere. Az egyszerű megjegyzésektől kezdve a formális jóváhagyásokig és igazolásokig.
Nos, és az utolsó összetevő: a CI/CD, amint már tudjuk, lehetőséget ad az infrastruktúra változtatások, tesztelés (az egyszerű szintaktikai ellenőrzéstől a bonyolultabb statikus kódanalízisig) automatizálására. És ezáltal a driftszámlálás későbbi felfedezésére is: a rendszer valós és kívánt állapota közötti eltérésekre. Például, az engedély nélküli manuális változtatások vagy a rendszerek meghibásodása következtében.
Igen, a kifejezés GitOps nem ismertet meg minket semmi újjal, nem találja fel a kereket, csupán a már felhalmozott tapasztalatokat alkalmazza egy új területen. De ebben rejlik az ereje.
Ha pedig úgy tűnik, hogy érdekli, hogyan néz ki mindez a gyakorlatban, akkor invitállak, hogy nézd meg a következőket , amelyben lépésről lépésre bemutatom, hogyan lehet a GitLab segítségével:
Megvalósítani a GitOps alapelveit
Készíteni és változtatásokat végrehajtani a felhő infrastruktúrában (például Yandex Cloud)
Automatizálni a rendszerdrift felfedezését a kívánt állapottól aktív monitoring segítségével
https://bit.ly/34tRpwZ
Forrás: habr.com
