GitOps: porovnanie metód Pull a Push

Pozn. prekl.: V komunite Kubernetes získava čoraz väčšiu popularitu trend nazývaný GitOps, čo sme si osobne overili, navštívením KubeCon Europe 2019. Tento termín bol relatívne nedávno vymyslený šéfom spoločnosti Weaveworks — Alexom Richardsonom — a znamená uplatnenie známych nástrojov pre vývojárov (predovšetkým Git, odkiaľ pochádza aj samotný názov) na riešenie prevádzkových úloh. Konkrétne ide o prevádzku Kubernetes prostredníctvom uloženia jeho konfigurácií v Gite a automatického nasadenia zmien do klastru. O dvoch prístupoch k tomuto nasadeniu hovorí Matthias Jg v tomto článku.

V minulom roku (v skutočnosti sa to formálne stalo v auguste 2017 — pozn. prekl.) objavil nový prístup k nasadzovaniu aplikácií v Kubernetes. Nazýva sa GitOps a jeho základným konceptom je, že verzovanie nasadení sa vykonáva v bezpečnom prostredí Git-repozitára.

Hlavné výhody tohto prístupu sú nasledovné:

1. Verziovanie nasadení a história zmien. Stav celého klastru sa uchováva v Git-repozitári a nasadenia sa aktualizujú iba prostredníctvom commitov. Okrem toho je možné všetky zmeny sledovať pomocou histórie commitov.
2. Návraty pomocou známych príkazov Git. Jednoduché git reset umožňuje obnovovať predchádzajúce stavy v nasadeniach; vždy sú k dispozícii predchádzajúce stavy.
3. Hotová kontrola prístupu. Zvyčajne Git-systém obsahuje množstvo dôverných údajov, preto väčšina spoločností venuje zvláštnu pozornosť jej ochrane. Zodpovedajúco sa táto ochrana vzťahuje aj na operácie s nasadeniami.
4. Politiky pre nasadenia. Väčšina Git-systémov podporuje politiky pre rôzne vetvy — napríklad iba pull requesty môžu aktualizovať master, a zmeny musí overiť a schváliť iný člen tímu. Rovnako ako pri kontrole prístupu, tie isté politiky sa aplikujú na aktualizácie nasadení.

Ako vidíte, metóda GitOps má množstvo výhod. V uplynulom roku sa osobitnú popularitu získali dva prístupy. Jeden je založený na push, druhý — na pull. Predtým, než sa na ne pozrieme, sa najprv pozrime, ako vyzerajú typické nasadenia Kubernetes.

Spôsoby nasadenia

V uplynulých rokoch sa v Kubernetes ustálili rôzne spôsoby a nástroje na nasadenia:

1. Na základe natívnych šablón Kubernetes/Kustomize. Toto je najjednoduchší spôsob nasadzovania aplikácií v Kubernetes. Developer vytvára základné YAML súbory a aplikuje ich. Aby sa zabránilo neustálemu prepísaniu tých istých šablón, bol vyvinutý Kustomize (ten mení Kubernetes šablóny na moduly). Pozn. prekl.: Kustomize bol integrovaný do kubectl od vydania Kubernetes 1.14.
2. Helm chartov. Helm chartové súbory umožňujú vytvárať sady šablón, init-kontajnerov, sidecarov atď., ktoré sú aplikované na nasadzovanie aplikácií s flexibilnejšími možnosťami nastavenia ako pri prístupe založenom na šablónach. Tento prístup spočíva na šablónach YAML súborov. Helm ich vyplňuje rôznymi parametrami a následne ich posiela Tilleru — klustrovému komponentu, ktorý ich deployuje do klastru a umožňuje vykonávať aktualizácie a návraty. Dôležité je, že Helm v podstate len vkladá potrebné hodnoty do šablón a následne ich aplikuje rovnakým spôsobom ako pri tradičnom prístupe. (podrobnosti o tom, ako to všetko funguje a ako to možno využiť, nájdete v našej článok o Helme — pozn. prekl.). Existuje veľké množstvo hotových Helm chartov, ktoré pokrývajú široké spektrum úloh.
3. Alternatívne nástroje. Existuje množstvo alternatívnych nástrojov. Všetky spája to, že premienia nejaké šablónové súbory na zrozumiteľné Kubernetes YAML súbory a následne ich aplikujú.

Vo svojej práci neustále používame Helm chartové súbory pre dôležité nástroje (keďže v nich je už veľa predpripraveného, čo značne uľahčuje život) a „čisté“ YAML súbory Kubernetes na nasadzovanie našich vlastných aplikácií.

Pull & Push

V jednom zo svojich nedávnych príspevkov na blogu som predstavil nástroj Weave Flux, ktorý umožňuje posielať šablóny do Git repozitára a aktualizovať nasadenie po každom commite alebo pushnutí kontajnera. Moje skúsenosti ukazujú, že tento nástroj je jedným z hlavných pri presadzovaní pull prístupu, preto budem často odkazovať naň. Ak sa chcete dozvedieť viac o tom, ako ho používať, tu je odkaz na článok.

