Poznámka. preklad.: V komunite Kubernetes si trend s názvom GitOps získava zjavnú popularitu, ako sme osobne videli, KubeCon Europe 2019. Tento termín bol relatívne nedávny od šéfa Weaveworks - Alexisa Richardsona - a znamená použitie nástrojov známych vývojárom (predovšetkým Git, odtiaľ názov) na riešenie prevádzkových problémov. Hovoríme najmä o fungovaní Kubernetes ukladaním jeho konfigurácií v Git a automatickým zavádzaním zmien do klastra. Matthias Jg v tomto článku hovorí o dvoch prístupoch k tomuto zavádzaniu.
V minulom roku, (v skutočnosti sa to formálne stalo v auguste 2017 - približne preklad.) V Kubernetes existuje nový prístup k nasadzovaniu aplikácií. Volá sa GitOps a je založená na základnej myšlienke, že verzie nasadenia sa sledujú v zabezpečenom prostredí úložiska Git.
Hlavné výhody tohto prístupu sú nasledovné::
- Verzia nasadenia a história zmien. Stav celého klastra je uložený v úložisku Git a nasadenia sa aktualizujú iba prostredníctvom potvrdení. Okrem toho je možné všetky zmeny sledovať pomocou histórie odovzdania.
- Vrátenie zmien pomocou známych príkazov Git... Prostý
git resetumožňuje resetovať zmeny v nasadení; minulé stavy sú vždy k dispozícii. - Pripravená kontrola prístupu. Systém Git zvyčajne obsahuje veľa citlivých údajov, takže väčšina spoločností venuje osobitnú pozornosť ich ochrane. V súlade s tým sa táto ochrana vzťahuje aj na operácie s nasadením.
- Zásady pre nasadenia. Väčšina systémov Git natívne podporuje politiku po vetve – napríklad iba požiadavky na stiahnutie môžu aktualizovať hlavný server a zmeny musí skontrolovať a prijať iný člen tímu. Rovnako ako pri riadení prístupu sa na aktualizácie nasadenia vzťahujú rovnaké zásady.
Ako vidíte, metóda GitOps má veľa výhod. Za posledný rok získali mimoriadnu popularitu dva prístupy. Jeden je založený na tlaku, druhý na ťahu. Skôr než sa na ne pozrieme, pozrime sa najprv na to, ako vyzerajú typické nasadenia Kubernetes.
Metódy nasadenia
V posledných rokoch Kubernetes vytvoril rôzne metódy a nástroje na nasadenie:
- Založené na natívnych šablónach Kubernetes/Kustomize. Toto je najjednoduchší spôsob nasadenia aplikácií na Kubernetes. Vývojár vytvorí základné súbory YAML a použije ich. Aby sme sa zbavili neustáleho prepisovania rovnakých šablón, bol vyvinutý Kustomize (premieňa šablóny Kubernetes na moduly). Poznámka. preklad.: Kustomize bola integrovaná do kubectl s .
- Tabuľky kormidla. Helmové grafy vám umožňujú vytvárať sady šablón, init kontajnerov, postranných vozíkov atď., ktoré sa používajú na nasadenie aplikácií s flexibilnejšími možnosťami prispôsobenia ako v prístupe založenom na šablónach. Táto metóda je založená na šablónových súboroch YAML. Helm ich naplní rôznymi parametrami a potom ich odošle do Tiller, komponentu klastra, ktorý ich nasadí do klastra a umožní aktualizácie a návraty. Dôležité je, že Helm v podstate len vloží požadované hodnoty do šablón a potom ich aplikuje rovnakým spôsobom, ako sa to robí v tradičnom prístupe. (prečítajte si viac o tom, ako to všetko funguje a ako to môžete použiť v našom - približne. preklad.). Existuje široká škála hotových Helmových máp pokrývajúcich širokú škálu úloh.
- Alternatívne nástroje. Existuje mnoho alternatívnych nástrojov. Všetky majú spoločné to, že premenia niektoré súbory šablón na súbory YAML čitateľné Kubernetes a potom ich použijú.
Pri našej práci neustále využívame Helm grafy pre dôležité nástroje (keďže už majú veľa vecí pripravených, čo značne uľahčuje život) a „čisté“ súbory Kubernetes YAML na nasadenie vlastných aplikácií.
Ťahať tlačiť
V jednom z mojich nedávnych blogových príspevkov som tento nástroj predstavil , ktorý vám umožňuje odovzdať šablóny do úložiska Git a aktualizovať nasadenie po každom odovzdaní alebo odoslaní kontajnera. Moje skúsenosti ukazujú, že tento nástroj je jedným z hlavných pri presadzovaní ťahového prístupu, preto sa naň budem často odvolávať. Ak sa chcete dozvedieť viac o tom, ako ho používať, tu .
NB! Všetky výhody používania GitOps zostávajú rovnaké pre oba prístupy.
Prístup založený na ťahu
Prístup ťahania je založený na skutočnosti, že všetky zmeny sa aplikujú zvnútra klastra. Vo vnútri klastra je operátor, ktorý pravidelne kontroluje súvisiace úložiská registrov Git a Docker. Ak sa v nich vyskytnú nejaké zmeny, stav klastra sa interne aktualizuje. Tento proces je všeobecne považovaný za veľmi bezpečný, keďže žiadny externý klient nemá prístup k právam správcu klastra.
Pros:
- Žiadny externý klient nemá práva na vykonávanie zmien v klastri, všetky aktualizácie sa zavádzajú zvnútra.
- Niektoré nástroje vám tiež umožňujú synchronizovať aktualizácie grafu Helm a prepojiť ich s klastrom.
- V registri Docker je možné skenovať nové verzie. Ak je k dispozícii nový obrázok, úložisko Git a nasadenie sa aktualizujú na novú verziu.
- Pull nástroje môžu byť distribuované cez rôzne menné priestory s rôznymi Git archívmi a povoleniami. Vďaka tomu je možné použiť multitenantový model. Napríklad tím A môže používať priestor názvov A, tím B môže používať priestor názvov B a tím infraštruktúry môže používať globálny priestor.
- Nástroje sú spravidla veľmi ľahké.
- V kombinácii s nástrojmi, ako je operátor , tajomstvá môžu byť uložené zašifrované v úložisku Git a načítané v rámci klastra.
- Neexistuje žiadne pripojenie k kanálom CD, pretože nasadenia sa vyskytujú v rámci klastra.
Zápory:
- Správa tajných informácií nasadenia z Helmových grafov je náročnejšia ako pri bežných, pretože sa musia najskôr vygenerovať vo forme, povedzme, zapečatených tajomstiev, potom ich dešifruje interný operátor a až potom sa sprístupnia nástroju sťahovania. Potom môžete spustiť vydanie v Helme s hodnotami v už nasadených tajomstvách. Najjednoduchším spôsobom je vytvoriť tajomstvo so všetkými hodnotami Helm použitých na nasadenie, dešifrovať ho a odovzdať Gitu.
- Keď použijete ťahový prístup, budete pripútaní k ťahaniu nástrojov. To obmedzuje možnosť prispôsobiť proces nasadenia v klastri. Kustomize je napríklad komplikovaná skutočnosťou, že musí byť spustená skôr, ako sú finálne šablóny odovzdané Gitu. Nehovorím, že nemôžete používať samostatné nástroje, ale je ťažšie ich integrovať do procesu nasadenia.
Push založený prístup
V prístupe push spustí externý systém (hlavne kanály CD) nasadenia do klastra po odovzdaní do úložiska Git alebo ak je predchádzajúci kanál CI úspešný. V tomto prístupe má systém prístup do klastra.
Pros:
- Bezpečnosť je určená úložiskom Git a kanálom zostavovania.
- Nasadenie grafov Helm je jednoduchšie a podporuje doplnky Helm.
- Tajomstvá sa ľahšie spravujú, pretože tajomstvá môžu byť použité v kanáloch a môžu byť uložené aj zašifrované v Git (v závislosti od preferencií používateľa).
- Neexistuje žiadne spojenie s konkrétnym nástrojom, pretože je možné použiť akýkoľvek typ.
- Aktualizácie verzie kontajnera môžu byť spustené pomocou procesu zostavovania.
Zápory:
- Prístupové údaje klastra sú vo vnútri zostavovacieho systému.
- Aktualizácia kontajnerov na nasadenie je ešte jednoduchšia pomocou procesu sťahovania.
- Silná závislosť na systéme CD, pretože kanály, ktoré potrebujeme, mohli byť pôvodne napísané pre Gitlab Runners, a potom sa tím rozhodne prejsť na Azure DevOps alebo Jenkins... a bude musieť migrovať veľké množstvo potrubí na zostavenie.
Výsledky: tlačiť alebo ťahať?
Ako to už býva, každý prístup má svoje pre a proti. Niektoré úlohy sa dajú ľahšie splniť s jedným a ťažšie s iným. Najprv som nasadenia robil manuálne, ale potom, čo som narazil na pár článkov o Weave Flux, rozhodol som sa implementovať procesy GitOps pre všetky projekty. Pre základné šablóny to bolo jednoduché, ale potom som začal narážať na problémy s Helmovými grafmi. V tom čase Weave Flux ponúkal iba základnú verziu Helm Chart Operator, ale aj teraz sú niektoré úlohy zložitejšie kvôli potrebe ručne vytvárať tajomstvá a aplikovať ich. Mohli by ste namietať, že prístup sťahovania je oveľa bezpečnejší, pretože poverenia klastra nie sú prístupné mimo klastra, vďaka čomu je oveľa bezpečnejší, že to stojí za ďalšie úsilie.
Po premýšľaní som dospel k nečakanému záveru, že to tak nie je. Ak hovoríme o komponentoch, ktoré vyžadujú maximálnu ochranu, tento zoznam bude zahŕňať tajné úložisko, systémy CI/CD a úložiská Git. Informácie v nich sú veľmi zraniteľné a potrebujú maximálnu ochranu. Navyše, ak sa niekto dostane do vášho úložiska Git a môže tam vložiť kód, môže nasadiť, čo chce (či už je to pull alebo push), a infiltrovať sa do systémov klastra. Najdôležitejšie komponenty, ktoré je potrebné chrániť, sú teda úložisko Git a systémy CI/CD, nie klastrové poverenia. Ak máte dobre nakonfigurované politiky a bezpečnostné ovládacie prvky pre tieto typy systémov a klastrové poverenia sa extrahujú do kanálov iba ako tajomstvá, pridaná bezpečnosť prístupu sťahovania nemusí byť taká cenná, ako sa pôvodne predpokladalo.
Ak je teda ťahový prístup náročnejší na prácu a neposkytuje bezpečnostnú výhodu, nie je logické použiť iba ťahový prístup? Niekto by však mohol namietať, že v prístupe push ste príliš viazaní na systém CD a možno je lepšie to nerobiť, aby bolo v budúcnosti jednoduchšie vykonávať migráciu.
Podľa mňa (ako vždy) treba použiť to, čo je pre konkrétny prípad alebo kombináciu najvhodnejšie. Osobne používam oba prístupy: Weave Flux pre nasadenia založené na ťahaní, ktoré väčšinou zahŕňajú naše vlastné služby, a prístup push s Helm a pluginmi, ktorý uľahčuje aplikáciu Helmových grafov na klaster a umožňuje vám bezproblémovo vytvárať tajomstvá. Myslím si, že nikdy nebude existovať jediné riešenie vhodné pre všetky prípady, pretože vždy existuje veľa nuancií a závisia od konkrétnej aplikácie. Ako už bolo povedané, veľmi odporúčam GitOps – výrazne uľahčuje život a zlepšuje bezpečnosť.
Dúfam, že moje skúsenosti na túto tému vám pomôžu rozhodnúť sa, ktorá metóda je vhodnejšia pre váš typ nasadenia, a rád si vypočujem váš názor.
PS Poznámka od prekladateľa
Nevýhodou modelu sťahovania je, že je ťažké umiestniť vykreslené manifesty do systému Git, ale neexistuje žiadna nevýhoda, že kanál CD v modeli sťahovania žije oddelene od zavádzania a v podstate sa stáva potrubím kategórií. Nepretržité uplatňovanie. Preto bude potrebné ešte viac úsilia zhromaždiť ich stav zo všetkých nasadení a nejakým spôsobom poskytnúť prístup k protokolom/stavu, najlepšie s odkazom na systém CD.
V tomto zmysle nám push model umožňuje poskytnúť aspoň nejaké záruky rolloutu, pretože životnosť potrubia sa môže rovnať životnosti rolloutu.
Vyskúšali sme oba modely a dospeli sme k rovnakým záverom ako autor článku:
- Pulzný model je pre nás vhodný na organizovanie aktualizácií systémových komponentov na veľkom počte klastrov (viď. ).
- Push model založený na GitLab CI je vhodný na zavádzanie aplikácií pomocou Helmových grafov. Zároveň sa pomocou nástroja monitoruje zavádzanie nasadení v rámci potrubí . Mimochodom, v kontexte tohto nášho projektu sme počuli neustále „GitOps“, keď sme diskutovali o naliehavých problémoch inžinierov DevOps v našom stánku na KubeCon Europe'19.
PPS od prekladača
Prečítajte si aj na našom blogu:
- «»;
- «»;
- «»;
- «".
Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prosím.
Používate GitOps?
-
Áno, ťahový prístup
-
Áno, tlačiť
-
Áno, ťahať + tlačiť
-
Áno, niečo iné
-
Nie
Hlasovalo 30 užívateľov. 10 užívateľov sa zdržalo hlasovania.
Zdroj: hab.com