Jegyzet. ford.: A Kubernetes közösségben a GitOps nevű trend nyilvánvaló népszerűségnek örvend, ahogy azt személyesen is láthattuk, KubeCon Europe 2019. Ez a kifejezés viszonylag friss volt a Weaveworks vezetője - Alexis Richardson -, és a fejlesztők számára ismert eszközök (elsősorban Git, innen a név) használatát jelenti a működési problémák megoldására. Konkrétan a Kubernetes működéséről beszélünk a konfigurációk Gitben történő tárolásával és a fürt módosításainak automatikus bevezetésével. Matthias Jg ebben a cikkben ennek a kiterjesztésnek két megközelítéséről beszél.
Az elmúlt évben (sőt, formálisan ez 2017 augusztusában történt – kb. fordítás.) A Kubernetesben új megközelítés létezik az alkalmazások üzembe helyezésére. Ezt GitOps-nak hívják, és azon az alapgondolaton alapul, hogy a telepítési verziók nyomon követhetők a Git-tároló biztonságos környezetében.
Ennek a megközelítésnek a fő előnyei a következők::
- Üzembe helyezési verziók és változástörténet. A teljes fürt állapotát egy Git-lerakatban tárolják, és a központi telepítések csak véglegesítéseken keresztül frissülnek. Ezenkívül minden változás nyomon követhető a véglegesítési előzmények segítségével.
- Visszagörgetés az ismert Git-parancsok használatával... Egyszerű
git resetlehetővé teszi a telepítések változásainak visszaállítását; a múltbeli állapotok mindig rendelkezésre állnak. - Kész hozzáférés-szabályozás. Egy Git rendszer jellemzően sok érzékeny adatot tartalmaz, ezért a legtöbb cég kiemelt figyelmet fordít ezek védelmére. Ennek megfelelően ez a védelem a telepítésekkel végzett műveletekre is vonatkozik.
- Telepítési szabályzatok. A legtöbb Git-rendszer natívan támogatja az ágonkénti házirendeket – például csak a lekérési kérelmek frissíthetik a mestert, és a változtatásokat egy másik csapattagnak át kell tekintenie és el kell fogadnia. A hozzáférés-szabályozáshoz hasonlóan a központi telepítési frissítésekre is ugyanazok a házirendek vonatkoznak.
Amint láthatja, a GitOps módszernek számos előnye van. Az elmúlt évben két megközelítés vált különösen népszerűvé. Az egyik push alapú, a másik húzás alapú. Mielőtt megvizsgálnánk őket, először nézzük meg, hogyan néznek ki a tipikus Kubernetes-telepítések.
Telepítési módszerek
Az elmúlt években a Kubernetesben különféle módszerek és eszközök jelentek meg a telepítéshez:
- Natív Kubernetes/Kustomize sablonokon alapul. Ez a legegyszerűbb módja az alkalmazások telepítésének a Kubernetes rendszeren. A fejlesztő létrehozza az alapvető YAML fájlokat és alkalmazza azokat. Az azonos sablonok állandó újraírásától való megszabadulás érdekében a Kustomize-t fejlesztették ki (a Kubernetes sablonokat modulokká alakítja). Jegyzet. ford.: A Kustomize integrálva lett a kubectl-be .
- Helm Charts. A Helm diagramok lehetővé teszik sablonkészletek, init-tárolók, oldalkocsik stb. létrehozását, amelyek segítségével rugalmasabb testreszabási lehetőségeket kínáló alkalmazások telepíthetők, mint a sablonalapú megközelítésben. Ez a módszer sablonos YAML-fájlokon alapul. A Helm különféle paraméterekkel tölti meg őket, majd elküldi a Tillernek, egy fürtkomponensnek, amely telepíti őket a fürtbe, és lehetővé teszi a frissítéseket és a visszaállításokat. A lényeg az, hogy a Helm lényegében csak beszúrja a kívánt értékeket a sablonokba, majd ugyanúgy alkalmazza azokat, mint a hagyományos megközelítésben. (További információ arról, hogy mindez hogyan működik, és hogyan használhatod fel a mi oldalunkban - kb. fordítás.). A kész Helm diagramok széles választéka létezik, amelyek a feladatok széles skáláját fedik le.
- Alternatív eszközök. Számos alternatív eszköz létezik. Mindannyiukban az a közös, hogy egyes sablonfájlokat Kubernetes által olvasható YAML-fájlokká alakítanak, majd felhasználják őket.
Munkánk során folyamatosan használjuk a Helm diagramokat a fontos eszközökhöz (hiszen már sok minden készen van, ami nagyban megkönnyíti az életet), illetve a „tiszta” Kubernetes YAML fájlokat saját alkalmazásaink telepítéséhez.
Húz tol
Az egyik legutóbbi blogbejegyzésemben bemutattam az eszközt , amely lehetővé teszi a sablonok véglegesítését a Git-tárban, és a központi telepítés frissítését a tároló minden véglegesítése vagy leküldése után. Tapasztalataim azt mutatják, hogy ez az eszköz az egyik fő eszköz a pull megközelítés népszerűsítésében, ezért gyakran hivatkozom rá. Ha többet szeretne tudni a használatáról, itt .
Megjegyzés! A GitOps használatának minden előnye ugyanaz marad mindkét megközelítésben.
Húzás alapú megközelítés
A lehívási megközelítés azon a tényen alapszik, hogy minden változás a fürtön belülről történik. A fürtön belül van egy operátor, aki rendszeresen ellenőrzi a kapcsolódó Git és Docker Registry tárolókat. Ha bármilyen változás történik bennük, a fürt állapota belsőleg frissül. Ez a folyamat általában nagyon biztonságosnak tekinthető, mivel egyetlen külső ügyfél sem fér hozzá a fürt rendszergazdai jogaihoz.
Előnyök:
- Egyetlen külső ügyfélnek sincs joga módosítani a fürtön; minden frissítés belülről kerül bevezetésre.
- Egyes eszközök lehetővé teszik a Helm diagram frissítéseinek szinkronizálását és a fürthöz való kapcsolását is.
- A Docker Registry átvizsgálható új verziókért. Ha új lemezkép áll rendelkezésre, a Git-tárház és a központi telepítés az új verzióra frissül.
- A lehúzási eszközök különböző névterek között oszthatók el különböző Git-tárolókkal és engedélyekkel. Ennek köszönhetően több bérlős modell is használható. Például az A csapat használhatja az A névteret, a B csapat használhatja a B névteret, az infrastruktúra csoport pedig a globális teret.
- Általában az eszközök nagyon könnyűek.
- Olyan eszközökkel kombinálva, mint a kezelő , a titkok titkosítva tárolhatók egy Git-tárolóban, és lekérhetők a fürtön belül.
- Nincs kapcsolat a CD-folyamatokkal, mivel a telepítések a fürtön belül történnek.
Hátrányok:
- Az üzembe helyezési titkok kezelése Helm diagramokból nehezebb, mint a hagyományosaké, mivel először le kell őket generálni mondjuk lezárt titkok formájában, majd egy belső operátorral dekódolni kell, és csak ezt követően válnak elérhetővé a pull tool számára. Ezután futtathatja a kiadást a Helmben a már telepített titkok értékeivel. A legegyszerűbb módja annak, hogy létrehozzon egy titkot a telepítéshez használt Helm összes értékével, visszafejtse és véglegesítse a Gitben.
- Ha húzós megközelítést alkalmazol, húzószerszámokhoz leszel kötve. Ez korlátozza a telepítési folyamat testreszabásának lehetőségét egy fürtben. Például a Kustomize-t bonyolítja az a tény, hogy le kell futnia, mielőtt a végső sablonokat a Githez kötik. Nem azt mondom, hogy nem használhat önálló eszközöket, de ezeket nehezebb integrálni a telepítési folyamatba.
Push alapú megközelítés
A leküldéses megközelítésben egy külső rendszer (főleg CD-folyamatok) elindítja a központi telepítést a fürtben a Git-lerakatra vonatkozó véglegesítés után, vagy ha az előző CI-folyamat sikeres volt. Ebben a megközelítésben a rendszer hozzáfér a fürthöz.
Érvek:
- A biztonságot a Git adattár és a build folyamat határozza meg.
- A Helm diagramok telepítése egyszerűbb, és támogatja a Helm beépülő modulokat.
- A titkokat könnyebb kezelni, mert a titkok csővezetékekben használhatók, és Gitben titkosítva is tárolhatók (a felhasználó preferenciáitól függően).
- Nincs kapcsolat egy adott szerszámmal, mivel bármilyen típus használható.
- A tárolóverzió frissítését az összeállítási folyamat kezdeményezheti.
Hátrányok:
- A fürt hozzáférési adatok az összeállítási rendszeren belül vannak.
- A telepítési tárolók frissítése továbbra is egyszerűbb lekérési folyamattal.
- Erősen függ a CD-rendszertől, mivel a szükséges folyamatokat eredetileg a Gitlab Runners számára írták, majd a csapat úgy dönt, hogy az Azure DevOps-ra vagy a Jenkins-re költözik... és nagyszámú build-folyamatot kell migrálnia.
Eredmények: Push vagy Pull?
Mint általában, minden megközelítésnek megvannak a maga előnyei és hátrányai. Egyes feladatokat az egyikkel könnyebben, a másikkal nehezebben lehet végrehajtani. Eleinte manuálisan végeztem az üzembe helyezést, de miután találkoztam néhány cikkel a Weave Flux-ról, úgy döntöttem, hogy minden projektben megvalósítom a GitOps folyamatokat. Az alapsablonoknál ez könnyű volt, de aztán nehézségekbe ütköztem a Helm diagramokkal. Akkoriban a Weave Flux csak a Helm Chart Operator kezdetleges verzióját kínálta, de néhány feladat még most is nehezebb a titkok manuális létrehozása és alkalmazása miatt. Érvelhetnénk, hogy a lehívási megközelítés sokkal biztonságosabb, mivel a fürt hitelesítő adatai nem érhetők el a fürtön kívül, így sokkal biztonságosabb, hogy megéri az extra erőfeszítést.
Némi gondolkodás után arra a váratlan következtetésre jutottam, hogy ez nem így van. Ha a maximális védelmet igénylő összetevőkről beszélünk, akkor ez a lista tartalmazza a titkos tárolást, a CI/CD-rendszereket és a Git-tárolókat. A bennük lévő információ nagyon sérülékeny, és maximális védelmet igényel. Ezen túlmenően, ha valaki belép a Git-tárházába, és kódot küldhet oda, azt telepítheti, amit akar (legyen az pull vagy push), és behatol a fürt rendszereibe. Így a legfontosabb védendő összetevők a Git adattár és a CI/CD rendszerek, nem pedig a fürt hitelesítő adatai. Ha jól konfigurált házirendekkel és biztonsági vezérlőkkel rendelkezik az ilyen típusú rendszerekhez, és a fürt hitelesítő adatait csak titokként vonják ki a folyamatokba, akkor előfordulhat, hogy a lehívási megközelítés hozzáadott biztonsága nem lesz olyan értékes, mint azt eredetileg gondoltuk.
Tehát, ha a pull megközelítés munkaigényesebb, és nem nyújt biztonsági előnyt, nem logikus-e csak a push megközelítés alkalmazása? De valaki azzal érvelhet, hogy a push megközelítésben túlságosan kötődik a CD-rendszerhez, és talán jobb, ha ezt nem teszi meg, hogy a jövőben könnyebb legyen az áttelepítés.
Véleményem szerint (mint mindig) azt kell használni, ami egy adott esethez vagy kombájnhoz a legalkalmasabb. Személy szerint mindkét megközelítést használom: a Weave Flux-ot a húzás alapú telepítésekhez, amelyek többnyire saját szolgáltatásainkat tartalmazzák, és a push megközelítést Helmmel és bővítményekkel, amely megkönnyíti a Helm diagramok fürtre való alkalmazását, és lehetővé teszi a titkok zökkenőmentes létrehozását. Szerintem soha nem lesz egyetlen, minden esetre megfelelő megoldás, mert mindig sok az árnyalat, ami az adott alkalmazástól függ. Ennek ellenére nagyon ajánlom a GitOpsot – ez nagyban megkönnyíti az életet és javítja a biztonságot.
Remélem, a témával kapcsolatos tapasztalataim segítenek eldönteni, hogy melyik módszer felel meg jobban az Ön bevetési típusának, és szívesen meghallgatom a véleményét.
PS Megjegyzés a fordítótól
A pull modell hátránya, hogy nehéz a renderelt manifeszteket a Gitbe helyezni, de nincs hátránya, hogy a pull modellben a CD-folyamat elkülönül a közzétételtől, és lényegében kategóriafolyamattá válik. Folyamatos alkalmazás. Ezért még több erőfeszítésre lesz szükség ahhoz, hogy az összes telepítésből összegyűjtsük az állapotukat, és valamilyen módon hozzáférést biztosítsunk a naplókhoz/állapotokhoz, lehetőleg a CD-rendszerre hivatkozva.
Ebben az értelemben a push modell lehetővé teszi számunkra, hogy legalább bizonyos garanciákat nyújtsunk a kiépítésre, mivel a csővezeték élettartama egyenlővé tehető a kiterítés élettartamával.
Mindkét modellt kipróbáltuk, és ugyanazokra a következtetésekre jutottunk, mint a cikk szerzője:
- A pull modell alkalmas arra, hogy a rendszerkomponensek frissítéseit nagyszámú klaszteren szervezzük (lásd. ).
- A GitLab CI-n alapuló push modell kiválóan alkalmas Helm diagramokat használó alkalmazások bevezetésére. Ezzel egyidejűleg az eszközzel figyelik a csővezetékeken belüli telepítések kiépítését . Ezzel a projektünkkel kapcsolatban egyébként az állandó „GitOps”-t hallottuk, amikor a KubeCon Europe'19-es standunkon megvitattuk a DevOps mérnökök sürgető problémáit.
PPS a fordítótól
Olvassa el blogunkon is:
- «";
- «";
- «";
- «".
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
GitOps-ot használsz?
-
Igen, húzós megközelítés
-
Igen, nyomja
-
Igen, húzza + nyomja
-
Igen, valami más
-
Nincs
30 felhasználó szavazott. 10 felhasználó tartózkodott.
Forrás: will.com