🥇GitOps: Pull ja Push meetodite võrdlus

Märkus tõlke kohta.: Kubernetes'i kogukonnas on populaarsust saavutanud trend nimega GitOps, mille tõhusust oleme isiklikult näinud, külastades KubeCon Europe 2019. See termin on suhteliselt hiljuti loodud ettevõtte Weaveworks juhtimisest — Alexis Richardson — ja viitab arendajatele tuttavate tööriistade (eelkõige Git, kust ka nimi) kasutamisele operatiivsete probleemide lahendamiseks. Eelkõige räägime Kubernetes'i haldamisest, salvestades selle konfiguratsioonid Git'is ja automaatsete muudatuste rakendamisest klastrisse. Kahest lähenemisest nende muudatuste rakendamisel räägib Matthias Jg käesolevas artiklis.

GitOps: Pull ja Push meetodite võrdlus

Eelmisel aastal (tegelikult toimus see formaalselt 2017. aasta augustis — täiendav märkus tõlkijalt.) ilmnes uus lähenemine rakenduste juurutamiseks Kubernetes'is. Seda nimetatakse GitOps'iks ja selle aluseks on põhimõte, et versioonide jälgimine toimub turvalises Git-repositooriumis.

Selle lähenemise peamised eelised on järgmised:

Deployment'ide versioonimine ja muudatused. Kogu klastri olek salvestatakse Git-repositooriumis ja deployment'id uuendatakse ainult commit'ide kaudu. Lisaks on kõik muudatused jälgitavad commit'ide ajaloo kaudu.
Tagasiulatuvad muudatused tuttavate Git käskude abil. Lihtne git reset võimaldab tagasi keelduda muudatustest deployment'ides; alati on saadaval varasemad olekud.
Valmis juurdepääsuhaldus. Tavaliselt sisaldab Git-süsteem palju konfidentsiaalset teavet, seetõttu pööravad enamik ettevõtteid suurt tähelepanu selle kaitsmisele. Vastavalt laieneb see kaitse ka deployment'idega toimingutele.
Poliitikad juurutamiseks. Enamik Git-süsteeme toetab algselt poliitikaid erinevate harude jaoks — näiteks saavad ainult pull request'id uuendada master'it ning muudatused peab üle vaatama ja aktsepteerima teine meeskonnaliige. Nagu juurdepääsu haldamisel, rakendatakse samu poliitikaid deployment'ide uuendamisel.

Nagu näete, on GitOps meetodil palju eeliseid. Viimase aasta jooksul on kaks lähenemist saavutanud erilist populaarsust. Üks põhineb push-lähenemisel, teine — pull-lähenemisel. Enne nende arutamist vaatame esmalt, kuidas näevad välja tüüpilised Kubernetes'i deployment'id.

Juurutamise viisid

Viimastel aastatel on Kubernetes'is kindlaks saanud mitmed juurutamise viisid ja tööriistad:

Põhineb Kubernetes'i/Kustomize'i natiivsetel mallidel. See on lihtsaim viis rakenduste juurutamiseks Kuberneteses. Arendaja loob põhielemendid YAML-failidest ja rakendab need. Korduvate šabloonide uuesti kirjutamise vältimiseks töötati välja Kustomize (mis muudab Kubernetes šabloonid mooduliteks). Märkus tõlke kohta.: Kustomize on integreeritud kubectl'iga versioonist Kubernetes 1.14.
Helm Chart'id. Helm Chart'id võimaldavad luua šabloonide, init-konteinerite, sidecar'ide jne komplekte, mida rakendatakse rakenduste juurutamiseks paindlikumate seadistamisvõimalustega kui šabloonide põhine lähenemine. Selle meetodi aluseks on šabloonitud YAML-failid. Helm täidab need erinevate parameetritega ja seejärel edastab Need Tiller'ile — klastri komponendile, mis juurutab neid klastrisse ja võimaldab uuendusi ja tagasipöördeid. Oluline on see, et põhimõtteliselt lisab Helm lihtsalt vajalikud väärtused šabloonidesse ja rakendab need just nagu traditsioonilises lähenemises. (lisainfot selle kohta, kuidas see kõik töötab ja kuidas seda kasutada, leiate meie Helmi artiklist — toimetaja märkus). On olemas suur valik valmis Helm-chart'e, mis katab laia valikut ülesandeid.
Alternatiivsed tööriistad. On palju alternatiivseid tööriistu. Kõik need muudavad teatud šabloonifailid arusaadavateks Kubernetes YAML-failideks ja rakendavad need seejärel.

