{"id":35594,"date":"2019-10-31T22:05:15","date_gmt":"2019-10-31T19:05:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/gitops-sravnenie-metodov-pull-i-push\/"},"modified":"2019-10-31T22:05:15","modified_gmt":"2019-10-31T19:05:15","slug":"gitops-sravnenie-metodov-pull-i-push","status":"publish","type":"post","link":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps: srovn\u00e1n\u00ed metod Pull a Push","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pozn. p\u0159ek.<\/b>: V komunit\u011b Kubernetes z\u00edsk\u00e1v\u00e1 na popularit\u011b trend zvan\u00fd GitOps, \u010demu\u017e jsme se osobn\u011b p\u0159esv\u011bd\u010dili, kdy\u017e jsme nav\u0161t\u00edvili<\/a><\/noindex> KubeCon Europe 2019. Tento term\u00edn byl relativn\u011b ned\u00e1vno vynalezen<\/a><\/noindex> \u0161\u00e9fem spole\u010dnosti Weaveworks \u2014 Alexisem Richardstonem \u2014 a znamen\u00e1 vyu\u017eit\u00ed b\u011b\u017en\u00fdch n\u00e1stroj\u016f pro v\u00fdvoj\u00e1\u0159e (p\u0159edev\u0161\u00edm Git, odtud i n\u00e1zev) pro \u0159e\u0161en\u00ed provozn\u00edch \u00fakol\u016f. Konkr\u00e9tn\u011b jde o provoz Kubernetes prost\u0159ednictv\u00edm ukl\u00e1d\u00e1n\u00ed jeho konfigurac\u00ed v Gitu a automatick\u00e9ho nasazen\u00ed zm\u011bn do clusteru. O dvou p\u0159\u00edstupech k tomuto nasazen\u00ed hovo\u0159\u00ed Matthias Jg v tomto \u010dl\u00e1nku.<\/i><\/p>\n

\"GitOps:
\n
\nV lo\u0148sk\u00e9m roce (ve skute\u010dnosti se to form\u00e1ln\u011b stalo v srpnu 2017 \u2014 pozn. p\u0159ekl.)<\/i> Objevil se nov\u00fd p\u0159\u00edstup k nasazen\u00ed aplikac\u00ed v Kubernetes. Jmenuje se GitOps a jeho z\u00e1kladem je z\u00e1kladn\u00ed p\u0159edstava, \u017ee sledov\u00e1n\u00ed verz\u00ed deployment\u016f prob\u00edh\u00e1 v bezpe\u010dn\u00e9m prost\u0159ed\u00ed Git repozit\u00e1\u0159e.<\/a><\/noindex><\/p>\n

