Jegyzet. ford.: Egy friss publikáció után A GitOps-ban található pull és push módszerekről általánosságban láttunk érdeklődést ez a modell iránt, de nagyon kevés orosz nyelvű publikáció jelent meg ebben a témában (a Habrén egyszerűen nincs). Ezért örömmel ajánljuk figyelmébe egy másik cikk fordítását - igaz, majdnem egy évvel ezelőtt! - a Weaveworks-től, amelynek vezetője megalkotta a „GitOps” kifejezést. A szöveg elmagyarázza a megközelítés lényegét és a lényeges különbségeket a meglévőkhöz képest.
Egy éve publikáltuk . Akkoriban megosztottuk, hogy a Weaveworks csapata miként indított el egy teljes egészében Kubernetesen alapuló SaaS-t, és hogyan dolgozott ki egy sor bevált gyakorlatot a felhőalapú környezetben történő telepítéshez, kezeléshez és figyeléshez.
A cikk népszerűnek bizonyult. Mások elkezdtek beszélni a GitOps-ról, és új eszközöket tettek közzé a számára , , , , stb. Megjelent honlapunkon kiadványok és GitOps használati esetek. De néhány embernek még mindig van kérdése. Miben különbözik a modell a hagyományostól? és folyamatos szállítás ()? Szükséges a Kubernetes használata?
Hamar rájöttünk, hogy új leírásra van szükség, amely a következőket kínálja:
- Számos példa és történet;
- A GitOps konkrét meghatározása;
- Összehasonlítás a hagyományos folyamatos szállítással.
Ebben a cikkben megpróbáltuk lefedni ezeket a témákat. Frissített bevezetést nyújt a GitOps-hoz, valamint egy fejlesztői és CI/CD perspektívát. Elsősorban a Kubernetesre koncentrálunk, bár a modell általánosítható.
Ismerje meg a GitOpsot
Képzeld Alice-t. Ő vezeti a Family Insurance-t, amely egészség-, autó-, lakás- és utazási biztosítást kínál azoknak az embereknek, akik túl elfoglaltak ahhoz, hogy maguk találják ki a szerződések csínját-bínját. Vállalkozása mellékprojektként indult, amikor Alice egy bankban dolgozott adattudósként. Egy nap rájött, hogy fejlett számítógépes algoritmusokkal hatékonyabban elemezheti az adatokat és biztosítási csomagokat dolgozhat ki. A befektetők finanszírozták a projektet, és most cége több mint 20 millió dollárt hoz évente, és gyorsan növekszik. Jelenleg 180 főt foglalkoztat különböző munkakörökben. Ide tartozik egy technológiai csapat, amely fejleszti, karbantartja a webhelyet, az adatbázist és elemzi az ügyfélbázist. A 60 fős csapatot Bob, a cég műszaki igazgatója vezeti.
Bob csapata éles rendszereket telepít a felhőben. Alapvető alkalmazásaik a GKE-n futnak, kihasználva a Google Cloud Kubernetes előnyeit. Emellett különféle adat- és elemzőeszközöket használnak munkájuk során.
A Családi Biztosító nem konténerek használatára törekedett, hanem elkapta a Docker-lelkesedés. A vállalat hamarosan felfedezte, hogy a GKE megkönnyítette a fürtök telepítését az új funkciók tesztelésére. A Jenkins for CI és a Quay hozzá lett adva a konténer-nyilvántartás megszervezéséhez, a Jenkins számára pedig szkripteket írtak, amelyek új konténereket és konfigurációkat helyeztek át a GKE-be.
Eltelt egy kis idő. Alice és Bob csalódottak voltak az általuk választott megközelítés teljesítménye és az üzletre gyakorolt hatása miatt. A konténerek bevezetése nem javította annyira a termelékenységet, mint azt a csapat remélte. Néha a telepítések megszakadtak, és nem volt világos, hogy a kódmódosítások okolhatók-e. A konfigurációs változások követése is nehézkesnek bizonyult. Gyakran szükség volt egy új fürt létrehozására és az alkalmazások áthelyezésére, mivel ez volt a legegyszerűbb módja annak, hogy kiküszöbölje a rendszer által okozott zűrzavart. Alice attól tartott, hogy az alkalmazás fejlesztésével a helyzet tovább romlik (ráadásul egy új, gépi tanuláson alapuló projekt készülődik). Bob a munka nagy részét automatizálta, és nem értette, miért volt még mindig instabil a csővezeték, miért nem skálázódik jól, és miért van szükség időnként manuális beavatkozásra?
Aztán tanultak a GitOps-ról. Ez a döntés pontosan az lett, amire szükségük volt a magabiztos előrelépéshez.
Alice és Bob évek óta hallott a Gitről, a DevOps-ról és az infrastruktúráról, mint kódmunkafolyamatokról. A GitOps egyedülállósága az, hogy bevált gyakorlatokat tartalmaz – mind végleges, mind normatív módon – ezen ötletek Kubernetes kontextusában való megvalósításához. Ez a téma , beleértve a .
A Családbiztosítás a GitOps bevezetése mellett dönt. A vállalat most már rendelkezik egy automatizált működési modellel, amely kompatibilis a Kubernetes és a kombájnokkal sebesség -val stabilitásmert ők:
- megállapította, hogy a csapat termelékenysége megduplázódott anélkül, hogy bárki megőrült volna;
- leállította a szkriptek kiszolgálását. Ehelyett most az új funkciókra összpontosíthatnak, és javíthatják a mérnöki módszereket – például bevezethetik a kanári változatokat és javíthatják a tesztelést;
- javítottuk a telepítési folyamatot, hogy az ritkán omoljon meg;
- lehetőséget kapott a telepítések visszaállítására részleges hibák után manuális beavatkozás nélkül;
- használtan vásároltоNagyobb bizalom a kézbesítési rendszerekben. Alice és Bob felfedezték, hogy a csapatot feloszthatják párhuzamosan dolgozó mikroszolgáltatási csapatokra;
- naponta 30-50 változtatást tud végrehajtani a projekten az egyes csoportok erőfeszítései révén, és új technikákat próbál ki;
- könnyű új fejlesztőket vonzani a projektbe, akiknek lehetőségük van néhány órán belül lehívási kérelmekkel frissíteni a termelésben;
- könnyen átmegy az auditon a SOC2 keretein belül (a szolgáltatók biztonságos adatkezelési követelményeinek való megfeleléséért; bővebben pl. - kb. fordítás.).
Mi történt?
A GitOps két dolog:
- Működési modell a Kubernetes és a felhő natív számára. Bevált gyakorlatokat kínál a konténeres fürtök és alkalmazások telepítéséhez, kezeléséhez és figyeléséhez. Elegáns meghatározás a formában -tól :
- A fejlesztőközpontú alkalmazáskezelő környezet létrehozásának útja. A Git-munkafolyamatot mind az üzemeltetésre, mind a fejlesztésre alkalmazzuk. Felhívjuk figyelmét, hogy ez nem csak a Git push-ról szól, hanem a CI/CD és UI/UX eszközök teljes készletének megszervezéséről.
Néhány szó Gitről
Ha nem ismeri a verziókezelő rendszereket és a Git-alapú munkafolyamatot, erősen javasoljuk, hogy ismerkedjen meg velük. Az ágakkal és húzási kérésekkel végzett munka elsőre fekete mágiának tűnhet, de az előnyök megérik a fáradságot. Itt kezdeni.
Hogyan működik a Kubernetes
Történetünkben Alice és Bob a GitOps felé fordult, miután egy ideig a Kubernetesszel dolgoztak. Valójában a GitOps szorosan kapcsolódik a Kuberneteshez – ez a Kubernetesen alapuló infrastruktúra és alkalmazások működési modellje.
Mit ad a Kubernetes a felhasználóknak?
Íme néhány fő funkció:
- A Kubernetes modellben minden deklaratív formában leírható.
- A Kubernetes API-kiszolgáló ezt a deklarációt bemenetként veszi, majd folyamatosan megpróbálja a fürtöt a deklarációban leírt állapotba hozni.
- A nyilatkozatok elegendőek sokféle munkaterhelés – „alkalmazások” leírásához és kezeléséhez.
- Ennek eredményeként az alkalmazásban és a fürtben a következő okok miatt változnak meg:
- változások a konténerképekben;
- módosítások a deklaratív specifikációban;
- hibák a környezetben – például a konténer összeomlása.
A Kubernetes nagyszerű konvergencia-képességei
Amikor egy rendszergazda módosítja a konfigurációt, a Kubernetes Orchestrator alkalmazza azokat a fürtre, amíg annak állapota nem közelíti meg az új konfigurációt. Ez a modell bármely Kubernetes-erőforráshoz használható, és egyéni erőforrás-definíciókkal (CRD) 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 olyan mechanizmust biztosítanak, amely automatizálja a változtatások kecsesen és időben történő alkalmazását.
- Konvergencia: A Kubernetes továbbra is próbálkozik a frissítésekkel, amíg sikerrel nem jár.
- Idempotencia: A konvergencia ismételt alkalmazása ugyanarra az eredményre vezet.
- Determinizmus: Ha elegendőek az erőforrások, a frissített fürt állapota csak a kívánt állapottól függ.
Hogyan működik a GitOps
Eleget tanultunk a Kubernetesről ahhoz, hogy elmagyarázzuk a GitOps működését.
Térjünk vissza a Családi Biztosító mikroszolgáltatási csapataihoz. Általában mit kell tenniük? Tekintse meg az alábbi listát (ha bármely tétel furcsának vagy ismeretlennek tűnik, kérjük, ne kritizáljon, és maradjon velünk). Ezek csak példák a Jenkins-alapú munkafolyamatokra. Sok más folyamat is van, ha más eszközökkel dolgozik.
A lényeg az, hogy látjuk, hogy minden frissítés a konfigurációs fájlok és a Git-tárolók módosításával ér véget. A Git ezen módosításai miatt a „GitOps operátor” frissíti a fürtöt:
1. Munkafolyamat: "Jenkins build – mester ág".
Feladat lista:
- Jenkins elküldi a címkézett képeket a rakpartra;
- Jenkins a konfigurációs és a Helm diagramokat a fő tárolóba helyezi;
- A felhőfüggvény átmásolja a konfigurációt és a diagramokat a fő tárolótárolóból a fő Git-tárba;
- A GitOps operátor frissíti a fürtöt.
2. Jenkins build – kiadás vagy gyorsjavítás ág:
- Jenkins címkézetlen képeket küld a rakpartra;
- Jenkins a konfigurációs és Helm-diagramokat az átmeneti tárolótartályba tolja;
- A felhőfüggvény átmásolja a konfigurációt és a diagramokat az átmeneti tárolótárolóból az átmeneti Git-tárba;
- A GitOps operátor frissíti a fürtöt.
3. Jenkins build – fejlesztés vagy jellemző ág:
- Jenkins címkézetlen képeket küld a rakpartra;
- Jenkins a konfigurációs és a Helm diagramokat a fejlesztési tárolódobozba helyezi;
- A felhőfüggvény átmásolja a konfigurációt és a diagramokat a fejlesztési tárolótárolóból a fejlesztési Git-tárba;
- A GitOps operátor frissíti a fürtöt.
4. Új ügyfél hozzáadása:
- A menedzser vagy a rendszergazda (LCM/ops) meghívja a Gradle-t, hogy először telepítse és konfigurálja a hálózati terheléselosztókat (NLB);
- Az LCM/ops új konfigurációt hajt végre, hogy előkészítse a telepítést a frissítésekre;
- A GitOps operátor frissíti a fürtöt.
A GitOps rövid leírása
- Írja le a teljes rendszer kívánt állapotát az egyes környezetekre vonatkozó deklaratív specifikációk segítségével (történetünkben Bob csapata határozza meg a teljes rendszerkonfigurációt a Gitben).
- A Git adattár az igazság egyetlen forrása a teljes rendszer kívánt állapotával kapcsolatban.
- A kívánt állapot minden módosítása a Gitben végrehajtott véglegesítéseken keresztül történik.
- A klaszter összes kívánt paramétere magában a klaszterben is megfigyelhető. Így megállapíthatjuk, hogy egybeesnek-e (konvergálnak, konvergálni) vagy különböznek (eltérnek, eltér) kívánt és megfigyelt állapotok.
- Ha a kívánt és a megfigyelt állapotok eltérnek, akkor:
- Létezik egy konvergenciamechanizmus, amely előbb-utóbb automatikusan szinkronizálja a cél és a megfigyelt állapotokat. A fürtön belül a Kubernetes ezt teszi.
- A folyamat azonnal elindul egy „módosítás történt” riasztással.
- Bizonyos konfigurálható idő elteltével „diff” riasztás küldhető, ha az állapotok eltérőek.
- Ily módon a Gitben végzett összes véglegesítés ellenőrizhető és hatékony frissítéseket eredményez a fürtben.
- A visszaállítás a korábban kívánt állapothoz való konvergencia.
- A konvergencia végleges. Előfordulását jelzi:
- Egy bizonyos ideig nincsenek eltérési riasztások.
- "konvergens" riasztás (pl. webhook, Git visszaírási esemény).
Mi az eltérés?
Ismételjük meg még egyszer: a klaszter összes kívánt tulajdonságának megfigyelhetőnek kell lennie magában a klaszterben.
Néhány példa az eltérésekre:
- Változás a konfigurációs fájlban az ágak összevonása miatt a Gitben.
- Változás a konfigurációs fájlban a GUI kliens által végrehajtott Git véglegesítés miatt.
- A kívánt állapot többszöri módosítása a Git PR-ja miatt, majd a konténerkép felépítése és a konfigurációs változások.
- A fürt állapotában bekövetkezett változás hiba, erőforrás-ütközés miatt, ami "rossz viselkedést" eredményez, vagy egyszerűen véletlenszerű eltérés az eredeti állapottól.
Mi a konvergencia mechanizmusa?
Néhány példa:
- A tárolók és fürtök esetében a konvergencia mechanizmust a Kubernetes biztosítja.
- Ugyanez a mechanizmus használható a Kubernetes-alapú alkalmazások és tervek (például Istio és Kubeflow) kezelésére is.
- A Kubernetes, a képtárak és a Git közötti operatív interakció kezelésére szolgáló mechanizmust biztosít , amely része .
- Az alapgépeknél a konvergencia mechanizmusnak deklaratívnak és autonómnak kell lennie. Saját tapasztalatunk alapján elmondhatjuk legközelebb ehhez a meghatározáshoz, de még mindig emberi irányítást igényel. Ebben az értelemben a GitOps kiterjeszti az infrastruktúra mint kód hagyományát.
A GitOps a Git-et a Kubernetes kiváló konvergenciamotorjával kombinálja, hogy modellt biztosítson a kiaknázáshoz.
A GitOps lehetővé teszi a következőket: Csak a leírható és megfigyelhető rendszerek automatizálhatók és vezérelhetők.
A GitOps a teljes felhőalapú natív veremhez készült (például Terraform stb.)
A GitOps nem csak a Kubernetes. Azt akarjuk, hogy az egész rendszer deklaratív módon működjön, és konvergenciát használjon. A teljes rendszer alatt a Kubernetes-szel működő környezetek gyűjteményét értjük – például „fejlesztői fürt 1”, „gyártás”, stb. Minden környezet tartalmaz gépeket, fürtöket, alkalmazásokat, valamint interfészeket külső szolgáltatásokhoz, amelyek adatokat szolgáltatnak, figyelnek. és stb.
Figyeld meg, mennyire fontos a Terraform a rendszerindítási probléma szempontjából ebben az esetben. A Kuberneteset valahol telepíteni kell, és a Terraform használatával ugyanazokat a GitOps-munkafolyamatokat alkalmazhatjuk a Kubernetes és az alkalmazások alapját képező vezérlőréteg létrehozásához. Ez egy hasznos bevált gyakorlat.
Nagy hangsúlyt fektetnek a GitOps-koncepciók Kubernetes feletti rétegekre történő alkalmazására. Jelenleg az Istio, a Helm, a Ksonnet, az OpenFaaS és a Kubeflow, valamint például a Pulumi számára léteznek GitOps típusú megoldások, amelyek egy réteget hoznak létre a felhő natív alkalmazások fejlesztéséhez.
Kubernetes CI/CD: a GitOps összehasonlítása más megközelítésekkel
Amint már említettük, a GitOps két dolog:
- A fent leírt Kubernetes és felhőalapú natív működési modell.
- Út a fejlesztőközpontú alkalmazáskezelő környezethez.
Sokak számára a GitOps elsősorban a Git push-okon alapuló munkafolyamat. Őt is szeretjük. De ez még nem minden: nézzük most a CI/CD csővezetékeket.
A GitOps folyamatos telepítést (CD) tesz lehetővé a Kubernetes számára
A GitOps folyamatos üzembe helyezési mechanizmust kínál, amely szükségtelenné teszi a különálló „telepítés-felügyeleti rendszereket”. A Kubernetes mindent megtesz helyetted.
- Az alkalmazás frissítéséhez Gitben kell frissíteni. Ez egy tranzakciós frissítés a kívánt állapothoz. A „telepítést” ezután maga a Kubernetes végzi el a fürtön belül a frissített leírás alapján.
- A Kubernetes működésének jellege miatt ezek a frissítések konvergensek. Ez egy olyan mechanizmust biztosít a folyamatos telepítéshez, amelyben minden frissítés atomi.
- Megjegyzés: GitOps operátort kínál, amely integrálja a Git-et és a Kubernetes-et, és lehetővé teszi a CD végrehajtását a fürt kívánt és aktuális állapotának egyeztetésével.
Kubectl és scriptek nélkül
Kerülje a Kubectl használatát a fürt frissítéséhez, és különösen kerülje a szkriptek használatát a kubectl parancsok csoportosításához. Ehelyett a GitOps-folyamattal a felhasználó frissítheti Kubernetes-fürtjét a Giten keresztül.
Az előnyök közé tartozik:
- Jobb. Frissítések egy csoportja alkalmazható, konvergálható és végül érvényesíthető, így közelebb kerülhetünk az atomi telepítés céljához. Ezzel szemben a szkriptek használata nem garantálja a konvergenciát (erről lentebb olvashat bővebben).
- biztonság. Kelsey Hightower: "A Kubernetes-fürthöz való hozzáférést korlátozza az automatizálási eszközökre és a rendszergazdákra, akik felelősek a hibakeresésért vagy a karbantartásért." Lásd még a biztonságról és a műszaki előírások betartásáról, valamint egy hanyagul megírt Jenkins-forgatókönyv hitelesítő adatainak ellopásával.
- Felhasználói tapasztalat. A Kubectl feltárja a Kubernetes objektummodell mechanikáját, amely meglehetősen összetett. Ideális esetben a felhasználók magasabb absztrakciós szinten lépnek kapcsolatba a rendszerrel. Itt ismét Kelsey-re fogok hivatkozni, és ajánlom a megtekintését .
Különbség a CI és a CD között
A GitOps javítja a meglévő CI/CD modelleket.
A modern CI szerver egy hangszerelési eszköz. Ez egy eszköz a CI-csővezetékek összehangolására. Ezek közé tartozik az összeállítás, a tesztelés, a trönkbe egyesítés stb. A CI-kiszolgálók automatizálják az összetett többlépcsős folyamatok kezelését. Gyakori kísértés, hogy Kubernetes-frissítések készletét írják le, és egy folyamat részeként futtatják, hogy a fürt módosításait bevezesse. Valójában sok szakértő ezt teszi. Ez azonban nem optimális, és itt van az ok.
A CI-t kell használni a frissítések küldésére a törzsbe, és a Kubernetes-fürtnek e frissítések alapján önmagának kell változnia a CD belső kezeléséhez. Úgy hívjuk , ellentétben a CI push modellel. A CD része futásidejű hangszerelés.
Miért nem szabad a CI-kiszolgálóknak CD-ket készíteni a Kubernetes közvetlen frissítésével?
Ne használjon CI-kiszolgálót a Kubernetes közvetlen frissítéseinek CI-feladatok halmazaként történő összehangolására. Ez az anti-minta, amiről beszélünk a blogodon.
Térjünk vissza Alice-hez és Bobhoz.
Milyen problémákkal szembesültek? Bob CI-kiszolgálója alkalmazza a módosításokat a fürtre, de ha a folyamat során összeomlik, Bob nem fogja tudni, hogy a fürt milyen állapotban van (vagy milyen állapotban kell lennie), és nem fogja tudni, hogyan javítsa ki. Ugyanez igaz siker esetén is.
Tegyük fel, hogy Bob csapata készített egy új lemezképet, majd javította a telepítéseket a lemezkép telepítéséhez (mind a CI-folyamatból).
Ha a kép megfelelően épül fel, de a folyamat meghibásodik, a csapatnak ki kell találnia:
- Megjelent a frissítés?
- Új konstrukciót indítunk? Ez szükségtelen mellékhatásokhoz vezet - azzal a lehetőséggel, hogy ugyanazt a változtathatatlan képet két összeállítással készítsük?
- Meg kell várnunk a következő frissítést a build futtatása előtt?
- Pontosan mi romlott el? Mely lépéseket kell megismételni (és melyeket biztonságosan megismételni)?
A Git-alapú munkafolyamat létrehozása nem garantálja, hogy Bob csapata nem találkozik ezekkel a problémákkal. Továbbra is hibázhatnak a commit push, a címkével vagy más paraméterrel; ez a megközelítés azonban még mindig sokkal közelebb áll az explicit mindent vagy semmit megközelítéshez.
Összefoglalva: a CI-kiszolgálóknak miért nem szabad CD-vel foglalkozniuk:
- A frissítési szkriptek nem mindig determinisztikusak; Könnyű hibázni bennük.
- A CI-kiszolgálók nem konvergálnak a deklaratív fürtmodellhez.
- Nehéz garantálni az idempotenciát. A felhasználóknak meg kell érteniük a rendszer mély szemantikáját.
- A részleges meghibásodásból nehezebb felépülni.
Megjegyzés a Helmmel kapcsolatban: Ha a Helmet szeretné használni, javasoljuk, hogy kombinálja egy GitOps operátorral, mint pl. . Ez elősegíti a konvergencia biztosítását. Helm maga sem nem determinisztikus, sem nem atomi.
A GitOps a Kubernetes folyamatos kézbesítésének legjobb módja
Alice és Bob csapata implementálja a GitOps-ot, és rájön, hogy sokkal könnyebbé vált a szoftvertermékekkel való munka, a nagy teljesítmény és a stabilitás fenntartása. Fejezzük be ezt a cikket egy illusztrációval, amely bemutatja, hogyan néz ki új megközelítésük. Ne feledje, hogy leginkább alkalmazásokról és szolgáltatásokról beszélünk, de a GitOps egy teljes platform kezelésére használható.
A Kubernetes működési modellje
Nézze meg a következő diagramot. Megosztott erőforrásként mutatja be a Git-et és a tárolókép-tárat két összehangolt életciklushoz:
- Folyamatos integrációs folyamat, amely fájlokat olvas és ír a Gitbe, és frissítheti a tárolóképek tárát.
- Futásidejű GitOps folyamat, amely egyesíti a telepítést a kezeléssel és a megfigyelhetőséggel. Fájlokat olvas és ír a Gitbe, és letöltheti a konténerképeket.
Mik a főbb megállapítások?
- Az aggodalmak szétválasztása: Felhívjuk figyelmét, hogy mindkét folyamat csak a Git vagy a képtár frissítésével tud kommunikálni. Más szóval, tűzfal van a CI és a futási környezet között. "Megváltozhatatlanság tűzfalának" hívjuk. (változhatatlan tűzfal), mivel minden lerakatfrissítés új verziót hoz létre. A témával kapcsolatos további információkért lásd a 72-87. diát .
- Bármilyen CI és Git szervert használhat: A GitOps bármely összetevővel működik. Továbbra is használhatja kedvenc CI- és Git-kiszolgálóit, képtárait és tesztcsomagjait. Szinte az összes többi folyamatos szállítási eszköz a piacon saját CI/Git szervert vagy képtárat igényel. Ez korlátozó tényezővé válhat a felhő natív fejlesztésében. A GitOps segítségével ismerős eszközöket használhat.
- Az események mint integrációs eszköz: Amint a Gitben lévő adatok frissülnek, a Weave Flux (vagy a Weave Cloud operátor) értesíti a futásidőt. Amikor a Kubernetes elfogad egy változáskészletet, a Git frissítésre kerül. Ez egy egyszerű integrációs modellt biztosít a GitOps munkafolyamatainak szervezéséhez, az alábbiak szerint.
Következtetés
A GitOps minden modern CI/CD eszköz által megkövetelt erős frissítési garanciákat nyújt:
- automatizálás;
- konvergencia;
- idempotencia;
- determinizmus.
Ez azért fontos, mert működési modellt kínál a felhőalapú natív fejlesztők számára.
- A rendszerek kezelésére és felügyeletére szolgáló hagyományos eszközök a runbookon belül működő műveleti csapatokhoz kapcsolódnak (rutin eljárások és műveletek sorozata - kb. fordítás), egy adott telepítéshez kötve.
- A felhőalapú natív menedzsmentben a megfigyelési eszközök jelentik a legjobb módszert a telepítések eredményeinek mérésére, hogy a fejlesztőcsapat gyorsan reagálhasson.
Képzeljen el sok fürtöt szétszórva különböző felhőkön és számos szolgáltatáson saját csapatokkal és telepítési tervekkel. A GitOps egy skálainvariáns modellt kínál ennek a bőségnek a kezelésére.
PS a fordítótól
Olvassa el blogunkon is:
- «";
- «";
- «".
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
Tudott a GitOps-ról, mielőtt ez a két fordítás megjelent a Habrén?
-
Igen, mindent tudtam
-
Csak felületesen
-
Nincs
35 felhasználó szavazott. 10 felhasználó tartózkodott.
Forrás: will.com