{"id":35941,"date":"2019-10-31T22:07:41","date_gmt":"2019-10-31T19:07:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-zhe-takoe-gitops\/"},"modified":"2019-10-31T22:07:41","modified_gmt":"2019-10-31T19:07:41","slug":"chto-zhe-takoe-gitops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/chto-zhe-takoe-gitops","title":{"rendered":"\u010co je to GitOps?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Pozn. prekl.<\/b>: Po ned\u00e1vnej publik\u00e1cii <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/456754\/\">materi\u00e1lu<\/a><\/noindex> o met\u00f3dach pull a push v GitOps sme zaznamenali z\u00e1ujem o tento model ako celok, av\u0161ak v sloven\u010dine sa objavilo ve\u013emi m\u00e1lo publik\u00e1ci\u00ed na t\u00fato t\u00e9mu (na Habr\u00e9 ich jednoducho niet). Preto sme radi, \u017ee v\u00e1m m\u00f4\u017eeme pon\u00faknu\u0165 preklad in\u00e9ho \u010dl\u00e1nku \u2014 aj ke\u010f u\u017e takmer rok star\u00e9ho! \u2014 od spolo\u010dnosti Weaveworks, ktorej zakladate\u013e vymyslel pojem \u201eGitOps\u201c. V texte je vysvetlen\u00e1 podstata pr\u00edstupu a k\u013e\u00fa\u010dov\u00e9 rozdiely od u\u017e existuj\u00facich.<\/i><\/p>\n<p>\nPred rokom sme publikovali <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-operations-by-pull-request\">\u00favod do GitOps<\/a><\/noindex>. Vtedy sme hovorili, ako t\u00edm Weaveworks spustil SaaS, ktor\u00fd je \u00faplne zalo\u017een\u00fd na Kubernetes, a vyvinul s\u00fabor preskript\u00edvnych osved\u010den\u00fdch prakt\u00edk pre nasadzovanie, spr\u00e1vu a monitorovanie v prostred\u00ed cloud native.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>\u010cl\u00e1nok sa stal popul\u00e1rnym. O GitOps za\u010dali hovori\u0165 in\u00ed, za\u010dali publikova\u0165 nov\u00e9 n\u00e1stroje na <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/hasura\/gitkube\">git push<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/dzone.com\/articles\/weaveworks-gitops-developer-toolkit-part-one-skaff\">v\u00fdvoj<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/storing-secure-sealed-secrets-using-gitops\">tajomstv\u00e1<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.alexellis.io\/introducing-openfaas-cloud\/\">funkci\u00ed<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/jenkins.io\/blog\/2018\/03\/19\/introducing-jenkins-x\/\">nepretr\u017eitej integr\u00e1cie<\/a><\/noindex> a pod. Na na\u0161ich str\u00e1nkach sa objavili <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/category\/gitops\/\">ve\u013ek\u00e9 mno\u017estvo<\/a><\/noindex> publik\u00e1cie a pr\u00edpady pou\u017eitia GitOps. Ale niektor\u00ed \u013eudia mali st\u00e1le ot\u00e1zky. \u010c\u00edm sa model l\u00ed\u0161i od tradi\u010dn\u00fdch <noindex><a rel=\"nofollow\" href=\"https:\/\/puppet.com\/blog\/a-deployment-pipeline-for-infrastructure-a-devops-case-study-at-nbn\">infrastructure as code<\/a><\/noindex> a nepretr\u017eit\u00e9ho dod\u00e1vania (<noindex><a rel=\"nofollow\" href=\"https:\/\/puppet.com\/blog\/a-deployment-pipeline-for-infrastructure-a-devops-case-study-at-nbn\">continuous delivery<\/a><\/noindex>)? Je nutn\u00e9 pou\u017e\u00edva\u0165 Kubernetes?<\/p>\n<p>\u010coskoro sme pochopili, \u017ee je potrebn\u00fd nov\u00fd popis, ktor\u00fd pon\u00fakne:<\/p>\n<ol>\n<li> Ve\u013ea pr\u00edkladov a pr\u00edbehov;<\/li>\n<li> Konkr\u00e9tnu defin\u00edciu GitOps;<\/li>\n<li> Porovnanie s tradi\u010dn\u00fdm nepretr\u017eit\u00fdm dod\u00e1van\u00edm.<\/li>\n<\/ol>\n<p>\nV tomto \u010dl\u00e1nku sme sa pok\u00fasili pokry\u0165 v\u0161etky tieto t\u00e9my. N\u00e1jdete v \u0148om aktualizovan\u00fd \u00favod do GitOps a poh\u013ead na neho z poh\u013eadu v\u00fdvoj\u00e1rov a CI\/CD. S\u00fastred\u00edme sa preva\u017ene na Kubernetes, aj ke\u010f je model mo\u017en\u00e9 celkom zov\u0161eobecni\u0165.<\/p>\n<h2>Zozn\u00e1mte sa: GitOps<\/h2>\n<p>\nPredstavte si Alisu. Riadi spolo\u010dnos\u0165 Family Insurance, ktor\u00e1 pon\u00faka poistn\u00e9 zmluvy na zdravotn\u00e9, automobilov\u00e9, nehnute\u013enostn\u00e9 poistenie a cestovn\u00e9 poistenie pre \u013eud\u00ed, ktor\u00ed s\u00fa pr\u00edli\u0161 zanepr\u00e1zdnen\u00ed, aby sa s detailmi zml\u00fav zaoberali sami. Jej podnikanie sa za\u010d\u00ednalo ako doplnkov\u00fd projekt, ke\u010f Alisa pracovala v banke ako data scientist. Raz si uvedomila, \u017ee m\u00f4\u017ee vyu\u017ei\u0165 pokro\u010dil\u00e9 po\u010d\u00edta\u010dov\u00e9 algoritmy na efekt\u00edvnej\u0161iu anal\u00fdzu \u00fadajov a tvorbu poistn\u00fdch bal\u00edkov. Investori financovali projekt a teraz jej spolo\u010dnos\u0165 generuje viac ako 20 mili\u00f3nov dol\u00e1rov ro\u010dne a r\u00fdchlo rastie. V s\u00fa\u010dasnosti v nej pracuje 180 zamestnancov na r\u00f4znych poz\u00edci\u00e1ch. Medzi nimi je aj technologick\u00fd t\u00edm, ktor\u00fd sa zaober\u00e1 v\u00fdvojom, \u00fadr\u017ebou webovej str\u00e1nky, datab\u00e1zy a anal\u00fdzou z\u00e1kazn\u00edckych \u00fadajov. T\u00edm s 60 \u010dlenmi vedie Bob \u2014 technick\u00fd riadite\u013e spolo\u010dnosti.<\/p>\n<p>Bobov t\u00edm nasadzuje production syst\u00e9my v cloude. Ich hlavn\u00e9 aplik\u00e1cie funguj\u00fa na GKE, pri\u010dom vyu\u017e\u00edvaj\u00fa v\u00fdhody Kubernetes v Google Cloud. Okrem toho pou\u017e\u00edvaj\u00fa r\u00f4zne n\u00e1stroje na pr\u00e1cu s \u00fadajmi a anal\u00fdzu.<\/p>\n<p>Spolo\u010dnos\u0165 Family Insurance nemala v pl\u00e1ne pou\u017e\u00edva\u0165 kontajnery, ale nakazila sa nad\u0161en\u00edm okolo Dockera. \u010coskoro odborn\u00edci zo spolo\u010dnosti zistili, \u017ee GKE umo\u017e\u0148uje nasadzova\u0165 klastre na testovanie nov\u00fdch funkci\u00ed \u013eahko a bez n\u00e1mahy. Pridali Jenkins na CI a Quay na organiz\u00e1ciu registra kontajnerov, nap\u00edsali skripty pre Jenkins, ktor\u00e9 posielali nov\u00e9 kontajnery a konfigur\u00e1cie do GKE.<\/p>\n<p>Pre\u0161lo nejak\u00e9 \u010das. Alena a Bob boli sklaman\u00ed v\u00fdkonom zvolen\u00e9ho pr\u00edstupu a jeho vplyvom na podnikanie. Zavedenie kontajnerov nezv\u00fd\u0161ilo v\u00fdkon tak, ako d\u00fafala t\u00edm. Niekedy sa nasadenia rozpadli a nebolo jasn\u00e9, \u010di s\u00fa za to zmeny k\u00f3du. Takisto sa uk\u00e1zalo by\u0165 \u0165a\u017ek\u00e9 sledova\u0165 zmeny konfigur\u00e1ci\u00ed. \u010casto museli vytvori\u0165 nov\u00fd klaster a presun\u00fa\u0165 do\u0148 aplik\u00e1cie, preto\u017ee takto bolo najjednoduch\u0161ie zlikvidova\u0165 ten neporiadok, do ktor\u00e9ho sa syst\u00e9m zmenil. Alena sa ob\u00e1vala, \u017ee sa situ\u00e1cia zhor\u0161\u00ed, ke\u010f sa aplik\u00e1cia vyvinie (okrem toho sa bl\u00ed\u017eil nov\u00fd projekt zalo\u017een\u00fd na strojovom u\u010den\u00ed). Bob automatizoval v\u00e4\u010d\u0161inu pr\u00e1ce a nech\u00e1pal, pre\u010do je pipeline st\u00e1le nestabiln\u00e1, zle sa \u0161k\u00e1luje a ob\u010das si vy\u017eaduje manu\u00e1lne z\u00e1sahy?<\/p>\n<p><b>Potom sa dozvedeli o GitOps. Toto rie\u0161enie sa uk\u00e1zalo by\u0165 presne to, \u010do potrebovali na sebavedom\u00fd postup vpred.<\/b><\/p>\n<p>Alisa a Bob u\u017e nieko\u013eko rokov po\u010duli o pracovn\u00fdch postupoch zalo\u017een\u00fdch na Gite, DevOps a infra\u0161trukt\u00fare ako k\u00f3de. V\u00fdnimo\u010dnos\u0165 GitOps spo\u010d\u00edva v tom, \u017ee prin\u00e1\u0161a mno\u017estvo osved\u010den\u00fdch prakt\u00edk \u2014 kategorizovan\u00fdch a normat\u00edvnych \u2014 na implement\u00e1ciu t\u00fdchto ide\u00ed v kontexte Kubernetes. Toto t\u00e9mu <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/search?q=gitops&amp;src=typd\">neust\u00e1le zd\u00f4raz\u0148ovali<\/a><\/noindex>, vr\u00e1tane <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-high-velocity-cicd-for-kubernetes\">blogu Weaveworks<\/a><\/noindex>.<\/p>\n<p>Rodinn\u00e1 pois\u0165ov\u0148a rozhodla zavies\u0165 GitOps. Teraz m\u00e1 spolo\u010dnos\u0165 automatizovan\u00fd prev\u00e1dzkov\u00fd model, ktor\u00fd je kompatibiln\u00fd s Kubernetes a kombinuj\u00faci <i>r\u00fdchlos\u0165<\/i> so <i>stabilitou<\/i>, preto\u017ee:<\/p>\n<ul>\n<li> zistili, \u017ee produktivita t\u00edmu sa zdvojn\u00e1sobila a nikto pritom nezo\u0161alie;<\/li>\n<li> prestali spravova\u0165 skripty. Namiesto toho sa teraz m\u00f4\u017eu s\u00fastredi\u0165 na nov\u00e9 funkcie a zdokona\u013eova\u0165 in\u017einierske met\u00f3dy \u2014 napr\u00edklad zavies\u0165 kan\u00e1rske release a zlep\u0161i\u0165 testovanie;<\/li>\n<li> vylep\u0161ili proces nasadzovania \u2014 teraz zriedka zlyh\u00e1va;<\/li>\n<li> mohli obnovova\u0165 nasadenia po \u010diasto\u010dn\u00fdch zlyhaniach bez manu\u00e1lneho z\u00e1sahu;<\/li>\n<li> z\u00edskali v\u00e4\u010d\u0161iu istotu v dod\u00e1vkov\u00fdch syst\u00e9moch. Alisa a Bob zistili, \u017ee t\u00edm m\u00f4\u017eu rozdeli\u0165 na skupiny, ktor\u00e9 sa venuj\u00fa mikroslu\u017eb\u00e1m a pracuj\u00fa paralelne;<i>o<\/i>m\u00f4\u017eu prida\u0165 30-50 zmien do projektu ka\u017ed\u00fd de\u0148 \u00fasil\u00edm ka\u017edej skupiny a vysk\u00fa\u0161a\u0165 nov\u00e9 techniky;<\/li>\n<li> m\u00f4\u017eu vykona\u0165 30-50 zmien v projekte ka\u017ed\u00fd de\u0148 \u00fasil\u00edm jednotliv\u00fdch skup\u00edn a sk\u00fa\u0161a\u0165 nov\u00e9 techniky;<\/li>\n<li> \u013eahko pril\u00e1kaj\u00fa do projektu nov\u00fdch v\u00fdvoj\u00e1rov, ktor\u00ed maj\u00fa mo\u017enos\u0165 nasadi\u0165 aktualiz\u00e1cie na produkciu prostredn\u00edctvom pull requestov u\u017e za nieko\u013eko hod\u00edn;<\/li>\n<li> \u013eahko prech\u00e1dzaj\u00fa auditom v r\u00e1mci SOC2 <i>(na s\u00falad poskytovate\u013eov slu\u017eieb s po\u017eiadavkami na bezpe\u010dn\u00e9 riadenie \u00fadajov; viac si pre\u010d\u00edtajte napr\u00edklad, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.imperva.com\/learn\/data-security\/soc-2-compliance\/\">tu<\/a><\/noindex> \u2014 pozn. prekl.)<\/i>.<\/li>\n<\/ul>\n<p><\/p>\n<h3>\u010co sa stalo?<\/h3>\n<p>\nGitOps \u2014 to s\u00fa dve veci:<\/p>\n<ol>\n<li> Model prev\u00e1dzky pre Kubernetes a cloud native. Poskytuje s\u00fabor osved\u010den\u00fdch prakt\u00edk pre nasadenie, spr\u00e1vu a monitorovanie klastrov a aplik\u00e1ci\u00ed zabalen\u00fdch v kontajneroch. Elegantn\u00e9 definovanie vo forme <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/vitorsilva\/status\/999978906903080961\">jedn\u00e9ho sn\u00edmku<\/a><\/noindex> od <noindex><a rel=\"nofollow\" href=\"https:\/\/2018.agilept.org\/speaker_luis_faceira.html\">Luis Faceira<\/a><\/noindex>:\n<\/li>\n<li> Cesta k vytvoreniu prostredia orientovan\u00e9ho na v\u00fdvoj\u00e1rov na spr\u00e1vu aplik\u00e1ci\u00ed. Pou\u017e\u00edvame pracovn\u00fd tok Git ako pre prev\u00e1dzku, tak aj pre v\u00fdvoj. Upozor\u0148ujeme, \u017ee sa nejedn\u00e1 len o Git push, ale o organiz\u00e1ciu cel\u00e9ho s\u00faboru n\u00e1strojov CI\/CD a UI\/UX.<\/li>\n<\/ol>\n<p><\/p>\n<h3>P\u00e1r slov o Gite<\/h3>\n<p>\nAk nie ste obozn\u00e1men\u00ed so syst\u00e9mami spr\u00e1vy verzi\u00ed a pracovn\u00fdm procesom zalo\u017een\u00fdm na Gite, d\u00f4razne odpor\u00fa\u010dame ich \u0161t\u00fadium. Z po\u010diatku m\u00f4\u017ee pr\u00e1ca s vetvami a pull requestami vyzera\u0165 ako \u010dierna m\u00e1gia, ale v\u00fdhody stoja za vynalo\u017een\u00e9 \u00fasilie. Tu je <noindex><a rel=\"nofollow\" href=\"https:\/\/codeburst.io\/trunk-based-development-vs-git-flow-a0212a6cae64\">dobr\u00fd \u010dl\u00e1nok<\/a><\/noindex> na za\u010diatok.<\/p>\n<h2>Ako funguje Kubernetes<\/h2>\n<p>\nV na\u0161om pr\u00edbehu Ali\u0161 a Bob sa obr\u00e1tili na GitOps po nieko\u013ek\u00fdch mesiacoch pr\u00e1ce s Kubernetes. Naozaj, GitOps \u00fazko s\u00favis\u00ed s Kubernetes \u2014 je to model prev\u00e1dzky pre infra\u0161trukt\u00faru a aplik\u00e1cie zalo\u017een\u00e9 na Kubernetes.<\/p>\n<h3>\u010co Kubernetes pon\u00faka pou\u017e\u00edvate\u013eom?<\/h3>\n<p>\nTu s\u00fa niektor\u00e9 z\u00e1kladn\u00e9 mo\u017enosti:<\/p>\n<ol>\n<li> V modeli Kubernetes je mo\u017en\u00e9 v\u0161etko pop\u00edsa\u0165 v deklarat\u00edvnej forme.<\/li>\n<li> API server Kubernetes prij\u00edma t\u00fato deklar\u00e1ciu ako vstupn\u00e9 \u00fadaje a neust\u00e1le sa sna\u017e\u00ed privies\u0165 klaster do stavu, ktor\u00fd je pop\u00edsan\u00fd v deklar\u00e1cii.<\/li>\n<li> Deklar\u00e1cie s\u00fa dostato\u010dn\u00e9 na to, aby pop\u00edsali a spravovali \u0161irok\u00e9 spektrum pracovn\u00fdch za\u0165a\u017een\u00ed \u2014 'aplik\u00e1ci\u00ed'.<\/li>\n<li> V d\u00f4sledku toho, zmeny v aplik\u00e1cii a klastri nast\u00e1vaj\u00fa z d\u00f4vodu:\n<ul>\n<li> zmien vo vzoroch kontajnerov;<\/li>\n<li> zmien v deklarat\u00edvnej \u0161pecifik\u00e1cii;<\/li>\n<li> ch\u00fdb v prostred\u00ed \u2014 napr\u00edklad, p\u00e1d kontajnerov.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p><\/p>\n<h3>\u00da\u017easn\u00e9 schopnosti Kubernetes v oblasti konvergencie<\/h3>\n<p>\nKe\u010f administr\u00e1tor vykon\u00e1 zmeny v konfigur\u00e1cii, orchestr\u00e1tor Kubernetes ich bude aplikova\u0165 na klaster, k\u00fdm jeho stav <i>sa nepribl\u00ed\u017ei k novej konfigur\u00e1cii<\/i>. Tento model funguje pre ak\u00fdko\u013evek zdroj Kubernetes a roz\u0161\u00edri sa pomocou Custom Resource Definitions (CRDs). Preto maj\u00fa nasadenia Kubernetes nasleduj\u00face \u00fa\u017easn\u00e9 vlastnosti:<\/p>\n<ul>\n<li> <b>Automatiz\u00e1cia<\/b>: aktualiz\u00e1cie Kubernetes poskytuj\u00fa mechanizmus na automatiz\u00e1ciu procesu aplikovania zmien spr\u00e1vne a v\u010das.<\/li>\n<li> <b>Konvergencia<\/b>: Kubernetes sa bude neust\u00e1le sna\u017ei\u0165 o aktualiz\u00e1cie, a\u017e k\u00fdm nedosiahne \u00faspech.<\/li>\n<li> <b>Idempotencia<\/b>: opakovan\u00e9 aplik\u00e1cie konvergencie ved\u00fa k rovnak\u00e9mu v\u00fdsledku.<\/li>\n<li> <b>Determinizmus<\/b>: pri dostato\u010dnosti zdrojov z\u00e1vis\u00ed stav aktualizovan\u00e9ho klastra len od po\u017eadovan\u00e9ho stavu.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Ako funguje GitOps<\/h2>\n<p>\nDoteraz sme sa dozvedeli dos\u0165 o Kubernetes, aby sme mohli vysvetli\u0165 z\u00e1sady fungovania GitOps.<\/p>\n<p>Vr\u00e1\u0165me sa k t\u00edmom Family Insurance, ktor\u00e9 s\u00favisia s mikroslu\u017ebami. \u010c\u00edm sa obvykle zaoberaj\u00fa? Pozrite si zoznam ni\u017e\u0161ie (ak sa v\u00e1m v \u0148om nie\u010do zd\u00e1 divn\u00e9 alebo nezn\u00e1me \u2014 pros\u00edm, po\u010dkajte s kritikou a zosta\u0148te s nami). Toto s\u00fa iba pr\u00edklady pracovn\u00fdch procesov zalo\u017een\u00fdch na Jenkinse. Existuje aj mno\u017estvo \u010fal\u0161\u00edch procesov pri pr\u00e1ci s in\u00fdmi n\u00e1strojmi.<\/p>\n<p>Hlavn\u00e9 je, \u017ee vid\u00edme, \u017ee ka\u017ed\u00e1 aktualiz\u00e1cia kon\u010d\u00ed zmenou v konfigura\u010dn\u00fdch s\u00faboroch a repozit\u00e1roch Git. Tieto zmeny v Gite ved\u00fa k tomu, \u017ee \u201eGitOps oper\u00e1tor\u201c aktualizuje klaster:<\/p>\n<p>1. Pracovn\u00fd proces: \u201e<i>Jenkins build \u2014 vetva master<\/i>\u00bb.<br \/>\nZoznam \u00faloh:<\/p>\n<ul>\n<li> Jenkins posiela ozna\u010den\u00e9 obr\u00e1zky do Quay;<\/li>\n<li> Jenkins posiela konfigur\u00e1ciu a Helm diagramy do bucketu master \u00falo\u017eiska;<\/li>\n<li> Cloudov\u00e1 funkcia kop\u00edruje konfigur\u00e1ciu a grafy z bucketu master \u00falo\u017eiska do Git repozit\u00e1ra master;<\/li>\n<li> GitOps oper\u00e1tor aktualizuje klaster.<\/li>\n<\/ul>\n<p>\n2. <i>Jenkins build \u2014 vetva release alebo hotfix<\/i>:<\/p>\n<ul>\n<li> Jenkins posiela neozna\u010den\u00e9 obr\u00e1zky do Quay;<\/li>\n<li> Jenkins posiela konfigur\u00e1ciu a Helm diagramy do bucketu staging \u00falo\u017eiska;<\/li>\n<li> Cloudov\u00e1 funkcia kop\u00edruje konfigur\u00e1ciu a grafy z bucketu staging \u00falo\u017eiska do Git repozit\u00e1ra staging;<\/li>\n<li> GitOps oper\u00e1tor aktualizuje klaster.<\/li>\n<\/ul>\n<p>\n3. <i>Jenkins build \u2014 vetva develop alebo feature<\/i>:<\/p>\n<ul>\n<li> Jenkins posiela neozna\u010den\u00e9 obr\u00e1zky do Quay;<\/li>\n<li> Jenkins posiela konfigur\u00e1ciu a Helm diagramy do bucketu develop \u00falo\u017eiska;<\/li>\n<li> Cloudov\u00e1 funkcia kop\u00edruje konfigur\u00e1ciu a grafy z bucketu develop \u00falo\u017eiska do Git repozit\u00e1ra develop;<\/li>\n<li>GitOps oper\u00e1tor aktualizuje klaster.<\/li>\n<\/ul>\n<p>\n4. <i>Pridanie nov\u00e9ho klienta<\/i>:<\/p>\n<ul>\n<li> Mana\u017e\u00e9r alebo administr\u00e1tor (LCM\/ops) sp\u00fa\u0161\u0165a Gradle na prvotn\u00e9 nasadenie a konfigur\u00e1ciu sie\u0165ov\u00fdch vyva\u017eova\u010dov za\u0165a\u017eenia (NLB);<\/li>\n<li> LCM\/ops odosiela nov\u00fa konfigur\u00e1ciu na pr\u00edpravu nasadenia na aktualiz\u00e1cie;<\/li>\n<li> GitOps oper\u00e1tor aktualizuje klaster.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Kr\u00e1tky popis GitOps<\/h3>\n<p><\/p>\n<ol>\n<li> Pop\u00ed\u0161te po\u017eadovan\u00fd stav celej s\u00fastavy, pomocou deklarat\u00edvnych \u0161pecifik\u00e1ci\u00ed pre ka\u017ed\u00e9 prostredie (v na\u0161om pr\u00edbehu t\u00edm Boba definuje cel\u00fa konfigur\u00e1ciu syst\u00e9mu v Gite).\n<ul>\n<li> Git repozit\u00e1r je jedin\u00fdm zdrojom pravdy o po\u017eadovanom stave celej s\u00fastavy.<\/li>\n<li> V\u0161etky zmeny v po\u017eadovanom stave sa realizuj\u00fa prostredn\u00edctvom commitov v Gite.<\/li>\n<li> V\u0161etky po\u017eadovan\u00e9 parametre klastra s\u00fa tie\u017e vidite\u013en\u00e9 v samotnom klastri. Takto m\u00f4\u017eeme ur\u010di\u0165, \u010di sa po\u017eadovan\u00fd a pozorovan\u00fd stav zhoduj\u00fa (konverguj\u00fa, <i>converge<\/i>) alebo sa l\u00ed\u0161ia (diverguj\u00fa, <i>diverge<\/i>) od po\u017eadovan\u00e9ho a pozorovan\u00e9ho stavu.<\/li>\n<\/ul>\n<\/li>\n<li> Ak sa po\u017eadovan\u00fd a pozorovan\u00fd stav l\u00ed\u0161ia,\n<ul>\n<li> existuje mechanizmus konvergencie, ktor\u00fd sk\u00f4r \u010di nesk\u00f4r automaticky synchronizuje cie\u013eov\u00fd a pozorovan\u00fd stav. V r\u00e1mci klastra sa o to star\u00e1 Kubernetes.<\/li>\n<li> Proces sa spust\u00ed okam\u017eite s upozornen\u00edm \u201echange committed\u201c.<\/li>\n<li> Po ur\u010ditom nastavite\u013enom \u010dasovom intervale m\u00f4\u017ee by\u0165 zaslan\u00e9 upozornenie \u201ediff\u201c, ak sa stavy l\u00ed\u0161ia.<\/li>\n<\/ul>\n<\/li>\n<li> Tak\u017ee v\u0161etky commity v Gite sp\u00f4sobuj\u00fa kontrolovate\u013en\u00e9 a idempotentn\u00e9 aktualiz\u00e1cie v klastri.\n<ul>\n<li>Rollback je konvergencia k predch\u00e1dzaj\u00facemu po\u017eadovan\u00e9mu stavu.<\/li>\n<\/ul>\n<\/li>\n<li> Konvergencia je kone\u010dn\u00e1. O jej nast\u00fapen\u00ed sved\u010dia:\n<ul>\n<li> Absencia upozornen\u00ed \u201ediff\u201c po ur\u010ditom \u010dasovom obdob\u00ed.<\/li>\n<li> Upozornenie \u201econverged\u201c (napr\u00edklad webhook, udalos\u0165 Git writeback).<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p><\/p>\n<h3>\u010co je to divergencia?<\/h3>\n<p>\nOpakujme e\u0161te raz: <i>v\u0161etky po\u017eadovan\u00e9 vlastnosti klastra musia by\u0165 vidite\u013en\u00e9 v samotnom klastri.<\/i>.<\/p>\n<p>Nieko\u013eko pr\u00edkladov divergencie:<\/p>\n<ul>\n<li> Zmena v konfigura\u010dnom s\u00fabore v d\u00f4sledku zl\u00fa\u010denia vetiev v Gite.<\/li>\n<li> Zmena v konfigura\u010dnom s\u00fabore v d\u00f4sledku commitu v Gite, ktor\u00fd vykonal GUI klient.<\/li>\n<li> Viacer\u00e9 zmeny v po\u017eadovanom stave v d\u00f4sledku PR v Gite s n\u00e1slednou kompil\u00e1ciou obrazu kontajnera a zmenami v konfigur\u00e1cii.<\/li>\n<li> Zmena stavu klastra v d\u00f4sledku chyby, konfliktu zdrojov, ved\u00faceho k \u201ezl\u00e9mu spr\u00e1vaniu\u201c, alebo jednoducho n\u00e1hodn\u00e9mu odklonu od p\u00f4vodn\u00e9ho stavu.<\/li>\n<\/ul>\n<p><\/p>\n<h3>\u010co zah\u0155\u0148a mechanizmus konvergencie?<\/h3>\n<p>\nNieko\u013eko pr\u00edkladov:<\/p>\n<ul>\n<li> Pre kontajnery a klastry mechanizmus konvergencie poskytuje Kubernetes.<\/li>\n<li> Ten ist\u00fd mechanizmus sa d\u00e1 pou\u017ei\u0165 na spr\u00e1vu aplik\u00e1ci\u00ed a kon\u0161trukci\u00ed zalo\u017een\u00fdch na Kubernetes (napr\u00edklad Istio a Kubeflow).<\/li>\n<li> Mechanizmus na riadenie pracovnej interakcie medzi Kubernetes, repozit\u00e1rmi obrazov a Gitom poskytuje <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/weaveworks\/flux\">GitOps oper\u00e1tor Weave Flux<\/a><\/noindex>, ktor\u00fd je s\u00fa\u010das\u0165ou <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.weave.works\/\">Weave Cloud<\/a><\/noindex>.<\/li>\n<li> Pre z\u00e1kladn\u00e9 stroje mus\u00ed by\u0165 mechanizmus konvergencie deklarat\u00edvny a auton\u00f3mny. Na z\u00e1klade na\u0161ich sk\u00fasenost\u00ed m\u00f4\u017eeme poveda\u0165, \u017ee <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.gruntwork.io\/why-we-use-terraform-and-not-chef-puppet-ansible-saltstack-or-cloudformation-7989dad2865c\">Terraform<\/a><\/noindex> je najbli\u017e\u0161ie k tomuto definovaniu, av\u0161ak st\u00e1le vy\u017eaduje kontrolu zo strany \u010dloveka. V tomto zmysle GitOps roz\u0161iruje trad\u00edcie Infrastructure as Code.<\/li>\n<\/ul>\n<p>\nGitOps sp\u00e1ja Git s vynikaj\u00facim mechanizmom konvergencie Kubernetes a pon\u00faka model pre prev\u00e1dzku.<\/p>\n<p>GitOps n\u00e1m umo\u017e\u0148uje poveda\u0165: <i>automatis\u00e1ci\u00ed a kontrole podliehaj\u00fa iba tie syst\u00e9my, ktor\u00e9 je mo\u017en\u00e9 opisova\u0165 a monitorova\u0165<\/i>.<\/p>\n<h3>GitOps je ur\u010den\u00fd pre cel\u00fd cloud native stack (napr\u00edklad Terraform a podobne)<\/h3>\n<p>\nGitOps nie je len Kubernetes. Chceme, aby cel\u00fd syst\u00e9m bol spravovan\u00fd deklarat\u00edvne a pou\u017e\u00edval konvergenciu. Pod cel\u00fdm syst\u00e9mom rozumieme s\u00fabor prostred\u00ed pracuj\u00facich s Kubernetes - napr\u00edklad \u201edev cluster 1\u201c, \u201eproduction\u201c a pod. Ka\u017ed\u00e9 prostredie zah\u0155\u0148a stroje, klastry, aplik\u00e1cie a tie\u017e rozhrania pre vonkaj\u0161ie slu\u017eby, ktor\u00e9 zabezpe\u010duj\u00fa d\u00e1ta, monitorovanie a podobne.<\/p>\n<p>V\u0161imnite si, ak\u00fa d\u00f4le\u017eit\u00fa \u00falohu zohr\u00e1va Terraform pri probl\u00e9me bootstrappingu. Kubernetes mus\u00ed by\u0165 niekde nasaden\u00fd a pou\u017e\u00edvanie Terraformu znamen\u00e1, \u017ee m\u00f4\u017eeme aplikova\u0165 tie ist\u00e9 pracovn\u00e9 postupy GitOps na vytvorenie riadiacej vrstvy, ktor\u00e1 le\u017e\u00ed na z\u00e1klade Kubernetes a aplik\u00e1ci\u00ed. To je u\u017eito\u010dn\u00e1 osved\u010den\u00e1 prax.<\/p>\n<p>Ve\u013ek\u00e1 pozornos\u0165 sa venuje aplik\u00e1cii konceptov GitOps na vrstvy nad Kubernetes. V s\u00fa\u010dasnosti existuj\u00fa GitOps rie\u0161enia pre Istio, Helm, Ksonnet, OpenFaaS a Kubeflow, ako aj pre Pulumi, ktor\u00e9 vytv\u00e1raj\u00fa vrstvu pre v\u00fdvoj aplik\u00e1ci\u00ed pod cloud native.<\/p>\n<h2>Kubernetes CI\/CD: porovnanie GitOps s in\u00fdmi pr\u00edstupmi<\/h2>\n<p>\nAko sme u\u017e spom\u00ednali, GitOps s\u00fa dve veci:<\/p>\n<ol>\n<li> Model prev\u00e1dzky pre Kubernetes a cloud native, ktor\u00fd je pop\u00edsan\u00fd vy\u0161\u0161ie.<\/li>\n<li> Cesta k organiz\u00e1cii zameranej na v\u00fdvoj\u00e1rov pre spr\u00e1vu aplik\u00e1ci\u00ed.<\/li>\n<\/ol>\n<p>\nPre mnoh\u00fdch je GitOps predov\u0161etk\u00fdm pracovn\u00fd proces zalo\u017een\u00fd na Git push. N\u00e1m sa to tie\u017e p\u00e1\u010di. Ale to nie je v\u0161etko: pozrime sa teraz na CI\/CD pipeline.<\/p>\n<h3>GitOps zabezpe\u010duje kontinu\u00e1lne nasadzovanie (CD) pod Kubernetes<\/h3>\n<p>\nGitOps pon\u00faka mechanizmus kontinu\u00e1lneho nasadzovania, ktor\u00fd odstra\u0148uje potrebu samostatn\u00fdch \"syst\u00e9mov spr\u00e1vy nasadzovania\". Cel\u00fa pr\u00e1cu za v\u00e1s vykon\u00e1va Kubernetes.<\/p>\n<ul>\n<li> Aktualiz\u00e1cia aplik\u00e1cie si vy\u017eaduje aktualiz\u00e1ciu v Gite. To je transak\u010dn\u00e1 aktualiz\u00e1cia do po\u017eadovan\u00e9ho stavu. 'Nasadenie' sa potom vykon\u00e1va vo vn\u00fatri klasteru samotn\u00fdm Kubernetes na z\u00e1klade aktualizovan\u00e9ho opisu.<\/li>\n<li> Z d\u00f4vodu \u0161pecif\u00edk fungovania Kubernetes s\u00fa tieto aktualiz\u00e1cie konvergentn\u00e9. Zabezpe\u010duje sa tak mechanizmus pre kontinu\u00e1lne nasadenie, v ktorom s\u00fa v\u0161etky aktualiz\u00e1cie atom\u00e1rne.<\/li>\n<li> Pozn\u00e1mka: <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.weave.works\/\">Weave Cloud<\/a><\/noindex> pon\u00faka GitOps-operator, ktor\u00fd integruje Git a Kubernetes a umo\u017e\u0148uje realizova\u0165 CD pomocou zladenia po\u017eadovan\u00e9ho a aktu\u00e1lneho stavu klasteru.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Bez kubectl a skriptov<\/h3>\n<p>\nJe potrebn\u00e9 sa vyhn\u00fa\u0165 pou\u017e\u00edvaniu Kubectl na aktualiz\u00e1ciu klasteru, a najm\u00e4 skriptom na zoskupovanie pr\u00edkazov kubectl. Namiesto toho m\u00f4\u017ee pou\u017e\u00edvate\u013e aktualizova\u0165 svoj klaster Kubernetes prostredn\u00edctvom GitOps-pipeline.<\/p>\n<p>V\u00fdhody zah\u0155\u0148aj\u00fa:<\/p>\n<ol>\n<li> <b>Spr\u00e1vnos\u0165<\/b>. M\u00f4\u017eeme aplikova\u0165 skupinu aktualiz\u00e1ci\u00ed, konvergova\u0165 ich a nakoniec validova\u0165, \u010do n\u00e1s pribli\u017euje k cie\u013eu atom\u00e1rneho nasadenia. Naopak, pou\u017eitie skriptov neposkytuje \u017eiadne z\u00e1ruky konvergencie (viac o tom ni\u017e\u0161ie).<\/li>\n<li> <b>Bezpe\u010dnos\u0165<\/b>. <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/kelseyhightower\/status\/939003832805179392?lang=en\">Cituj\u00fac<\/a><\/noindex> Kelsey Hightower: \u201eObmedzte pr\u00edstup ku klasteru Kubernetes automatiza\u010dn\u00fdm n\u00e1strojom a administr\u00e1torom, ktor\u00fdch \u00falohou je jeho ladenie alebo udr\u017eiavanie prev\u00e1dzky\u201c. Pozri tie\u017e <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-compliance-and-secure-cicd\">moju publik\u00e1ciu<\/a><\/noindex> o bezpe\u010dnosti a dodr\u017eiavan\u00ed technick\u00fdch podmienok, ako aj <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@vesirin\/how-i-gained-commit-access-to-homebrew-in-30-minutes-2ae314df03ab\">\u010dl\u00e1nok o hackovan\u00ed Homebrew<\/a><\/noindex> prostredn\u00edctvom kr\u00e1de\u017ee prihlasovac\u00edch \u00fadajov z neprimerane zostaven\u00e9ho Jenkins-skriptu.<\/li>\n<li> <b>Pou\u017e\u00edvate\u013esk\u00e1 sk\u00fasenos\u0165<\/b>. Kubectl odha\u013euje mechaniku objektov\u00e9ho modelu Kubernetes, ktor\u00fd je ve\u013emi zlo\u017eit\u00fd. Ide\u00e1lne by bolo, aby pou\u017e\u00edvatelia interagovali so syst\u00e9mom na vy\u0161\u0161ej \u00farovni abstrakcie. Tu sa op\u00e4\u0165 odvol\u00e1vam na Kelseyho a odpor\u00fa\u010dam pozrie\u0165 <noindex><a rel=\"nofollow\" href=\"http:\/\/superuser.openstack.org\/articles\/kubernetes-boring\/\">tak\u00e9to zhrnutie<\/a><\/noindex>.<\/li>\n<\/ol>\n<p><\/p>\n<h3>Rozdiel medzi CI a CD<\/h3>\n<p>\nGitOps zlep\u0161uje existuj\u00face CI\/CD modely.<\/p>\n<p>Modern\u00fd CI server je n\u00e1stroj na orchestr\u00e1ciu. Konkr\u00e9tne je to n\u00e1stroj na orchestr\u00e1ciu CI pipeline. Tieto obsahuj\u00fa build, test, merge to trunk a pod. CI servery automatizuj\u00fa spr\u00e1vu zlo\u017eit\u00fdch viacstup\u0148ov\u00fdch pipeline. Be\u017en\u00e1 n\u00e1straha spo\u010d\u00edva v tom, aby sa vytvoril skript na s\u00fabor aktualiz\u00e1ci\u00ed Kubernetes a vykonal sa ako s\u00fa\u010das\u0165 pipeline na push zmien do klasteru. Skuto\u010dne, mnoh\u00ed odborn\u00edci to robia. Av\u0161ak, to nie je optim\u00e1lne, a tu je d\u00f4vod.<\/p>\n<p>CI by mala by\u0165 pou\u017eit\u00e1 na aktualiz\u00e1cie trunku a Kubernetes klaster by sa mal na z\u00e1klade t\u00fdchto aktualiz\u00e1ci\u00ed samo\u010dinne menil na riadenie CD \"intern\u00e9\". Naz\u00fdvame to <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-compliance-and-secure-cicd\">modelom pull pre CD<\/a><\/noindex>, na rozdiel od modelu push CI. CD je s\u00fa\u010das\u0165ou <i>runtime-orchestr\u00e1cie<\/i>.<\/p>\n<h3>Pre\u010do by CI servery nemali vykon\u00e1va\u0165 CD prostredn\u00edctvom priameho aktualizovania v Kubernetes<\/h3>\n<p>\n<i>Nepou\u017e\u00edvajte CI server na orchestr\u00e1ciu priamych aktualiz\u00e1ci\u00ed v Kubernetes vo forme CI \u00faloh. To je anti-pattern, o ktorom sme <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/kubernetes-anti-patterns-let-s-do-gitops-not-ciops\">u\u017e p\u00edsali<\/a><\/noindex> na na\u0161om blogu.<\/i><\/p>\n<p>Vr\u00e1\u0165me sa k Alice a Bobovi.<\/p>\n<p>S ak\u00fdmi probl\u00e9mami sa stretli? CI server Boba aplikuje zmeny na klaster, ale ak by po\u010das toho zlyhal, Bob nebude vedie\u0165, v akom stave sa klaster nach\u00e1dza (alebo by mal by\u0165) a ako ho opravi\u0165. To ist\u00e9 plat\u00ed aj v pr\u00edpade \u00faspechu.<\/p>\n<p>Predpokladajme, \u017ee Bobov t\u00edm vytvoril nov\u00fd obraz a potom upravil svoje nasadenia (v\u0161etko to z CI pipeline), aby nasadil obraz.<\/p>\n<p>Ak sa obraz spr\u00e1vne zostav\u00ed, ale pipeline zlyh\u00e1, t\u00edm bude musie\u0165 zisti\u0165:<\/p>\n<ul>\n<li> Bolo nasaden\u00e9 aktualizovanie?<\/li>\n<li> Sp\u00fa\u0161\u0165ame nov\u00fa zostavu? Privedie to k zbyto\u010dn\u00fdm ved\u013eaj\u0161\u00edm \u00fa\u010dinkom \u2013 so mo\u017enos\u0165ou ma\u0165 dve zostavy toho ist\u00e9ho nemenn\u00e9ho obrazu? <\/li>\n<li> M\u00e1me po\u010dka\u0165 na \u010fal\u0161iu aktualiz\u00e1ciu predt\u00fdm, ako spust\u00edme zostavu?<\/li>\n<li> \u010co presne sa pokazilo? Ak\u00e9 kroky treba zopakova\u0165 (a ktor\u00e9 z nich je bezpe\u010dn\u00e9 opakova\u0165)?<\/li>\n<\/ul>\n<p>\n<i>Organizovanie pracovn\u00e9ho postupu zalo\u017een\u00e9ho na Git neznamen\u00e1, \u017ee Bobov t\u00edm sa nestretne s t\u00fdmito probl\u00e9mami. M\u00f4\u017eu sa st\u00e1le pom\u00fdli\u0165 s pushom commitu, s tagom alebo in\u00fdm parametrom; av\u0161ak tento pr\u00edstup je st\u00e1le omnoho bli\u017e\u0161ie k jasnej koncepcii v\u0161etko alebo ni\u010d.<\/i><\/p>\n<p>Zhrnutie, pre\u010do by CI servery nemali rie\u0161i\u0165 CD:<\/p>\n<ul>\n<li> Aktualiza\u010dn\u00e9 skripty nie s\u00fa v\u017edy deterministick\u00e9; \u013eahko sa v nich robia chyby.<\/li>\n<li> CI servery neprech\u00e1dzaj\u00fa k deklarat\u00edvnemu modelu klastru.<\/li>\n<li> Je \u0165a\u017ek\u00e9 zabezpe\u010di\u0165 idempotentnos\u0165. Pou\u017e\u00edvatelia musia rozumie\u0165 hlbokej semantike syst\u00e9mu.<\/li>\n<li> Obnovenie po \u010diasto\u010dnom zlyhan\u00ed je \u0165a\u017e\u0161ie.<\/li>\n<\/ul>\n<p>\n<i>Pozn\u00e1mka o Helme: ak chcete pou\u017e\u00edva\u0165 Helm, odpor\u00fa\u010dame kombinova\u0165 ho s GitOps oper\u00e1torom, ako je <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/managing-helm-releases-the-gitops-way\">Flux-Helm<\/a><\/noindex>. To pom\u00f4\u017ee zabezpe\u010di\u0165 konvergenciu. Samotn\u00fd Helm nie je ani deterministick\u00fd, ani atom\u00e1rny.<\/i><\/p>\n<h2>GitOps ako najlep\u0161\u00ed sp\u00f4sob, ako realizova\u0165 nepretr\u017eit\u00e9 dod\u00e1vanie pre Kubernetes<\/h2>\n<p>\nT\u00edm Alice a Bob implementuje GitOps a zist\u00ed, \u017ee je omnoho jednoduch\u0161ie pracova\u0165 so softv\u00e9rov\u00fdmi produktmi, udr\u017eiava\u0165 vysok\u00fd v\u00fdkon a stabilitu. Po\u010fme skon\u010di\u0165 tento \u010dl\u00e1nok ilustr\u00e1ciami, ktor\u00e9 ukazuj\u00fa, ako vyzer\u00e1 ich nov\u00fd pr\u00edstup. Berte na vedomie, \u017ee hovor\u00edme predov\u0161etk\u00fdm o aplik\u00e1ci\u00e1ch a slu\u017eb\u00e1ch, ale GitOps m\u00f4\u017ee by\u0165 pou\u017eit\u00fd na spravovanie celej platformy.<\/p>\n<h3>Model oper\u00e1cie pre Kubernetes<\/h3>\n<p>\nPozrite sa na nasleduj\u00faci diagram. Predstavuje Git a \u00falo\u017eisko obrazov kontajnerov ako spolo\u010dn\u00e9 zdroje pre dva orchestr\u00e1lne \u017eivotn\u00e9 cykly:<\/p>\n<ul>\n<li> Pipeliny nepretr\u017eit\u00e9j integr\u00e1cie, ktor\u00e9 \u010d\u00edtaj\u00fa a zapisuj\u00fa s\u00fabory do Gitu a m\u00f4\u017eu aktualizova\u0165 repozit\u00e1r kontajnerov\u00fdch obrazov.<\/li>\n<li> Pipeliny Runtime GitOps, ktor\u00e9 kombinuj\u00fa nasadenie s riaden\u00edm a monitorovan\u00edm. \u010c\u00edtaj\u00fa a zapisuj\u00fa s\u00fabory do Gitu a m\u00f4\u017eu nahr\u00e1va\u0165 obrazy kontajnerov.<\/li>\n<\/ul>\n<h3>Ak\u00e9 s\u00fa hlavn\u00e9 zistenia?<\/h3>\n<p><\/p>\n<ol>\n<li> <b>Rozdelenie probl\u00e9mov<\/b>: V\u0161imnite si, \u017ee oba pipeliny m\u00f4\u017eu vymie\u0148a\u0165 \u00fadaje len aktualizovan\u00edm Gitu alebo repozit\u00e1ra obrazov. In\u00fdmi slovami, medzi CI a runtime prostred\u00edm je firewall. Naz\u00fdvame ho \"firewallom nemennosti\" <i>(immutability firewall)<\/i>, preto\u017ee v\u0161etky aktualiz\u00e1cie repozit\u00e1rov vytv\u00e1raj\u00fa nov\u00e9 verzie. Pre \u010fal\u0161ie inform\u00e1cie k tejto t\u00e9me sa obr\u00e1tte na sn\u00edmky 72-87 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.slideshare.net\/weaveworks\/continuous-lifecycle-london-2018-event-keynote-97418556\">tejto prezent\u00e1cie<\/a><\/noindex>.<\/li>\n<li> <b>M\u00f4\u017eete pou\u017ei\u0165 ak\u00fdko\u013evek CI- a Git-server<\/b>: GitOps funguje s ak\u00fdmiko\u013evek komponentmi. M\u00f4\u017eete na\u010falej pou\u017e\u00edva\u0165 svoje ob\u013e\u00faben\u00e9 CI- a Git-servery, repozit\u00e1re obrazov a testovacie sady. Takmer v\u0161etky ostatn\u00e9 n\u00e1stroje na nepretr\u017eit\u00e9 dod\u00e1vanie na trhu vy\u017eaduj\u00fa vlastn\u00fd CI\/Git-server alebo \u00falo\u017eisko obrazov. To m\u00f4\u017ee by\u0165 obmedzuj\u00facim faktorom pri v\u00fdvoji cloud native. V pr\u00edpade GitOps m\u00f4\u017eete pou\u017e\u00edva\u0165 v\u00fdhodn\u00e9 n\u00e1stroje.<\/li>\n<li> <b>Udalosti ako n\u00e1stroj integr\u00e1cie<\/b>: Ke\u010f s\u00fa \u00fadaje v Gite aktualizovan\u00e9, Weave Flux (alebo oper\u00e1tor Weave Cloud) o tom informuje runtime. Kedyko\u013evek Kubernetes prijme s\u00fabor zmien, Git sa aktualizuje. To poskytuje jednoduch\u00fd model integr\u00e1cie pre organiz\u00e1ciu pracovn\u00fdch tokov pre GitOps, ako je zn\u00e1zornen\u00e9 ni\u017e\u0161ie.<\/li>\n<\/ol>\n<h2>Z\u00e1ver<\/h2>\n<p>\nGitOps poskytuje siln\u00e9 z\u00e1ruky aktualiz\u00e1cie, potrebn\u00e9 pre ka\u017ed\u00fd modern\u00fd n\u00e1stroj CI\/CD:<\/p>\n<ul>\n<li> automatiz\u00e1cia;<\/li>\n<li> konvergencia;<\/li>\n<li> idempotentnos\u0165;<\/li>\n<li> deterministickos\u0165.<\/li>\n<\/ul>\n<p>\nJe d\u00f4le\u017eit\u00e9, preto\u017ee pon\u00faka model prev\u00e1dzky pre v\u00fdvoj\u00e1rov v oblasti cloud native.<\/p>\n<ul>\n<li> Tradi\u010dn\u00e9 n\u00e1stroje na spr\u00e1vu a monitoring syst\u00e9mov s\u00favisia s t\u00edmami prev\u00e1dzky, ktor\u00e9 p\u00f4sobia v r\u00e1mci runbooku <i>(s\u00fabor rutinn\u00fdch postupov a oper\u00e1ci\u00ed \u2014 pozn. prekl.)<\/i>, viazan\u00e9ho na konkr\u00e9tne nasadenie.<\/li>\n<li> V spr\u00e1ve cloud native syst\u00e9mov je n\u00e1stroj na sledovanie najlep\u0161\u00edm sp\u00f4sobom, ako pos\u00fadi\u0165 v\u00fdsledky nasaden\u00ed, aby sa v\u00fdvojov\u00fd t\u00edm mohol na ne r\u00fdchlo reagova\u0165.<\/li>\n<\/ul>\n<p>\nPredstavte si mno\u017estvo klastrov roztr\u00fasen\u00fdch po r\u00f4znych cloudoch a mno\u017estvo slu\u017eieb so svojimi vlastn\u00fdmi t\u00edmami a pl\u00e1nmi nasaden\u00ed. GitOps pon\u00faka \u0161k\u00e1lovate\u013en\u00fd a invariabiln\u00fd model na spr\u00e1vu tohto bohatstva.<\/p>\n<h2>P.S. od prekladate\u013ea<\/h2>\n<p>\nPre\u010d\u00edtajte si tie\u017e na na\u0161om blogu:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/456754\/\">GitOps: porovnanie met\u00f3d Pull a Push<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/434160\/\">Predstavujeme kni\u017enicu kubedog na sledovanie zdrojov Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/449096\/\">Roz\u0161irujeme a dop\u013a\u0148ame Kubernetes (preh\u013ead a video predn\u00e1\u0161ky)<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p class=\"for_users_only_msg\">Len registrovan\u00ed pou\u017e\u00edvatelia sa m\u00f4\u017eu z\u00fa\u010dastni\u0165 prieskumu. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Prihl\u00e1ste sa<\/a><\/noindex>, pros\u00edm.<\/p>\n<h2 class=\"default-block__polling-title\">Vedeli ste o GitOps pred t\u00fdmito dvomi prekladmi na habre?<\/h2>\n<ul class=\"content-list content-list_polling\">\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    \u00c1no, v\u0161etko som vedel(a)<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Iba povrchn\u00e9 znalosti<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Nie<\/p>\n<\/li>\n<\/ul>\n<p>    Hlasovalo 35 pou\u017e\u00edvate\u013eov. Zdr\u017ealo sa 10 pou\u017e\u00edvate\u013eov.<br \/>\n<br \/>Zdroj: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/458878\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u041f\u043e\u0441\u043b\u0435 \u043d\u0435\u0434\u0430\u0432\u043d\u0435\u0439 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430 \u043e \u043c\u0435\u0442\u043e\u0434\u0430\u0445 pull \u0438 push \u0432 GitOps \u043c\u044b \u0443\u0432\u0438\u0434\u0435\u043b\u0438 \u0438\u043d\u0442\u0435\u0440\u0435\u0441 \u043a \u044d\u0442\u043e\u0439 \u043c\u043e\u0434\u0435\u043b\u0438 \u0432 \u0446\u0435\u043b\u043e\u043c, \u043e\u0434\u043d\u0430\u043a\u043e \u0440\u0443\u0441\u0441\u043a\u043e\u044f\u0437\u044b\u0447\u043d\u044b\u0445 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0439 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443 \u043e\u043a\u0430\u0437\u0430\u043b\u043e\u0441\u044c \u0441\u043e\u0432\u0441\u0435\u043c \u043c\u0430\u043b\u043e (\u043d\u0430 \u0445\u0430\u0431\u0440\u0435 \u0438\u0445 \u043f\u043e\u043f\u0440\u043e\u0441\u0442\u0443 \u043d\u0435\u0442). \u041f\u043e\u0441\u0435\u043c\u0443 \u0440\u0430\u0434\u044b \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u044c \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u0434\u0440\u0443\u0433\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 \u043f\u0443\u0441\u0442\u044c \u0438 \u0443\u0436\u0435 \u043f\u043e\u0447\u0442\u0438 \u0433\u043e\u0434\u0438\u0447\u043d\u043e\u0439 \u0434\u0430\u0432\u043d\u043e\u0441\u0442\u0438! \u2014 \u043e\u0442 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Weaveworks, \u0433\u043b\u0430\u0432\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35941","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.5 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/chto-zhe-takoe-gitops\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"sk_SK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0427\u0442\u043e \u0436\u0435 \u0442\u0430\u043a\u043e\u0435 GitOps? | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/chto-zhe-takoe-gitops\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:07:41+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:07:41+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u010co je to GitOps? | ProHoster","description":"Pr\u00edklad","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/chto-zhe-takoe-gitops","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0427\u0442\u043e \u0436\u0435 \u0442\u0430\u043a\u043e\u0435 GitOps? | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/chto-zhe-takoe-gitops","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:07:41+00:00","article:modified_time":"2019-10-31T19:07:41+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35941","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 01:21:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:53:31","updated":"2026-01-22 01:21:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/35941","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=35941"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/35941\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=35941"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=35941"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=35941"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}