{"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\/hu\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps: A Pull \u00e9s Push m\u00f3dszerek \u00f6sszehasonl\u00edt\u00e1sa","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Megjegyz\u00e9s ford\u00edt\u00e1s.<\/b>: A Kubernetes k\u00f6z\u00f6ss\u00e9gben egyre n\u00e9pszer\u0171bb\u00e9 v\u00e1lik a GitOps n\u00e9ven ismert trend, aminek mi is tan\u00fai voltunk, amikor r\u00e9szt vett\u00fcnk<\/a><\/noindex> a KubeCon Europe 2019-en. Ez a kifejez\u00e9s viszonylag nemr\u00e9giben ker\u00fclt kital\u00e1l\u00e1sra<\/a><\/noindex> a Weaveworks c\u00e9g vezet\u0151je, Alexis Richardson \u00e1ltal, \u00e9s azt jelenti, hogy a fejleszt\u0151k \u00e1ltal megszokott eszk\u00f6z\u00f6ket (els\u0151sorban a Git-et, ahonnan a n\u00e9v is sz\u00e1rmazik) alkalmazz\u00e1k az \u00fczemeltet\u00e9si feladatok megold\u00e1s\u00e1ra. K\u00fcl\u00f6n\u00f6sen arr\u00f3l van sz\u00f3, hogy a Kubernetes \u00fczemeltet\u00e9s\u00e9t a konfigur\u00e1ci\u00f3k Git-ben t\u00f6rt\u00e9n\u0151 t\u00e1rol\u00e1s\u00e1val \u00e9s a v\u00e1ltoz\u00e1sok automatikus kihelyez\u00e9s\u00e9vel v\u00e9gezz\u00fck a klaszteren. Matthias Jg erre a kihelyez\u00e9si folyamatra k\u00e9t megk\u00f6zel\u00edt\u00e9st ismertet ebben a cikkben.<\/i><\/p>\n

\"GitOps:
\n
\nTavaly (val\u00f3j\u00e1ban form\u00e1lisan ez 2017 augusztus\u00e1ban t\u00f6rt\u00e9nt \u2014 a ford\u00edt\u00f3 megjegyz\u00e9se)<\/i> Megjelent egy \u00faj megk\u00f6zel\u00edt\u00e9s az alkalmaz\u00e1sok Kubernetesben t\u00f6rt\u00e9n\u0151 telep\u00edt\u00e9s\u00e9re. Ezt GitOps-nak h\u00edvj\u00e1k, \u00e9s alapj\u00e1t az adja, hogy a deployment v\u00e1ltoz\u00e1sainak nyomon k\u00f6vet\u00e9se egy biztons\u00e1gos Git-repozit\u00f3riumban t\u00f6rt\u00e9nik.<\/a><\/noindex><\/p>\n

Ennek a megk\u00f6zel\u00edt\u00e9snek az alapvet\u0151 el\u0151nyei a k\u00f6vetkez\u0151k<\/b>:<\/p>\n

    \n
  1. A deployment-ek verzi\u00f3kezel\u00e9se \u00e9s a v\u00e1ltoztat\u00e1sok t\u00f6rt\u00e9nete<\/b>. Az eg\u00e9sz klaszter \u00e1llapota a Git-repozit\u00f3riumban van t\u00e1rolva, \u00e9s a deployment-eket csak commitok r\u00e9v\u00e9n friss\u00edtik. Ezenk\u00edv\u00fcl minden v\u00e1ltoz\u00e1s nyomon k\u00f6vethet\u0151 a commitok t\u00f6rt\u00e9net\u00e9vel.<\/li>\n
  2. Rollback a megszokott Git parancsokkal<\/b>. Egyszer\u0171 git reset<\/code> lehet\u0151v\u00e9 teszi a deployment-ekben t\u00f6rt\u00e9nt v\u00e1ltoz\u00e1sok visszavon\u00e1s\u00e1t; a kor\u00e1bbi \u00e1llapotok mindig el\u00e9rhet\u0151k.<\/li>\n
  3. K\u00e9sz hozz\u00e1f\u00e9r\u00e9s-ellen\u0151rz\u00e9s<\/b>. A legt\u00f6bb Git rendszer sz\u00e1mos bizalmas adatot tartalmaz, ez\u00e9rt a c\u00e9gek kiemelt figyelmet ford\u00edtanak a v\u00e9delemre. K\u00f6vetkez\u00e9sk\u00e9ppen ez a v\u00e9delem a deployment-ekkel v\u00e9gzett m\u0171veletekre is vonatkozik.<\/li>\n
  4. Politik\u00e1k a telep\u00edt\u00e9sekhez<\/b>. A legt\u00f6bb Git rendszer alap\u00e9rtelmez\u00e9s szerint t\u00e1mogatja a k\u00fcl\u00f6nb\u00f6z\u0151 \u00e1gakra vonatkoz\u00f3 szab\u00e1lyokat \u2014 p\u00e9ld\u00e1ul csak a pull-requests friss\u00edthetik a master-t, a v\u00e1ltoztat\u00e1sokat pedig egy m\u00e1sik csapattagnak kell \u00e1tn\u00e9znie \u00e9s j\u00f3v\u00e1hagynia. Mint a hozz\u00e1f\u00e9r\u00e9s-ellen\u0151rz\u00e9s eset\u00e9ben, ugyanazok a szab\u00e1lyok vonatkoznak a deployment-ek friss\u00edt\u00e9seire is.<\/li>\n<\/ol>\n

    \nAhogy l\u00e1tja, a GitOps m\u00f3dszernek sz\u00e1mos el\u0151nye van. Az elm\u00falt \u00e9vben k\u00e9t megk\u00f6zel\u00edt\u00e9s k\u00fcl\u00f6n\u00f6sen n\u00e9pszer\u0171v\u00e9 v\u00e1lt. Az egyik a push-alap\u00fa, a m\u00e1sik a pull-alap\u00fa. Miel\u0151tt ezeket megvizsg\u00e1ln\u00e1nk, el\u0151sz\u00f6r n\u00e9zz\u00fck meg, hogyan n\u00e9znek ki a tipikus Kubernetes deployment-ek.<\/p>\n

    Telep\u00edt\u00e9si m\u00f3dok<\/h2>\n

    \nAz ut\u00f3bbi \u00e9vekben a Kubernetes-alap\u00fa k\u00fcl\u00f6nf\u00e9le telep\u00edt\u00e9si m\u00f3dok \u00e9s eszk\u00f6z\u00f6k alakultak ki:<\/p>\n

      \n
    1. A Kubernetes \/ Kustomize nat\u00edv sablonjaira alapozva<\/b>Ez a legegyszer\u0171bb m\u00f3dja az alkalmaz\u00e1sok telep\u00edt\u00e9s\u00e9nek a Kubernetesben. A fejleszt\u0151 alap YAML f\u00e1jlokat k\u00e9sz\u00edt \u00e9s alkalmazza \u0151ket. Annak \u00e9rdek\u00e9ben, hogy megszabaduljon az \u00e1lland\u00f3an \u00fajra\u00edrhat\u00f3 sablonokt\u00f3l, kifejlesztett\u00e9k a Kustomize-ot (ez a Kubernetes sablonokat modulokk\u00e1 alak\u00edtja). Megjegyz\u00e9s ford\u00edt\u00e1s.<\/b>: A Kustomize integr\u00e1lva van a kubectl-lel a Kubernetes 1.14-es verzi\u00f3j\u00e1val.<\/a><\/noindex>.<\/i><\/li>\n
    2. Helm chartok.<\/b>. A Helm chart-ok lehet\u0151v\u00e9 teszik sablonok, init-kont\u00e9nerek, sidecar-ok stb. k\u00e9sz\u00edt\u00e9s\u00e9t, amelyek alkalmaz\u00e1sok telep\u00edt\u00e9s\u00e9re szolg\u00e1lnak, rugalmasabb be\u00e1ll\u00edt\u00e1si lehet\u0151s\u00e9gekkel, mint a sablon-alap\u00fa megk\u00f6zel\u00edt\u00e9ssel. A m\u00f3dszer alapj\u00e1t a sablonos\u00edtott YAML-f\u00e1jlok k\u00e9pezik. A Helm ezeket k\u00fcl\u00f6nf\u00e9le param\u00e9terekkel t\u00f6lti ki, majd a Tiller-nek k\u00fcldi \u2014 a klaszter \u00f6sszetev\u0151j\u00e9nek, amely telep\u00edti azokat a klaszterbe \u00e9s lehet\u0151v\u00e9 teszi a friss\u00edt\u00e9seket \u00e9s visszag\u00f6rget\u00e9seket. Fontos, hogy gyakorlatilag a Helm egyszer\u0171en behelyettes\u00edti a sz\u00fcks\u00e9ges \u00e9rt\u00e9keket a sablonokba, majd alkalmazza azokat, ahogyan az a hagyom\u00e1nyos megk\u00f6zel\u00edt\u00e9s sor\u00e1n t\u00f6rt\u00e9nik. (tov\u00e1bbi inform\u00e1ci\u00f3kat arr\u00f3l, hogyan m\u0171k\u00f6dik mindez, \u00e9s hogyan haszn\u00e1lhat\u00f3, olvasson el a Helm cikk\u00fcnkb\u0151l.<\/a><\/noindex> \u2014 a ford\u00edt\u00f3 megjegyz\u00e9se)<\/i>. Sz\u00e1mos k\u00e9sz Helm chart l\u00e9tezik, amelyek sz\u00e9les spektrum\u00fa feladatokat \u00f6lelnek fel.<\/li>\n
    3. Alternat\u00edv eszk\u00f6z\u00f6k.<\/b>Sok alternat\u00edv eszk\u00f6z l\u00e9tezik. K\u00f6z\u00f6s benn\u00fck, hogy \u00e1talak\u00edtanak bizonyos sablon f\u00e1jlokat \u00e9rthet\u0151 Kubernetes YAML f\u00e1jlokk\u00e1, majd alkalmazz\u00e1k \u0151ket.<\/li>\n<\/ol>\n

      \nA munk\u00e1nk sor\u00e1n folyamatosan haszn\u00e1lunk Helm chartokat fontos eszk\u00f6z\u00f6kh\u00f6z (mivel sok minden k\u00e9szen \u00e1ll, ami jelent\u0151sen megk\u00f6nny\u00edti az \u00e9let\u00fcnket), \u00e9s \"tiszta\" Kubernetes YAML f\u00e1jlokat a saj\u00e1t alkalmaz\u00e1saink telep\u00edt\u00e9s\u00e9re.<\/p>\n

      Pull & Push.<\/h2>\n

      \nA k\u00f6zelm\u00faltban a blogomban bemutattam egy eszk\u00f6zt, Weave Flux<\/a><\/noindex>, lehet\u0151v\u00e9 t\u00e9ve a sablonok commit\u00e1l\u00e1s\u00e1t a Git-repozit\u00f3riumban, \u00e9s a deployment friss\u00edt\u00e9s\u00e9t minden egyes commit vagy a kont\u00e9ner push ut\u00e1n. Tapasztalataim szerint ez az eszk\u00f6z az egyik alapvet\u0151 a pull-alap\u00fa megk\u00f6zel\u00edt\u00e9s n\u00e9pszer\u0171s\u00edt\u00e9s\u00e9ben, ez\u00e9rt gyakran hivatkozni fogok r\u00e1. Ha t\u00f6bbet szeretne megtudni arr\u00f3l, hogyan haszn\u00e1lja, itt van link a cikkhez.<\/a><\/noindex>.<\/p>\n

      NB!<\/b> A GitOps haszn\u00e1lat\u00e1nak minden el\u0151nye \u00e9rv\u00e9nyes\u00fcl mindk\u00e9t megk\u00f6zel\u00edt\u00e9sn\u00e9l.<\/i><\/p>\n

      Pull megk\u00f6zel\u00edt\u00e9s<\/h2>\n

      \n\"GitOps:
      \n
      \nA pull megk\u00f6zel\u00edt\u00e9s alapja az a t\u00e9ny, hogy minden v\u00e1ltoztat\u00e1s a klaszter belsej\u00e9b\u0151l t\u00f6rt\u00e9nik. A klaszterben van egy oper\u00e1tor, amely folyamatosan ellen\u0151rzi a kapcsol\u00f3d\u00f3 Git \u00e9s Docker Registry-repozit\u00f3riumokat. Ha ezekben b\u00e1rmilyen v\u00e1ltoz\u00e1s t\u00f6rt\u00e9nik, a klaszter \u00e1llapota bel\u00fclr\u0151l friss\u00fcl. \u00c1ltal\u00e1ban \u00fagy v\u00e9lik, hogy az ilyen folyamat rendk\u00edv\u00fcl biztons\u00e1gos, mivel egyetlen k\u00fcls\u0151 kliens sem f\u00e9r hozz\u00e1 a klaszter adminisztr\u00e1tori jogaihoz.<\/p>\n

      El\u0151ny\u00f6k:<\/b><\/p>\n

        \n
      1. Egyetlen k\u00fcls\u0151 kliens sem rendelkezik jogosults\u00e1ggal a klaszter m\u00f3dos\u00edt\u00e1s\u00e1ra, az \u00f6sszes friss\u00edt\u00e9st bel\u00fclr\u0151l hajtj\u00e1k v\u00e9gre.<\/li>\n
      2. N\u00e9h\u00e1ny eszk\u00f6z lehet\u0151v\u00e9 teszi a Helm-diagramok friss\u00edt\u00e9seinek szinkroniz\u00e1l\u00e1s\u00e1t \u00e9s a klaszterhez val\u00f3 k\u00f6t\u00e9s\u00e9t.<\/li>\n
      3. A Docker Registry kereshet\u0151 \u00faj verzi\u00f3k ut\u00e1n. Ha \u00faj k\u00e9p jelenik meg, a Git-repozit\u00f3rium \u00e9s a telep\u00edt\u00e9s friss\u00fcl az \u00faj verzi\u00f3ra.<\/li>\n
      4. A pull-eszk\u00f6z\u00f6k k\u00fcl\u00f6nb\u00f6z\u0151 n\u00e9vt\u00e9rben, k\u00fcl\u00f6nb\u00f6z\u0151 Git-repozit\u00f3riumokkal \u00e9s jogosults\u00e1gokkal oszthat\u00f3k el. Ennek k\u00f6sz\u00f6nhet\u0151en alkalmazhat\u00f3 a multitenant modell. P\u00e9ld\u00e1ul az A csapat az A n\u00e9vteret haszn\u00e1lhatja, a B csapat a B n\u00e9vteret, m\u00edg az infrastrukt\u00far\u00e1val foglalkoz\u00f3 csapat glob\u00e1lis n\u00e9vteret haszn\u00e1lhat.<\/li>\n
      5. \u00c1ltal\u00e1ban az eszk\u00f6z\u00f6k meglehet\u0151sen k\u00f6nny\u0171ek.<\/li>\n
      6. Olyan eszk\u00f6z\u00f6kkel, mint az oper\u00e1tor Bitnami Sealed Secrets<\/a><\/noindex>, a titkok titkos\u00edtott form\u00e1ban t\u00e1rolhat\u00f3k a Git-repozit\u00f3riumban, \u00e9s a klaszter belsej\u00e9ben vonhat\u00f3k ki.<\/li>\n
      7. Nincs kapcsolat a CD-pipeline-ekkel, mivel a telep\u00edt\u00e9sek a klaszter belsej\u00e9ben t\u00f6rt\u00e9nnek.<\/li>\n<\/ol>\n

        \nH\u00e1tr\u00e1nyok<\/b>:<\/p>\n

          \n
        1. A Helm chart deployment's secrets management is more complex than usual, as they first need to be generated into, let's say, sealed secrets, then decrypted by the internal operator, and only after that are they available for the pull tool. You can then launch a release in Helm with the values already deployed in the secrets. The simplest way is to create a secret with all the Helm values used for the deployment, decrypt it, and commit it to Git.<\/li>\n
        2. By applying a pull approach, you are tied to tools operating with pulls. This limits the ability to customize the deployment process in the cluster. For example, working with Kustomize is complicated because it must be executed before the final templates reach Git. I'm not saying that separate tools can't be used, but they are harder to integrate into the deployment process.<\/li>\n<\/ol>\n

          <\/p>\n

          Push alap\u00fa megk\u00f6zel\u00edt\u00e9s<\/h2>\n

          \n\"GitOps:
          \n
          \nA push megk\u00f6zel\u00edt\u00e9sben egy k\u00fcls\u0151 rendszer (els\u0151sorban CD-pipeline-ok) ind\u00edt el telep\u00edt\u00e9seket a klaszterben a Git t\u00e1rol\u00f3ba t\u00f6rt\u00e9n\u0151 elk\u00f6telez\u0151d\u00e9s ut\u00e1n vagy a kor\u00e1bbi CI-pipeline sikeres fut\u00e1sa eset\u00e9n. Ebben a megk\u00f6zel\u00edt\u00e9sben a rendszer hozz\u00e1f\u00e9r\u00e9ssel rendelkezik a klaszterhez.<\/p>\n

          El\u0151ny\u00f6k<\/b>:<\/p>\n

            \n
          1. A biztons\u00e1g a Git t\u00e1rol\u00f3 \u00e9s a build pipeline \u00e1ltal meghat\u00e1rozott.<\/li>\n
          2. A Helm chartok telep\u00edt\u00e9se egyszer\u0171bb, H\u00e9jpluginok t\u00e1mogat\u00e1s\u00e1val.<\/li>\n
          3. A titkok kezel\u00e9se k\u00f6nnyebb, mivel a titkok a pipeline-okban alkalmazhat\u00f3k, illetve titkos\u00edtott form\u00e1ban t\u00e1rolhat\u00f3k a Git-ben (a felhaszn\u00e1l\u00f3 preferenci\u00e1i szerint).<\/li>\n
          4. Nincs k\u00f6t\u0151d\u00e9s egy adott eszk\u00f6zh\u00f6z, mivel b\u00e1rmilyen t\u00edpus\u00fa eszk\u00f6z haszn\u00e1lhat\u00f3.<\/li>\n
          5. A kont\u00e9nerv\u00e1ltoz\u00e1sok friss\u00edt\u00e9seket a build pipeline ind\u00edthatja.<\/li>\n<\/ol>\n

            \nH\u00e1tr\u00e1nyok<\/b>:<\/p>\n

              \n
            1. A klaszterhez val\u00f3 hozz\u00e1f\u00e9r\u00e9s adatai a build rendszeren bel\u00fcl tal\u00e1lhat\u00f3k.<\/li>\n
            2. Updating deployment containers is still easier with a pull process.<\/li>\n
            3. Er\u0151s f\u00fcgg\u0151s\u00e9g a CD-rendszert\u0151l, mivel a sz\u00fcks\u00e9ges pipeline-ok esetleg eredetileg Gitlab Runners-re \u00edr\u00f3dtak, majd a csapat \u00fagy d\u00f6nt, hogy \u00e1t\u00e1ll az Azure DevOps-ra vagy Jenkinsre... \u00e9s sok build pipeline migr\u00e1l\u00e1s\u00e1ra lehet sz\u00fcks\u00e9g.<\/li>\n<\/ol>\n

              <\/p>\n

              \u00d6sszegz\u00e9s: Push vagy Pull?<\/h2>\n

              \nMint ahogy az lenni szokott, minden megk\u00f6zel\u00edt\u00e9snek megvannak a maga el\u0151nyei \u00e9s h\u00e1tr\u00e1nyai. Egyes feladatokat k\u00f6nnyebb egyik m\u00f3dszerrel v\u00e9grehajtani, m\u00edg m\u00e1sokkal nehezebb. Eleinte manu\u00e1lisan v\u00e9geztem a telep\u00edt\u00e9seket, de miut\u00e1n r\u00e1bukkantam n\u00e9h\u00e1ny cikkre a Weave Fluxr\u00f3l, \u00fagy d\u00f6nt\u00f6ttem, hogy GitOps folyamatokat vezetek be minden projektbe. Az alap sablonok eset\u00e9ben ez egyszer\u0171nek bizonyult, de k\u00e9s\u0151bb neh\u00e9zs\u00e9gekbe \u00fctk\u00f6ztem a Helm chartokkal kapcsolatban. Akkoriban a Weave Flux csak a Helm Chart Operator kezdeti verzi\u00f3j\u00e1t k\u00edn\u00e1lta, de m\u00e9g most is vannak olyan feladatok, amelyeket nehez\u00edt a titkok manu\u00e1lis l\u00e9trehoz\u00e1s\u00e1nak \u00e9s alkalmaz\u00e1s\u00e1nak sz\u00fcks\u00e9gess\u00e9ge. Mondhatn\u00e1, hogy a pull megk\u00f6zel\u00edt\u00e9s sokkal biztons\u00e1gosabb, mivel a klaszter hiteles\u00edt\u0151 adatai nem hozz\u00e1f\u00e9rhet\u0151k azon k\u00edv\u00fcl, ami annyira n\u00f6veli a biztons\u00e1got, hogy meg\u00e9rdemli a plusz er\u0151fesz\u00edt\u00e9st.<\/p>\n

              After some thought, I came to the surprising conclusion that this is not the case. When it comes to components that require maximum protection, a list would include secret storage and CI\/CD systems, as well as Git repositories. The information within them is quite vulnerable and needs maximum protection. Moreover, if someone gains access to your Git repository and can push code there, they can deploy anything they want (regardless of whether it\u2019s pull or push), and infiltrate the cluster\u2019s systems. Thus, the most important components requiring protection are the Git repository and CI\/CD systems, not the cluster credentials. If you have well-configured policies and security measures for such systems, and the cluster credentials are fetched in pipelines only as secrets, the additional security of the pull approach may turn out to be not as valuable as initially thought.<\/p>\n

              Teh\u00e1t, ha a pull megk\u00f6zel\u00edt\u00e9s munkaig\u00e9nyesebb \u00e9s nem ny\u00fajt biztons\u00e1gi el\u0151nyt, nem lenne logikus csak a push megk\u00f6zel\u00edt\u00e9st haszn\u00e1lni? De valaki azt mondhatja, hogy a push megk\u00f6zel\u00edt\u00e9sn\u00e9l t\u00falzottan f\u00fcgg a CD-rendszert\u0151l, \u00e9s tal\u00e1n jobb elker\u00fclni ezt, hogy a j\u00f6v\u0151ben k\u00f6nnyebb legyen a migr\u00e1ci\u00f3.<\/p>\n

              Szerintem (ahogy mindig) azt kell haszn\u00e1lni, ami legjobban megfelel a konkr\u00e9t esetre, vagy kombin\u00e1lni kell \u0151ket. Szem\u00e9ly szerint mindk\u00e9t megk\u00f6zel\u00edt\u00e9st alkalmazom: a Weave Flux-ot a pull-alap\u00fa telep\u00edt\u00e9sekhez, amelyek f\u0151k\u00e9nt a saj\u00e1t szolg\u00e1ltat\u00e1sainkat tartalmazz\u00e1k, \u00e9s a Helm push megk\u00f6zel\u00edt\u00e9st, amely egyszer\u0171s\u00edti a Helm chartok alkalmaz\u00e1s\u00e1t a klaszterhez, \u00e9s lehet\u0151v\u00e9 teszi a titkok z\u00f6kken\u0151mentes l\u00e9trehoz\u00e1s\u00e1t. \u00dagy gondolom, soha nem lesz egyetlen megold\u00e1s, amely minden esetben megfelel\u0151, mivel mindig nagyon sok r\u00e9szlet van, \u00e9s ezek a konkr\u00e9t alkalmaz\u00e1si lehet\u0151s\u00e9gekt\u0151l f\u00fcggnek. Ez\u00e9rt hat\u00e1rozottan aj\u00e1nlom a GitOps-ot \u2013 nagym\u00e9rt\u00e9kben megk\u00f6nny\u00edti az \u00e9letet \u00e9s n\u00f6veli a biztons\u00e1got.<\/p>\n

              Rem\u00e9lem, hogy tapasztalataim ezen a ter\u00fcleten seg\u00edtenek meghat\u00e1rozni, hogy melyik m\u00f3dszer a legmegfelel\u0151bb az \u00d6n t\u00edpus\u00fa telep\u00edt\u00e9seihez, \u00e9s \u00f6r\u00f6mmel v\u00e1rom a v\u00e9lem\u00e9ny\u00e9t.<\/p>\n

              P.S. Megjegyz\u00e9s a ford\u00edt\u00f3t\u00f3l<\/h2>\n

              \nA pull modell h\u00e1tr\u00e1nyai k\u00f6z\u00f6tt van, hogy neh\u00e9z Git-be rakni a renderelt manifestumokat, azonban nem h\u00e1tr\u00e1ny, hogy a CD-pipeline a pull modellben k\u00fcl\u00f6n \u00e9l a telep\u00edt\u00e9st\u0151l, \u00e9s l\u00e9nyeg\u00e9ben egy k\u00fcl\u00f6n kateg\u00f3ri\u00e1j\u00fa pipeline-n\u00e1 v\u00e1lik. Folyamatos Alkalmaz\u00e1s<\/i>. Ez\u00e9rt m\u00e9g t\u00f6bb er\u0151fesz\u00edt\u00e9sre lesz sz\u00fcks\u00e9g ahhoz, hogy \u00f6sszegy\u0171jts\u00fck az \u00f6sszes telep\u00edt\u00e9s st\u00e1tusz\u00e1t, \u00e9s valahogy hozz\u00e1f\u00e9r\u00e9st biztos\u00edtsunk a napl\u00f3khoz\/st\u00e1tuszhoz, lehet\u0151leg a CD rendszerhez val\u00f3 kapcsol\u00f3d\u00e1ssal.<\/p>\n

              Ebben az \u00e9rtelemben a push-modell legal\u00e1bb n\u00e9mi garanci\u00e1t ad a kiad\u00e1sra, mert a pipeline \u00e9lettartam\u00e1t egyenl\u0151v\u00e9 lehet tenni a kiad\u00e1s \u00e9lettartam\u00e1val.<\/p>\n

              Kipr\u00f3b\u00e1ltuk mindk\u00e9t modellt, \u00e9s ugyanerre a k\u00f6vetkeztet\u00e9sre jutottunk, mint a cikk szerz\u0151je:<\/p>\n

                \n
              1. A pull modell alkalmas a rendszerszint\u0171 komponensek friss\u00edt\u00e9s\u00e9nek megszervez\u00e9s\u00e9re nagy sz\u00e1m\u00fa klaszterben (l\u00e1sd: a kieg\u00e9sz\u00edt\u0151 oper\u00e1torral kapcsolatos cikket<\/a><\/noindex>).<\/li>\n
              2. A GitLab CI-alap\u00fa push-modell j\u00f3l alkalmas alkalmaz\u00e1sok telep\u00edt\u00e9s\u00e9re Helm-charts haszn\u00e1lat\u00e1val. Ezzel egy\u00fctt a telep\u00edt\u00e9sek a pipeline-ok keretein bel\u00fcl a k\u00f6vetkez\u0151 eszk\u00f6zzel k\u00f6vethet\u0151k. werf<\/a><\/noindex>Ami \u00e9rdekes, hogy a projekt\u00fcnk kapcs\u00e1n folyamatosan hallottuk a \u201eGitOps\u201d kifejez\u00e9st, amikor a DevOps m\u00e9rn\u00f6k\u00f6k s\u00fcrget\u0151 probl\u00e9m\u00e1it vitattuk a KubeCon Europe'19-es standunkn\u00e1l.<\/li>\n<\/ol>\n

                <\/p>\n

                Megjegyz\u00e9s: Ez a cikk az IBM Cloud m\u00e9rn\u00f6kei \u00e1ltal v\u00e9gzett mini-kutat\u00e1s eredm\u00e9nye, amely a val\u00f3s probl\u00e9m\u00e1k megold\u00e1s\u00e1t c\u00e9lozta meg az etcd adatb\u00e1zis \u00fczemeltet\u00e9s\u00e9vel kapcsolatban.<\/h2>\n

                \nOlvasson tov\u00e1bbi inform\u00e1ci\u00f3kat a blogunkban:<\/p>\n