{"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: Pulli ja Pushi meetodite v\u00f5rdlus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

M\u00e4rk. t\u00f5lge.<\/b>: Kubernetes'e kogukonnas on populaarsust kogumas suund nimega GitOps, milles oleme isiklikult veendunud, k\u00fclastades<\/a><\/noindex> KubeCon Europe 2019. See termin m\u00f5eldi v\u00e4lja suhteliselt hiljuti Weaveworks'i juhi \u2014 Alexis Richardson'i poolt \u2014 ja see t\u00e4hendab arendajatele tuttavate vahendite (esmaj\u00e4rjekorras Git, kust ka nimi) kasutamist operatiivsete \u00fclesannete lahendamiseks. Eelk\u00f5ige r\u00e4\u00e4gime Kubernetes'e haldamisest, salvestades selle konfiguratsioonid Git'isse ja rakendades muudatused automaatselt klastrisse. Kahest l\u00e4henemisest sellele rakendusele r\u00e4\u00e4gib Matthias Jg k\u00e4esolevas artiklis.<\/a><\/noindex> Weaveworks'i tegevjuhi Alexis Richardsoni selgituses t\u00e4hendab see arendajatele tuttavate t\u00f6\u00f6riistade (eelk\u00f5ige Git'i, mille j\u00e4rgi see nimi on saanud) rakendamist operatiivt\u00f6\u00f6de lahendamiseks. T\u00e4psemalt \u00f6eldes r\u00e4\u00e4gime Kubernetes'i haldamisest, hoides selle konfigureerimisi Git'is ja automaatsete muudatuste rakendamisest klastrisse. Kahest l\u00e4henemisviisist nende muudatuste rakendamisel r\u00e4\u00e4gib Matthias Jg antud artiklis.<\/i><\/p>\n

\"GitOps:
\n
\nEelmisel aastal (tegelikult juhtus see formaalselt 2017. aasta augustis \u2014 m\u00e4rk. t\u00f5lge.)<\/i> ilmunud on uus l\u00e4henemine rakenduste juurutamiseks Kuberneteses. Seda nimetatakse GitOps-iks, mille p\u00f5hialuseks on arusaam, et juurutamiste versioonide j\u00e4lgimine toimub Git-repo turvalises keskkonnas.<\/a><\/noindex><\/p>\n

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

    \n
  1. Juurutamiste versioonimine ja muudatuste ajalugu<\/b>. Kogu klastriseisund salvestatakse Git-repos, ning juurutamisi uuendatakse ainult commit'ide kaudu. Lisaks saab k\u00f5iki muudatusi j\u00e4lgida commit-ide ajalooga.<\/li>\n
  2. Tagasiv\u00f5tmised, kasutades tuttavaid Git-k\u00e4sku<\/b>. Lihtne git reset<\/code> lubab tagasi p\u00f6\u00f6rduda juurutamiste muutustes; minevikud olekud on alati kergesti ligip\u00e4\u00e4setavad.<\/li>\n
  3. Valmis juurdep\u00e4\u00e4sukontroll<\/b>. T\u00fc\u00fcpiliselt sisaldab Git-s\u00fcsteem hulgaliselt konfidentsiaalset teavet, mist\u00f5ttu p\u00f6\u00f6ravad enamik ettev\u00f5tteid erilist t\u00e4helepanu selle kaitsmisele. Vastavalt laieneb see kaitse ka juurutamistele.<\/li>\n
  4. Poliitikad deployment\u2019ide jaoks<\/b>. Enamik Git-s\u00fcsteemidest toetab algselt poliitikaid erinevatele harudele \u2014 n\u00e4iteks v\u00f5ivad ainult pull request'id v\u00e4rskendada masterit, ning muudatused peab kontrollima ja kinnitama teine meeskonna liige. Ligip\u00e4\u00e4su kontrolliga seonduvalt kehtivad samad poliitikad ka juurutamiste v\u00e4rskendustele.<\/li>\n<\/ol>\n

    \nNagu n\u00e4ete, on GitOps meetodil palju eeliseid. Viimase aasta jooksul on kaks l\u00e4henemist saavutanud erilist populaarsust. \u00dcks p\u00f5hineb push-l\u00e4htepunktidel, teine aga pull-l\u00e4htepunktidel. Enne nende arutamist vaatame esmalt, millised on t\u00fc\u00fcpilised Kubernetes'i juurutused.<\/p>\n

    Deployment'ide meetodid<\/h2>\n

    \nViimastel aastatel on Kubernetesis kujunenud v\u00e4lja erinevad meetodid ja t\u00f6\u00f6riistad rakenduste juurutamiseks:<\/p>\n

      \n
    1. Kubernetes\/Kustomize'i natiivsete mallide p\u00f5hjal<\/b>. See on k\u00f5ige lihtsam rakenduste juurutamise viis Kubernetesis. Arendaja loob p\u00f5hjalikud YAML-failid ja rakendab need. \u00dchenduses pideva sama malli uuesti kirjutamisega on v\u00e4lja t\u00f6\u00f6tatud Kustomize (see muudab Kubernetes'i mallid mooduliteks). M\u00e4rk. t\u00f5lge.<\/b>: Kustomize on integreeritud kubectl-ga alates Kubernetes 1.14 versioonist<\/a><\/noindex>.<\/i><\/li>\n
    2. Helm'i chart'id<\/b>. Helm'i graafikud v\u00f5imaldavad luua malle, init-konteinereid, sidecar'e ja muud, mida kasutatakse rakenduste juurutamiseks, pakkudes paindlikumaid konfiguratsiooniv\u00f5imalusi kui \u0161abloonip\u00f5hine l\u00e4henemine. Selle meetodi aluseks on malleeritud YAML-failid. Helm t\u00e4idab need erinevate parameetritega ja saadab seej\u00e4rel Tiller'ile \u2014 klastrikomponendile, mis paigaldab need klastrisse ja v\u00f5imaldab uuendusi ja tagasiv\u00f5ttu. Oluline on see, et Helm lihtsalt sisestab vajalikud v\u00e4\u00e4rtused malli ja rakendab need nii, nagu tehakse traditsioonilises l\u00e4henemises. (rohkem selle kohta, kuidas see k\u00f5ik t\u00f6\u00f6tab ja kuidas seda kasutada, loe meie Helm'i artiklist<\/a><\/noindex> \u2014 kt. t\u00f5lge)<\/i>. On olemas suur valik valmis Helm-chart'e, mis katab laia valikut \u00fclesandeid.<\/li>\n
    3. Alternatiivsed t\u00f6\u00f6riistad<\/b>. On mitmeid alternatiivseid t\u00f6\u00f6riistu. Kuldne liitja on see, et nad muudavad mingid mallifailid arusaadavateks Kubernetes YAML-failideks ja seej\u00e4rel rakendavad need.<\/li>\n<\/ol>\n

      \nOma t\u00f6\u00f6s kasutame pidevalt Helm-chart'e oluliste t\u00f6\u00f6riistade jaoks (kuna neis on palju juba valmis, mis lihtsustab elu) ja \u201epuhasid\u201d Kubernetes YAML-failid oma rakenduste juurutamiseks.<\/p>\n

      Pull & Push<\/h2>\n

      \n\u00dches oma hiljutises blogipostituses tutvustasin t\u00f6\u00f6riista Weave Flux<\/a><\/noindex>, mis v\u00f5imaldab kommitida malli Git-reposiiti ja uuendada juurutust p\u00e4rast iga kommiti v\u00f5i konteineri push’imist. Minu kogemus n\u00e4itab, et see t\u00f6\u00f6riist on \u00fcks peamisi pull-approach'i edendamise vahendeid, seet\u00f5ttu viitan ma sellele sageli. Kui soovite rohkem teada, kuidas seda kasutada, siis siin on artikkel<\/a><\/noindex>.<\/p>\n

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

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

      \n\"GitOps:
      \n
      \nPull-approach'i alus on see, et k\u00f5ik muudatused rakendatakse klusteri seestpoolt. Klusteris on operaator, mis regulaarselt kontrollib seotud Git ja Docker Registry reposid. Kui seal toimub mingeid muudatusi, uuendatakse klusteri olek seestpoolt. \u00dcldiselt peetakse sarnast protsessi \u00fcsna ohutuks, kuna \u00fchelgi v\u00e4lisel kliendil pole juur\u00f5igusi klusterile.<\/p>\n

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

        \n
      1. \u00dchelgi v\u00e4lisel kliendil pole \u00f5igusi klusterisse muudatusi teha, k\u00f5ik uuendused rakendatakse seestpoolt.<\/li>\n
      2. M\u00f5ned t\u00f6\u00f6riistad v\u00f5imaldavad samuti Helm-chartide uuenduste s\u00fcnkroonimist ja nende sidumist klastriga.<\/li>\n
      3. Docker Registry't saab skaneerida uute versioonide leidmiseks. Kui ilmub uus pilt, uuendatakse Git-repo ja deployment uuteks versioonideks.<\/li>\n
      4. T\u00f5mbet\u00f6\u00f6riistad v\u00f5ivad olla jaotatud erinevatesse nimekohtadesse koos erinevate Git-repositooriumide ja juurdep\u00e4\u00e4su\u00f5igustega. Selle kaudu saab rakendada mitme\u00fc\u00fcrilise mudeli. N\u00e4iteks v\u00f5ib meeskond A kasutada nimekohta A, meeskond B nimekohta B ning infrastruktuuri haldav meeskond v\u00f5ib kasutada globaalset nimekohta.<\/li>\n
      5. Tavaliselt on t\u00f6\u00f6riistad v\u00e4ga kerged.<\/li>\n
      6. Koos selliste t\u00f6\u00f6riistadega nagu operaator Bitnami Sealed Secrets<\/a><\/noindex>, saavad saladused salvestuda kr\u00fcpteeritud kujul Git-repositooriumisse ja neid saab klastri sees v\u00e4lja v\u00f5tta.<\/li>\n
      7. CD-pipeline'idega pole \u00fchendust, kuna juurutamised toimuvad klastri sees.<\/li>\n<\/ol>\n

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

          \n
        1. Juurutuste saladuste haldamine Helm-chartide hulgast on keerulisem kui tavalised, kuna neid tuleb esmalt genereerida n\u00e4iteks suletud saladustena, seej\u00e4rel dekr\u00fcpteerida sisemise operaatori poolt ja alles siis on need pull-t\u00f6\u00f6riistale k\u00e4ttesaadavad. Seej\u00e4rel saab Helm’is k\u00e4ivitada v\u00e4ljaande juba juurutatud saladustes olevate v\u00e4\u00e4rtustega. Lihtsaim viis on luua saladus k\u00f5igi juurutuse jaoks kasutatavate Helm v\u00e4\u00e4rtustega, dekr\u00fcpteerida see ja kommitida Git-i.<\/li>\n
        2. Pull-approach'i rakendamine seob teid t\u00f6\u00f6riistadega, mis t\u00f6\u00f6tavad pull'idega. See piirab teie v\u00f5imet kohandada deployment'i protsessi klastris. N\u00e4iteks Kustomize'i kasutamine muutub keeruliseks, kuna seda tuleb k\u00e4ivitada enne, kui l\u00f5plikud mallid Git'i j\u00f5uavad. Ma ei v\u00e4ida, et eraldi t\u00f6\u00f6riistade kasutamine ei ole v\u00f5imalik, kuid nende integreerimine deploy\u00adment'i protsessi on keerulisem.<\/li>\n<\/ol>\n

          <\/p>\n

          Push-p\u00f5hine l\u00e4henemine<\/h2>\n

          \n\"GitOps:
          \n
          \nPush-l\u00e4henemise korral k\u00e4ivitab v\u00e4line s\u00fcsteem (peamiselt CD-pipeurad) klastrisse juurutusi Git-repo kohustusest v\u00f5i eelneva CI-pipeuri edukast t\u00e4itmisest. Selles l\u00e4henemises on s\u00fcsteemil juurdep\u00e4\u00e4s klastrile.<\/p>\n

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

            \n
          1. Turvalisus m\u00e4\u00e4ratakse Git-repositoiumi ja koostamispipeuri poolt.<\/li>\n
          2. Helm-chartide juurutamine on kergem, kuna on olemas Helm-pluginite tugi.<\/li>\n
          3. Salajaste haldamine on lihtsam, kuna salajasi saab rakendada pipeurades ja samuti salvestada Git'is kr\u00fcpteeritud kujul (vastavalt kasutaja eelistustele).<\/li>\n
          4. Ei ole spetsiifilist t\u00f6\u00f6riista, kuna saab kasutada igasuguseid.<\/li>\n
          5. Konteinerite versioonide uuendusi v\u00f5ib algatada koostamispipeur.<\/li>\n<\/ol>\n

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

              \n
            1. Juurdep\u00e4\u00e4suklahvi andmed asuvad koostamiss\u00fcsteemi sees.<\/li>\n
            2. Containerite deployment'ide uuendamine on endiselt lihtsam pull-protsessi k\u00e4igus.<\/li>\n
            3. Tugev s\u00f5ltuvus CD-s\u00fcsteemist, kuna vajalikud pipeurid v\u00f5ivad olla algselt kirjutatud Gitlabi Runner'itele ja seej\u00e4rel otsustab meeskond \u00fcle minna Azure DevOps'ile v\u00f5i Jenkins'ile... ning tuleb teostada suure hulga koostamispipeuride migratsioon.<\/li>\n<\/ol>\n

              <\/p>\n

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

              \nNagu tavaliselt on igal l\u00e4henemisel oma eelised ja puudused. M\u00f5ned \u00fclesanded on lihtsamad \u00fchega teostada ja keerulisemad teisega. Alguses tegin juurutusi k\u00e4sitsi, kuid p\u00e4rast mitmete Weave Fluxi artiklite leidmist otsustasin rakendada GitOps-protsesse k\u00f5igi projektide jaoks. P\u00f5hijoonistega osutus see lihtsaks, kuid hiljem hakkasin kohtama raskusi Helm-chart'idega t\u00f6\u00f6tamisel. Sel ajal pakkus Weave Flux vaid algelise versiooni Helm Chart Operatorist, kuid isegi n\u00fc\u00fcd on m\u00f5ned \u00fclesanded keerulisemad k\u00e4sitsi loodud saladuste loomise ja nende rakendamise t\u00f5ttu. V\u00f5ite \u00f6elda, et pull-l\u00e4henemine on palju turvalisem, kuna klastri mandaadid ei ole v\u00e4ljastpoolt kergesti ligip\u00e4\u00e4setavad, mis suurendab turvalisust nii palju, et see tasub lisatingimusi.<\/p>\n

              P\u00e4rast natuke m\u00f5tlemist j\u00f5udsin \u00fcllatavale j\u00e4reldusele, et see pole nii. Maximaalset kaitset vajavate komponentide hulka kuuluvad saladuste hoidlad ja CI\/CD s\u00fcsteemid, Git-repositorid. Teave nende sees on \u00e4\u00e4rmiselt haavatav ja vajab maksimaalset kaitset. Lisaks, kui keegi p\u00e4\u00e4seb teie Git-repositori, ja suudab sinna koodi push'ida, siis saab ta juurutada k\u00f5ike, mida soovib (\u00fcksk\u00f5ik, kas see on pull v\u00f5i push meetod), ja siseneda klastris\u00fcsteemidesse. Seega on k\u00f5ige olulisemad komponendid, mida tuleb kaitsta, Git-repositor ja CI\/CD s\u00fcsteemid, mitte klastriga seotud mandaadid. Kui teil on selliste s\u00fcsteemide jaoks n\u00f5uetekohaselt seadistatud poliitikad ja turvameetmed ning klastriga seotud mandaadid tuletatakse t\u00f6\u00f6tubadesse ainult saladustena, v\u00f5idakse pull-l\u00e4henemise t\u00e4iendav turvalisus osutuda v\u00e4hem v\u00e4\u00e4rtuslikuks, kui algselt arvati.<\/p>\n

              Seega, kui pull-l\u00e4henemine on t\u00f6\u00f6mahukam ja ei paku turvalisuse eeliseid, ei oleks siis loogiline kasutada ainult push-l\u00e4henemist? Kuid keegi v\u00f5ib v\u00e4ita, et push-l\u00e4henemine on liiga seotud CD-s\u00fcsteemiga ja v\u00f5ib-olla ei ole parem seda teha, et tulevikus oleks lihtsam migreerida.<\/p>\n

              Minu arvates (nagu alati) tuleks kasutada seda, mis konkreetsele olukorrale k\u00f5ige paremini sobib, v\u00f5i neid kombineerida. Isiklikult kasutan m\u00f5lemat l\u00e4henemist: Weave Fluxi pull-p\u00f5histe deployment'ide jaoks, mis peamiselt sisaldavad meie enda teenuseid, ja push-l\u00e4henemist Helmiga ja pistikprogrammidega, mis lihtsustavad Helm-chartide rakendamist klastrisse ja v\u00f5imaldavad probleemideta luua salajasi andmeid. Arvan, et kunagi ei tule \u00fchtegi lahendust, mis sobiks k\u00f5ikidele juhtudele, kuna n\u00fcansse on alati v\u00e4ga palju ja need s\u00f5ltuvad konkreetsest kasutusvariandist. Sellegipoolest soovitan tungivalt GitOps'i \u2014 see lihtsustab elu ja suurendab turvalisust.<\/p>\n

              Loodan, et minu kogemused selles k\u00fcsimuses aitavad m\u00e4\u00e4rata, milline meetod sobib teie deployment'idele k\u00f5ige paremini, ja ma oleksin hea meelega huvitatud teie arvamusest.<\/p>\n

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

              \nPull-mudeli miinustena on punkt, et on keeruline Gitisse panna renderdatud manifestid, kuid puudub miinus selles osas, et CD-pipeline pull-mudelis eksisteerib eraldi v\u00e4ljalaskest ning muutub seel\u00e4bi tegelikult kategoriseeritavaks pipeline'iks. J\u00e4tkuv rakendamine<\/i>. Seet\u00f5ttu on veelgi rohkem pingutusi vajalik, et koguda nende deployment'ide staatus ja kuidagi anda juurdep\u00e4\u00e4s logidele\/staatusele, eelistatult CD s\u00fcsteemiga seotud.<\/p>\n

              Selles m\u00f5ttes v\u00f5imaldab push-mudel anda mingisuguseid garantiiid v\u00e4ljapoole, kuna pipeline'i eluiga saab seada v\u00f5rdseks v\u00e4ljaku eluigaga.<\/p>\n

              Oleme proovinud m\u00f5lemat mudelit ning j\u00f5udnud samadele j\u00e4reldustele, mis autor artiklis:<\/p>\n

                \n
              1. Pull-mudel sobib meile s\u00fcsteemikomponentide uuendamise korraldamiseks suures koguses klastrites (vt. artiklit addon-operatorist<\/a><\/noindex>).<\/li>\n
              2. GitLab CI p\u00f5hinev push-mudel sobib h\u00e4sti rakenduste k\u00e4itamiseks Helm-chartide abil. Samuti j\u00e4lgitakse deployment'ide k\u00e4ivitamist pipeline'ides t\u00f6\u00f6riista abil. werf<\/a><\/noindex>. Muide, selle projekti kontekstis kuulsime pidevat \"GitOps\"-i, kui arutasime DevOps-inseneride aktuaalseid probleeme oma kioskis KubeCon Europe'19.<\/li>\n<\/ol>\n

                <\/p>\n

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

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