{"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\/lv\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps: Pull un Push meto\u017eu sal\u012bdzin\u0101jums","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Piez\u012bme:<\/b>: Kubernetes kopien\u0101 arvien liel\u0101ku popularit\u0101ti ieg\u016bst GitOps, ko m\u0113s pa\u0161i p\u0101rliecin\u0101j\u0101mies, apmekl\u0113jot<\/a><\/noindex> KubeCon Europe 2019. \u0160is termins tika rad\u012bts sal\u012bdzino\u0161i nesen izveidot<\/a><\/noindex> Weaveworks uz\u0146\u0113muma vad\u012bt\u0101ja \u2013 Aleksisa Ri\u010dardsona \u2013 un noz\u012bm\u0113, ka tiek izmantoti izstr\u0101d\u0101t\u0101jiem paz\u012bstami r\u012bki (galvenok\u0101rt \u2013 Git, no kura ar\u012b n\u0101k nosaukums) operacion\u0101lo uzdevumu risin\u0101\u0161anai. \u012apa\u0161i, tas attiecas uz Kubernetes oper\u0113\u0161anu, saglab\u0101jot t\u0101 konfigur\u0101cijas Git un automatiz\u0113jot izmai\u0146u ievie\u0161anu klaster\u012b. Par diviem pieejas veidiem \u0161ai ievie\u0161anai st\u0101sta Mat\u012bss Jg \u0161aj\u0101 rakst\u0101.<\/i><\/p>\n

\"GitOps:
\n
\nPag\u0101ju\u0161aj\u0101 gad\u0101 (faktiski tas form\u0101li notika 2017. gada august\u0101 \u2013 piez\u012bme tulkot\u0101jam)<\/i> Ir ien\u0101kusi jauna pieeja lietojumprogrammu izvieto\u0161anai Kubernetes. T\u0101 saucas GitOps, un t\u0101s pamat\u0101 ir ideja, ka versiju uzskaites process tiek veikts dro\u0161\u0101 Git repozitorij\u0101.<\/a><\/noindex><\/p>\n

\u0160\u012bs pieejas galvenie ieguvumi ir \u0161\u0101di<\/b>:<\/p>\n

    \n
  1. Deployment versiju un izmai\u0146u v\u0113sture<\/b>. Visa klastera st\u0101voklis tiek glab\u0101ts Git repozitorij\u0101, un deployment tiek atjaunin\u0101ti tikai ar komit\u0113\u0161anu. Turkl\u0101t visas izmai\u0146as var izsekot, izmantojot komitu v\u0113sturi.<\/li>\n
  2. Atgrie\u0161an\u0101s, izmantojot paz\u012bstamas Git komandas<\/b>. Vienk\u0101r\u0161s git reset<\/code> \u013cauj atjaunot izmai\u0146as deployment; vienm\u0113r ir pieejami iepriek\u0161\u0113jie st\u0101vok\u013ci.<\/li>\n
  3. Ieg\u016bts piek\u013cuves kontroles meh\u0101nisms<\/b>. Parasti Git sist\u0113m\u0101s ir daudz konfidenci\u0101lu datu, t\u0101p\u0113c liel\u0101k\u0101 da\u013ca uz\u0146\u0113mumu piev\u0113r\u0161 \u012bpa\u0161u uzman\u012bbu t\u0101s aizsardz\u012bbai. L\u012bdz ar to \u0161\u012b aizsardz\u012bba attiecas ar\u012b uz oper\u0101cij\u0101m ar deployment.<\/li>\n
  4. Politikas izvieto\u0161anai<\/b>. Liel\u0101k\u0101 da\u013ca Git sist\u0113mu s\u0101kotn\u0113ji atbalsta politikas da\u017e\u0101d\u0101m fili\u0101l\u0113m \u2014 piem\u0113ram, tikai pull piepras\u012bjumi var atjaunin\u0101t master, un izmai\u0146as j\u0101p\u0101rbauda un j\u0101apstiprina citam komandas dal\u012bbniekam. T\u0101pat k\u0101 piek\u013cuves kontrol\u0113, t\u0101s pa\u0161as politikas tiek piem\u0113rotas deployment atjaunin\u0101jumiem.<\/li>\n<\/ol>\n

    \nK\u0101 redzat, GitOps metodei ir daudz priek\u0161roc\u012bbu. P\u0113d\u0113j\u0101 gada laik\u0101 ir k\u013cuvu\u0161i popul\u0101ri divi pieg\u0101jieni. Viens balst\u0101s uz push, otrs \u2014 uz pull. Pirms tos apl\u016bkojam, vispirms apskat\u012bsim tipiskos Kubernetes deployment.<\/p>\n

    Izvieto\u0161anas veidi<\/h2>\n

    \nP\u0113d\u0113jos gados Kubernetes ir nostiprin\u0101ju\u0161\u0101s da\u017e\u0101das pieejas un r\u012bki izvieto\u0161anai:<\/p>\n

      \n
    1. Balstoties uz Kubernetes\/Kustomize dzimtajiem \u0161abloniem<\/b>Tas ir visvienk\u0101r\u0161\u0101kais veids, k\u0101 izv\u0113rst lietojumprogrammas Kubernetes. Izstr\u0101d\u0101t\u0101js izveido pamata YAML failus un tos piem\u0113ro. Lai izvair\u012btos no past\u0101v\u012bgas identisku veid\u0146u p\u0101rrakst\u012b\u0161anas, tika izstr\u0101d\u0101ts Kustomize (tas p\u0101rv\u0113r\u0161 Kubernetes veidnes modu\u013cos). Piez\u012bme:<\/b>: Kustomize tika integr\u0113ts kubectl kop\u0161 Kubernetes 1.14 izdevuma<\/a><\/noindex>.<\/i><\/li>\n
    2. Helm chart<\/b>. Helm charti \u013cauj rad\u012bt veid\u0146u komplektus, init konteinerus, sidecar u.tml., kas tiek izmantoti lietojumprogrammu izvieto\u0161anai ar elast\u012bg\u0101k\u0101m konfigur\u0113\u0161anas iesp\u0113j\u0101m nek\u0101 veidnei balst\u012btaj\u0101 pieej\u0101. \u0160\u012bs metodes pamat\u0101 ir veid\u0146u YAML faili. Helm aizpilda tos ar da\u017e\u0101diem parametru datiem un p\u0113c tam nos\u016bta Tiller \u2014 klastera komponentam, kas tos izvieto klaster\u012b un \u013cauj veikt atjaunin\u0101jumus un atgrie\u0161an\u0101s. Svar\u012bgi ir tas, ka b\u016bt\u012bb\u0101 Helm vienk\u0101r\u0161i ievieto vajadz\u012bgo v\u0113rt\u012bbu veidn\u0113s un p\u0113c tam t\u0101s piem\u0113ro t\u0101pat k\u0101 tradicion\u0101laj\u0101 pieej\u0101. (s\u012bk\u0101k par to, k\u0101 tas viss darbojas un k\u0101 to var izmantot, lasiet m\u016bsu rakst\u0101 par Helm<\/a><\/noindex> \u2014 piez\u012bme tulkot\u0101jam)<\/i>. Past\u0101v liels da\u017e\u0101d\u012bbas kl\u0101sts gatavu Helm chart, kas aptver pla\u0161u uzdevumu spektru.<\/li>\n
    3. Alternat\u012bvi r\u012bki<\/b>. Ir daudz alternat\u012bvu r\u012bku. Visiem tiem ir kop\u012bgs tas, ka tie p\u0101rveido noteiktus veid\u0146u failus par saprotamiem Kubernetes YAML failiem un p\u0113c tam tos piem\u0113ro.<\/li>\n<\/ol>\n

      \nM\u0113s sav\u0101 darb\u0101 past\u0101v\u012bgi izmantojam Helm chart svar\u012bg\u0101m lietojumus (jo tajos ir daudz jau gatava, kas b\u016btiski atvieglo dz\u012bvi) un \u201et\u012brus\u201d Kubernetes YAML failus savus lietojumprogrammu izv\u0113r\u0161anai.<\/p>\n

      Pull & Push<\/h2>\n

      \nViens no manu neseno emu\u0101ru rakstu laik\u0101 es iepaz\u012bstin\u0101ju ar r\u012bku Weave Flux<\/a><\/noindex>, \u013caujot komit\u0113t veidnes Git repozitorij\u0101 un atjaunin\u0101t deployment p\u0113c katra komita vai push konteinera. Mana pieredze r\u0101da, ka \u0161is instruments ir viens no svar\u012bg\u0101kajiem pull pieejas veicin\u0101\u0161an\u0101, t\u0101p\u0113c es bie\u017ei uz to atsauk\u0161os. Ja v\u0113laties uzzin\u0101t vair\u0101k par to, k\u0101 to izmantot, \u0161eit ir saite uz rakstu<\/a><\/noindex>.<\/p>\n

      NB!<\/b> Visi GitOps izmanto\u0161anas priek\u0161roc\u012bbas saglab\u0101jas ab\u0101m pieej\u0101m.<\/i><\/p>\n

      Pull balst\u012bt\u0101 pieeja<\/h2>\n

      \n\"GitOps:
      \n
      \nPull pieejas pamat\u0101 ir fakts, ka visas izmai\u0146as tiek piem\u0113rotas no iek\u0161puses klastera. Klastera iek\u0161ien\u0113 ir operators, kas regul\u0101ri p\u0101rbauda saist\u012btos Git un Docker Registry kr\u0101jumus. Ja tajos notiek k\u0101das izmai\u0146as, klastera st\u0101voklis tiek atjaunin\u0101ts no iek\u0161puses. Parasti tiek uzskat\u012bts, ka \u0161\u0101ds process ir diezgan dro\u0161s, jo nevienam \u0101r\u0113jam klientam nav piek\u013cuves administratora ties\u012bb\u0101m klaster\u012b.<\/p>\n

      Priek\u0161roc\u012bbas:<\/b><\/p>\n

        \n
      1. Nevienam \u0101r\u0113jam klientam nav ties\u012bbu veikt izmai\u0146as klaster\u012b, visas atjaunin\u0101\u0161anas tiek pielietotas no iek\u0161puses.<\/li>\n
      2. Da\u017ei r\u012bki ar\u012b \u013cauj sinhroniz\u0113t Helm chartu atjaunin\u0101jumus un piesaist\u012bt tos klasterim.<\/li>\n
      3. Docker Registry var sken\u0113t jauno versiju mekl\u0113\u0161anai. Ja tiek pieejams jauns att\u0113ls, Git kr\u0101jums un deployment tiek atjaunin\u0101ti uz jauno versiju.<\/li>\n
      4. Pull r\u012bki var tikt izplat\u012bti pa da\u017e\u0101diem nosaukumu telp\u0101m ar da\u017e\u0101diem Git kr\u0101jumiem un piek\u013cuves ties\u012bb\u0101m. T\u0101d\u0113j\u0101di var ieviest daudz\u012bpa\u0161nieku (multitenant) modeli. Piem\u0113ram, komanda A var izmantot nosaukumu telpu A, komanda B \u2014 nosaukumu telpu B, bet infrastrukt\u016bras komanda var izmantot glob\u0101lo telpu.<\/li>\n
      5. Parasti r\u012bki ir diezgan viegli.<\/li>\n
      6. Kombin\u0101cij\u0101 ar t\u0101diem r\u012bkiem k\u0101 operators Bitnami Sealed Secrets<\/a><\/noindex>, slepenie dati var tikt glab\u0101ti \u0161ifr\u0113t\u0101 form\u0101 Git kr\u0101jum\u0101 un ieg\u016bti klastera iek\u0161ien\u0113.<\/li>\n
      7. Tr\u016bkst saiknes ar CD cauru\u013cvadiem, jo izvieto\u0161anas notiek klastera iek\u0161ien\u0113.<\/li>\n<\/ol>\n

        \nM\u012bnusi<\/b>:<\/p>\n

          \n
        1. P\u0101rvald\u012bt geheimus dizaina no Helm diagramm\u0101m ir gr\u016bt\u0101k nek\u0101 parastus, jo vispirms tos j\u0101\u0123ener\u0113, teiksim, k\u0101 sealed secrets, p\u0113c tam j\u0101de\u0161ifr\u0113 iek\u0161\u0113j\u0101 operator\u0101 un tikai tad tie k\u013c\u016bst pieejami pull r\u012bkam. P\u0113c tam var uzs\u0101kt laidienu Helm ar v\u0113rt\u012bb\u0101m jau izvietotajos geheimos. Visvienk\u0101r\u0161\u0101kais veids ir izveidot geheimu ar vis\u0101m Helm v\u0113rt\u012bb\u0101m, kas tiek izmantotas dizain\u0101, de\u0161ifr\u0113t to un saglab\u0101t Git.<\/li>\n
        2. Pielietojot pull pieeju, j\u016bs esat saist\u012bti ar r\u012bkiem, kas darbojas uz pull. Tas ierobe\u017eo iesp\u0113ju konfigur\u0113t dizaina procesu klaster\u012b. Piem\u0113ram, darbs ar Kustomize tiek apgr\u016btin\u0101ts, jo tas j\u0101veic pirms gal\u012bgie \u0161abloni non\u0101k Git. Es nesaku, ka nevarat izmantot atsevi\u0161\u0137us r\u012bkus, bet tos ir gr\u016bt\u0101k integr\u0113t dizaina proces\u0101.<\/li>\n<\/ol>\n

          <\/p>\n

          Push orient\u0113ta pieeja<\/h2>\n

          \n\"GitOps:
          \n
          \nPush pieej\u0101 \u0101r\u0113j\u0101 sist\u0113ma (galvenok\u0101rt CD cauru\u013cvadi) uzs\u0101k izvietojumus klaster\u012b p\u0113c kommit\u0113\u0161anas Git repozitorij\u0101 vai veiksm\u012bgas iepriek\u0161\u0113j\u0101 CI cauru\u013cvada izpildes. \u0160aj\u0101 pieej\u0101 sist\u0113mai ir piek\u013cuve klasterim.<\/p>\n

          Priek\u0161roc\u012bbas<\/b>:<\/p>\n

            \n
          1. Dro\u0161\u012bba tiek noteikta ar Git repozitoriju un b\u016bvniec\u012bbas cauru\u013cvadu.<\/li>\n
          2. Helm chartu izvieto\u0161ana ir vienk\u0101r\u0161\u0101ka, l\u012bdz ar to ir atbalsts Helm spraud\u0146iem.<\/li>\n
          3. P\u0101rvald\u012bt nosl\u0113pumus ir viegl\u0101k, jo nosl\u0113pumus var izmantot cauru\u013cvados, k\u0101 ar\u012b uzglab\u0101t Git \u0161ifr\u0113t\u0101 veid\u0101 (atkar\u012bb\u0101 no lietot\u0101ja izv\u0113l\u0113m).<\/li>\n
          4. Nav saist\u012bbas ar konkr\u0113tu r\u012bku, jo var izmantot jebkurus r\u012bku veidus.<\/li>\n
          5. Tvert\u0146u versiju atjaunin\u0101jumus var inici\u0113t cauru\u013cvads.<\/li>\n<\/ol>\n

            \nM\u012bnusi<\/b>:<\/p>\n

              \n
            1. Dati piek\u013cuvei klasterim atrodas iek\u0161\u0113j\u0101 b\u016bvniec\u012bbas sist\u0113m\u0101.<\/li>\n
            2. Atjaunot konteiners dizains joproj\u0101m ir viegl\u0101k veikt ar pull procesu.<\/li>\n
            3. Sp\u0113c\u012bga atkar\u012bba no CD sist\u0113mas, jo nepiecie\u0161amie cauru\u013cvadi var b\u016bt s\u0101kotn\u0113ji rakst\u012bti Gitlab Runners, bet p\u0113c tam komanda var nolemt p\u0101riet uz Azure DevOps vai Jenkins... un b\u016bs j\u0101veic liela daudzuma b\u016bvniec\u012bbas cauru\u013cvadu migr\u0101cija.<\/li>\n<\/ol>\n

              <\/p>\n

              Secin\u0101jumi: Push vai Pull?<\/h2>\n

              \nK\u0101 parasti notiek, katram pieejai ir savi plusi un m\u012bnusi. Da\u017eas uzdevumus viegl\u0101k izpild\u012bt ar vienu, bet gr\u016bt\u0101k \u2014 ar citu. S\u0101kum\u0101 es veicu izvietojumus manu\u0101li, ta\u010du p\u0113c tam, kad sastapos ar da\u017e\u0101m rakstiem par Weave Flux, nol\u0113mu ieviest GitOps procesus visos projektos. Pamata veidne izr\u0101d\u012bj\u0101s viegla, bet v\u0113l\u0101k s\u0101ku saskarties ar gr\u016bt\u012bb\u0101m, str\u0101d\u0101jot ar Helm diagramm\u0101m. Taj\u0101 laik\u0101 Weave Flux pied\u0101v\u0101ja tikai s\u0101kotn\u0113ju Helm Chart Operator versiju, bet pat tagad da\u017eas uzdevumus ir gr\u016bt\u0101k veikt, jo ir nepiecie\u0161ams manu\u0101li izveidot nosl\u0113pumus un tos piem\u0113rot. J\u016bs varat teikt, ka pull pieeja ir daudz dro\u0161\u0101ka, jo klastera akredit\u012bvi nav pieejami \u0101rpus t\u0101, un tas tik \u013coti paaugstina dro\u0161\u012bbu, ka tas ir papildu p\u016b\u013cu v\u0113rts.<\/p>\n

              P\u0101ris min\u016btes padom\u0101jot, es non\u0101cu pie negaid\u012bta secin\u0101juma, ka tas t\u0101 nav. Ja run\u0101jam par komponentiem, kas prasa maksim\u0101lu aizsardz\u012bbu, \u0161aj\u0101 sarakst\u0101 ietilpst geheimu glab\u0101\u0161anas vietas un CI\/CD sist\u0113mas, Git repozitoriji. Inform\u0101cija iek\u0161\u0101 ir \u013coti neaizsarg\u0101ta un prasa maksim\u0101lu aizsardz\u012bbu. Turkl\u0101t, ja k\u0101ds iek\u013c\u016bst j\u016bsu Git repozitorij\u0101 un var iesniegt kodu, vi\u0146\u0161 var izvietot visu, ko v\u0113las (neatkar\u012bgi no izv\u0113l\u0113t\u0101s pieejas, vai tas ir pull vai push), un iek\u013c\u016bt klastera sist\u0113m\u0101s. T\u0101d\u0113j\u0101di visnoz\u012bm\u012bg\u0101k\u0101s sast\u0101vda\u013cas, kur\u0101m nepiecie\u0161ama aizsardz\u012bba, ir Git repozitorijs un CI\/CD sist\u0113mas, nevis klastera akredit\u0101cijas dati. Ja jums ir labi konfigur\u0113tas politikas un dro\u0161\u012bbas pas\u0101kumi \u0161\u0101da veida sist\u0113m\u0101m, un klastera akredit\u0101cijas dati tiek izvilkti uz caurul\u0113m tikai k\u0101 geheimi, papildu dro\u0161\u012bba pull pieej\u0101 var izr\u0101d\u012bties ne tik v\u0113rt\u012bga, k\u0101 s\u0101kotn\u0113ji tika dom\u0101ts.<\/p>\n

              T\u0101tad, ja pull pieeja ir sare\u017e\u0123\u012bt\u0101ka un nesniedz dro\u0161\u012bbas ieguvumus, vai neb\u016btu lo\u0123iski izmantot tikai push pieeju? Ta\u010du k\u0101ds var\u0113tu apgalvot, ka push pieej\u0101 j\u016bs p\u0101r\u0101k esat atkar\u012bgs no CD sist\u0113mas, un varb\u016bt lab\u0101k to nedar\u012bt, lai n\u0101kotn\u0113 viegl\u0101k b\u016btu veikt migr\u0101cijas.<\/p>\n

              Manupr\u0101t, (k\u0101 vienm\u0113r) j\u0101izmanto tas, kas vislab\u0101k atbilst konkr\u0113tajai situ\u0101cijai, vai j\u0101kombin\u0113. Person\u012bgi es izmantoju abus pieeju veidus: Weave Flux, lai veiktu deploymentus, kas galvenok\u0101rt ietver m\u016bsu pa\u0161u pakalpojumus, un push pieeju ar Helm un papla\u0161in\u0101jumiem, kas atvieglo Helm chartu piem\u0113ro\u0161anu klasterim un \u013cauj viegli izveidot slepen\u0101s inform\u0101cijas. Dom\u0101ju, ka nekad neb\u016bs vienota risin\u0101juma, kas atbilst vis\u0101m situ\u0101cij\u0101m, jo vienm\u0113r ir daudz nianses, un t\u0101s ir atkar\u012bgas no konkr\u0113t\u0101 pielietojuma. Taj\u0101 pa\u0161\u0101 laik\u0101 es \u013coti iesaku GitOps \u2014 tas b\u016btiski atvieglo dz\u012bvi un palielina dro\u0161\u012bbu.<\/p>\n

              Ceru, ka mans pieredzes st\u0101sts \u0161aj\u0101 jom\u0101 pal\u012bdz\u0113s izlemt, kura metode vislab\u0101k atbilst j\u016bsu veida deploymentiem, un es labpr\u0101t uzzin\u0101tu j\u016bsu viedokli.<\/p>\n

              P.S. Piez\u012bme no tulkot\u0101ja<\/h2>\n

              \nPull mode\u013ca m\u012bnuss ir tas, ka ir gr\u016bti ievietot Git atrender\u0113tos manifestus, tom\u0113r nav m\u012bnusa, ka CD cauru\u013cu l\u012bnija pull model\u012b dz\u012bvo atsevi\u0161\u0137i no izvieto\u0161anas un b\u016bt\u012bb\u0101 p\u0101rv\u0113r\u0161as par Continuous Apply<\/i>. T\u0101d\u0113\u013c b\u016bs nepiecie\u0161ams v\u0113l vair\u0101k p\u016b\u013cu, lai apkopotu visu deploymentu statusu un kaut k\u0101 nodro\u0161in\u0101tu piek\u013cuvi \u017eurn\u0101liem\/statusam, v\u0113lams, sasaistot to ar CD sist\u0113mu.<\/p>\n

              \u0160aj\u0101 zi\u0146\u0101 push mode\u013ca pieeja \u013cauj sniegt k\u0101das garantijas izvieto\u0161anai, jo pipeline dz\u012bves ilgumu var piel\u0101got izvieto\u0161anas laika ilgumam.<\/p>\n

              M\u0113s izm\u0113\u0123in\u0101j\u0101m abus mode\u013cus un non\u0101c\u0101m pie t\u0101diem pa\u0161iem secin\u0101jumiem k\u0101 raksta autors:<\/p>\n

                \n
              1. Pull modelis mums ir piem\u0113rots, lai organiz\u0113tu sist\u0113mas komponentu atjaunin\u0101\u0161anu uz liela skaita klasteriem (skat. rakstu par addon-operatoru<\/a><\/noindex>).<\/li>\n
              2. Push modelis, pamatojoties uz GitLab CI, ir labi piem\u0113rots programmat\u016bras izvieto\u0161anai, izmantojot Helm chartus. Turkl\u0101t deploymentu izpilde caur pipeline tiek uzraudz\u012bta ar r\u012bku werf<\/a><\/noindex>. Run\u0101jot par \u0161o m\u016bsu projektu, m\u0113s dzird\u0113j\u0101m past\u0101v\u012bgu \u201eGitOps\u201d, kad apspried\u0101m svar\u012bg\u0101s probl\u0113mas, ar kur\u0101m sastopas DevOps in\u017eenieri pie sava stenda KubeCon Europe\u201919.<\/li>\n<\/ol>\n

                <\/p>\n

                P.S. no tulkot\u0101ja<\/h2>\n

                \nLasiet ar\u012b m\u016bsu emu\u0101ra rakstos:<\/p>\n