Hlavn\u00ed v\u00fdhody tohoto p\u0159\u00edstupu jsou n\u00e1sleduj\u00edc\u00ed<\/b>:<\/p>\n

    \n
  1. Verzionov\u00e1n\u00ed deployment\u016f a historie zm\u011bn<\/b>. Stav cel\u00e9ho clusteru je uchov\u00e1v\u00e1n v Git repozit\u00e1\u0159i a deploymenty se aktualizuj\u00ed pouze prost\u0159ednictv\u00edm commit\u016f. Krom\u011b toho lze v\u0161echny zm\u011bny sledovat pomoc\u00ed historie commit\u016f.<\/li>\n
  2. Vr\u00e1tit pomoc\u00ed b\u011b\u017en\u00fdch gitov\u00fdch p\u0159\u00edkaz\u016f<\/b>. Snadn\u00e9 git reset<\/code> umo\u017e\u0148uje vr\u00e1tit zm\u011bny v deploymentech; v\u017edy jsou k dispozici p\u0159edchoz\u00ed stavy.<\/li>\n
  3. Hotov\u00e1 kontrola p\u0159\u00edstupu<\/b>. V\u011bt\u0161ina Git syst\u00e9m\u016f obsahuje mnoho d\u016fv\u011brn\u00fdch \u00fadaj\u016f, proto v\u011bt\u0161ina firem v\u011bnuje zv\u00fd\u0161enou pozornost jejich ochran\u011b. Tato ochrana se samoz\u0159ejm\u011b vztahuje i na operace s deploymenty.<\/li>\n
  4. Politiky pro nasazen\u00ed<\/b>. V\u011bt\u0161ina Git syst\u00e9m\u016f od za\u010d\u00e1tku podporuje politiky pro r\u016fzn\u00e9 v\u011btve \u2013 nap\u0159\u00edklad pouze pull requesty mohou aktualizovat master, a zm\u011bny mus\u00ed b\u00fdt zkontrolov\u00e1ny a schv\u00e1leny jin\u00fdm \u010dlenem t\u00fdmu. Stejn\u00e9 politiky se uplat\u0148uj\u00ed na aktualizace deployment\u016f, jak je tomu u \u0159\u00edzen\u00ed p\u0159\u00edstupu.<\/li>\n<\/ol>\n

    \nJak vid\u00edte, metoda GitOps m\u00e1 \u0159adu v\u00fdhod. B\u011bhem posledn\u00edho roku z\u00edskaly zvl\u00e1\u0161tn\u00ed popularitu dva p\u0159\u00edstupy. Jeden je zalo\u017een na push, druh\u00fd na pull. Ne\u017e se na n\u011b pod\u00edv\u00e1me, pod\u00edvejme se nejprve, jak vypadaj\u00ed typick\u00e9 deploymenty Kubernetes.<\/p>\n

    Zp\u016fsoby nasazen\u00ed<\/h2>\n

    \nV posledn\u00edch letech se v Kubernetes ust\u00e1lily r\u016fzn\u00e9 zp\u016fsoby a n\u00e1stroje pro nasazen\u00ed:<\/p>\n

      \n
    1. Na z\u00e1klad\u011b dom\u00e1c\u00edch \u0161ablon Kubernetes\/Kustomize<\/b>. To je nejjednodu\u0161\u0161\u00ed zp\u016fsob nasazen\u00ed aplikac\u00ed na Kubernetes. V\u00fdvoj\u00e1\u0159 vytv\u00e1\u0159\u00ed z\u00e1kladn\u00ed YAML soubory a aplikuje je. Aby se zbavil neust\u00e1l\u00e9ho p\u0159episov\u00e1n\u00ed stejn\u00fdch \u0161ablon, byl vyvinut Kustomize (ten p\u0159etv\u00e1\u0159\u00ed \u0161ablony Kubernetes na moduly). Pozn. p\u0159ek.<\/b>: Kustomize byl integrov\u00e1n do kubectl s verz\u00ed Kubernetes 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Helm Charts<\/b>. Helm chartry umo\u017e\u0148uj\u00ed vytv\u00e1\u0159et sady \u0161ablon, init kontejner\u016f, sidecar\u016f atd., kter\u00e9 se pou\u017e\u00edvaj\u00ed pro nasazen\u00ed aplikac\u00ed s flexibiln\u011bj\u0161\u00edmi mo\u017enostmi konfigurace ne\u017e v p\u0159\u00edstupu zalo\u017een\u00e9m na \u0161ablon\u00e1ch. Tento p\u0159\u00edstup je zalo\u017een na \u0161ablonizovan\u00fdch YAML souborech. Helm je vypl\u0148uje r\u016fzn\u00fdmi parametry a pot\u00e9 je odes\u00edl\u00e1 Tillerovi \u2014 clusterov\u00e9mu komponentu, kter\u00fd je nasazuje v clusteru a umo\u017e\u0148uje prov\u00e1d\u011bt aktualizace a vracen\u00ed zp\u011bt. D\u016fle\u017eit\u00e9 je, \u017ee Helm v podstat\u011b jednodu\u0161e vkl\u00e1d\u00e1 pot\u0159ebn\u00e9 hodnoty do \u0161ablon a pot\u00e9 je aplikuje stejn\u011b, jako se to d\u011bl\u00e1 v tradi\u010dn\u00edm p\u0159\u00edstupu (v\u00edce o tom, jak to v\u0161echno funguje a jak to lze pou\u017e\u00edt, si p\u0159e\u010dt\u011bte v na\u0161\u00ed \u010dl\u00e1nku o Helmu<\/a><\/noindex> \u2014 pozn. p\u0159ekl.)<\/i>. Existuje velk\u00e9 mno\u017estv\u00ed hotov\u00fdch Helm chart\u016f, pokr\u00fdvaj\u00edc\u00edch \u0161irok\u00e9 spektrum \u00fakol\u016f.<\/li>\n
    3. Alternativn\u00ed n\u00e1stroje<\/b>. Existuje mnoho alternativn\u00edch n\u00e1stroj\u016f. V\u0161echny spojuje to, \u017ee p\u0159ev\u00e1d\u011bj\u00ed ur\u010dit\u00e9 \u0161ablonov\u00e9 soubory na srozumiteln\u00e9 Kubernetes YAML soubory a n\u00e1sledn\u011b je aplikuj\u00ed.<\/li>\n<\/ol>\n

      \nVe sv\u00e9 pr\u00e1ci neust\u00e1le pou\u017e\u00edv\u00e1me Helm chart pro d\u016fle\u017eit\u00e9 n\u00e1stroje (proto\u017ee v nich je ji\u017e mnoho p\u0159ipraveno, co\u017e zna\u010dn\u011b usnad\u0148uje \u017eivot) a '\u010dist\u00e9' YAML soubory Kubernetes pro nasazen\u00ed vlastn\u00edch aplikac\u00ed.<\/p>\n

      Pull & Push<\/h2>\n

      \nV jednom ze sv\u00fdch ned\u00e1vn\u00fdch p\u0159\u00edsp\u011bvk\u016f na blogu jsem p\u0159edstavil n\u00e1stroj Weave Flux<\/a><\/noindex>, co\u017e umo\u017e\u0148uje commitov\u00e1n\u00ed \u0161ablon do Git repozit\u00e1\u0159e a aktualizaci deploymentu po ka\u017ed\u00e9m commitu nebo pushi kontejneru. Moje zku\u0161enosti ukazuj\u00ed, \u017ee tento n\u00e1stroj je jedn\u00edm z hlavn\u00edch v propagaci pull p\u0159\u00edstupu, proto na n\u011bj budu \u010dasto odkazovat. Pokud chcete v\u011bd\u011bt v\u00edce o jeho pou\u017eit\u00ed, zde je odkaz na \u010dl\u00e1nek<\/a><\/noindex>.<\/p>\n

      NB!<\/b> V\u0161echny v\u00fdhody pou\u017e\u00edv\u00e1n\u00ed GitOps z\u016fst\u00e1vaj\u00ed pro oba p\u0159\u00edstupy.<\/i><\/p>\n

      Pull p\u0159\u00edstup<\/h2>\n

      \n\"GitOps:
      \n
      \nZ\u00e1kladn\u00ed my\u0161lenka p\u0159\u00edstupu pull spo\u010d\u00edv\u00e1 v tom, \u017ee v\u0161echny zm\u011bny se aplikuj\u00ed zevnit\u0159 clusteru. Uvnit\u0159 clusteru je oper\u00e1tor, kter\u00fd pravideln\u011b kontroluje souvisej\u00edc\u00ed repozit\u00e1\u0159e Git a Docker Registry. Pokud dojde k jak\u00fdmkoli zm\u011bn\u00e1m, stav clusteru se aktualizuje zevnit\u0159. Obvykle se pova\u017euje, \u017ee tento proces je pom\u011brn\u011b bezpe\u010dn\u00fd, proto\u017ee \u017e\u00e1dn\u00fd extern\u00ed klient nem\u00e1 p\u0159\u00edstup k administr\u00e1torsk\u00fdm pr\u00e1v\u016fm clusteru.<\/p>\n

      Plusy:<\/b><\/p>\n

        \n
      1. \u017d\u00e1dn\u00fd extern\u00ed klient nem\u00e1 pr\u00e1va prov\u00e1d\u011bt zm\u011bny v clusteru, ve\u0161ker\u00e9 aktualizace se prov\u00e1d\u011bj\u00ed zevnit\u0159.<\/li>\n
      2. N\u011bkter\u00e9 n\u00e1stroje tak\u00e9 umo\u017e\u0148uj\u00ed synchronizaci aktualizac\u00ed Helm chart\u016f a jejich p\u0159i\u0159azen\u00ed k clusteru.<\/li>\n
      3. Docker Registry lze skenovat na nov\u00e9 verze. Pokud se objev\u00ed nov\u00fd obraz, Git repozit\u00e1\u0159 a deployment se aktualizuj\u00ed na novou verzi.<\/li>\n
      4. Pull n\u00e1stroje mohou b\u00fdt distribuov\u00e1ny mezi r\u016fzn\u00fdmi jmenn\u00fdmi prostory s r\u016fzn\u00fdmi repozit\u00e1\u0159i Git a p\u0159\u00edstupov\u00fdmi pr\u00e1vy. D\u00edky tomu lze pou\u017e\u00edt multitenantn\u00ed model. Nap\u0159\u00edklad t\u00fdm A m\u016f\u017ee pou\u017e\u00edvat jmenn\u00fd prostor A, t\u00fdm B jmenn\u00fd prostor B, a t\u00fdm zab\u00fdvaj\u00edc\u00ed se infrastrukturou m\u016f\u017ee pou\u017e\u00edvat glob\u00e1ln\u00ed prostor.<\/li>\n
      5. Obecn\u011b jsou n\u00e1stroje velmi lehk\u00e9.<\/li>\n
      6. V kombinaci s n\u00e1stroji jako je oper\u00e1tor Bitnami Sealed Secrets<\/a><\/noindex>, mohou b\u00fdt tajemstv\u00ed uchov\u00e1v\u00e1na v za\u0161ifrovan\u00e9 podob\u011b v Git repozit\u00e1\u0159i a vyta\u017eena uvnit\u0159 clusteru.<\/li>\n
      7. Nen\u00ed zde \u017e\u00e1dn\u00e1 vazba na CD pipeline, nebo\u0165 nasazen\u00ed prob\u00edh\u00e1 uvnit\u0159 clusteru.<\/li>\n<\/ol>\n

        \nNev\u00fdhody<\/b>:<\/p>\n

          \n
        1. Spr\u00e1va tajemstv\u00ed nasazen\u00ed z Helm chart\u016f je slo\u017eit\u011bj\u0161\u00ed ne\u017e s obvykl\u00fdmi, proto\u017ee mus\u00ed b\u00fdt nejprve generov\u00e1na jako nap\u0159\u00edklad sealed secrets, pot\u00e9 de\u0161ifrov\u00e1na intern\u00edm oper\u00e1torem a teprve pot\u00e9 jsou k dispozici pro n\u00e1stroj pull. Pot\u00e9 lze spustit release v Helmu s hodnotami v ji\u017e nasazen\u00fdch tajemstv\u00edch. Nejjednodu\u0161\u0161\u00ed zp\u016fsob je vytvo\u0159it tajemstv\u00ed se v\u0161emi hodnotami Helm pou\u017e\u00edvan\u00fdmi pro nasazen\u00ed, de\u0161ifrovat je a commitnout je do Gitu.<\/li>\n
        2. P\u0159i pou\u017eit\u00ed pull p\u0159\u00edstupu jste v\u00e1z\u00e1ni na n\u00e1stroje, kter\u00e9 operuj\u00ed s pull. To omezuje mo\u017enosti konfigurace procesu nasazen\u00ed v clusteru. Nap\u0159\u00edklad pr\u00e1ce s Kustomize je komplikovan\u00e1 t\u00edm, \u017ee mus\u00ed b\u00fdt provedena p\u0159ed t\u00edm, ne\u017e kone\u010dn\u00e9 \u0161ablony p\u0159ijdou do Gitu. Ne\u0159\u00edk\u00e1m, \u017ee nelze pou\u017e\u00edt jednotliv\u00e9 n\u00e1stroje, ale jejich integrace do nasazovac\u00edho procesu je slo\u017eit\u011bj\u0161\u00ed.<\/li>\n<\/ol>\n

          <\/p>\n

          P\u0159\u00edstup na z\u00e1klad\u011b Push<\/h2>\n

          \n\"GitOps:
          \n
          \nVe vzd\u00e1len\u00e9m p\u0159\u00edstupu spou\u0161t\u00ed extern\u00ed syst\u00e9m (p\u0159ev\u00e1\u017en\u011b CD pipeline) nasazen\u00ed v clusteru po commitu do Git repozit\u00e1\u0159e nebo v p\u0159\u00edpad\u011b \u00fasp\u011b\u0161n\u00e9ho dokon\u010den\u00ed p\u0159edchoz\u00edho CI pipeline. V tomto p\u0159\u00edstupu m\u00e1 syst\u00e9m p\u0159\u00edstup do clusteru.<\/p>\n

          V\u00fdhody<\/b>:<\/p>\n

            \n
          1. Bezpe\u010dnost je ur\u010dena Git repozit\u00e1\u0159em a build pipeline.<\/li>\n
          2. Nasazen\u00ed Helm chart\u016f je snaz\u0161\u00ed, existuje podpora pro Helm pluginy.<\/li>\n
          3. Spr\u00e1va tajemstv\u00ed je snaz\u0161\u00ed, proto\u017ee je mo\u017en\u00e9 je pou\u017e\u00edvat v pipelines a tak\u00e9 je uchov\u00e1vat v Gitu v za\u0161ifrovan\u00e9 podob\u011b (v z\u00e1vislosti na preferenc\u00edch u\u017eivatele).<\/li>\n
          4. Nen\u00ed zde v\u00e1zanost na konkr\u00e9tn\u00ed n\u00e1stroj, proto\u017ee lze pou\u017e\u00edt jak\u00fdkoliv jejich typ.<\/li>\n
          5. Aktualizace verz\u00ed kontejner\u016f mohou b\u00fdt iniciov\u00e1ny build pipeline.<\/li>\n<\/ol>\n

            \nNev\u00fdhody<\/b>:<\/p>\n

              \n
            1. \u00dadaje pro p\u0159\u00edstup k clustru se nach\u00e1zej\u00ed uvnit\u0159 build syst\u00e9mu.<\/li>\n
            2. Aktualizace kontejner\u016f nasazen\u00ed je st\u00e1le snaz\u0161\u00ed prov\u00e1d\u011bt pomoc\u00ed pull procesu.<\/li>\n
            3. Siln\u00e1 z\u00e1vislost na CD syst\u00e9mu, proto\u017ee pot\u0159ebn\u00e9 pipeline byly mo\u017en\u00e1 p\u016fvodn\u011b naps\u00e1ny pro Gitlab Runners, a pot\u00e9 se t\u00fdm rozhodne p\u0159ej\u00edt na Azure DevOps nebo Jenkins... a bude nutn\u00e9 migrovat velk\u00e9 mno\u017estv\u00ed build pipeline.<\/li>\n<\/ol>\n

              <\/p>\n

              Shrnut\u00ed: Push nebo Pull?<\/h2>\n

              \nJak to obvykle b\u00fdv\u00e1, ka\u017ed\u00fd p\u0159\u00edstup m\u00e1 sv\u00e9 klady a z\u00e1pory. N\u011bkter\u00e9 \u00fakoly se l\u00e9pe pln\u00ed jedn\u00edm zp\u016fsobem a slo\u017eit\u011bji druh\u00fdm. Zpo\u010d\u00e1tku jsem prov\u00e1d\u011bl nasazen\u00ed ru\u010dn\u011b, ale pot\u00e9, co jsem narazil na n\u011bkolik \u010dl\u00e1nk\u016f o Weave Flux, jsem se rozhodl zav\u00e9st procesy GitOps pro v\u0161echny projekty. Pro z\u00e1kladn\u00ed \u0161ablony to bylo snadn\u00e9, ale pak jsem za\u010dal nar\u00e1\u017eet na obt\u00ed\u017ee p\u0159i pr\u00e1ci s Helm chartami. V t\u00e9 dob\u011b Weave Flux nab\u00edzel pouze z\u00e1kladn\u00ed verzi Helm Chart Operatoru, ale i dnes jsou n\u011bkter\u00e9 \u00fakoly slo\u017eit\u011bj\u0161\u00ed kv\u016fli nutnosti ru\u010dn\u011b vytv\u00e1\u0159et tajemstv\u00ed a aplikovat je. M\u016f\u017eete \u0159\u00edci, \u017ee pull p\u0159\u00edstup je mnohem bezpe\u010dn\u011bj\u0161\u00ed, proto\u017ee p\u0159ihla\u0161ovac\u00ed \u00fadaje k clustru nejsou dostupn\u00e9 mimo n\u011bj, co\u017e zvy\u0161uje bezpe\u010dnost natolik, \u017ee to stoj\u00ed za dodate\u010dn\u00e9 \u00fasil\u00ed.<\/p>\n

              Po chv\u00edli p\u0159em\u00fd\u0161len\u00ed jsem dosp\u011bl k p\u0159ekvapiv\u00e9mu z\u00e1v\u011bru, \u017ee tomu tak nen\u00ed. Pokud jde o komponenty, kter\u00e9 vy\u017eaduj\u00ed maxim\u00e1ln\u00ed ochranu, do takov\u00e9ho seznamu by m\u011bly pat\u0159it \u00falo\u017ei\u0161t\u011b tajemstv\u00ed a CI\/CD syst\u00e9my, Git repozit\u00e1\u0159e. Informace uvnit\u0159 nich jsou velmi zraniteln\u00e9 a pot\u0159ebuj\u00ed maxim\u00e1ln\u00ed ochranu. Krom\u011b toho, pokud se n\u011bkdo dostane do va\u0161eho Git repozit\u00e1\u0159e a bude moci tam pushnout k\u00f3d, bude schopen nasadit cokoliv si p\u0159eje (bez ohledu na to, zda je to pull nebo push) a proniknout do syst\u00e9m\u016f clusteru. Nejkriti\u010dt\u011bj\u0161\u00edmi komponentami, kter\u00e9 pot\u0159ebuj\u00ed ochranu, jsou Git repozit\u00e1\u0159 a CI\/CD syst\u00e9my, nikoliv pov\u011b\u0159en\u00ed clusteru. Pokud m\u00e1te dob\u0159e nastaven\u00e9 politiky a bezpe\u010dnostn\u00ed opat\u0159en\u00ed pro syst\u00e9my tohoto typu, a pov\u011b\u0159en\u00ed clusteru jsou v pipelinech extrahov\u00e1na pouze jako tajemstv\u00ed, m\u016f\u017ee b\u00fdt dodate\u010dn\u00e1 bezpe\u010dnost pull p\u0159\u00edstupu m\u00e9n\u011b cenn\u00e1, ne\u017e se p\u016fvodn\u011b p\u0159edpokl\u00e1dalo.<\/p>\n

              Pokud je tedy pull p\u0159\u00edstup pracn\u011bj\u0161\u00ed a nep\u0159in\u00e1\u0161\u00ed \u017e\u00e1dn\u00e9 v\u00fdhody z hlediska bezpe\u010dnosti, nen\u00ed logick\u00e9 pou\u017e\u00edvat pouze push p\u0159\u00edstup? Ale n\u011bkdo by mohl \u0159\u00edci, \u017ee v push p\u0159\u00edstupu jste p\u0159\u00edli\u0161 z\u00e1visl\u00ed na CD syst\u00e9mu a mo\u017en\u00e1 by bylo lep\u0161\u00ed to ned\u011blat, abyste v budoucnu usnadnili migrace.<\/p>\n

              Podle m\u00e9ho n\u00e1zoru (jako v\u017edy) by se m\u011blo pou\u017e\u00edvat to, co nejl\u00e9pe vyhovuje konkr\u00e9tn\u00ed situaci, nebo kombinovat r\u016fzn\u00e9 p\u0159\u00edstupy. Osobn\u011b pou\u017e\u00edv\u00e1m ob\u011b metody: Weave Flux pro nasazen\u00ed zalo\u017een\u00e1 na pull, kter\u00e9 v\u011bt\u0161inou zahrnuj\u00ed na\u0161e vlastn\u00ed slu\u017eby, a push p\u0159\u00edstup s Helmem a pluginy, kter\u00e9 usnad\u0148uj\u00ed aplikaci Helm chart\u016f na klastr a umo\u017e\u0148uj\u00ed bezprobl\u00e9mov\u00e9 vytv\u00e1\u0159en\u00ed tajemstv\u00ed. Mysl\u00edm, \u017ee nikdy nebude jedin\u00e9 \u0159e\u0161en\u00ed vyhovuj\u00edc\u00ed v\u0161em situac\u00edm, proto\u017ee je zde v\u017edy mnoho nuanc\u00ed a ty z\u00e1vis\u00ed na konkr\u00e9tn\u00ed aplikaci. P\u0159esto d\u016frazn\u011b doporu\u010duji GitOps \u2014 v\u00fdrazn\u011b usnad\u0148uje \u017eivot a zvy\u0161uje bezpe\u010dnost.<\/p>\n

              Douf\u00e1m, \u017ee m\u00e9 zku\u0161enosti ohledn\u011b tohoto t\u00e9matu pomohou ur\u010dit, kter\u00fd zp\u016fsob nejl\u00e9pe vyhovuje va\u0161emu typu nasazen\u00ed, a r\u00e1d se dozv\u00edm v\u00e1\u0161 n\u00e1zor.<\/p>\n

              P.S. Pozn\u00e1mka od p\u0159ekladatele<\/h2>\n

              \nMezi nev\u00fdhodami pull modelu je bod, \u017ee je obt\u00ed\u017en\u00e9 ulo\u017eit v Gitu renderovan\u00e9 manifesty, nicm\u00e9n\u011b nen\u00ed nev\u00fdhodou, \u017ee CD pipeline v pull modelu \u017eije odd\u011blen\u011b od nasazen\u00ed a v podstat\u011b se st\u00e1v\u00e1 pipeline kategorie Continuous Apply<\/i>. Proto bude zapot\u0159eb\u00ed je\u0161t\u011b v\u00edce \u00fasil\u00ed k tomu, aby bylo mo\u017en\u00e9 shroma\u017e\u010fovat stav ze v\u0161ech nasazen\u00ed a n\u011bjak\u00fdm zp\u016fsobem poskytovat p\u0159\u00edstup k log\u016fm\/stavu, ide\u00e1ln\u011b s vazbou na CD syst\u00e9m.<\/p>\n

              V tomto smyslu push model umo\u017e\u0148uje poskytnout alespo\u0148 n\u011bjak\u00e9 z\u00e1ruky nasazen\u00ed, proto\u017ee doba \u017eivota pipeline m\u016f\u017ee b\u00fdt nastavena na dobu \u017eivota nasazen\u00ed.<\/p>\n

              Otestovali jsme ob\u011b modely a do\u0161li jsme k t\u011bmto stejn\u00fdm z\u00e1v\u011br\u016fm jako autor \u010dl\u00e1nku:<\/p>\n

                \n
              1. Pull model n\u00e1m vyhovuje pro organizaci aktualizac\u00ed syst\u00e9mov\u00fdch komponent na velk\u00e9m mno\u017estv\u00ed cluster\u016f (viz) \u010dl\u00e1nek o addon-operatoru<\/a><\/noindex>).<\/li>\n
              2. Push model zalo\u017een\u00fd na GitLab CI je dob\u0159e p\u0159izp\u016fsoben pro nasazen\u00ed aplikac\u00ed pomoc\u00ed Helm chart\u016f. P\u0159i tom je nasazen\u00ed v r\u00e1mci pipeline sledov\u00e1no pomoc\u00ed n\u00e1stroje werf<\/a><\/noindex>. Mimochodem, v kontextu tohoto na\u0161eho projektu jsme pravideln\u011b sl\u00fdchali \"GitOps\", kdy\u017e jsme diskutovali o aktu\u00e1ln\u00edch probl\u00e9mech DevOps in\u017een\u00fdr\u016f u na\u0161eho st\u00e1nku na KubeCon Europe 19.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.S. od p\u0159ekladatele<\/h2>\n

                \nP\u0159e\u010dt\u011bte si tak\u00e9 n\u00e1\u0161 blog:<\/p>\n