{"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\/sl\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps: pore\u0111enje Pull i Push metoda","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Op. prev.<\/b>: V skupnosti Kubernetes pridobiva izrazit pomen trend, imenovan GitOps, \u010demur smo osebno pri\u010de, ko smo obiskali<\/a><\/noindex> KubeCon Europe 2019. Ta izraz je bil relativno nedavno izumljen<\/a><\/noindex> od vodje podjetja Weaveworks - Alexis Richardson - in pomeni uporabo orodij, ki so razvojnim ekipam poznana (predvsem Git, od koder tudi ime) za re\u0161evanje nalog upravljanja. Gre predvsem za upravljanje Kubernetes, pri \u010demer so njegove konfiguracije shranjene v Gitu in se spremembe avtomatsko nalagajo v klaster. O dveh pristopih k tej nalogi pi\u0161e Matthias Jg v tem \u010dlanku.<\/i><\/p>\n

\"GitOps:
\n
\nLani (v resnici se je to formalno zgodilo avgusta 2017 - op. prev.)<\/i> Pojavio se novi pristup implementaciji aplikacija u Kubernetesu. Zove se GitOps, a temelji se na osnovnoj ideji da se pra\u0107enje verzija deploymenta vr\u0161i u sigurnom okru\u017eenju Git repozitorija.<\/a><\/noindex><\/p>\n

Osnovne prednosti tega pristopa so naslednje<\/b>:<\/p>\n

    \n
  1. Verzioniranje deploymenta i istorija izmena<\/b>. Stanje celog klastera se \u010duva u Git repozitoriju, a deploymenti se a\u017euriraju samo putem commit-a. Pored toga, sve promene se mogu pratiti pomo\u0107u istorije commit-a.<\/li>\n
  2. Povratki z uporabo znanih ukazov Git<\/b>. Preprosto git reset<\/code> omogu\u0107ava vra\u0107anje promena u deploymentima; sve prethodne verzije su uvek dostupne.<\/li>\n
  3. Pripravljen nadzor dostopa<\/b>. Obi\u010dno Git sistemi sadr\u017ee brojne poverljive podatke, zbog \u010dega ve\u0107ina kompanija pridaje posebnu pa\u017enju njihovoj za\u0161titi. Stoga se ova za\u0161tita odnosi i na operacije sa deploymentima.<\/li>\n
  4. Politike za namestitve<\/b>. Ve\u0107ina Git sistema inicijalno podr\u017eava politike za razli\u010dite grane \u2014 na primer, samo pull request-i mogu a\u017eurirati master, a izmene moraju proveriti i odobriti drugi \u010dlan tima. Kao i kod kontrole pristupa, iste politike se primenjuju na a\u017euriranja deploymenta.<\/li>\n<\/ol>\n

    \nKao \u0161to vidite, metoda GitOps ima brojne prednosti. Tokom pro\u0161le godine, dva pristupa su posebno popularna. Jedan se zasniva na push, dok se drugi oslanja na pull. Pre nego \u0161to ih razmotrimo, najpre hajde da pogledamo kako izgledaju tipi\u010dni deploymenti Kubernetes-a.<\/p>\n

    Na\u010dini uvajanja<\/h2>\n

    \nV zadnjih letih so se v Kubernetesu uveljavili razli\u010dni na\u010dini in orodja za uvajanje:<\/p>\n

      \n
    1. Na osnovi doma\u010dih predlog Kubernetes\/Kustomize<\/b>To je najla\u017eji na\u010din za upravljanje aplikacijami v Kubernetesu. Razvijalec ustvari osnovne YAML datoteke in jih uporabi. Da se izogne nenehnemu prepisovanju istih predlog, je bil razvit Kustomize (spremeni predloge Kubernetes v module). Op. prev.<\/b>: Kustomize je bil integriran v kubectl z izdajo Kubernetes 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Helm Charti<\/b>. Helm chartovi omogu\u0107avaju kreiranje setova \u0161ablona, init kontejnera, sidecar-a itd., koji se koriste za implementaciju aplikacija sa fleksibilnijim mogu\u0107nostima konfiguracije nego u pristupu zasnovanom na \u0161ablonima. Osnova ove metode su \u0161ablonizovani YAML fajlovi. Helm ih popunjava razli\u010ditim parametrima i zatim \u0161alje Tiller-u \u2014 klasterskom komponentu koja ih implementira u klasteru i omogu\u0107ava a\u017euriranja i vra\u0107anja. Va\u017eno je to \u0161to se su\u0161tinski, Helm jednostavno ubacuje potrebne vrednosti u \u0161ablone i zatim ih primenjuje na isti na\u010din kao u tradicionalnom pristupu (ve\u010d o tem, kako to vse deluje in kako ga lahko uporabite, preberite v na\u0161i \u010dlanku o Helmu<\/a><\/noindex> \u2014 op. prev.)<\/i>. Obstaja velika raznolikost pripravljenih Helm chartov, ki pokrivajo \u0161irok spekter nalog.<\/li>\n
    3. Alternativna orodja<\/b>. Obstaja \u0161tevilna alternativna orodja. Vse jih zdru\u017euje dejstvo, da pretvarjajo dolo\u010dene predloge v razumljive Kubernetes YAML datoteke in jih nato aplicirajo.<\/li>\n<\/ol>\n

      \nPri svojem delu nenehno uporabljamo Helm chart-e za pomembna orodja (ker je v njih veliko \u017ee pripravljenega, kar bistveno olaj\u0161a \u017eivljenje) ter '\u010diste' YAML datoteke Kubernetes za name\u0161\u010danje lastnih aplikacij.<\/p>\n

      Pull & Push<\/h2>\n

      \nV eni svojih nedavnih objav na blogu sem predstavil orodje Weave Flux<\/a><\/noindex>, omogu\u0107avaju\u0107i commit-ovanje \u0161ablona u Git repozitorij i a\u017euriranje deploymenta nakon svakog commita ili push-a kontejnera. Moje iskustvo pokazuje da je ovaj alat jedan od klju\u010dnih u promociji pull pristupa, stoga \u0107u \u010desto upu\u0107ivati na njega. Ako \u017eelite da saznate vi\u0161e o tome kako ga koristiti, evo povezava do \u010dlanka<\/a><\/noindex>.<\/p>\n

      NB!<\/b> Vse prednosti uporabe GitOps ostajajo za oba pristopa.<\/i><\/p>\n

      Pristop na osnovi Pull<\/h2>\n

      \n\"GitOps:
      \n
      \nOsnova pristopa pull temelji na dejstvu, da se vse spremembe izvajajo znotraj klasterja. Znotraj klasterja je operator, ki redno preverja povezane Git in Docker Registry repozitorije. \u010ce pride do kakr\u0161nih koli sprememb, se stanje klasterja posodobi od znotraj. To se obi\u010dajno \u0161teje za precej varno, saj noben zunanji klient nima dostopa do adminsitrativnih pravic klasterja.<\/p>\n

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

        \n
      1. Noben zunanji klient nima pravic za uvajanje sprememb v klaster, vse posodobitve se izvajajo od znotraj.<\/li>\n
      2. Nekateri alati prav tako omogo\u010dajo sinhronizacijo posodobitev Helm chartov in njihovo povezovanje s klasterjem.<\/li>\n
      3. Docker Registry lahko skenirate za nove razli\u010dice. \u010ce se pojavi nova slika, se Git repozitorij in deployment posodobita na novo razli\u010dico.<\/li>\n
      4. Pull alati so lahko razdeljeni po razli\u010dnih imenskih prostorih z razli\u010dnimi Git repozitoriji in pravicami dostopa. Zaradi tega je mogo\u010de uporabiti ve\u010dnajemno (multitenant) model. Na primer, skupina A lahko uporablja imenski prostor A, skupina B pa imenski prostor B, skupina, ki se ukvarja z infrastrukturo, pa lahko uporablja globalni prostor.<\/li>\n
      5. Na splo\u0161no so alati precej lahki.<\/li>\n
      6. V kombinaciji z alat omejevalcem, Bitnami Sealed Secrets,<\/a><\/noindex>, se skrivnosti lahko shranijo v \u0161ifrirani obliki v Git repozitoriju in pridobijo znotraj klasterja.<\/li>\n
      7. Ni povezave s CD-pipelines, saj se razporeditve izvajajo znotraj klasterja.<\/li>\n<\/ol>\n

        \n\u041d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043a\u0438<\/b>:<\/p>\n

          \n
        1. Upravljanje tajnama implementacija iz Helm \u010dartera je slo\u017eenije nego s obi\u010dnima, jer ih prvo treba generirati u obliku, recimo, zatvorenih tajni, zatim de\u0161ifrirati putem unutarnjeg operatora i tek tada postaju dostupne za pull alat. Nakon toga mo\u017eete pokrenuti verziju u Helmu s vrijednostima u ve\u0107 implementiranim tajnama. Najjednostavniji na\u010din je stvoriti tajnu sa svim Helm vrijednostima koje se koriste za implementaciju, de\u0161ifrirati je i poslu\u017eiti u Gitu.<\/li>\n
        2. Primjenom pull pristupa vezani ste za alate koji upravljaju pull-ima. To ograni\u010dava mogu\u0107nost prilagodbe procesa implementacije u klasteru. Na primjer, rad s Kustomizeom je ote\u017ean jer se mora izvr\u0161avati prije nego \u0161to kona\u010dni obrasci odu u Git. Ne ka\u017eem da se ne mogu koristiti odvojeni alati, ali ih je te\u017ee integrirati u proces implementacije.<\/li>\n<\/ol>\n

          <\/p>\n

          Pristop, ki temelji na Push<\/h2>\n

          \n\"GitOps:
          \n
          \nV push-pristopu zunanja sistem (predvsem CD-pipeline) spro\u017ei uvajanja v grozd po commitu v Git-repozitoriju ali ob uspe\u0161nem zaklju\u010dku prej\u0161njega CI-pipeline. V tem pristopu ima sistem dostop do grozda.<\/p>\n

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

            \n
          1. Varnost je dolo\u010dena z Git-repozitorijem in procesom gradnje.<\/li>\n
          2. Uvajanje Helm grafikonov je la\u017eje, saj je podprto s Helm vti\u010dniki.<\/li>\n
          3. Upravljanje s skrivnostmi je la\u017eje, saj jih lahko uporabite v pipeline, poleg tega pa jih lahko shranite v Git v \u0161ifrirani obliki (odvisno od uporabnikovih preferenc).<\/li>\n
          4. Pomanjkanje vezave na dolo\u010deno orodje, saj lahko uporabite katerokoli vrsto.<\/li>\n
          5. Posodobitve razli\u010dic kontejnerjev lahko spro\u017ei proces gradnje.<\/li>\n<\/ol>\n

            \n\u041d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043a\u0438<\/b>:<\/p>\n

              \n
            1. Podatki za dostop do grozda so shranjeni v sistemu gradnje.<\/li>\n
            2. A\u017euriranje kontejnera implementacija i dalje se lak\u0161e provodi s pull procesom.<\/li>\n
            3. Mo\u010dna odvisnost od CD-sistema, saj so potrebni pipeline morda prvotno napisani za Gitlab Runners, nato pa se odlo\u010di ekipa preiti na Azure DevOps ali Jenkins\u2026 in bo potrebno migrirati veliko \u0161tevilo procesov gradnje.<\/li>\n<\/ol>\n

              <\/p>\n

              Zaklju\u010dki: Push ali Pull?<\/h2>\n

              \nKot obi\u010dajno, vsak pristop ima svoje prednosti in slabosti. Nekatere naloge je la\u017eje izvesti na en na\u010din, druge pa na drugega. Sprva sem ro\u010dno izvajal wdpritje, a ko sem naletel na nekaj \u010dlankov o Weave Flux, sem se odlo\u010dil uvesti procese GitOps za vse projekte. Za osnovne predloge je bilo to enostavno, a kmalu sem se za\u010del sre\u010devati s te\u017eavami pri delu z Helm charti. Takrat je Weave Flux ponujal le za\u010detno razli\u010dico Helm Chart Operatorja, vendar tudi zdaj so nekatere naloge zahtevnej\u0161e zaradi potrebe po ro\u010dni izdelavi skrivnosti in njihovem uporabi. Lahko bi rekli, da je pull pristop veliko bolj varen, saj so poverilnice klasterja dostopne le v svojem okviru, kar pove\u010duje varnost in upravi\u010duje dodatne napore.<\/p>\n

              Nakon malog razmi\u0161ljanja, do\u0161ao sam do iznena\u0111uju\u0107eg zaklju\u010dka da to nije slu\u010daj. Kada govorimo o komponentama koje zahtijevaju maksimalnu za\u0161titu, na takav bi popis u\u0161li skladi\u0161ta tajni i CI\/CD sustavi, Git repozitoriji. Informacije unutar njih su vrlo ranjive i trebaju maksimalnu za\u0161titu. Osim toga, ako netko prodre u va\u0161 Git repozitorij i mo\u017ee push-ati kod, mo\u017ee implementirati sve \u0161to po\u017eeli (neovisno o odabranom pristupu, bilo da je to pull ili push) i infiltrirati se u sustave klastera. Stoga su najva\u017enije komponente koje zahtijevaju za\u0161titu Git repozitorij i CI\/CD sustavi, a ne podaci o klasteru. Ako imate dobro postavljene politike i sigurnosne mjere za takve sustave, a podaci o klasteru se izvode u pipeline samo kao tajne, dodatna sigurnost pull pristupa mo\u017eda se ne\u0107e pokazati tako vrijednom kao \u0161to se prvotno pretpostavljalo.<\/p>\n

              Torej, \u010de je pull pristop bolj delovno intenziven in ne prina\u0161a varnostne prednosti, ali ni logi\u010dno uporabiti le push pristop? Vendar pa bi nekdo lahko trdil, da ste pri push pristopu preve\u010d odvisni od CD sistema in da morda ni pametno, da to delate, da bi v prihodnosti olaj\u0161ali migracije.<\/p>\n

              Po mojem mnenju (kot vedno) je treba uporabiti tisto, kar najbolj ustreza konkretnemu primeru, ali kombinirati oboje. Osebno uporabljam oba pristopa: Weave Flux za deploymente na podlagi pull, ki ve\u010dinoma vklju\u010dujejo na\u0161e lastne storitve, in push-pristop s Helmom in vti\u010dniki, ki poenostavijo uporabo Helm-chartov na klastru ter omogo\u010dajo brezskrbno ustvarjanje skrivnosti. Mislim, da nikoli ne bo enotne re\u0161itve, primerne za vse primere, ker ima vedno veliko podrobnosti, ki so odvisne od konkretnega na\u010dina uporabe. Kljub temu toplo priporo\u010dam GitOps \u2014 mo\u010dno olaj\u0161a \u017eivljenje in pove\u010duje varnost.<\/p>\n

              Upam, da bo moje izku\u0161nje na tem podro\u010dju pomagale dolo\u010diti, kateri postopek najve\u010d ustreza va\u0161emu tipu deploymentov, in vesel bom, da bom sli\u0161al va\u0161e mnenje.<\/p>\n

              P.S. Opomba prevajalca<\/h2>\n

              \nMed slabostmi pull modela je to\u010dka, da je te\u017eko shraniti v Git upodobljene manifeste, vendar ni slabosti, da CD-pipeline v pull modelu \u017eivi lo\u010deno od implementacije in v bistvu postane pipeline kategorije Continuous Apply<\/i>. Zato bo potrebno \u0161e ve\u010d napora, da se zbira status vseh deploymentov in na nek na\u010din omogo\u010di dostop do logov\/statusa, pri \u010demer je za\u017eeleno, da je povezan s CD sistemom.<\/p>\n

              V tem smislu push-model omogo\u010da, da se zagotovi vsaj nekaj garancij za izvedbo, saj lahko \u010das \u017eivljenja pipeline-a nastavimo na \u010das \u017eivljenja izvedbe.<\/p>\n

              Preizkusili smo oba modela in pri\u0161li do enakih zaklju\u010dkov kot avtor \u010dlanka:<\/p>\n

                \n
              1. Pull model se nam prilagaja za organizacijo posodobitve sistemskih komponent na \u0161tevilnih klasterjih (glejte \u010dlanek o addon-operatorju<\/a><\/noindex>).<\/li>\n
              2. Push-model na osnovi GitLab CI je dobro primeren za izvedbo aplikacij s pomo\u010djo Helm-chartov. Pri tem se izvedba deploymentov v okviru pipeline-ov spremlja s pomo\u010djo orodja werf<\/a><\/noindex>. Mimogrede, v kontekstu tega na\u0161ega projekta smo nenehno sli\u0161ali 'GitOps', ko smo razpravljali o nujnih te\u017eavah DevOps in\u017eenirjev na na\u0161em stojnico na KubeCon Europe'19.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.S. od prevajalca<\/h2>\n

                \nPreberite tudi na na\u0161em blogu:<\/p>\n