Megjegyzés fordítás.: A Kubernetes közösségben egyre népszerűbbé válik a GitOps néven ismert trend, aminek mi is tanúi voltunk, a KubeCon Europe 2019-en. Ez a kifejezés viszonylag nemrégiben a Weaveworks cég vezetője, Alexis Richardson által, és azt jelenti, hogy a fejlesztők által megszokott eszközöket (elsősorban a Git-et, ahonnan a név is származik) alkalmazzák az üzemeltetési feladatok megoldására. Különösen arról van szó, hogy a Kubernetes üzemeltetését a konfigurációk Git-ben történő tárolásával és a változások automatikus kihelyezésével végezzük a klaszteren. Matthias Jg erre a kihelyezési folyamatra két megközelítést ismertet ebben a cikkben.
Tavaly (valójában formálisan ez 2017 augusztusában történt — a fordító megjegyzése) megjelenik egy új megközelítés az alkalmazások Kubernetes alá történő telepítésében. Ezt GitOps-nak hívják, és alapvetően az a gondolat áll mögötte, hogy a deployment-ek verziókövetését egy Git-repo biztonságos környezetében végzik.
Ennek a megközelítésnek az alapvető előnyei a következők:
- A deployment-ek verziókövetése és a változások története. Az egész klaszter állapota Git-repo-ban van tárolva, és a deployment-eket kizárólag ún. commit-ok útján frissítjük. Ezenkívül az összes változást a commit-történet segítségével lehet nyomon követni.
- Rollback a megszokott Git parancsokkal. Egyszerű
git resetlehetővé teszi az események visszaállítását a deployment-ekben; mindig elérhetők a korábbi állapotok. - Kész hozzáférés-ellenőrzés. A Git rendszer általában számos bizalmas adatot tartalmaz, ezért a legtöbb cég különös figyelmet fordít a védelemre. Ennek megfelelően ez a védelem a deployment-ekkel kapcsolatos műveletekre is vonatkozik.
- Politikák a telepítésekhez. A legtöbb Git rendszer alapértelmezetten támogatja a különböző ágak politikáit — például csak a pull request-ek frissíthetik a master-t, a változásokat pedig egy másik csapattag jóváhagyása szükséges. Mint a hozzáférés-ellenőrzés esetében, ugyanazok a politikák vonatkoznak a deployment-ek frissítéseire is.
Ahogy látható, a GitOps módszernek számos előnye van. Az elmúlt évben két közkedvelt megközelítés vált népszerűvé. Az egyik a push, a másik a pull alapú. Mielőtt rátérnénk ezekre, először nézzük meg, hogyan is néznek ki a tipikus Kubernetes deployment-ek.
Telepítési módok
Az utóbbi években a Kubernetes-alapú különféle telepítési módok és eszközök alakultak ki:
- A Kubernetes / Kustomize natív sablonjaira alapozvaEz a legegyszerűbb módja az alkalmazások telepítésének a Kubernetesben. A fejlesztő alap YAML fájlokat készít és alkalmazza őket. Annak érdekében, hogy megszabaduljon az állandóan újraírható sablonoktól, kifejlesztették a Kustomize-ot (ez a Kubernetes sablonokat modulokká alakítja). Megjegyzés fordítás.: A Kustomize integrálva van a kubectl-lel a .
- Helm chartok.A Helm chartok lehetővé teszik sablonok, init-konténerek, sidecar-ok stb. készleteinek létrehozását, amelyek rugalmasabb konfigurálási lehetőségeket kínálnak az alkalmazások telepítésére, mint a sablontalapú megközelítés. Ennek a metodológiának a lényege sablonozott YAML fájlokban rejlik. A Helm kitölti őket különböző paraméterekkel, majd elküldi a Tiller-nek – a klaszter összetevőjének, amely telepíti őket a klaszterben, és lehetővé teszi a frissítéseket és visszagörgetéseket. Fontos megjegyezni, hogy a Helm lényegében csak megfelelő értékeket illeszt a sablonokba, és alkalmazza őket, ahogy azt a klasszikus megközelítésnél is teszik. (további információkat arról, hogyan működik mindez, és hogyan használható, olvasson el a — a fordító megjegyzése). Számos kész Helm chart létezik, amelyek széles spektrumú feladatokat ölelnek fel.
- Alternatív eszközök.Sok alternatív eszköz létezik. Közös bennük, hogy átalakítanak bizonyos sablon fájlokat érthető Kubernetes YAML fájlokká, majd alkalmazzák őket.
A munkánk során folyamatosan használunk Helm chartokat fontos eszközökhöz (mivel sok minden készen áll, ami jelentősen megkönnyíti az életünket), és "tiszta" Kubernetes YAML fájlokat a saját alkalmazásaink telepítésére.
Pull & Push.
A közelmúltban a blogomban bemutattam egy eszközt, amely lehetővé teszi a sablonok git-repozitóriumba való elkötelezését és a telepítés frissítését minden elkötelezés vagy konténer push után. Tapasztalataim szerint ez az eszköz az egyik alapvető segédeszköz a pull megközelítés népszerűsítésében, ezért gyakran hivatkozni fogok rá. Ha többet szeretne megtudni annak használatáról, itt van egy .
NB! A GitOps használatának minden előnye érvényesül mindkét megközelítésnél.
Pull megközelítés
A pull megközelítés alapja az a tény, hogy minden változtatás a klaszter belsejéből történik. A klaszterben van egy operátor, amely folyamatosan ellenőrzi a kapcsolódó Git és Docker Registry-repozitóriumokat. Ha ezekben bármilyen változás történik, a klaszter állapota belülről frissül. Általában úgy vélik, hogy az ilyen folyamat rendkívül biztonságos, mivel egyetlen külső kliens sem fér hozzá a klaszter adminisztrátori jogaihoz.
Előnyök:
- Egyetlen külső kliens sem rendelkezik jogosultsággal a klaszter módosítására, az összes frissítést belülről hajtják végre.
- Néhány eszköz lehetővé teszi a Helm-diagramok frissítéseinek szinkronizálását és a klaszterhez való kötését.
- A Docker Registry kereshető új verziók után. Ha új kép jelenik meg, a Git-repozitórium és a telepítés frissül az új verzióra.
- A pull-eszközök különböző névtérben, különböző Git-repozitóriumokkal és jogosultságokkal oszthatók el. Ennek köszönhetően alkalmazható a multitenant modell. Például az A csapat az A névteret használhatja, a B csapat a B névteret, míg az infrastruktúrával foglalkozó csapat globális névteret használhat.
- Általában az eszközök meglehetősen könnyűek.
- Olyan eszközökkel, mint az operátor , a titkok titkosított formában tárolhatók a Git-repozitóriumban, és a klaszter belsejében vonhatók ki.
- Nincs kapcsolat a CD-pipeline-ekkel, mivel a telepítések a klaszter belsejében történnek.
Hátrányok:
- A Helm-diagramokból származó telepítések titkainak kezelése nehezebb, mint a hagyományosak, mivel először azokat például sealed secrets formájában kell generálni, majd a belső operátor titkosítja őket, és csak ezután válnak elérhetővé a pull-eszköz számára. Ezután lehet a Helm-ben kiadást indítani az már telepített titkokban lévő értékekkel. A legegyszerűbb módszer, ha készítünk egy titkot minden Helm értékkel, amelyet a telepítéshez használnak, ezt titkosítjuk és elkötelezzük a Git-ben.
- A pull módszer alkalmazásával a pull-eszközökhöz vagyunk kötve. Ez korlátozza a telepítési folyamat testreszabásának lehetőségét a klaszterben. Például a Kustomize használata nehezebb, mivel annak a végső sablonok Git-be történő felbocsátása előtt kell futnia. Nem azt mondom, hogy nem lehet külön eszközöket használni, de azokat nehezebb integrálni a telepítési folyamatba.
Push alapú megközelítés
A push megközelítésben egy külső rendszer (elsősorban CD-pipeline-ok) indít el telepítéseket a klaszterben a Git tárolóba történő elköteleződés után vagy a korábbi CI-pipeline sikeres futása esetén. Ebben a megközelítésben a rendszer hozzáféréssel rendelkezik a klaszterhez.
Előnyök:
- A biztonság a Git tároló és a build pipeline által meghatározott.
- A Helm chartok telepítése egyszerűbb, Héjpluginok támogatásával.
- A titkok kezelése könnyebb, mivel a titkok a pipeline-okban alkalmazhatók, illetve titkosított formában tárolhatók a Git-ben (a felhasználó preferenciái szerint).
- Nincs kötődés egy adott eszközhöz, mivel bármilyen típusú eszköz használható.
- A konténerváltozások frissítéseket a build pipeline indíthatja.
Hátrányok:
- A klaszterhez való hozzáférés adatai a build rendszeren belül találhatók.
- A telepítések konténereinek frissítése továbbra is egyszerűbb a pull folyamattal.
- Erős függőség a CD-rendszertől, mivel a szükséges pipeline-ok esetleg eredetileg Gitlab Runners-re íródtak, majd a csapat úgy dönt, hogy átáll az Azure DevOps-ra vagy Jenkinsre... és sok build pipeline migrálására lehet szükség.
Összegzés: Push vagy Pull?
Mint ahogy az lenni szokott, minden megközelítésnek megvannak a maga előnyei és hátrányai. Egyes feladatokat könnyebb egyik módszerrel végrehajtani, míg másokkal nehezebb. Eleinte manuálisan végeztem a telepítéseket, de miután rábukkantam néhány cikkre a Weave Fluxról, úgy döntöttem, hogy GitOps folyamatokat vezetek be minden projektbe. Az alap sablonok esetében ez egyszerűnek bizonyult, de később nehézségekbe ütköztem a Helm chartokkal kapcsolatban. Akkoriban a Weave Flux csak a Helm Chart Operator kezdeti verzióját kínálta, de még most is vannak olyan feladatok, amelyeket nehezít a titkok manuális létrehozásának és alkalmazásának szükségessége. Mondhatná, hogy a pull megközelítés sokkal biztonságosabb, mivel a klaszter hitelesítő adatai nem hozzáférhetők azon kívül, ami annyira növeli a biztonságot, hogy megérdemli a plusz erőfeszítést.
Egy kis gondolkodás után meglepő következtetésre jutottam: ez nem így van. Ha a maximális védelmet igénylő komponensekről beszélünk, a titkos adattárolók és a CI/CD rendszerek, a Git-repozitóriumok felkerülnek a listára. Az információk bennük meglehetősen sebezhetőek, és maximális védelemre van szükségük. Ezen kívül, ha valaki behatol a Git-repozitóriumába, és tud oda kódot push-olni, akkor mindent telepíthet, amit csak akar (függetlenül attól, hogy pull vagy push megközelítést választ), és behatolhat a klaszter rendszereibe. Így a legfontosabb védendő komponensek a Git-repozitórium és a CI/CD rendszerek, nem pedig a klaszter hitelesítő adatai. Ha jól konfigurálta a politikákat és biztonsági intézkedéseket az ilyen típusú rendszerekhez, és a klaszter hitelesítő adatai csak titkok formájában vonhatók ki a pipeline-okba, akkor a pull megközelítés további biztonsága lehet, hogy nem olyan értékes, mint eredetileg gondolták.
Tehát, ha a pull megközelítés munkaigényesebb és nem nyújt biztonsági előnyt, nem lenne logikus csak a push megközelítést használni? De valaki azt mondhatja, hogy a push megközelítésnél túlzottan függ a CD-rendszertől, és talán jobb elkerülni ezt, hogy a jövőben könnyebb legyen a migráció.
Szerintem (mint mindig) azt kell használni, ami jobban illik a konkrét esetre, vagy kombinálni kell a megoldásokat. Én személy szerint mindkét megközelítést alkalmazom: a Weave Fluxot az olyan telepítésekhez, amelyek a pull alapúak és főként a saját szolgáltatásainkat tartalmazzák, és a Helm alapú push megközelítést, amely megkönnyíti a Helm chartok alkalmazását a klaszterre és lehetővé teszi a titkok egyszerű létrehozását. Úgy gondolom, sosem lesz egyetlen megoldás, ami mindenkire érvényes, mert rengeteg árnyalat van, és ezek a konkrét alkalmazási lehetőségektől függenek. Ugyanakkor határozottan ajánlom a GitOps-ot — ez jelentősen megkönnyíti az életet és növeli a biztonságot.
Remélem, a tapasztalataim segítenek eldönteni, hogy melyik módszer a legmegfelelőbb az önök telepítési típusához, és örömmel várom a véleményüket.
P.S. Megjegyzés a fordítótól
A pull modell hátrányai között van, hogy nehéz Git-be rakni a renderelt manifestumokat, azonban nem hátrány, hogy a CD-pipeline a pull modellben külön él a telepítéstől, és lényegében egy külön kategóriájú pipeline-ná válik. Folyamatos Alkalmazás. Ezért még több erőfeszítést igényel, hogy összegyűjtsük az összes telepítés státuszát, és valahogy hozzáférést biztosítsunk a naplókhoz/státuszhoz, lehetőleg a CD rendszerhez kapcsolódóan.
Ebben az értelemben a push modell némi garanciát ad a telepítésre, mert a pipeline élettartama egyenlő lehet a telepítés élettartamával.
Kipróbáltuk mindkét modellt, és ugyanerre a következtetésre jutottunk, mint a cikk szerzője:
- A pull modell alkalmas a rendszerszintű komponensek frissítésének megszervezésére nagy számú klaszterben (lásd: ).
- A GitLab CI alapú push modell jól használható az alkalmazások telepítésére Helm chartok segítségével. A telepítések követését a pipeline keretein belül egy eszköz segítségével valósítjuk meg. . Érdekes, hogy a projektünk kontextusában állandóan hallottuk a „GitOps”-ot, amikor a DevOps mérnökök sürgető problémáit vitattuk meg a KubeCon Europe ’19-es rendezvényen.
Megjegyzés: Ez a cikk az IBM Cloud mérnökei által végzett mini-kutatás eredménye, amely a valós problémák megoldását célozta meg az etcd adatbázis üzemeltetésével kapcsolatban.
Olvasson további információkat a blogunkban:
- «»;
- «»;
- «»;
- «».
Csak a regisztrált felhasználók vehetnek részt a szavazáson. , kérem.
Használja a GitOps-t?
Igen, pull megközelítés
Igen, push
Igen, pull + push
Igen, valami más
Nem
30 felhasználó szavazott. 10 felhasználó tartózkodott.
Forrás: habr.com