Meie töös kasutame pidevalt Helm-chart'e oluliste tööriistade jaoks (kuna need sisaldavad palju valmis komponente, mis lihtsustavad elu) ja "puhtaid" Kubernetes YAML-failisid oma rakenduste juurutamiseks.

Pull & Push

Ühes oma hiljutises blogipostituses tutvustasin tööriista Weave Flux, mis võimaldab šabloone Git-repositooriumisse salvestada ja juurutamist uuendada pärast iga commit'i või konteineri push'i. Minu kogemus näitab, et see tööriist on üks peamisi pull-lähenemise edendamisel, seega viitan sellele sageli. Kui soovite rohkem teada, kuidas seda kasutada, siis siin on link artiklile.

NB! Kõik GitOps'i kasutamise eelised kehtivad mõlema lähenemise puhul.

Pull-lähenemine

GitOps: Pull ja Push meetodite võrdlus

Pull-lähestumisstrateegia põhineb tõsiselt, et kõik 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. Üldiselt peetakse seda protsessi üsna turvaliseks, kuna ei ühelgi välisel kliendil ei ole juurdepääsu klastri administreerimisõigustele.

Plussid:

Ühelgi välisel kliendil ei ole õigusi muudatuste tegemiseks klastri sees, kõik uuendused tehakse seestpoolt.
Mõned tööriistad võimaldavad samuti sünkroonida Helm-chartide uuendusi ja seondada need klastriga.
Docker Registry't saab skaneerida uute versioonide olemasolu osas. Kui ilmub uus pilt, uuendatakse Git-repositoorium ja deploymendit uusimale versioonile.
Pull-tööriistad võivad olla jaotatud erinevatesse ruumidesse, millel on erinevad Git-reposid ja ligipääsuõigused. Selle tulemusena saadakse multiüürilise (multitenant) mudeli rakendamine. Näiteks võib meeskond A kasutada ruumi A, meeskond B ruumi B ja infrastruktuuri meeskond võib kasutada globaalset ruumi.
Üldiselt on tööriistad üsna kergekaalulised.
Koos selliste tööriistadega nagu operaator, Bitnami Sealed Secrets, võivad saladused olla krüpteeritud kujul Git-repositoriumis ja neid saab klastris välja võtta.
CD-piiplainidega pole seost, kuna deploymendid toimuvad klastris.

Miinused:

Saladuste haldamine Helm-chartide kaudu on keerulisem kui tavapäraselt, kuna neid tuleb kõigepealt genereerida näiteks, varjatud saladustena, seejärel dekrüpteerida sisemise operaatori poolt ja alles siis on need pull-tööriista jaoks kättesaadavad. Seejärel saab Helm'is käivitada väljalaskmise, kasutades juba deklareeritud saladusi. Lihtsaim viis on luua saladus, milles sisaldub kõik kasutatavad Helm'i väärtused deploymendi jaoks, dekrüpteerida see ja teha Git'i salvestus.
Kasutades pull-approchi, olete seotud tööriistadega, mis töötavad pullide põhjal. See piirab võimalust seadistada deploy'ide käitamisprotsessi klastris. Näiteks Kustomize'i kasutamine on keerulisem, kuna see peab toimuma enne, kui lõplikud mallid jõuavad Git'i. Ma ei ütle, et eraldi tööriistade kasutamine on võimatu, kuid nende integreerimine deployimisprotsessi on keerulisem.

Push-approach

GitOps: Pull ja Push meetodite võrdlus

Push-approach'i puhul käivitab väline süsteem (peamiselt CD-torud) klastris deploy'e pärast Git'i reposiitri commit'i tegemist või eelmise CI-toru edukat täitmist. Selle lähenemise korral on süsteemil juurdepääs klastrile.

Plussid:

Turvalisus määratakse Git'i reposiitri ja ehituspipeliini kaudu.
Helm'i charte on lihtsam deployida, olemas on Helm'i pluginad.
Salajaste haldamine on lihtsam, kuna saladusi saab rakendada pipeliinides ja samuti salvestada Git'is krüpteeritud kujul (sõltuvalt kasutaja eelistustest).
Spetsiifiliste tööriistade seose puudumine, kuna saab kasutada igasuguseid tööriistu.
Konteinerite versioonide uuendusi saab käivitada ehituspipeliini kaudu.

Miinused:

