Megjegyzés fordítás.: A közelmúltban közzétett a GitOps pull és push módszereiről szóló cikkünk után érdeklődést tapasztaltunk a modell iránt, azonban a magyar nyelvű publikációk száma erről a témáról meglehetősen alacsony (a Habr-on gyakorlatilag nincsenek). Ezért örömmel ajánljuk figyelmetekbe egy másik cikk fordítását — bár már majdnem egy évvel ezelőtt készült! — a Weaveworks-től, akinek az alapítója kitalálta a «GitOps» kifejezést. A szövegben a megközelítés lényegét és a már meglévőktől való kulcsfontosságú eltéréseket magyarázzák el.
Egy éve közzétettük Akkor arról beszéltünk, hogy a Weaveworks csapata elindította a Kubernetes alapú SaaS-ját, és kidolgozott egy ajánlásokat tartalmazó legjobb gyakorlatok készletét a cloud native környezetek telepítéséhez, kezeléséhez és monitorozásához.
A cikk népszerű lett. Mások elkezdtek beszélni a GitOps-ról, új eszközöket kezdtek publikálni a , , , , stb. A weboldalunkon megjelentek publikációk és felhasználási esetek a GitOps-szal kapcsolatban. De néhány emberben még mindig megmaradtak a kérdések. Miben különbözik a modell a hagyományos és a folyamatos szállítás () témáitól? Kötelező-e Kubernetes használata?
Hamarosan rájöttünk, hogy szükség van egy új leírásra, amely a következőket kínálja:
- Sok példát és történetet;
- Konkrét definíció a GitOps-ra;
- Összehasonlítás a hagyományos continuous delivery-vel.
Ebben a cikkben próbáltuk lefedni ezeket a témákat. Frissített bevezetőt találtok a GitOps-ról, és a fejlesztők és CI/CD szempontjából is átfogóbb képet nyújtunk. Főként a Kubernetes-ra összpontosítunk, bár a modell bővíthető.
Ismerjétek meg: GitOps
Képzelj el egy Alisát. Ő vezeti a Family Insurance céget, amely egészségügyi, autó-, ingatlan- és utazási biztosításokat kínál olyan embereknek, akik túl elfoglaltak ahhoz, hogy maguk intézzék a szerződések részleteit. Üzlete kezdetben egy mellékprojekt volt, mikor Alisa bankban dolgozott adatkutatóként. Egy nap rájött, hogy a legmodernebb számítógépes algoritmusok segítségével hatékonyabban elemezheti az adatokat és formálhatja meg a biztosítási csomagokat. A befektetők finanszírozták a projektet, és most a cége évente több mint 20 millió dollárt hoz, és gyors ütemben növekszik. Jelenleg 180 ember dolgozik a cégnél különböző pozíciókban. Közöttük van egy technológiai csapat, amely a weboldal, az adatbázis karbantartásáért és az ügyféladatok elemzéséért felelős. A 60 fős csapatot Bob vezeti, aki a cég műszaki igazgatója.
Bob csapata a felhőben telepíti a production rendszereket. Fő alkalmazásaik a GKE-n működnek, kihasználva a Kubernetes előnyeit a Google Cloud-ban. Emellett különféle adatkezelő és elemző eszközöket is használnak.
A Family Insurance nem tervezett konténereket használni, de a Docker iránti lelkesedés megfertőzte őket. Hamarosan a cég szakemberei felfedezték, hogy a GKE lehetővé teszi klaszterek egyszerű és zökkenőmentes telepítését új funkciók tesztelésére. A Jenkins-t CI célokra, a Quay-t pedig a konténerregiszter megszervezésére adták hozzá, valamint írtak skripteket Jenkins-re, amelyek új konténereket és konfigurációkat push-oltak a GKE-be.
Eltelt egy kis idő. Aliza és Bob csalódott a választott megoldás teljesítményében és annak üzletre gyakorolt hatásában. A konténerizálás nem növelte meg annyira a teljesítményt, mint a csapat remélte. Néha a telepítések megbicsaklottak, és nem volt világos, hogy a kódbeli változtatások miatt történt-e. Emellett nehéz volt nyomon követni a konfigurációs változásokat. Gyakran új klasztert kellett létrehozni és az alkalmazásokat átmozgatni oda, mivel ez tűnt a legegyszerűbb megoldásnak a rendszert elborító káosz felszámolására. Aliza attól tartott, hogy a helyzet romlani fog, ahogy az alkalmazás fejlődik (továbbá egy új gépi tanuláson alapuló projekt is érlelődött). Bob automatizálta a munka nagy részét, és nem értette, miért olyan instabil a folyamat, miért nem skálázódik jól, és miért igényel időnként manuális beavatkozást.
Ezután felfedezték a GitOps-ot. Ez a megoldás bizonyult éppen annak, amire szükségük volt a magabiztos előrehaladáshoz.
Aliza és Bob évek óta hallanak a Git-alapú munkafolyamatokról, a DevOps-ról és az infrastruktúrával kapcsolatos kódról. A GitOps egyedisége abban rejlik, hogy számos legjobb gyakorlatot — kategorikus és normatív — hoz be ezen ötletek megvalósításába a Kubernetes kontextusában. Ez a téma , többek között a .
A Family Insurance döntött a GitOps bevezetéséről. Most a cégnek van egy automatizált üzemeltetési modellje, amely kompatibilis a Kubernetesszel, és ötvözi a gyorsaságot használata a stabilitással, mivel ők:
- felfedezték, hogy a csapat teljesítménye megduplázódott, és senki sem őrül meg közben;
- megszabadultak a szkriptek karbantartásától. Ehelyett most már új funkciókra összpontosíthatnak, és fejleszthetik az mérnöki módszereket — például bevezethetik a kanárita telepítéseket és javíthatják a tesztelést;
- javították a telepítési folyamatot — most ritkán hibásodik meg;
- lehetőséget kaptak a telepítések helyreállítására részleges hibák után manuális beavatkozás nélkül;
- nagyobb bizalmat nyertek a szállítási rendszerekben. Aliza és Bob felfedezték, hogy a csapatot mikroszolgáltatásokra oszthatják, amelyek párhuzamosan működnek;óminden csoport napi 30-50 változtatást végezhet a projekten, és új technikákat próbálhatnak ki.
- naponta 30-50 módosítást végezhetnek a projekten a csapatok együttműködésével, és új technikákat próbálhatnak ki;
- könnyen vonzzák a projektbe az új fejlesztőket, akik már néhány órán belül képesek frissítéseket telepíteni a production környezetbe pull requesteken keresztül;
- könnyen átesnek a SOC2 auditon (a szolgáltatók adatkezelés biztonságos kezelésének megfelelősége; bővebben olvashatsz például, — a fordító megjegyzése).
Mi történt?
A GitOps két dolgot jelent:
- Kubernetes és cloud native üzemeltetési modell. Ez a legjobb gyakorlatok összességét kínálja a tartályokba csomagolt klaszterek és alkalmazások telepítésére, kezelésére és nyomon követésére. Elegáns definíció egy tól :
- Az alkalmazások kezelésére orientált fejlesztői környezet kialakításának útja. A Git munkafolyamatot alkalmazzuk mind az üzemeltetésben, mind a fejlesztésben. Ne feledd, hogy nem csupán a Git push-ról van szó, hanem az összes CI/CD és UI/UX eszközkészlet megszervezéséről.
Néhány szó a Gitről
Ha nem vagy ismerős a verziókövető rendszerekkel és a Git-alapú munkafolyamattal, akkor erősen ajánljuk a tanulmányozását. Eleinte a branchekkel és a pull requestekkel való munka fekete mágiának tűnhet, de az előnyök megérik a ráfordított időt. Íme kezdésként.
Hogyan működik a Kubernetes
Történetünkben Alice és Bob a GitOps-hoz fordult, miután egy ideig dolgoztak a Kubernetes-szel. Valóban, a GitOps szorosan kapcsolódik a Kuberneteshez — ez egy üzemeltetési modell a Kubernetes-alapú infrastruktúrák és alkalmazások számára.
Mit ad a Kubernetes a felhasználóknak?
Íme néhány alapvető képesség:
- A Kubernetes modellben minden deklaratív formában leírható.
- A Kubernetes API-szerver ezt a deklarációt bemeneti adatként kezeli, majd folyamatosan próbálja a klasztert a deklarációban leírt állapothoz közelíteni.
- A deklarációk elegendőek a különböző munkaterhelések — 'alkalmazások' — leírására és kezelésére.
- Ennek eredményeként az alkalmazásban és a klaszterben történő változások az alábbiaktól függenek:
- a tartályképek változásaitól;
- a deklaratív specifikáció változásaitól;
- a környezet hibáitól — például a tartályok összeomlásától.
A Kubernetes figyelemre méltó konvergáló képességei
Amikor az adminisztrátor módosítja a konfigurációt, a Kubernetes orchestrátor alkalmazni fogja azokat a klaszterre mindaddig, amíg annak állapota megközelíti az új konfigurációt.Ez a modell bármilyen Kubernetes erőforráshoz működik, és testreszabott erőforrás-defineciókkal (CRD-kkel) bővíthető. Ezért a Kubernetes telepítések a következő csodálatos tulajdonságokkal rendelkeznek:
- Automatizálás: a Kubernetes frissítések mechanizmust biztosítanak a változtatások alkalmazásának automatizálására, helyesen és időben.
- Konvergencia: a Kubernetes folyamatosan megpróbálja a frissítéseket, amíg sikeresen végrehajtja azokat.
- Idempotencia: a konvergencia ismételt alkalmazása azonos eredményhez vezet.
- Döntésképes: elegendő erőforrás mellett a frissített klaszter állapota kizárólag a kívánt állapottól függ.
Hogyan működik a GitOps
Elég sokat megtudtunk a Kubernetesről ahhoz, hogy elmagyarázzuk a GitOps működésének alapelveit.
Térjünk vissza a Family Insurance csapatokhoz, amelyek mikroszolgáltatásokkal foglalkoznak. Mivel általában foglalkoznak? Nézze meg az alábbi listát (ha néhány pont furcsának vagy ismeretlennek tűnik — kérjük, várjon a kritikával, és maradjon velünk). Ezek csupán példák a Jenkins alapú munkafolyamatokra. Számos más folyamat is létezik más eszközökkel.
A lényeg — látjuk, hogy minden frissítés végül a konfigurációs fájlok és a Git-repozitóriumok módosításával zárul. Ezek a Git-ben végrehajtott változások növelik a „GitOps operátor” szerepet, ami frissíti a klasztert:
1. Munkafolyamat: „Jenkins építés — master ága».
Feladatlista:
- A Jenkins a címkézett képeket a Quay-re tolja;
- A Jenkins a konfigurációt és a Helm-diagramokat a master tárolóba tolja;
- A felhőfunkció átmásolja a konfigurációt és a diagramokat a master tárolóból a Git master-repozitóriumba;
- A GitOps operátor frissíti a klasztert.
2. Jenkins építés — release vagy hotfix ág:
- A Jenkins a címkétlen képeket a Quay-re tolja;
- A Jenkins a konfigurációt és a Helm-diagramokat a staging tárolóba tolja;
- A felhőfunkció átmásolja a konfigurációt és a diagramokat a staging tárolóból a Git staging-repozitóriumba;
- A GitOps operátor frissíti a klasztert.
3. Jenkins építés — develop vagy feature ág:
- A Jenkins a címkétlen képeket a Quay-re tolja;
- A Jenkins a konfigurációt és a Helm-diagramokat a develop tárolóba tolja;
- A felhőfunkció átmásolja a konfigurációt és a diagramokat a develop tárolóból a Git develop-repozitóriumba;
- A GitOps operátor frissíti a klasztert.
4. Új kliens hozzáadása:
- A menedzser vagy adminisztrátor (LCM/ops) elindítja a Gradle-t az első telepítéshez és a hálózati terheléselosztók (NLB) beállításához;
- Az LCM/ops elkötelezi az új konfigurációt a telepítés frissítéseihez való előkészítéshez;
- A GitOps operátor frissíti a klasztert.
A GitOps rövid leírása
- Írja le a rendszer kívánt állapotát deklaratív specifikációk használatával minden környezetre (történetünkben Bob csapata a Git-ben határozza meg a rendszer teljes konfigurációját).
- A Git-tárház az egyetlen valódi forrás a rendszer kívánt állapotáról.
- Minden változtatás a kívánt állapotra a Git-be történő elkötelezések útján történik.
- Minden kívánt paraméter a klaszterben is megfigyelhető. Így meghatározhatjuk, hogy a kívánt és a megfigyelt állapotok egybeesnek (konvergálnak, converge) vagy eltérnek (divergálnak, diverge) a kívánt és a megfigyelt állapotok.
- Ha a kívánt és a megfigyelt állapotok eltérnek, akkor:
- Van egy konvergencia mechanizmus, amely előbb-utóbb automatikusan összehangolja a célt és a megfigyelt állapotot. Ezt a klaszteren belül a Kubernetes végzi.
- A folyamat azonnal elindul a „változás elkötelezve” értesítéssel.
- Egy bizonyos konfigurálható időközön belül lehet küldeni egy „különbség” értesítést, ha az állapotok eltérnek.
- Így minden Git-ben végzett elkötelezés ellenőrizhető és idempotens frissítéseket okoz a klaszterben.
- A visszavonás egy korábbi kívánt állapothoz való konvergencia.
- A konvergencia végleges. A következők tanúskodnak róla:
- Nincs „különbség” értesítés egy bizonyos időtartamon belül.
- A „konvergált” értesítés (pl. webhook, Git writeback esemény).
Mi a divergencia?
Ismételjük meg: minden kívánt tulajdonságnak meg kell figyelhetőnek lennie a klaszterben.
Néhány példa a divergiálásra:
- Változás a konfigurációs fájlban a Git ágak egyesítése miatt.
- Változás a konfigurációs fájlban a Git-be végzett elkötelezés miatt, amelyet egy GUI-ügyfél hajtott végre.
- Többszöri változás a kívánt állapotban a Git PR miatt, amely után konténerkép épül és a konfiguráció módosul.
- A klaszter állapotának megváltozása hiba, erőforrás-ütközés miatt, amely „rossz viselkedéshez” vezet, vagy egyszerűen véletlen eltérés miatt az eredeti állapottól.
Mi a konvergencia mechanizmusa?
Néhány példa:
- A konténerek és klaszterek esetében a konvergencia mechanizmust a Kubernetes biztosítja.
- Ugyanezt a mechanizmust használhatjuk alkalmazások és Kubernetes alapú felépítmények (pl. Istio és Kubeflow) kezelésére.
- A munkafolyamatok Kubernetes, képkatalógusok és Git közötti kezelésére szolgáló mechanizmus biztosítja , amely része .
- Alapvető gépeknél a konvergencia mechanizmusának deklaratívnak és autonómnak kell lennie. Tapasztalataink szerint a legjobban megfelel ennek a definíciónak, azonban mégis emberi ellenőrzést igényel. E tekintetben a GitOps kiterjeszti az Infrastructure as Code hagyományait.
A GitOps a Git-et egy nagyszerű Kubernetes konvergencia mechanizmussal ötvözi, és egy modellt kínál a működtetéshez.
A GitOps lehetővé teszi számunkra, hogy kijelentsük: az automatizálás és ellenőrzés csak azokat a rendszereket érinti, amelyeket le lehet írni és figyelni lehet.
A GitOps a teljes cloud native stack-re tervezett (például Terraform és társai)
A GitOps nemcsak Kubernetes. Arra törekszünk, hogy az egész rendszer deklaratív módon legyen kezelve és konvergenciát alkalmazzon. Az egész rendszer alatt azokat a környezeteket értjük, amelyek Kubernetes-tel működnek — például a "dev cluster 1", "production" és így tovább. Minden környezet gépeket, klasztereket, alkalmazásokat, valamint külső szolgáltatások interfészeit tartalmaz, amelyek adatokat, figyelést stb. biztosítanak.
Figyelje meg, milyen fontos ebben az esetben a Terraform a bootstrapping problémához. A Kubernetes-nek valahol telepítve kell lennie, és a Terraform használata magával hozza, hogy ugyanazokat a GitOps munkafolyamatokat alkalmazhatjuk a Kubernetes és az alkalmazások alapját képező irányító réteg létrehozásához. Ez egy hasznos legjobb gyakorlat.
Nagy figyelmet fordítanak a GitOps koncepciók Kubernetes feletti rétegekre való alkalmazására. Jelenleg léteznek GitOps típusú megoldások az Istio, Helm, Ksonnet, OpenFaaS és Kubeflow területén, valamint például a Pulumi számára, amelyek réteget hoznak létre cloud native alkalmazások fejlesztéséhez.
Kubernetes CI/CD: A GitOps összehasonlítása más megközelítésekkel
Mint említettük, a GitOps két dolog:
- A fent említett működtetési modell Kubernetes és cloud native számára.
- Az alkalmazások kezelésére szolgáló, fejlesztők által orientált környezet megszervezésének útja.
Sokak számára a GitOps elsősorban a Git push alapú munkafolyamatot jelenti. Mi is kedveljük. De ez még nem minden: nézzük meg most a CI/CD pipeline-okat.
A GitOps biztosítja a folyamatos telepítést (CD) Kubernetes alatt
A GitOps folyamatos telepítési mechanizmust biztosít, amely megszünteti a külön "telepítési irányítási rendszerek" szükségességét. Az egész munkát a Kubernetes végzi el helyettünk.
- Az alkalmazásfrissítések Git-en való frissítést igényelnek. Ez egy tranzakciós frissítés a kívánt állapothoz. Az "implementálás" ezután a Kubernetes által az aktualizált leírás alapján történik a klaszteren belül.
- A Kubernetes működésének sajátosságai miatt ezek a frissítések konvergensek. Ez biztosítja a folyamatos telepítés mechanizmusát, amelyben minden frissítés atomáris.
- Megjegyzés: ajánlja a GitOps operátort, amely integrálja a Git-et és a Kubernetes-t, lehetővé téve a folyamatos telepítést a kívánt és a klaszter aktuális állapotának egyeztetésével.
Kubectl és szkriptek nélkül
Kerülni kell a Kubectl használatát a klaszter frissítésére, különösen a kubectl parancsok csoportosításához készült szkriptek alkalmazását. Ehelyett a GitOps folyamat segítségével a felhasználó a Git-en keresztül frissítheti a Kubernetes klaszterét.
Az előnyök közé tartozik:
- Helyesség. A frissítési csoportokat alkalmazni, konvergálni és végül érvényesíteni lehet, ami közelebb visz minket az atomáris implementálás céljához. Ezzel szemben a szkriptek használata nem garantálja a konvergenciát (erről alább részletesebben).
- Biztonság. Kelsey Hightower: "Korlátozza a Kubernetes klaszterhez való hozzáférést az automatizáló eszközök és az adminisztrátorok számára, akiknek feladatuk a hibakeresés vagy a működés fenntartása." Lásd még a biztonságról és a műszaki követelményeknek való megfelelésről, valamint az adatok ellopásával egy hanyagul megírt Jenkins-szkriptből.
- Felhasználói élmény. A Kubectl feltárja a Kubernetes objektummodell mechanikáját, amely meglehetősen bonyolult. Ideálisan a felhasználóknak magasabb absztrakciós szinten kellene interakcióba lépniük a rendszerrel. Itt ismét Kelsey-re hivatkoznék, és javaslom, hogy nézze meg .
A CI és CD közötti különbség
A GitOps javítja a meglévő CI/CD modelleket.
A modern CI szerver egy orkesztráló eszköz. Különösen ez egy CI pipelink orkesztrálására szolgáló eszköz. Magában foglalja az építést, a tesztelést, a trunkba való egyesítést stb. A CI szerverek automatizálják a bonyolult többlépcsős pipelinek kezelését. A gyakori kísértés, hogy egy szkriptet hozzanak létre a Kubernetes frissítéseinek beállításához, és ezt a klaszterbe való változtatások pusholásának elemévé tegyék. Valójában sok szakember így jár el. Azonban ez nem optimális, és ennek az az oka.
A CI-t a trunk frissítéseihez kell használni, a Kubernetes klaszter pedig ennek alapján fogja magát módosítani a belső CD irányításához. Ezt nevezzük , szemben a CI push-modellekkel. A CD része a runtime-orchestration-nak..
Miért ne folytassa a CI-szerver a CD-t közvetlen frissítésekkel Kubernetesbe?
Ne használjon CI-szervert közvetlen frissítések Kubernetesbe való orchestrálására CI-feladatok összességeként. Ez egy anti-minta, amiről mi már a blogunkban.
Térjünk vissza Alice-hoz és Bobhoz.
Milyen problémákkal szembesültek? Bob CI-szervere alkalmazza a változtatásokat a klaszterre, de ha közben leáll, Bob nem fogja tudni, milyen állapotban van a klaszter (vagy milyen állapotban kellene lennie), és hogyan javítsa azt. Ugyanez igaz akkor is, ha sikeres.
Tegyük fel, hogy Bob csapata új image-t épített, majd frissítette a deploymentjeit az image telepítéséhez (mindez a CI-pipeline-ból).
Ha az image rendben épül meg, de a pipeline leáll, a csapatnak ki kell derítenie:
- Települt a frissítés?
- Futtatjuk az új buildet? Ez indokolatlan mellékhatásokhoz vezet, amelyek lehetőségét adják két azonos, változatlan image egyidejű beszerzésének?
- Várjunk meg egy újabb frissítést, mielőtt indítanánk a buildet?
- Mi pontosan ment rosszul? Mely lépéseket kell megismételni (és melyeket lehet biztonságosan megismételni)?
A Git-alapú munkafolyamat megszervezése nem garantálja, hogy Bob csapata ne ütközzön ezekbe a problémákba. Még mindig hibázhatnak a commit push részében, a tagban vagy bármely más paraméterben; azonban ez a megközelítés sokkal közelebb áll a kifejezett all-or-nothing koncepcióhoz.
Összegzésül, itt van, miért nem kellene a CI-szervernek CD-vel foglalkoznia:
- A frissítő script-ek nem mindig determinisztikusak; könnyű hibákat elkövetni bennük.
- A CI-szerverek nem konvergálnak a deklaratív klasztermodellhez.
- Nehéz garantálni az idempotenciát. A felhasználóknak mély szemináriumokkal kell foglalkozniuk a rendszer mélyebb jelentésében.
- Nehéz visszaállni egy részleges hiba után.
Megjegyzés a Helm-ről: ha használni szeretné a Helm-et, javasoljuk, hogy kombinálja egy GitOps-operatorral, mint például . Ez segít a konvergencia biztosításában. A Helm önállóan nem determinisztikus, sem atomikus.
A GitOps a legjobb módja a Kubernetes folyamatos szállításának megvalósítására
Alice és Bob csapata bevezeti a GitOps-t, és felfedezi, hogy sokkal egyszerűbb szoftvertermékekkel dolgozni, fenntartani a magas teljesítményt és stabilitást. Fejezzük be ezt a cikket olyan illusztrációkkal, amelyek bemutatják, hogyan néz ki az új megközelítésük. Vegyük figyelembe, hogy főként alkalmazásokról és szolgáltatásokról beszélünk, azonban a GitOps használható az egész platform kezelésére is.
Kubernetes üzemeltetési modell
Nézd meg az alábbi diagramot. Ez a Git-ot és a konténerképek tárolóját közös erőforrásként ábrázolja két szervezett életciklus számára:
- A folyamatos integrációs pipeline, amely olvassa és írja a fájlokat a Git-be, és frissítheti a konténerkép tárolót.
- A Runtime GitOps pipeline, amely ötvözi a telepítést a kezeléssel és megfigyeléssel. Ez is olvassa és írja a fájlokat a Git-be, és képes konténerképeket betölteni.
Mik a legfőbb következtetések?
- Problémák szétválasztása: Figyeld meg, hogy mindkét pipeline adatokat tud cserélni, csak a Git vagy a képtároló frissítésével. Más szavakkal, van egy tűzfal a CI és a runtime környezet között. Ezt nevezzük „immutable firewall”-nak (immutability firewall), mivel minden tároló frissítése új verziókat hoz létre. További információkért a témában kérlek nézd meg a 72-87. diákat. .
- Bármilyen CI- és Git-szerver használható: A GitOps bármilyen komponenssel működik. Folytathatod kedvenc CI- és Git-szervereid, képtárolók és tesztkészletek használatát. A piac szinte összes többi folyamatos szállítási eszköze saját CI / Git-szervert vagy képtárolót igényel. Ez korlátozó tényezővé válhat a cloud native fejlődésében. A GitOps esetében azonban a megszokott eszközöket használhatod.
- Események mint integrációs eszköz: Amint az adatok frissülnek a Git-ben, a Weave Flux (vagy a Weave Cloud operátora) értesíti erről a runtime-ot. Valahányszor Kubernetes egy sor módosítást fogad, a Git frissül. Ez egy egyszerű integrációs modellt biztosít a GitOps munkafolyamatainak szervezéséhez, ahogyan az alább látható.
Zárás
A GitOps jelentős garanciákat nyújt a frissítéshez, amelyek szükségesek bármely modern CI/CD eszközhöz:
- automatizálás;
- konvergencia;
- idempotencia;
- determináltság.
Fontos, mivel üzemeltetési modellt kínál a felhőnatív fejlesztők számára.
- A hagyományos eszközök az üzemeltetés és a rendszerek nyomon követésére az üzemeltetési csapatokkal kapcsolatosak, amelyek a runbook keretein belül működnek. (rutinszerű eljárások és műveletek készletére utal — a fordító megj.), amely egy konkrét telepítéshez van kötve.
- A felhőnatív rendszerek kezelésében a megfigyelési eszközök a legjobb módja a telepítések eredményeinek értékelésére, hogy a fejlesztői csapat gyorsan reagálhasson rájuk.
Képzelj el sok klasztert, amelyek különböző felhőkben találhatók, és számos szolgáltatást, saját csapatokkal és telepítési tervekkel. A GitOps egy nagy léptékben invariant modell a sokféleség kezelésére.
Fejlesztési eszközök, amelyek Kubernetesben futnak
Olvasson további információkat a blogunkban:
- «»;
- «»;
- «».
Csak a regisztrált felhasználók vehetnek részt a szavazáson. , kérem.
Tudtad a GitOps-ról a két fordítás megjelenése előtt a Habr-on?
Igen, mindent tudtam
Csak felszínesen
Nem
35 felhasználó szavazott. 10 felhasználó tartózkodott.
Forrás: habr.com
