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

Nota traduc\u0103torului.<\/b>: \u00cen comunitatea Kubernetes, o tendin\u021b\u0103 numit\u0103 GitOps c\u00e2\u0219tig\u0103 o popularitate evident\u0103, ceea ce am constatat personal, vizit\u00e2nd<\/a><\/noindex> KubeCon Europe 2019. Acest termen a fost inventat relativ recent, de c\u0103tre<\/a><\/noindex> CEO-ul companiei Weaveworks \u2014 Alexis Richardson \u2014 \u0219i se refer\u0103 la aplicarea unor instrumente familiare pentru dezvoltatori (\u00een primul r\u00e2nd \u2014 Git, de unde provine \u0219i numele) pentru a rezolva sarcini de operare. \u00cen special, se vorbe\u0219te despre operarea Kubernetes prin stocarea configura\u021biilor sale \u00een Git \u0219i implementarea automat\u0103 a modific\u0103rilor \u00een cluster. Despre dou\u0103 abord\u0103ri ale acestei implement\u0103ri vorbe\u0219te Matthias Jg \u00een acest articol.<\/i><\/p>\n

\"GitOps:
\n
\nAnul trecut, (de fapt, formal a avut loc \u00een august 2017 \u2014 n.r.)<\/i> A ap\u0103rut o nou\u0103 abordare pentru desf\u0103\u0219urarea aplica\u021biilor \u00een Kubernetes. Se nume\u0219te GitOps \u0219i se bazeaz\u0103 pe conceptul fundamental c\u0103 urm\u0103rirea versiunilor desf\u0103\u0219ur\u0103rilor se face \u00eentr-un mediu sigur de repository Git.<\/a><\/noindex><\/p>\n