Andmed juurdepääsuks klastrile asuvad ehitussüsteemi sees.
Konteinerite deploy'de uuendamine on endiselt lihtsam pull-protsessiga.
Tugev sõltuvus CD-süsteemist, kuna vajalikud pipeliinid on võib-olla algselt kirjutatud Gitlab Runners'i jaoks, kuid seejärel otsustab meeskond üle minna Azure DevOpsile või Jenkinsile... ja tuleb migreerida suur hulk ehituspipeliine.

Kokkuvõtted: Push või Pull?

Nagu tavaliselt, igal lähenemisel on oma plussid ja miinused. Mõned ülesanded on ühega lihtsamad, teisega aga keerulisemad. Alguses tegin ma juurutamisi käsitsi, kuid pärast mitme Weave Fluxi kohta kirjutatud artikli lugemist otsustasin rakendada GitOps-protsesse kõigis projektides. Kõikide 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õned ülesanded keerulised, kuna tuleb käsitsi luua saladusi ja neid rakendada. Võite öelda, et pull-lähenemine on palju turvalisem, kuna klastri mandaat ei ole tema välispindadel ligipääsetav, mis suurendab turvalisust nii palju, et see õigustab lisapingutusi.

Mõeldes veidi, jõudsin ootamatule järeldusele, et see ei ole nii. Kui rääkida komponentidest, mis vajavad maksimaalset kaitset, kuuluvad sellesse nimekirja saladuste hoidlad ja CI/CD-süsteemid, Git-repositooriumid. Teave nende sees on väga haavatav ja vajab maksimaalset kaitset. Lisaks, kui keegi saab juurdepääsu teie Git-repositooriumile ja suudab sinna koodi push'ida, siis saab ta juurutada kõike, mida soovib (olgu see pull- või push-lähenemine), ja tungida klastri süsteemidesse. Seega on kõige olulisemad komponendid, mis vajavad kaitset, Git-repositoorium ja CI/CD-süsteemid, mitte klastri mandaat. Kui teie poliitikad ja turvameetmed on selliste süsteemide jaoks hästi seadistatud, ja klastri mandaat on torude kaudu toimetatud ainult saladustena, ei pruugi pull-lähenemise täiendav turvalisus osutuda nii väärtuslikuks, kui algselt eeldati.

Nii et kui pull-lähenemine on töömahukam ja ei paku turvalisuse eeliseid, kas ei oleks loogiline kasutada ainult push-lähenemist? Kuid keegi võib väita, et push-lähenemine seab teid liiga kinni CD-süsteemi, ja võib-olla on parem mitte niimoodi teha, et oleks tulevikus lihtsam migratsioone teostada.

Minu arvates (nagu alati) tuleks kasutada seda, mis sobib konkreetse juhtumi jaoks, või kombineerida. Isiklikult kasutan mõlemat lähenemist: Weave Flux deploy'miseks, mis põhinevad pull, mis peamiselt hõlmavad meie enda teenuseid, ja push-lähenemist Helmiga ja pluginatega, mis lihtsustavad Helm-chartide rakendamist klastrisse ja võimaldavad probleemideta luua salajasi võtmeid. Arvan, et ühtegi universaalset lahendust ei tule, mis sobiks kõikidele juhtudel, kuna nüansse on alati väga palju ja need sõltuvad konkreetsest rakenduse näitest. Sellegipoolest soovitan tungivalt GitOps'i — see teeb elu palju lihtsamaks ja suurendab turvalisust.

Loodan, et minu kogemus antud teema osas aitab teil otsustada, milline meetod sobib kõige enam teie deployment'ide tüübile, ja ma oleksin rõõmus, kui kuulda teie arvamust.

P.S. Tõlkija märkus

Pull-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. Seetõttu on vajalikud veelgi suuremad pingutused, et kogu deployment'ide staatust koguda ja kuidagi logide/status'e juurde juurdepääsu anda, soovitavalt CD süsteemiga seotud.

Sellest vaatepunktist võimaldab push-mudel anda mingid garantiid vabanemiseks, kuna pipeliini eluea saab määrata vabanemise elueaga.

Oleme proovinud mõlemat mudelit ja jõudnud samadele järeldustele nagu artikli autor:

Pull-mudel sobib meile süsteemikomponentide värskendamise korraldamiseks suure hulga klastrite peal (vt. artiklit addon-operator'i kohta).
Push-mudel GitLab CI põhjal sobib väga hästi rakenduste vabanemiseks Helm-chartide abil. Samuti jälgitakse deployment'ide vabanemist pipelinide raames tööriista abil werf. Muide, selle meie projekti kontekstis kuulsime pidevalt "GitOps", kui arutasime DevOps-inseneride pakilisi probleeme oma stendil KubeCon Europe’19.