NB! Všetky výhody používania GitOps sa zachovávajú pre oba prístupy.

Prístup založený na Pull

Zásadou prístupu pull je skutočnosť, že všetky zmeny sa aplikujú zvnútra klastra. Vnútri klastra je operátor, ktorý pravidelne kontroluje súvisiace repozitáre Git a Docker Registry. Ak dôjde k akýmkoľvek zmenám, stav klastra sa aktualizuje zo vnútra. Zvyčajne sa považuje, že takýto proces je veľmi bezpečný, pretože žiaden externý klient nemá prístup k právam správcu klastra.

Výhody:

1. Žiaden externý klient nemá práva na vykonávanie zmien v klastri, všetky aktualizácie sa aplikujú zvnútra.
2. Niektoré nástroje tiež umožňujú synchronizovať aktualizácie Helm grafov a viazať ich ku klastru.
3. Docker Registry možno skenovať na nové verzie. Ak sa objaví nový obraz, Git repozitár a nasadenie sa aktualizujú na novú verziu.
4. Nástroje pull môžu byť rozdelené do rôznych priestorov názvov s rôznymi repozitármi Git a prístupovými právami. Vďaka tomu je možné aplikovať multitenant model. Napríklad tím A môže používať priestor názvov A, tím B priestor názvov B a tím zameraný na infraštruktúru môže používať globálny priestor.
5. Vo všeobecnosti sú nástroje veľmi ľahké.
6. V kombinácii s takými nástrojmi, ako je operátor Bitnami Sealed Secrets, môžu byť tajomstvá uchovávané zašifrované v repozitári Git a extrahované vo vnútri klastra.
7. Neexistuje žiadne prepojenie s CD pipeline, pretože nasadenia sa uskutočňujú vo vnútri klastra.

Nevýhody:

1. Spravovať tajomstvá nasadení z Helm grafov je náročnejšie ako bežné, pretože ich najprv treba generovať v podobe, povedzme, sealed secrets, potom ich dešifrovať vnútorným operátorom a iba potom sa stávajú dostupnými pre nástroj pull. Následne môžete spustiť vydanie v Helme s hodnotami už nasadených tajomstiev. Najjednoduchší spôsob je vytvoriť tajomstvo so všetkými hodnotami Helm používanými pre nasadenie, dešifrovať ho a uložiť do Gitu.
2. Používanie prístupu pull vás viaže na nástroje, ktoré fungujú s pullmi. To obmedzuje možnosť prispôsobiť proces nasadzovania deploymentov v klastri. Napríklad práca s Kustomize je sťažená tým, že musí byť vykonaná skôr, ako konečné šablóny prídu do Git. Nehovorím, že nemôžete používať samostatné nástroje, ale ich integrácia do procesu nasadzovania je zložitejšia.

Prístup založený na Push

V prístupe push vonkajší systém (predovšetkým CD-pipelines) začína nasadzovanie do klastra po commite do Git-repozitára alebo v prípade úspešného vykonania predchádzajúceho CI-pipeline. V tomto prístupe má systém prístup do klastra.

Výhody:

1. Bezpečnosť je určená Git-repozitárom a pipeline na zostavenie.
2. Nasadzovať Helm chart je jednoduchšie, existuje podpora pre Helmové pluginy.
3. Správa tajomstiev je jednoduchšia, pretože tajomstvá je možné aplikovať v pipelines a tiež ich uchovávať v Gite v zašifrovanej podobe (v závislosti od preferencií používateľa).
4. Absencia viazanosti na konkrétny nástroj, pretože je možné používať akékoľvek ich typy.
5. Aktualizácie verzií kontajnerov môžu byť iniciované pipeline na zostavenie.

Nevýhody:

1. Údaje na prístup do klastra sú uložené v systéme na zostavenie.
2. Aktualizácia kontajnerov deploymentov je stále jednoduchšia s pull-procesom.
3. Silná závislosť na CD-systéme, pretože požadované pipelines, pravdepodobne, boli pôvodne napísané pre Gitlab Runners a potom sa tím rozhodne prejsť na Azure DevOps alebo Jenkins… a bude potrebné migrovať veľké množstvo pipelines na zostavenie.

Zhrnutie: Push alebo Pull?

Ako je známe, každý prístup má svoje výhody a nevýhody. Niektoré úlohy sa ľahšie realizujú jedným spôsobom a ťažšie iným. Na začiatku som vykonával nasadenia ručne, ale po tom, čo som narazil na niekoľko článkov o Weave Flux, som sa rozhodol 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 pri práci s Helm chartami. Vtedy Weave Flux ponúkal len začínajúcu verziu Helm Chart Operator, ale aj teraz sú niektoré úlohy zložité kvôli potrebe ručne vytvárať tajomstvá a aplikovať ich. Môžete povedať, že prístup s pullom je oveľa bezpečnejší, pretože poverenia klastru nie sú dostupné mimo neho, čo zvyšuje bezpečnosť do takej miery, že si to zaslúži dodatočné úsilie.

