{"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\/sk\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps: porovnanie met\u00f3d Pull a Push","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pozn. prekl.<\/b>: V komunite Kubernetes z\u00edskava \u010doraz v\u00e4\u010d\u0161iu popularitu trend naz\u00fdvan\u00fd GitOps, \u010do sme si osobne overili, nav\u0161t\u00edven\u00edm<\/a><\/noindex> KubeCon Europe 2019. Tento term\u00edn bol relat\u00edvne ned\u00e1vno vymyslen\u00fd<\/a><\/noindex> \u0161\u00e9fom spolo\u010dnosti Weaveworks \u2014 Alexom Richardsonom \u2014 a znamen\u00e1 uplatnenie zn\u00e1mych n\u00e1strojov pre v\u00fdvoj\u00e1rov (predov\u0161etk\u00fdm Git, odkia\u013e poch\u00e1dza aj samotn\u00fd n\u00e1zov) na rie\u0161enie prev\u00e1dzkov\u00fdch \u00faloh. Konkr\u00e9tne ide o prev\u00e1dzku Kubernetes prostredn\u00edctvom ulo\u017eenia jeho konfigur\u00e1ci\u00ed v Gite a automatick\u00e9ho nasadenia zmien do klastru. O dvoch pr\u00edstupoch k tomuto nasadeniu hovor\u00ed Matthias Jg v tomto \u010dl\u00e1nku.<\/i><\/p>\n

\"GitOps:
\n
\nV minulom roku (v skuto\u010dnosti sa to form\u00e1lne stalo v auguste 2017 \u2014 pozn. prekl.)<\/i> Objavil se je nov pristop k uvajanju aplikacij v Kubernetes. Imenuje se GitOps in temelji na osnovnem prepri\u010danju, da se sledenje razli\u010dicam deploymentov odvija v varnem okolju Git repozitorija.<\/a><\/noindex><\/p>\n

Hlavn\u00e9 v\u00fdhody tohto pr\u00edstupu s\u00fa nasledovn\u00e9<\/b>:<\/p>\n

    \n
  1. Razli\u010dne razli\u010dice deploymentov in zgodovina sprememb<\/b>. Stanje celotnega klasterja se shranjuje v Git repozitoriju, deploymenti pa se posodobijo le s pomo\u010djo commitov. Poleg tega je mogo\u010de vse spremembe slediti prek zgodovine commitov.<\/li>\n
  2. N\u00e1vraty pomocou zn\u00e1mych pr\u00edkazov Git<\/b>. Jednoduch\u00e9 git reset<\/code> omogo\u010da povrnitev sprememb v deploymentih; vedno so na voljo prej\u0161nje razli\u010dice.<\/li>\n
  3. Hotov\u00e1 kontrola pr\u00edstupu<\/b>. Obi\u010dajno Git sistem vsebuje veliko zaupnih podatkov, zato ve\u010dina podjetij posve\u010da posebno pozornost njegovi za\u0161\u010diti. To varstvo se seveda nana\u0161a tudi na operacije z deploymenti.<\/li>\n
  4. Politiky pre nasadenia<\/b>. Ve\u010dina Git sistemov \u017ee v osnovi podpira politike za razli\u010dne veje \u2014 na primer, le pull requesti lahko posodobijo master, spremembe pa mora pregledati in potrditi drug \u010dlan ekipe. Tako kot pri nadzoru dostopa se te politike uporabljajo tudi za posodobitve deploymentov.<\/li>\n<\/ol>\n

    \nKot vidite, ima metoda GitOps \u0161tevilne prednosti. V preteklem letu sta pridobila posebno priljubljenost dva pristopa. Eden temelji na push, drugi na pull. Preden ju podrobneje obravnavamo, si najprej poglejmo, kako izgledajo tipi\u010dni deploymenti Kubernetes.<\/p>\n

    Sp\u00f4soby nasadenia<\/h2>\n

    \nV uplynul\u00fdch rokoch sa v Kubernetes ust\u00e1lili r\u00f4zne sp\u00f4soby a n\u00e1stroje na nasadenia:<\/p>\n

      \n
    1. Na z\u00e1klade nat\u00edvnych \u0161abl\u00f3n Kubernetes\/Kustomize<\/b>. Toto je najjednoduch\u0161\u00ed sp\u00f4sob nasadzovania aplik\u00e1ci\u00ed v Kubernetes. Developer vytv\u00e1ra z\u00e1kladn\u00e9 YAML s\u00fabory a aplikuje ich. Aby sa zabr\u00e1nilo neust\u00e1lemu prep\u00edsaniu t\u00fdch ist\u00fdch \u0161abl\u00f3n, bol vyvinut\u00fd Kustomize (ten men\u00ed Kubernetes \u0161abl\u00f3ny na moduly). Pozn. prekl.<\/b>: Kustomize bol integrovan\u00fd do kubectl od vydania Kubernetes 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Helm chartov<\/b>. Helm charti omogo\u010dajo ustvarjanje sklopov predlog, init kontejnerjev, sidecarjev itd., ki se uporabljajo za uvajanje aplikacij z bolj fleksibilnimi mo\u017enostmi prilagajanja kot pri pristopu temelje\u010dem na predlogah. Osnovna ideja tega pristopa so predlogi vformatu YAML. Helm v njih vna\u0161a razli\u010dne parametre in jih nato po\u0161ilja Tillerju \u2014 sestavnemu delu klasterja, ki jih uvaja v klaster in omogo\u010da posodobitve in povratne korake. Pomembno je, da Helm v bistvu preprosto vstavi potrebne vrednosti v predloge in jih nato uporabi tako, kot se to po\u010dne v tradicionalnem pristopu (podrobnosti o tom, ako to v\u0161etko funguje a ako to mo\u017eno vyu\u017ei\u0165, n\u00e1jdete v na\u0161ej \u010dl\u00e1nok o Helme<\/a><\/noindex> \u2014 pozn. prekl.)<\/i>. Existuje ve\u013ek\u00e9 mno\u017estvo hotov\u00fdch Helm chartov, ktor\u00e9 pokr\u00fdvaj\u00fa \u0161irok\u00e9 spektrum \u00faloh.<\/li>\n
    3. Alternat\u00edvne n\u00e1stroje<\/b>. Existuje mno\u017estvo alternat\u00edvnych n\u00e1strojov. V\u0161etky sp\u00e1ja to, \u017ee premienia nejak\u00e9 \u0161abl\u00f3nov\u00e9 s\u00fabory na zrozumite\u013en\u00e9 Kubernetes YAML s\u00fabory a n\u00e1sledne ich aplikuj\u00fa.<\/li>\n<\/ol>\n

      \nVo svojej pr\u00e1ci neust\u00e1le pou\u017e\u00edvame Helm chartov\u00e9 s\u00fabory pre d\u00f4le\u017eit\u00e9 n\u00e1stroje (ke\u010f\u017ee v nich je u\u017e ve\u013ea predpripraven\u00e9ho, \u010do zna\u010dne u\u013eah\u010duje \u017eivot) a \u201e\u010dist\u00e9\u201c YAML s\u00fabory Kubernetes na nasadzovanie na\u0161ich vlastn\u00fdch aplik\u00e1ci\u00ed.<\/p>\n

      Pull & Push<\/h2>\n

      \nV jednom zo svojich ned\u00e1vnych pr\u00edspevkov na blogu som predstavil n\u00e1stroj Weave Flux<\/a><\/noindex>, kar omogo\u010da commit predlog v Git repozitorij in posodobitev deploymenta po vsakem commitu ali pushu kontejnerja. Moje izku\u0161nje ka\u017eejo, da je to orodje eno izmed klju\u010dnih pri promociji pull pristopa, zato se bom na to pogosto skliceval. \u010ce \u017eelite izvedeti ve\u010d o tem, kako ga uporabiti, tukaj je odkaz na \u010dl\u00e1nok<\/a><\/noindex>.<\/p>\n

      NB!<\/b> V\u0161etky v\u00fdhody pou\u017e\u00edvania GitOps sa zachov\u00e1vaj\u00fa pre oba pr\u00edstupy.<\/i><\/p>\n

      Pr\u00edstup zalo\u017een\u00fd na Pull<\/h2>\n

      \n\"GitOps:
      \n
      \nZ\u00e1sadou pr\u00edstupu pull je skuto\u010dnos\u0165, \u017ee v\u0161etky zmeny sa aplikuj\u00fa zvn\u00fatra klastra. Vn\u00fatri klastra je oper\u00e1tor, ktor\u00fd pravidelne kontroluje s\u00favisiace repozit\u00e1re Git a Docker Registry. Ak d\u00f4jde k ak\u00fdmko\u013evek zmen\u00e1m, stav klastra sa aktualizuje zo vn\u00fatra. Zvy\u010dajne sa pova\u017euje, \u017ee tak\u00fdto proces je ve\u013emi bezpe\u010dn\u00fd, preto\u017ee \u017eiaden extern\u00fd klient nem\u00e1 pr\u00edstup k pr\u00e1vam spr\u00e1vcu klastra.<\/p>\n

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

        \n
      1. \u017diaden extern\u00fd klient nem\u00e1 pr\u00e1va na vykon\u00e1vanie zmien v klastri, v\u0161etky aktualiz\u00e1cie sa aplikuj\u00fa zvn\u00fatra.<\/li>\n
      2. Niektor\u00e9 n\u00e1stroje tie\u017e umo\u017e\u0148uj\u00fa synchronizova\u0165 aktualiz\u00e1cie Helm grafov a viaza\u0165 ich ku klastru.<\/li>\n
      3. Docker Registry mo\u017eno skenova\u0165 na nov\u00e9 verzie. Ak sa objav\u00ed nov\u00fd obraz, Git repozit\u00e1r a nasadenie sa aktualizuj\u00fa na nov\u00fa verziu.<\/li>\n
      4. N\u00e1stroje pull m\u00f4\u017eu by\u0165 rozdelen\u00e9 do r\u00f4znych priestorov n\u00e1zvov s r\u00f4znymi repozit\u00e1rmi Git a pr\u00edstupov\u00fdmi pr\u00e1vami. V\u010faka tomu je mo\u017en\u00e9 aplikova\u0165 multitenant model. Napr\u00edklad t\u00edm A m\u00f4\u017ee pou\u017e\u00edva\u0165 priestor n\u00e1zvov A, t\u00edm B priestor n\u00e1zvov B a t\u00edm zameran\u00fd na infra\u0161trukt\u00faru m\u00f4\u017ee pou\u017e\u00edva\u0165 glob\u00e1lny priestor.<\/li>\n
      5. Vo v\u0161eobecnosti s\u00fa n\u00e1stroje ve\u013emi \u013eahk\u00e9.<\/li>\n
      6. V kombin\u00e1cii s tak\u00fdmi n\u00e1strojmi, ako je oper\u00e1tor Bitnami Sealed Secrets<\/a><\/noindex>, m\u00f4\u017eu by\u0165 tajomstv\u00e1 uchov\u00e1van\u00e9 za\u0161ifrovan\u00e9 v repozit\u00e1ri Git a extrahovan\u00e9 vo vn\u00fatri klastra.<\/li>\n
      7. Neexistuje \u017eiadne prepojenie s CD pipeline, preto\u017ee nasadenia sa uskuto\u010d\u0148uj\u00fa vo vn\u00fatri klastra.<\/li>\n<\/ol>\n

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

          \n
        1. Spr\u00e1va tajomstiev nasaden\u00ed z Helm grafov je zlo\u017eitej\u0161ia ako be\u017en\u00e1, preto\u017ee ich najprv treba generova\u0165 ako sealed secrets, potom ich de\u0161ifrova\u0165 vn\u00fatorn\u00fdm oper\u00e1torom a a\u017e potom sa stan\u00fa dostupn\u00e9 pre n\u00e1stroj pull. Potom je mo\u017en\u00e9 spusti\u0165 vydanie v Helme so hodnotami u\u017e nasaden\u00fdch tajomstiev. Najjednoduch\u0161\u00ed sp\u00f4sob je vytvori\u0165 tajomstvo so v\u0161etk\u00fdmi hodnotami Helm pou\u017e\u00edvan\u00fdmi na nasadenie, de\u0161ifrova\u0165 ho a commitn\u00fa\u0165 do Gitu.<\/li>\n
        2. Pou\u017eit\u00edm pristupu pull sa st\u00e1vate viazan\u00ed na n\u00e1stroje operuj\u00face s pullmi. To obmedzuje mo\u017enosti prisp\u00f4sobenia procesu nasadenia v klastre. Napr\u00edklad pr\u00e1ca s Kustomize je komplikovan\u00e1 t\u00fdm, \u017ee mus\u00ed by\u0165 vykonan\u00e1 predt\u00fdm, ne\u017e fin\u00e1lne \u0161abl\u00f3ny pr\u00eddu do Gitu. Nechcem poveda\u0165, \u017ee nem\u00f4\u017eete pou\u017e\u00edva\u0165 samostatn\u00e9 n\u00e1stroje, ale ich integr\u00e1cia do procesu nasadenia je zlo\u017eitej\u0161ia.<\/li>\n<\/ol>\n

          <\/p>\n

          Pr\u00edstup zalo\u017een\u00fd na Push<\/h2>\n

          \n\"GitOps:
          \n
          \nV pr\u00edstupe push vonkaj\u0161\u00ed syst\u00e9m (predov\u0161etk\u00fdm CD-pipelines) za\u010d\u00edna nasadzovanie do klastra po commite do Git-repozit\u00e1ra alebo v pr\u00edpade \u00faspe\u0161n\u00e9ho vykonania predch\u00e1dzaj\u00faceho CI-pipeline. V tomto pr\u00edstupe m\u00e1 syst\u00e9m pr\u00edstup do klastra.<\/p>\n

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

            \n
          1. Bezpe\u010dnos\u0165 je ur\u010den\u00e1 Git-repozit\u00e1rom a pipeline na zostavenie.<\/li>\n
          2. Nasadzova\u0165 Helm chart je jednoduch\u0161ie, existuje podpora pre Helmov\u00e9 pluginy.<\/li>\n
          3. Spr\u00e1va tajomstiev je jednoduch\u0161ia, preto\u017ee tajomstv\u00e1 je mo\u017en\u00e9 aplikova\u0165 v pipelines a tie\u017e ich uchov\u00e1va\u0165 v Gite v za\u0161ifrovanej podobe (v z\u00e1vislosti od preferenci\u00ed pou\u017e\u00edvate\u013ea).<\/li>\n
          4. Absencia viazanosti na konkr\u00e9tny n\u00e1stroj, preto\u017ee je mo\u017en\u00e9 pou\u017e\u00edva\u0165 ak\u00e9ko\u013evek ich typy.<\/li>\n
          5. Aktualiz\u00e1cie verzi\u00ed kontajnerov m\u00f4\u017eu by\u0165 iniciovan\u00e9 pipeline na zostavenie.<\/li>\n<\/ol>\n

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

              \n
            1. \u00dadaje na pr\u00edstup do klastra s\u00fa ulo\u017een\u00e9 v syst\u00e9me na zostavenie.<\/li>\n
            2. Aktualizova\u0165 kontajnery nasaden\u00ed je st\u00e1le jednoduch\u0161ie vykon\u00e1va\u0165 pomocou procesu pull.<\/li>\n
            3. Siln\u00e1 z\u00e1vislos\u0165 na CD-syst\u00e9me, preto\u017ee po\u017eadovan\u00e9 pipelines, pravdepodobne, boli p\u00f4vodne nap\u00edsan\u00e9 pre Gitlab Runners a potom sa t\u00edm rozhodne prejs\u0165 na Azure DevOps alebo Jenkins\u2026 a bude potrebn\u00e9 migrova\u0165 ve\u013ek\u00e9 mno\u017estvo pipelines na zostavenie.<\/li>\n<\/ol>\n

              <\/p>\n

              Zhrnutie: Push alebo Pull?<\/h2>\n

              \nAko je zn\u00e1me, ka\u017ed\u00fd pr\u00edstup m\u00e1 svoje v\u00fdhody a nev\u00fdhody. Niektor\u00e9 \u00falohy sa \u013eah\u0161ie realizuj\u00fa jedn\u00fdm sp\u00f4sobom a \u0165a\u017e\u0161ie in\u00fdm. Na za\u010diatku som vykon\u00e1val nasadenia ru\u010dne, ale po tom, \u010do som narazil na nieko\u013eko \u010dl\u00e1nkov o Weave Flux, som sa rozhodol implementova\u0165 procesy GitOps pre v\u0161etky projekty. Pre z\u00e1kladn\u00e9 \u0161abl\u00f3ny to bolo jednoduch\u00e9, ale potom som za\u010dal nar\u00e1\u017ea\u0165 na probl\u00e9my pri pr\u00e1ci s Helm chartami. Vtedy Weave Flux pon\u00fakal len za\u010d\u00ednaj\u00facu verziu Helm Chart Operator, ale aj teraz s\u00fa niektor\u00e9 \u00falohy zlo\u017eit\u00e9 kv\u00f4li potrebe ru\u010dne vytv\u00e1ra\u0165 tajomstv\u00e1 a aplikova\u0165 ich. M\u00f4\u017eete poveda\u0165, \u017ee pr\u00edstup s pullom je ove\u013ea bezpe\u010dnej\u0161\u00ed, preto\u017ee poverenia klastru nie s\u00fa dostupn\u00e9 mimo neho, \u010do zvy\u0161uje bezpe\u010dnos\u0165 do takej miery, \u017ee si to zasl\u00fa\u017ei dodato\u010dn\u00e9 \u00fasilie.<\/p>\n

              Po zamyslen\u00ed som dospel k prekvapiv\u00e9mu z\u00e1veru, \u017ee to nie je tak. Ak hovor\u00edme o komponentoch, ktor\u00e9 vy\u017eaduj\u00fa maxim\u00e1lnu ochranu, do takejto kateg\u00f3rie patr\u00ed \u00falo\u017eisk\u00e1 tajomstiev a CI\/CD syst\u00e9my, Git repozit\u00e1re. Inform\u00e1cie v nich s\u00fa ve\u013emi zranite\u013en\u00e9 a potrebuj\u00fa maxim\u00e1lnu ochranu. Navy\u0161e, ak sa niekto dostane do v\u00e1\u0161ho repozit\u00e1ra Git a bude m\u00f4c\u0165 tam pushova\u0165 k\u00f3d, m\u00f4\u017ee nasadi\u0165 \u010doko\u013evek, \u010do si praje (nez\u00e1visle od toho, \u010di ide o pr\u00edstup pull alebo push), a infiltrova\u0165 sa do syst\u00e9mov klastru. T\u00fdmto sp\u00f4sobom s\u00fa najd\u00f4le\u017eitej\u0161\u00edmi komponentmi, ktor\u00e9 potrebuj\u00fa ochranu, Git repozit\u00e1r a CI\/CD syst\u00e9my, nie prihlasovacie \u00fadaje k klastru. Ak m\u00e1te dobre nastaven\u00e9 politiky a bezpe\u010dnostn\u00e9 opatrenia pre tak\u00e9to syst\u00e9my, a prihlasovacie \u00fadaje k klastru s\u00fa \u0165ahan\u00e9 do pipeline len vo forme tajomstiev, \u010fal\u0161ia bezpe\u010dnos\u0165 pr\u00edstupu pull sa m\u00f4\u017ee uk\u00e1za\u0165 ako menej hodnotn\u00e1, ne\u017e sa p\u00f4vodne predpokladalo.<\/p>\n

              Tak\u017ee ak je pr\u00edstup s pullom pracnej\u0161\u00ed a neprin\u00e1\u0161a \u017eiadne v\u00fdhody v oblasti bezpe\u010dnosti, nie je logick\u00e9 pou\u017e\u00edva\u0165 len pr\u00edstup s pushom? Niekoho v\u0161ak m\u00f4\u017ee napadn\u00fa\u0165, \u017ee pri pr\u00edstupe s pushom ste pr\u00edli\u0161 z\u00e1visl\u00ed na CD syst\u00e9me a mo\u017eno by bolo lep\u0161ie to nerobi\u0165, aby ste v bud\u00facnosti u\u013eah\u010dili migr\u00e1cie.<\/p>\n

              Pod\u013ea m\u00f4jho n\u00e1zoru (ako v\u017edy) by sa malo pou\u017ei\u0165 to, \u010do najlep\u0161ie vyhovuje konkr\u00e9tnej situ\u00e1cii alebo kombinova\u0165 pr\u00edstupy. Osobne pou\u017e\u00edvam oba pr\u00edstupy: Weave Flux pre nasadenia na z\u00e1klade pull, ktor\u00e9 zvy\u010dajne zah\u0155\u0148aj\u00fa na\u0161e vlastn\u00e9 slu\u017eby, a push pr\u00edstup s Helmom a pluginmi, \u010do u\u013eah\u010duje aplik\u00e1ciu Helm chartov na klaster a bez probl\u00e9mov vytv\u00e1ra tajomstv\u00e1. Mysl\u00edm si, \u017ee nikdy nebude jedno univerz\u00e1lne rie\u0161enie, ktor\u00e9 by vyhovovalo ka\u017edej situ\u00e1cii, preto\u017ee nu\u00e1ns je v\u017edy ve\u013ea a z\u00e1visia od konkr\u00e9tneho pr\u00edpadu pou\u017eitia. Z\u00e1rove\u0148 odpor\u00fa\u010dam GitOps \u2014 v\u00fdrazne u\u013eah\u010duje \u017eivot a zvy\u0161uje bezpe\u010dnos\u0165.<\/p>\n

              D\u00fafam, \u017ee moje sk\u00fasenosti v tejto oblasti pom\u00f4\u017eu ur\u010di\u0165, ktor\u00fd pr\u00edstup je najvhodnej\u0161\u00ed pre v\u00e1\u0161 typ nasaden\u00ed, a r\u00e1d by som sa dozvedel v\u00e1\u0161 n\u00e1zor.<\/p>\n

              P.S. Pozn\u00e1mka od prekladate\u013ea<\/h2>\n

              \nV nev\u00fdhod\u00e1ch pull modelu je bod o tom, \u017ee je \u0165a\u017ek\u00e9 ulo\u017ei\u0165 do Gitu odrenderovan\u00e9 manifesty, av\u0161ak nie je uveden\u00e1 nev\u00fdhoda, \u017ee CD pipeline v pull modeli \u017eije oddelene od vyka a vlastne sa st\u00e1va pipeline-om kateg\u00f3rie Continuous Apply<\/i>. Preto bude potrebn\u00e9 vynalo\u017ei\u0165 e\u0161te viac \u00fasilia na to, aby sa zhroma\u017edil stav v\u0161etk\u00fdch nasaden\u00ed a nejako sa poskytol pr\u00edstup k z\u00e1znamom\/stavu, a to ide\u00e1lne s v\u00e4zbou na syst\u00e9m CD.<\/p>\n

              V tomto zmysle push model poskytuje aspo\u0148 nejak\u00e9 z\u00e1ruky pri nasaden\u00ed, preto\u017ee \u017eivotnos\u0165 pipeline sa m\u00f4\u017ee nastavi\u0165 na rovnak\u00fa dobu ako \u017eivotnos\u0165 nasadenia.<\/p>\n

              Otestovali sme obidva modely a dospeli sme k rovnak\u00fdm z\u00e1verom ako autor \u010dl\u00e1nku:<\/p>\n

                \n
              1. Pull model je pre n\u00e1s vhodn\u00fd na organizovanie aktualiz\u00e1cie syst\u00e9mov\u00fdch komponentov na ve\u013ekom po\u010dte klastrov (pozri \u010dl\u00e1nok o addon-operator<\/a><\/noindex>).<\/li>\n
              2. Push model zalo\u017een\u00fd na GitLab CI sa dobre hod\u00ed na nasadenie aplik\u00e1ci\u00ed pomocou Helm chartov. Pri\u010dom nasadenie v r\u00e1mci pipeline sa sleduje pomocou n\u00e1stroja werf<\/a><\/noindex>. Mimochodom, v kontexte tohto n\u00e1\u0161ho projektu sme po\u010duli neust\u00e1le \"GitOps\" pri diskusii o aktu\u00e1lnych probl\u00e9moch DevOps in\u017einierov pri na\u0161om st\u00e1nku na KubeCon Europe \u201919.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.S. od prekladate\u013ea<\/h2>\n

                \nPre\u010d\u00edtajte si tie\u017e na na\u0161om blogu:<\/p>\n