{"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\/et\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps: Pull ja Push meetodite v\u00f5rdlus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

M\u00e4rkus t\u00f5lke kohta.<\/b>: Kubernetes'i kogukonnas on populaarsust saavutanud trend nimega GitOps, mille t\u00f5husust oleme isiklikult n\u00e4inud, k\u00fclastades<\/a><\/noindex> KubeCon Europe 2019. See termin on suhteliselt hiljuti loodud<\/a><\/noindex> ettev\u00f5tte Weaveworks juhtimisest \u2014 Alexis Richardson \u2014 ja viitab arendajatele tuttavate t\u00f6\u00f6riistade (eelk\u00f5ige Git, kust ka nimi) kasutamisele operatiivsete probleemide lahendamiseks. Eelk\u00f5ige r\u00e4\u00e4gime Kubernetes'i haldamisest, salvestades selle konfiguratsioonid Git'is ja automaatsete muudatuste rakendamisest klastrisse. Kahest l\u00e4henemisest nende muudatuste rakendamisel r\u00e4\u00e4gib Matthias Jg k\u00e4esolevas artiklis.<\/i><\/p>\n

\"GitOps:
\n
\nEelmisel aastal (tegelikult toimus see formaalselt 2017. aasta augustis \u2014 t\u00e4iendav m\u00e4rkus t\u00f5lkijalt.)<\/i> Ilmus uus l\u00e4henemine rakenduste juurutamiseks Kuberneteses. Seda nimetatakse GitOps-iks, mille aluseks on p\u00f5him\u00f5te, et deploymintide versioonide j\u00e4lgimine toimub turvalises Git-repositooriumis.<\/a><\/noindex><\/p>\n

Selle l\u00e4henemise peamised eelised on j\u00e4rgmised<\/b>:<\/p>\n

    \n
  1. Deploymintide versioonimine ja muudatuste ajalugu<\/b>. Kogu klastrite seisund salvestatakse Git-repositooriumisse ja deploymendid uuendatakse ainult commitide kaudu. Lisaks on k\u00f5ik muudatused j\u00e4lgitavad commitide ajaloo abil.<\/li>\n
  2. Tagasiulatuvad muudatused tuttavate Git k\u00e4skude abil<\/b>. Lihtne git reset<\/code> v\u00f5imaldab muudatusi deploymendi puhul tagasi v\u00f5tta; varasemad seisundid on alati kergesti k\u00e4ttesaadavad.<\/li>\n
  3. Valmis juurdep\u00e4\u00e4suhaldus<\/b>. Tavaliselt sisaldab Git-s\u00fcsteem palju konfidentsiaalset teavet, seet\u00f5ttu p\u00f6\u00f6ravad enamus ettev\u00f5tteid sellele kaitsele erilist t\u00e4helepanu. Seega laieneb see kaitse ka deploymendiga seotud toimingutele.<\/li>\n
  4. Poliitikad juurutamiseks<\/b>. Enamik Git-s\u00fcsteeme toetab algselt poliitikaid erinevate harude jaoks \u2014 n\u00e4iteks v\u00f5ivad ainult pull requestid masterit uuendada, samas kui muudatused peavad olema kontrollitud ja kinnitatud m\u00f5ne teise meeskonna liikme poolt. Nagu juurdep\u00e4\u00e4su kontrolli puhul, kehtivad samad poliitikad ka deploymendi uuendustele.<\/li>\n<\/ol>\n

    \nNagu n\u00e4ete, on GitOps meetodil palju eeliseid. Viimase aasta jooksul on kaks l\u00e4henemist saanud erilist populaarsust. \u00dcks p\u00f5hineb push-l\u00e4henemisel, teine aga pull-l\u00e4henemisel. Enne nende arutamist vaatame k\u00f5igepealt, kuidas n\u00e4evad v\u00e4lja t\u00fc\u00fcpilised Kubernetes deploymendid.<\/p>\n

    Juurutamise viisid<\/h2>\n

    \nViimastel aastatel on Kubernetes'is kindlaks saanud mitmed juurutamise viisid ja t\u00f6\u00f6riistad:<\/p>\n

      \n
    1. P\u00f5hineb Kubernetes'i\/Kustomize'i natiivsetel mallidel<\/b>. See on lihtsaim viis rakenduste juurutamiseks Kuberneteses. Arendaja loob p\u00f5hielemendid YAML-failidest ja rakendab need. Korduvate \u0161abloonide uuesti kirjutamise v\u00e4ltimiseks t\u00f6\u00f6tati v\u00e4lja Kustomize (mis muudab Kubernetes \u0161abloonid mooduliteks). M\u00e4rkus t\u00f5lke kohta.<\/b>: Kustomize on integreeritud kubectl'iga versioonist Kubernetes 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Helm Chart'id<\/b>. Helm-chartid v\u00f5imaldavad luua mallikogumeid, init-konteinereid, sidecar'e jne, mis rakendatakse rakenduste deployimiseks, pakkudes paindlikumaid konfiguratsiooni v\u00f5imalusi v\u00f5rreldes mallip\u00f5hise l\u00e4henemisviisiga. Selle meetodi aluseks on mallitud YAML-failid. Helm t\u00e4idab need erinevate parameetritega ja saadab seej\u00e4rel Tiller'ile \u2014 klastrikomponendile, mis juurutab need klastris ja v\u00f5imaldab uuendusi ja tagasiulatuvaid muudatusi. Oluline on see, et sisuliselt lisab Helm vajalikke v\u00e4\u00e4rtusi mallidesse ja rakendab need samamoodi nagu traditsioonilise l\u00e4henemise puhul (lisainfot selle kohta, kuidas see k\u00f5ik t\u00f6\u00f6tab ja kuidas seda kasutada, leiate meie Helmi artiklist<\/a><\/noindex> \u2014 toimetaja m\u00e4rkus)<\/i>. On olemas suur valik valmis Helm-chart'e, mis katab laia valikut \u00fclesandeid.<\/li>\n
    3. Alternatiivsed t\u00f6\u00f6riistad<\/b>. On palju alternatiivseid t\u00f6\u00f6riistu. K\u00f5ik need muudavad teatud \u0161abloonifailid arusaadavateks Kubernetes YAML-failideks ja rakendavad need seej\u00e4rel.<\/li>\n<\/ol>\n

      \nMeie t\u00f6\u00f6s kasutame pidevalt Helm-chart'e oluliste t\u00f6\u00f6riistade jaoks (kuna need sisaldavad palju valmis komponente, mis lihtsustavad elu) ja \"puhtaid\" Kubernetes YAML-failisid oma rakenduste juurutamiseks.<\/p>\n

      Pull & Push<\/h2>\n

      \n\u00dches oma hiljutises blogipostituses tutvustasin t\u00f6\u00f6riista Weave Flux<\/a><\/noindex>, v\u00f5imaldades malli komiteerimise Git-repositooriumisse ja deploymendi uuendamist p\u00e4rast iga commit'i v\u00f5i konteineri push'i. Minu kogemus n\u00e4itab, et see t\u00f6\u00f6riist on \u00fcks p\u00f5hipunkte pull-l\u00e4henemise edendamisel, seega viitan sellele tihti. Kui soovite rohkem teada, kuidas seda kasutada, siis siin on link artiklile<\/a><\/noindex>.<\/p>\n

      NB!<\/b> K\u00f5ik GitOps'i kasutamise eelised kehtivad m\u00f5lema l\u00e4henemise puhul.<\/i><\/p>\n

      Pull-l\u00e4henemine<\/h2>\n

      \n\"GitOps:
      \n
      \nPull-l\u00e4hestumisstrateegia p\u00f5hineb t\u00f5siselt, et k\u00f5ik muudatused tehakse klastri seest. Klaster sisaldab operaatorit, kes regulaarselt kontrollib seotud Git-repositooriaid ja Docker Registry't. Kui seal toimuvad muudatused, uuendatakse klastri staatus seestpoolt. \u00dcldiselt peetakse seda protsessi \u00fcsna turvaliseks, kuna ei \u00fchelgi v\u00e4lisel kliendil ei ole juurdep\u00e4\u00e4su klastri administreerimis\u00f5igustele.<\/p>\n

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

        \n
      1. \u00dchelgi v\u00e4lisel kliendil ei ole \u00f5igusi muudatuste tegemiseks klastri sees, k\u00f5ik uuendused tehakse seestpoolt.<\/li>\n
      2. M\u00f5ned t\u00f6\u00f6riistad v\u00f5imaldavad samuti s\u00fcnkroonida Helm-chartide uuendusi ja seondada need klastriga.<\/li>\n
      3. Docker Registry't saab skaneerida uute versioonide olemasolu osas. Kui ilmub uus pilt, uuendatakse Git-repositoorium ja deploymendit uusimale versioonile.<\/li>\n
      4. Pull-t\u00f6\u00f6riistad v\u00f5ivad olla jaotatud erinevatesse ruumidesse, millel on erinevad Git-reposid ja ligip\u00e4\u00e4su\u00f5igused. Selle tulemusena saadakse multi\u00fc\u00fcrilise (multitenant) mudeli rakendamine. N\u00e4iteks v\u00f5ib meeskond A kasutada ruumi A, meeskond B ruumi B ja infrastruktuuri meeskond v\u00f5ib kasutada globaalset ruumi.<\/li>\n
      5. \u00dcldiselt on t\u00f6\u00f6riistad \u00fcsna kergekaalulised.<\/li>\n
      6. Koos selliste t\u00f6\u00f6riistadega nagu operaator, Bitnami Sealed Secrets<\/a><\/noindex>, v\u00f5ivad saladused olla kr\u00fcpteeritud kujul Git-repositoriumis ja neid saab klastris v\u00e4lja v\u00f5tta.<\/li>\n
      7. CD-piiplainidega pole seost, kuna deploymendid toimuvad klastris.<\/li>\n<\/ol>\n

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

          \n
        1. Salvestada Helm diagrammide deployment\u2019ide saladusi on keerulisem kui tavap\u00e4raste haldust\u00f6\u00f6de puhul, kuna neid tuleb esmalt genereerida n\u00e4iteks suletud saladustena, seej\u00e4rel dekr\u00fcpteerida sisemise operaatori poolt ja ainult p\u00e4rast seda on need saadaval pull-t\u00f6\u00f6riistale. Seej\u00e4rel saab Helm\u2019is k\u00e4ivitada v\u00e4ljaande olemasolevate saladustes olevate v\u00e4\u00e4rtustega. K\u00f5ige lihtsam viis on luua saladus, mis sisaldab k\u00f5iki deployment\u2019iks vajalikku Helm v\u00e4\u00e4rtuste, dekr\u00fcpteerida see ja commitida Git\u2019i.<\/li>\n
        2. Kasutades pull-l\u00e4hteviisi, olete seotud t\u00f6\u00f6riistadega, mis t\u00f6\u00f6tavad pull\u2019idega. See piirab v\u00f5imalusi kohandada deployment\u2019ide tehnikat klastris. N\u00e4iteks Kustomize\u2019iga t\u00f6\u00f6tamine on keerulisem, kuna see peab olema l\u00f5pule viidud enne, kui l\u00f5ppmallid sisenevad Git\u2019i. Ma ei \u00fctle, et eraldi t\u00f6\u00f6riistu ei saa kasutada, kuid nende integreerimine deployment-protsessi on keerulisem.<\/li>\n<\/ol>\n

          <\/p>\n

          Push-approach<\/h2>\n

          \n\"GitOps:
          \n
          \nPush-approach'i puhul k\u00e4ivitab v\u00e4line s\u00fcsteem (peamiselt CD-torud) klastris deploy'e p\u00e4rast Git'i reposiitri commit'i tegemist v\u00f5i eelmise CI-toru edukat t\u00e4itmist. Selle l\u00e4henemise korral on s\u00fcsteemil juurdep\u00e4\u00e4s klastrile.<\/p>\n

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

            \n
          1. Turvalisus m\u00e4\u00e4ratakse Git'i reposiitri ja ehituspipeliini kaudu.<\/li>\n
          2. Helm'i charte on lihtsam deployida, olemas on Helm'i pluginad.<\/li>\n
          3. Salajaste haldamine on lihtsam, kuna saladusi saab rakendada pipeliinides ja samuti salvestada Git'is kr\u00fcpteeritud kujul (s\u00f5ltuvalt kasutaja eelistustest).<\/li>\n
          4. Spetsiifiliste t\u00f6\u00f6riistade seose puudumine, kuna saab kasutada igasuguseid t\u00f6\u00f6riistu.<\/li>\n
          5. Konteinerite versioonide uuendusi saab k\u00e4ivitada ehituspipeliini kaudu.<\/li>\n<\/ol>\n

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

              \n
            1. Andmed juurdep\u00e4\u00e4suks klastrile asuvad ehituss\u00fcsteemi sees.<\/li>\n
            2. Konteinerite deployment\u2019ide v\u00e4rskendamine on siiski pull-protsessiga lihtsam.<\/li>\n
            3. Tugev s\u00f5ltuvus CD-s\u00fcsteemist, kuna vajalikud pipeliinid on v\u00f5ib-olla algselt kirjutatud Gitlab Runners'i jaoks, kuid seej\u00e4rel otsustab meeskond \u00fcle minna Azure DevOpsile v\u00f5i Jenkinsile... ja tuleb migreerida suur hulk ehituspipeliine.<\/li>\n<\/ol>\n

              <\/p>\n

              Kokkuv\u00f5tted: Push v\u00f5i Pull?<\/h2>\n

              \nNagu tavaliselt, igal l\u00e4henemisel on oma plussid ja miinused. M\u00f5ned \u00fclesanded on \u00fchega lihtsamad, teisega aga keerulisemad. Alguses tegin ma juurutamisi k\u00e4sitsi, kuid p\u00e4rast mitme Weave Fluxi kohta kirjutatud artikli lugemist otsustasin rakendada GitOps-protsesse k\u00f5igis projektides. K\u00f5ikide baasskeemide puhul oli see lihtne, kuid hiljem hakkasin kogema raskusi Helm-chartide kasutamisel. Sel ajal pakkus Weave Flux vaid algelise versiooni Helm Chart Operatoorist, kuid isegi praegu on m\u00f5ned \u00fclesanded keerulised, kuna tuleb k\u00e4sitsi luua saladusi ja neid rakendada. V\u00f5ite \u00f6elda, et pull-l\u00e4henemine on palju turvalisem, kuna klastri mandaat ei ole tema v\u00e4lispindadel ligip\u00e4\u00e4setav, mis suurendab turvalisust nii palju, et see \u00f5igustab lisapingutusi.<\/p>\n

              Veidi m\u00f5elnud j\u00f5udsin ootamatule j\u00e4reldusele, et see ei ole tegelikult nii. Kui r\u00e4\u00e4kida komponentidest, mis vajavad maksimaalset kaitset, kuuluvad sellesse nimekirja saladuste hoidlad ja CI\/CD s\u00fcsteemid, Git-repositooriumid. Nendes olev teave on v\u00e4ga haavatav ja vajab maksimaalset kaitset. Lisaks, kui keegi p\u00e4\u00e4seb teie Git-repositooriumisse ja suudab sinna koodi push\u2019ida, siis suudab ta k\u00e4ivitada k\u00f5ike, mida soovib (olgu see pull v\u00f5i push l\u00e4henemine), ja tungida klastris\u00fcsteemidesse. Seet\u00f5ttu on k\u00f5ige olulisemad kaitset vajavad komponendid Git-repositooriumid ja CI\/CD s\u00fcsteemid, mitte klastrikonto andmed. Kui teil on h\u00e4sti konfigureeritud poliitikad ja turvameetmed selliste s\u00fcsteemide jaoks ning klastrikonto andmed tuuakse pipeline\u2019idesse ainult saladustena, v\u00f5ib pull-l\u00e4hteviisi t\u00e4iendav turvalisus osutuda mitte nii v\u00e4\u00e4rtuslikuks, kui algselt arvati.<\/p>\n

              Nii et kui pull-l\u00e4henemine on t\u00f6\u00f6mahukam ja ei paku turvalisuse eeliseid, kas ei oleks loogiline kasutada ainult push-l\u00e4henemist? Kuid keegi v\u00f5ib v\u00e4ita, et push-l\u00e4henemine seab teid liiga kinni CD-s\u00fcsteemi, ja v\u00f5ib-olla on parem mitte niimoodi teha, et oleks tulevikus lihtsam migratsioone teostada.<\/p>\n

              Minu arvates (nagu alati) tuleks kasutada seda, mis sobib konkreetse juhtumiga k\u00f5ige paremini, v\u00f5i kombineerida. Isiklikult kasutan m\u00f5lemat l\u00e4henemist: Weave Flux deploy\u2019ide jaoks, mis p\u00f5hinevad pull'il ja h\u00f5lmavad peamiselt meie enda teenuseid, ning push-l\u00e4henemist Helm\u2019i ja pluginatega, mis lihtsustavad Helm-chartide rakendamist klastrisse ja v\u00f5imaldavad probleemideta luua salajasi andmeid. Arvan, et ei j\u00e4\u00e4 kunagi \u00fchtset lahendust, mis sobib k\u00f5igi juhtumite jaoks, kuna n\u00fcansse on alati palju ja need s\u00f5ltuvad konkreetsest rakendusvariandist. Sellegipoolest soovitan tungivalt GitOps\u2019i - see lihtsustab elu ja suurendab turvalisust.<\/p>\n

              Loodan, et minu kogemus antud teemal aitab teil v\u00e4lja selgitada, milline meetod sobib k\u00f5ige paremini teie t\u00fc\u00fcpi deploy\u2019ide jaoks, ja ma oleksin hea meelega kursis teie arvamusega.<\/p>\n

              P.S. T\u00f5lkija m\u00e4rkus<\/h2>\n

              \nPull-mudeli miinustes on punkt, et raske on Git'i panna renderdatud manifestid, kuid ei ole miinust, et CD-pipelii pull-mudelis elab eraldi vabanemisest ja muutub essentsiaalselt kategooria pipeliiniks Continuous Apply<\/i>. Seet\u00f5ttu vajatakse veelgi rohkem pingutusi, et koguda k\u00f5ikide deploy\u2019de staatust ja kuidagi anda juurdep\u00e4\u00e4s logidele\/staatusele, eelistatult koos CD s\u00fcsteemi sidumisega.<\/p>\n

              Selles m\u00f5ttes v\u00f5imaldab push-mudel anda mingeidki garantiisid deploy\u2019ide v\u00e4ljalaskmiseks, kuna pipeline'i eluiga saab seada v\u00f5rdseks v\u00e4ljalaske elueaga.<\/p>\n

              Oleme proovinud m\u00f5lemat mudelit ja j\u00f5udnud samadele j\u00e4reldustele nagu artikli autor:<\/p>\n

                \n
              1. Pull-mudel sobib meile s\u00fcsteemikomponentide v\u00e4rskendamise korraldamiseks suure hulga klastrite peal (vt. artiklit addon-operator'i kohta<\/a><\/noindex>).<\/li>\n
              2. Push-mudel, mis p\u00f5hineb GitLab CI-l, sobib h\u00e4sti rakenduste v\u00e4ljalaskmiseks Helm-chartide abil. Selle k\u00e4igus j\u00e4lgitakse deploy\u2019de v\u00e4ljalaskmist pipeline\u2019ide raames t\u00f6\u00f6riista abil werf<\/a><\/noindex>. Muide, selle projekti kontekstis kuulsime pidevalt \u201eGitOps\u2019, kui arutasime DevOps-inseneride aktuaalseid probleeme oma stendis KubeCon Europe\u201919.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.S. t\u00f5lkijalt<\/h2>\n

                \nLugege ka meie blogist:<\/p>\n