Principalele avantaje ale acestei abord\u0103ri sunt urm\u0103toarele:<\/b>:<\/p>\n

    \n
  1. Versiunea desf\u0103\u0219ur\u0103rilor \u0219i istoricul modific\u0103rilor<\/b>. Starea \u00eentregului cluster este stocat\u0103 \u00een repository-ul Git, iar desf\u0103\u0219ur\u0103rilor li se aduc actualiz\u0103ri doar prin commit-uri. \u00cen plus, toate modific\u0103rile pot fi urm\u0103rite cu ajutorul istoricului commit-urilor.<\/li>\n
  2. R\u0103sturn\u0103ri folosind comenzile familiare Git.<\/b>Simplu \u0219i git reset<\/code> permite revenirea la modific\u0103rile anterioare \u00een desf\u0103\u0219ur\u0103ri; st\u0103rile anterioare sunt mereu disponibile.<\/li>\n
  3. Controlul accesului complet.<\/b>. De obicei, sistemul Git con\u021bine o mul\u021bime de date confiden\u021biale, motiv pentru care majoritatea companiilor acord\u0103 o aten\u021bie deosebit\u0103 protec\u021biei sale. Astfel, aceast\u0103 protec\u021bie se aplic\u0103 \u0219i opera\u021biunilor cu desf\u0103\u0219ur\u0103rile.<\/li>\n
  4. Politicile pentru desf\u0103\u0219ur\u0103ri.<\/b>. Cele mai multe sisteme Git suport\u0103 din start politici pentru ramuri diferite - de exemplu, doar pull request-urile pot actualiza ramura master, iar modific\u0103rile trebuie s\u0103 fie verificate \u0219i acceptate de un alt membru al echipei. Asemenea controlului accesului, acelea\u0219i politici sunt aplicate actualiz\u0103rilor desf\u0103\u0219ur\u0103rilor.<\/li>\n<\/ol>\n

    \nDup\u0103 cum vede\u021bi, metoda GitOps are multe avantaje. \u00cen ultimul an, dou\u0103 abord\u0103ri au c\u00e2\u0219tigat popularitate. Una este bazat\u0103 pe push, iar cealalt\u0103 pe pull. \u00cenainte de a le discuta, haide\u021bi s\u0103 arunc\u0103m o privire asupra desf\u0103\u0219ur\u0103rilor tipice \u00een Kubernetes.<\/p>\n

    Modalit\u0103\u021bi de desf\u0103\u0219urare.<\/h2>\n

    \n\u00cen ultimii ani, au existat diverse modalit\u0103\u021bi \u0219i instrumente pentru desf\u0103\u0219ur\u0103ri \u00een Kubernetes:<\/p>\n

      \n
    1. Pe baza \u0219abloanelor native Kubernetes\/Kustomize.<\/b>. Aceasta este cea mai simpl\u0103 modalitate de desf\u0103\u0219urare a aplica\u021biilor \u00een Kubernetes. Dezvoltatorul creeaz\u0103 fi\u0219iere YAML de baz\u0103 \u0219i le aplic\u0103. Pentru a evita rescrierea constant\u0103 a acelora\u0219i \u0219abloane, a fost dezvoltat Kustomize (care transform\u0103 \u0219abloanele Kubernetes \u00een module). Nota traduc\u0103torului.<\/b>: Kustomize a fost integrat \u00een kubectl cu versiunea Kubernetes 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Grafice Helm<\/b>. Graficele Helm permit crearea de seturi de \u0219abloane, init-container-e, sidecar-uri etc., care sunt utilizate pentru desf\u0103\u0219urarea aplica\u021biilor cu op\u021biuni de configurare mai flexibile dec\u00e2t cele din abordarea bazat\u0103 pe \u0219abloane. La baza acestei metode stau fi\u0219ierele YAML \u0219ablonizate. Helm le completeaz\u0103 cu diferite parametri \u0219i apoi le trimite lui Tiller - componenta cluster-ului care le desf\u0103\u0219oar\u0103 \u00een cluster \u0219i permite actualiz\u0103ri \u0219i reveniri. Este important de men\u021bionat c\u0103, \u00een esen\u021b\u0103, Helm pur \u0219i simplu introduce valorile corespunz\u0103toare \u00een \u0219abloane \u0219i apoi le aplic\u0103 la fel cum se face \u00een abordarea tradi\u021bional\u0103 (mai multe detalii despre cum func\u021bioneaz\u0103 totul \u0219i cum poate fi utilizat, pute\u021bi citi \u00een articolul nostru despre Helm<\/a><\/noindex> \u2014 nota trad.)<\/i>. Exist\u0103 o mare diversitate de grafice Helm disponibile, acoperind o gam\u0103 larg\u0103 de sarcini.<\/li>\n
    3. Instrumente alternative<\/b>. Exist\u0103 numeroase instrumente alternative. Toate au \u00een comun faptul c\u0103 transform\u0103 fi\u0219iere \u0219ablon \u00een fi\u0219iere YAML Kubernetes u\u0219or de \u00een\u021beles \u0219i apoi le aplic\u0103.<\/li>\n<\/ol>\n

      \n\u00cen activitatea noastr\u0103, folosim constant grafice Helm pentru instrumente importante (deoarece acestea con\u021bin deja multe configura\u021bii, ceea ce faciliteaz\u0103 semnificativ munca) \u0219i fi\u0219iere YAML Kubernetes \u201epure\u201d pentru desf\u0103\u0219urarea aplica\u021biilor noastre.<\/p>\n

      Pull & Push<\/h2>\n

      \n\u00cen una dintre publica\u021biile mele recente pe blog, am prezentat un instrument Weave Flux<\/a><\/noindex>, permi\u021b\u00e2nd commitarea \u0219abloanelor \u00een repository-ul Git \u0219i actualizarea desf\u0103\u0219ur\u0103rilor dup\u0103 fiecare commit sau push al containerului. Experien\u021ba mea arat\u0103 c\u0103 acest instrument este unul dintre cele mai importante \u00een promovarea abord\u0103rii pull, a\u0219a c\u0103 voi face dese referiri la el. Dac\u0103 dori\u021bi s\u0103 afla\u021bi mai multe despre cum s\u0103-l utiliza\u021bi, iat\u0103 linkul c\u0103tre articol<\/a><\/noindex>.<\/p>\n

      NB!<\/b> Toate avantajele utiliz\u0103rii GitOps se p\u0103streaz\u0103 pentru ambele abord\u0103ri.<\/i><\/p>\n

      Abordare bazat\u0103 pe Pull<\/h2>\n

      \n\"GitOps:
      \n
      \nLa baza abord\u0103rii pull se afl\u0103 faptul c\u0103 toate modific\u0103rile sunt aplicate din interiorul cluster-ului. \u00cen interiorul cluster-ului exist\u0103 un operator care verific\u0103 \u00een mod regulat repositoriile Git \u0219i Docker Registry asociate. Dac\u0103 exist\u0103 vreo schimbare \u00een ele, starea cluster-ului este actualizat\u0103 din interior. \u00cen general, se consider\u0103 c\u0103 un astfel de proces este destul de sigur, deoarece niciun client extern nu are acces la drepturile de administrator ale cluster-ului.<\/p>\n

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

        \n
      1. Niciun client extern nu are drepturi de a efectua modific\u0103ri \u00een cluster, toate actualiz\u0103rile sunt aplicate din interior.<\/li>\n
      2. Unele instrumente permit, de asemenea, sincronizarea actualiz\u0103rilor helm-chart-urilor \u0219i legarea lor de cluster.<\/li>\n
      3. Docker Registry poate fi scanat pentru a verifica dac\u0103 exist\u0103 noi versiuni. Dac\u0103 apare o nou\u0103 imagine, repositorul Git \u0219i desf\u0103\u0219urarea sunt actualizate la noua versiune.<\/li>\n
      4. Instrumentele pull pot fi distribuite pe diferite spa\u021bii de nume cu diferite repositorii Git \u0219i drepturi de acces. Datorit\u0103 acestui lucru, se poate aplica un model multi-tenant. De exemplu, echipa A poate folosi spa\u021biul de nume A, echipa B - spa\u021biul de nume B, iar echipa responsabil\u0103 cu infrastructura poate folosi spa\u021biul global.<\/li>\n
      5. \u00cen general, instrumentele sunt destul de u\u0219oare.<\/li>\n
      6. \u00cempreun\u0103 cu instrumente precum operatorul Bitnami Sealed Secrets<\/a><\/noindex>, secretele pot fi stocate criptate \u00een repositorul Git \u0219i extrase din interiorul cluster-ului.<\/li>\n
      7. Nu exist\u0103 o leg\u0103tur\u0103 cu CD-pipelines deoarece desf\u0103\u0219ur\u0103rile au loc \u00een interiorul cluster-ului.<\/li>\n<\/ol>\n

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

          \n
        1. Gestionarea secretelor deployment-urilor din graficele Helm este mai complicat\u0103 dec\u00e2t gestionarea celor obi\u0219nuite, deoarece mai \u00eent\u00e2i trebuie generate sub form\u0103 de, s\u0103 zicem, secrete sigilate, apoi decriptate de un operator intern \u0219i abia dup\u0103 aceea devin accesibile pentru instrumentul de pull. Apoi, se poate lansa o versiune \u00een Helm cu valorile din secretele deja desf\u0103\u0219urate. Cea mai simpl\u0103 metod\u0103 este s\u0103 crea\u021bi un secret cu toate valorile Helm folosite pentru deployment, s\u0103 le decripta\u021bi \u0219i s\u0103 le comite\u021bi \u00een Git.<\/li>\n
        2. Folosind abordarea pull, v\u0103 g\u0103si\u021bi lega\u021bi de instrumente care opereaz\u0103 cu pull-uri. Aceasta limiteaz\u0103 posibilitatea de a personaliza procesul de desf\u0103\u0219urare a deployment-urilor \u00een cluster. De exemplu, lucrul cu Kustomize este complicat deoarece acesta trebuie s\u0103 fie executat \u00eenainte ca \u0219abloanele finale s\u0103 ajung\u0103 \u00een Git. Nu spun c\u0103 nu se pot folosi instrumente separate, dar integrarea lor \u00een procesul de desf\u0103\u0219urare este mai dificil\u0103.<\/li>\n<\/ol>\n

          <\/p>\n

          Abordarea bazat\u0103 pe Push<\/h2>\n

          \n\"GitOps:
          \n
          \n\u00cen abordarea push, un sistem extern (\u00een principal pipeline-uri CD) ini\u021biaz\u0103 desf\u0103\u0219ur\u0103rile \u00een cluster dup\u0103 un commit \u00een depozitul Git sau \u00een cazul \u00een care pipeline-ul CI anterior s-a finalizat cu succes. \u00cen aceast\u0103 abordare, sistemul are acces la cluster.<\/p>\n

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

            \n
          1. Securitatea este definit\u0103 de depozitul Git \u0219i pipeline-ul de construire.<\/li>\n
          2. Desf\u0103\u0219urarea chart-urilor Helm este mai simpl\u0103, av\u00e2nd suport pentru pluginuri Helm.<\/li>\n
          3. Gestionarea secretelor este mai u\u0219oar\u0103, deoarece se pot aplica \u00een pipeline-uri \u0219i se pot stoca \u00een Git \u00eentr-o form\u0103 criptat\u0103 (\u00een func\u021bie de preferin\u021bele utilizatorului).<\/li>\n
          4. Lipsa leg\u0103turii cu un instrument specific, deoarece se pot utiliza tipuri variate de instrumente.<\/li>\n
          5. Actualiz\u0103rile versiunilor containerelor pot fi ini\u021biate de pipeline-ul de construire.<\/li>\n<\/ol>\n

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

              \n
            1. Datele pentru accesul la cluster se afl\u0103 \u00een interiorul sistemului de construire.<\/li>\n
            2. Actualizarea containerelor \u00een deployment-uri este \u00eenc\u0103 mai simpl\u0103 de realizat cu un proces de pull.<\/li>\n
            3. Dependen\u021ba puternic\u0103 de sistemul CD, deoarece pipeline-urile necesare probabil au fost ini\u021bial scrise pentru Gitlab Runners, iar apoi echipa decizi s\u0103 treac\u0103 la Azure DevOps sau Jenkins\u2026 \u0219i va fi necesar\u0103 migrarea unui num\u0103r mare de pipeline-uri de construire.<\/li>\n<\/ol>\n

              <\/p>\n

              Concluzii: Push sau Pull?<\/h2>\n

              \nA\u0219a cum se \u00eent\u00e2mpl\u0103 de obicei, orice abordare are avantajele \u0219i dezavantajele sale. Anumite sarcini sunt mai u\u0219or de realizat cu una \u0219i mai dificil cu cealalt\u0103. La \u00eenceput, am efectuat desf\u0103\u0219ur\u0103ri manuale, dar dup\u0103 ce am dat peste c\u00e2teva articole despre Weave Flux, am decis s\u0103 implementez procesele GitOps pentru toate proiectele. Pentru \u0219abloanele de baz\u0103, aceasta s-a dovedit a fi simplu, dar apoi am \u00eenceput s\u0103 \u00eent\u00e2mpin dificult\u0103\u021bi \u00een utilizarea diagramelor Helm. La acea vreme, Weave Flux oferea doar o versiune incipient\u0103 a Helm Chart Operator, dar chiar \u0219i acum, anumite sarcini sunt mai dificile din cauza necesit\u0103\u021bii de a crea manual secrete \u0219i de a le aplica. Pute\u021bi spune c\u0103 abordarea pull este mult mai sigur\u0103, deoarece acreditivele clusterului nu sunt accesibile din afar\u0103, ceea ce spore\u0219te at\u00e2t de mult securitatea \u00eenc\u00e2t merit\u0103 eforturi suplimentare.<\/p>\n

              Reflect\u00e2nd pu\u021bin, am ajuns la o concluzie nea\u0219teptat\u0103: nu este chiar a\u0219a. Dac\u0103 vorbim despre componentele care necesit\u0103 o protec\u021bie maxim\u0103, \u00een aceast\u0103 categorie vor intra magazinele de secrete \u0219i sistemele CI\/CD, repozitoriile Git. Informa\u021bia din interiorul lor este foarte vulnerabil\u0103 \u0219i necesit\u0103 protec\u021bie maxim\u0103. \u00cen plus, dac\u0103 cineva p\u0103trunde \u00een repozitoriul dvs. Git \u0219i poate s\u0103 \u00eemping\u0103 cod acolo, atunci va putea desf\u0103\u0219ura tot ce \u00ee\u0219i dore\u0219te (indiferent de abordarea aleas\u0103, fie pull sau push) \u0219i s\u0103 se integreze \u00een sistemele clusterului. Astfel, cele mai importante componente care necesit\u0103 protec\u021bie sunt repozitoriul Git \u0219i sistemele CI\/CD, nu acreditivele clusterului. Dac\u0103 ave\u021bi politici \u0219i m\u0103suri de securitate bine configurate pentru astfel de sisteme, iar acreditivele clusterului sunt extrase \u00een pipeline-uri doar ca secrete, securitatea suplimentar\u0103 a abord\u0103rii pull poate s\u0103 nu fie at\u00e2t de valoroas\u0103 pe c\u00e2t s-a presupus ini\u021bial.<\/p>\n

              Deci, dac\u0103 abordarea pull este mai laborioas\u0103 \u0219i nu aduce beneficii \u00een ceea ce prive\u0219te securitatea, nu ar fi logic s\u0103 folose\u0219ti doar abordarea push? Dar cineva ar putea argumenta c\u0103 \u00een abordarea push e\u0219ti prea legat de sistemul CD \u0219i, poate, ar fi mai bine s\u0103 nu procedezi astfel, pentru a facilita migra\u021biile \u00een viitor.<\/p>\n

              Din punctul meu de vedere (ca de obicei), ar trebui s\u0103 folose\u0219ti ceea ce se potrive\u0219te cel mai bine cazului particular sau s\u0103 combini. Personal, folosesc ambele abord\u0103ri: Weave Flux pentru deployment-uri pe baza pull, care includ \u00een principal serviciile noastre, \u0219i abordarea push cu Helm \u0219i plugin-uri, care simplific\u0103 aplicarea chart-urilor Helm pe cluster \u0219i permite crearea secretelor f\u0103r\u0103 probleme. Cred c\u0103 nu va exista niciodat\u0103 o solu\u021bie unic\u0103 adecvat\u0103 pentru toate cazurile, deoarece exist\u0103 \u00eentotdeauna foarte multe nuan\u021be \u0219i depind de cazul specific de utilizare. \u00cen acest sens, recomand cu t\u0103rie GitOps \u2014 acesta \u00ee\u021bi u\u0219ureaz\u0103 mult via\u021ba \u0219i spore\u0219te securitatea.<\/p>\n

              Sper c\u0103 experien\u021ba mea pe acest subiect va ajuta la determinarea metodei care se potrive\u0219te cel mai bine pentru tipul vostru de deployment-uri, iar eu a\u0219 fi \u00eenc\u00e2ntat s\u0103 aflu p\u0103rerea voastr\u0103.<\/p>\n

              P.S. Not\u0103 de la traduc\u0103tor<\/h2>\n

              \nUn dezavantaj al modelului pull este c\u0103 este dificil s\u0103 se pun\u0103 \u00een Git manifestele renderizate, totu\u0219i nu exist\u0103 dezavantajul c\u0103 pipeline-ul CD \u00een modelul pull tr\u0103ie\u0219te separat de implementare \u0219i, \u00een esen\u021b\u0103, devine un pipeline din categoria Continuous Apply<\/i>. Prin urmare, va fi necesar s\u0103 depui \u0219i mai multe eforturi pentru a culege starea tuturor deployment-urilor \u0219i a oferi acces la jurnale\/stare, de preferat legat de sistemul CD.<\/p>\n

              \u00cen acest sens, modelul push permite oferirea unor garan\u021bii \u00een ceea ce prive\u0219te implementarea, deoarece durata de via\u021b\u0103 a pipeline-ului poate fi egal\u0103 cu durata de via\u021b\u0103 a implement\u0103rii.<\/p>\n

              Am testat ambele modele \u0219i am ajuns la acelea\u0219i concluzii ca \u0219i autorul articolului:<\/p>\n

                \n
              1. Modelul Pull se potrive\u0219te pentru organizarea actualiz\u0103rii componentelor de sistem pe un num\u0103r mare de clustere (vezi articolul despre addon-operator<\/a><\/noindex>).<\/li>\n
              2. Modelul push bazat pe GitLab CI se potrive\u0219te bine pentru implementarea aplica\u021biilor prin intermediul chart-urilor Helm. \u00cen acest context, implementarea deployment-urilor \u00een cadrul pipeline-urilor este urm\u0103rit\u0103 cu ajutorul unui instrument werf<\/a><\/noindex>. Apropo, \u00een contextul acestui proiect al nostru, am auzit constant \u201eGitOps\u201d c\u00e2nd discutam despre problemele actuale ale inginerilor DevOps la standul nostru de la KubeCon Europe'19.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.S. de la traduc\u0103tor<\/h2>\n

                \nCiti\u021bi \u0219i \u00een blogul nostru:<\/p>\n