Po zamyslení som dospel k neočakávanému záveru, že to nie je pravda. Ak hovoríme o komponentoch, ktoré si vyžadujú maximálnu ochranu, do takého zoznamu patrí úložisko tajomstiev a CI/CD systémy, Git repozitáre. Informácie v nich sú veľmi zraniteľné a potrebujú maximálnu ochranu. Okrem toho, ak sa niekto dostane do vášho Git repozitára a bude môcť tam pushovať kód, dokáže nasadiť čokoľvek si želá (bez ohľadu na zvolený prístup, či už ide o pull alebo push) a preniknúť do systémov klastru. Takže najdôležitejšími komponentmi, ktoré si vyžadujú ochranu, sú Git repozitár a CI/CD systémy, nie poverenia klastru. Ak máte dobre nastavené politiky a bezpečnostné opatrenia pre systémy tohto typu, a poverenia klastru sa do pipeline dostávajú iba vo forme tajomstiev, dodatočná bezpečnosť prístupu s pullom môže byť menej cenná, než sa pôvodne predpokladalo.

Takže ak je prístup s pullom pracnejší a neprináša žiadne výhody v oblasti bezpečnosti, nie je logické používať len prístup s pushom? Niekoho však môže napadnúť, že pri prístupe s pushom ste príliš závislí na CD systéme a možno by bolo lepšie to nerobiť, aby ste v budúcnosti uľahčili migrácie.

Podľa môjho názoru (ako vždy) by sa malo používať to, čo najlepšie vyhovuje konkrétnemu prípadu, alebo kombinovať prístupy. Osobne používam obidva prístupy: Weave Flux pre deploymenty založené na pull, ktoré prevažne zahŕňajú naše vlastné služby, a push prístup s Helmom a pluginmi, ktorý zjednodušuje aplikáciu Helm chartov na klaster a umožňuje bezproblémové vytváranie tajomstiev. Myslím si, že nikdy nebude existovať jediné riešenie vyhovujúce všetkým situáciám, pretože nuance sú vždy veľmi rozmanité a závisia od konkrétneho spôsobu použitia. Pri tom by som dôrazne odporučil GitOps – veľmi uľahčuje život a zvyšuje bezpečnosť.

Dúfam, že moje skúsenosti v tejto oblasti pomôžu určiť, ktorý prístup je pre vaše typy deploymentov najvhodnejší, a budem rád, ak sa dozviem váš názor.

P.S. Poznámka od prekladateľa

V nevýhodách pull modelu je bod o tom, že je ťažké uložiť do Gitu odrenderované manifesty, avšak nie je uvedená nevýhoda, že CD pipeline v pull modeli žije oddelene od vyka a vlastne sa stáva pipeline-om kategórie Continuous Apply. Preto bude potrebné vyvinúť ešte väčšie úsilie na to, aby sa zhromaždil stav zo všetkých deploymentov a nejako poskytol prístup k logom/stavu, pričom ideálne s väzbou na CD systém.

V tomto zmysle push model umožňuje poskytovať aspoň nejaké garancie nasadenia, pretože čas životnosti pipeline môže byť rovný času životnosti nasadenia.

Otestovali sme obidva modely a dospeli sme k rovnakým záverom ako autor článku:

1. Pull model je pre nás vhodný na organizovanie aktualizácie systémových komponentov na veľkom počte klastrov (pozri článok o addon-operator).
2. Push model založený na GitLab CI sa dobre hodí na nasadenie aplikácií pomocou Helm chartov. Pri tom je nasadenie deploymentov v rámci pipeline sledované pomocou nástroja werf. Mimochodom, v kontexte tohto nášho projektu sme neustále počuli „GitOps“, keď sme preberali aktuálne problémy DevOps inžinierov pri našom stánku na KubeCon Europe'19.

P.P.S. od prekladateľa

Prečítajte si tiež na našom blogu:

• «Kubernetes tipy & triky: preklad fungujúcich prostriedkov v klastri pod správou Helmu 2»;
• «Predstavujeme knižnicu kubedog na sledovanie zdrojov Kubernetes»;
• «Rozširujeme a dopĺňame Kubernetes (prehľad a video prednášky)»;
• «Tipy na vytváranie neštandardných pracovných postupov v GitLab CI».

Len registrovaní používatelia sa môžu zúčastniť prieskumu. Prihláste sa, prosím.

Používate GitOps?

• Áno, prístup pull

• Áno, push

• Áno, pull + push

• Áno, niečo iné

• Nie

Hlasovalo 30 používateľov. Zdržalo sa 10 používateľov.

Zdroj: habr.com