GitOps: Pulli ja Pushi meetodite võrdlus

Märk. tõlge.: Kubernetes'e kogukonnas on populaarsust kogumas suund nimega GitOps, milles oleme isiklikult veendunud, külastades KubeCon Europe 2019. See termin mõeldi välja suhteliselt hiljuti Weaveworks'i juhi — Alexis Richardson'i poolt — ja see tähendab arendajatele tuttavate vahendite (esmajärjekorras Git, kust ka nimi) kasutamist operatiivsete ülesannete lahendamiseks. Eelkõige räägime Kubernetes'e haldamisest, salvestades selle konfiguratsioonid Git'isse ja rakendades muudatused automaatselt klastrisse. Kahest lähenemisest sellele rakendusele räägib Matthias Jg käesolevas artiklis. Weaveworks'i tegevjuhi Alexis Richardsoni selgituses tähendab see arendajatele tuttavate tööriistade (eelkõige Git'i, mille järgi see nimi on saanud) rakendamist operatiivtööde lahendamiseks. Täpsemalt öeldes räägime Kubernetes'i haldamisest, hoides selle konfigureerimisi Git'is ja automaatsete muudatuste rakendamisest klastrisse. Kahest lähenemisviisist nende muudatuste rakendamisel räägib Matthias Jg antud artiklis.

Eelmisel aastal (tegelikult juhtus see formaalselt 2017. aasta augustis — märk. tõlge.) ilmus uus lähenemine rakenduste juurutamiseks Kubernetes'es. Seda nimetatakse GitOps ja selle põhjal on põhiidee, et deployment'ide versioonide jälgimine toimub turvalises Git-repositooriumis.

Selle lähenemise peamised eelised on järgmised:

1. Deployment'ide versioonimine ja muudatuste ajalugu. Kogu klastri olek salvestatakse Git-repositooriumisse ning deploymendid uuendatakse ainult commit’ide kaudu. Lisaks on kõik muudatused jälgitavad commit’ide ajaloo abil.
2. Tagasivõtmised, kasutades tuttavaid Git-käsku. Lihtne git reset võimaldab muudatusi deployment’ides tagasi tagasi tuua; varasemad olekud on alati saadaval.
3. Valmis juurdepääsukontroll. Tüüpiliselt sisaldab Git-süsteem palju konfidentsiaalset teavet, seega pööravad enamik ettevõtteid sellele kaitsele erilist tähelepanu. Vastavalt laieneb see kaitse ka deployment’idega seotud operatsioonidele.
4. Poliitikad deployment’ide jaoks. Enamik Git-süsteeme toetab algselt poliitikaid erinevate harude jaoks — näiteks võivad ainult pull request’id master’it uuendada, ning muudatusi peab kinnitama ja heaks kiitma teine meeskonna liige. Nagu juurdepääsukontrolli puhul, kehtivad samad poliitikad ka deployment’ide uuendustele.

Nagu näete, on GitOps meetodil palju eeliseid. Viimase aasta jooksul on toiminud kaks lähenemist, millest üks põhineb push'il ja teine pull'il. Enne kui neid arutame, vaatame esmalt, kuidas näevad välja tüüpilised Kubernetes’e deploymendid.

Deployment'ide meetodid

Viimastel aastatel on Kubernetesis kujunenud välja erinevad meetodid ja tööriistad rakenduste juurutamiseks:

1. Kubernetes/Kustomize'i natiivsete mallide põhjal. See on kõige lihtsam rakenduste juurutamise viis Kubernetesis. Arendaja loob põhjalikud YAML-failid ja rakendab need. Ühenduses pideva sama malli uuesti kirjutamisega on välja töötatud Kustomize (see muudab Kubernetes'i mallid mooduliteks). Märk. tõlge.: Kustomize on integreeritud kubectl-ga alates Kubernetes 1.14 versioonist.
2. Helm'i chart'id. Helm'i chart'id võimaldavad luua mallide komplekte, init-konteinerite, sidecar'ide jne, mida rakendatakse rakenduste juurutamiseks paindlikemate seadistamisvõimalustega kui mallide põhine lähenemine. Selle meetodi aluseks on mallitud YAML-failid. Helm täidab need erinevate parameetritega ja seejärel saadab Tiller'ile — klastrikomponendile, mis juurutab need klastris ja võimaldab uuendusi ja tagasipöördeid. Oluline on see, et põhimõtteliselt inserteerib Helm lihtsalt vajalikud väärtused mallidesse ja seejärel rakendab neid nagu traditsioonilise lähenemise puhul. (rohkem selle kohta, kuidas see kõik töötab ja kuidas seda kasutada, loe meie Helm'i artiklist — kt. tõlge). On olemas suur valik valmis Helm-chart'e, mis katab laia valikut ülesandeid.
3. Alternatiivsed tööriistad. On mitmeid alternatiivseid tööriistu. Kuldne liitja on see, et nad muudavad mingid mallifailid arusaadavateks Kubernetes YAML-failideks ja seejärel rakendavad need.

Oma töös kasutame pidevalt Helm-chart'e oluliste tööriistade jaoks (kuna neis on palju juba valmis, mis lihtsustab elu) ja „puhasid” Kubernetes YAML-failid oma rakenduste juurutamiseks.

Pull & Push

Ühes oma hiljutises blogipostituses tutvustasin tööriista Weave Flux, mis võimaldab malli salvestada Git-repositooriumisse ja uuendada juurutamist pärast igat salvestust või konteinereid push'ida. Minu kogemus näitab, et see tööriist on üks peamisi pull-lähenemise edendamise vahendeid, seega viitan sellele sageli. Kui soovite rohkem teada, kuidas seda kasutada, siis siin on artikkel.

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

Pull-lähenemine

Pull-approach'i alus on see, et kõik 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. Üldiselt peetakse sarnast protsessi üsna ohutuks, kuna ühelgi välisel kliendil pole juurõigusi klusterile.

Plussid:

1. Ühelgi välisel kliendil pole õigusi klusterisse muudatusi teha, kõik uuendused rakendatakse seestpoolt.
2. Mõned tööriistad võimaldavad samuti Helm-chartide uuenduste sünkroonimist ja nende sidumist klastriga.
3. Docker Registry't saab skaneerida uute versioonide leidmiseks. Kui ilmub uus pilt, uuendatakse Git-repo ja deployment uuteks versioonideks.
4. Tõmbetööriistad võivad olla jaotatud erinevatesse nimekohtadesse koos erinevate Git-repositooriumide ja juurdepääsuõigustega. Selle kaudu saab rakendada mitmeüürilise mudeli. Näiteks võib meeskond A kasutada nimekohta A, meeskond B nimekohta B ning infrastruktuuri haldav meeskond võib kasutada globaalset nimekohta.
5. Tavaliselt on tööriistad väga kerged.
6. Koos selliste tööriistadega nagu operaator Bitnami Sealed Secrets, saavad saladused salvestuda krüpteeritud kujul Git-repositooriumisse ja neid saab klastri sees välja võtta.
7. CD-pipeline'idega pole ühendust, kuna juurutamised toimuvad klastri sees.

Miinused:

1. Deployment'ide salajaste haldamine Helm chart'ide kaudu on keerulisem kui tavaliste salajaste haldamine, kuna neid tuleb esmalt genereerida näiteks 'sealed secrets' kujul, seejärel dekrüpteerida seesmise operaatori kaudu ja ainult siis on need pull-tööriista jaoks kättesaadavad. Seejärel saab Helm'is käivitada väljaandmise, kasutades juba juurutatud saladustes olevaid väärtusi. Lihtsaim viis on luua saladus kõigi deployment'ide jaoks kasutatavate Helm väärtustega, dekrüpteerida see ja salvestada Git'isse.
2. Kasutades pull-lähtekohta, olete seotud tööriistadega, mis opereerivad pull'ide kaudu. See piirab juurutamisprotsessi kohandamise võimalusi klastris. Näiteks Kustomize'iga töötamine on keerulisem, kuna see peab toimuma enne, kui lõplikud mallid Git'isse jõuavad. Ma ei ütle, et eraldi tööriistu on keelatud kasutada, kuid nende integreerimine juurutamisprotsessi on keerulisem.

Push-põhine lähenemine

Push-lähenemise korral käivitab väline süsteem (peamiselt CD-pipeurad) klastrisse juurutusi Git-repo kohustusest või eelneva CI-pipeuri edukast täitmisest. Selles lähenemises on süsteemil juurdepääs klastrile.

Plussid:

1. Turvalisus määratakse Git-repositoiumi ja koostamispipeuri poolt.
2. Helm-chartide juurutamine on kergem, kuna on olemas Helm-pluginite tugi.
3. Salajaste haldamine on lihtsam, kuna salajasi saab rakendada pipeurades ja samuti salvestada Git'is krüpteeritud kujul (vastavalt kasutaja eelistustele).
4. Ei ole spetsiifilist tööriista, kuna saab kasutada igasuguseid.
5. Konteinerite versioonide uuendusi võib algatada koostamispipeur.

Miinused:

1. Juurdepääsuklahvi andmed asuvad koostamissüsteemi sees.
2. Konteinerite uuendamine juurutustes on endiselt lihtsam pull-protsessiga.
3. Tugev sõltuvus CD-süsteemist, kuna vajalikud pipeurid võivad olla algselt kirjutatud Gitlabi Runner'itele ja seejärel otsustab meeskond üle minna Azure DevOps'ile või Jenkins'ile... ning tuleb teostada suure hulga koostamispipeuride migratsioon.

Kokkuvõte: Push või Pull?

Nagu tavaliselt on igal lähenemisel oma eelised ja puudused. Mõned ülesanded on lihtsamad ühega teostada ja keerulisemad teisega. Alguses tegin juurutusi käsitsi, kuid pärast mitmete Weave Fluxi artiklite leidmist otsustasin rakendada GitOps-protsesse kõigi projektide jaoks. Põhijoonistega osutus see lihtsaks, kuid hiljem hakkasin kohtama raskusi Helm-chart'idega töötamisel. Sel ajal pakkus Weave Flux vaid algelise versiooni Helm Chart Operatorist, kuid isegi nüüd on mõned ülesanded keerulisemad käsitsi loodud saladuste loomise ja nende rakendamise tõttu. Võite öelda, et pull-lähenemine on palju turvalisem, kuna klastri mandaadid ei ole väljastpoolt kergesti ligipääsetavad, mis suurendab turvalisust nii palju, et see tasub lisatingimusi.

Mõtle sellele veidi ja 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-repositorid. Nendes sisaldav teave on äärmiselt haavatav ja vajab kõrgendatud kaitset. Lisaks, kui keegi pääseb teie Git-repositorisse ja suudab sinna koodi push'ida, võib ta rakendada kõike, mida soovib (olenemata valitud lähenemisviisist, kas see on pull või push), ja siseneda klastrisüsteemidesse. Seega on kõige olulisemad komponendid, mis vajavad kaitset, Git-repositorid ja CI/CD süsteemid, mitte klastrikonto andmed. Kui teil on nende süsteemide jaoks korralikult seadistatud poliitikad ja turvameetmed ning klastrikonto andmed võetakse pipelinesse ainult saladustena, võib pull-lähenemise täiendav kaitse mitte osutuda nii väärtuslikuks, kui esialgu arvati.

Seega, kui pull-lähenemine on töömahukam ja ei paku turvalisuse eeliseid, ei oleks siis loogiline kasutada ainult push-lähenemist? Kuid keegi võib väita, et push-lähenemine on liiga seotud CD-süsteemiga ja võib-olla ei ole parem seda teha, et tulevikus oleks lihtsam migreerida.

Minu arvates (nagu alati) tuleks kasutada seda, mis sobib konkreetsesse olukorda või kombineerida. Isiklikult kasutan mõlemat lähenemist: Weave Flux pull-põhiste deploy’de jaoks, mis koosnevad enamasti meie enda teenustest, ja push-lähenemist Helm’iga ning pistikprogrammidega, mis lihtsustab Helm-chartide rakendamist klastrisse ja võimaldab probleemideta luua salajasi andmeid. Arvan, et kunagi ei tule olema ühte lahendust, mis sobiks kõigi olukordade jaoks, kuna nüansse on alati palju ning need sõltuvad konkreetsest kasutusjuhust. Samuti soovitan tungivalt GitOps'i — see lihtsustab elu ja suurendab turvalisust.

Loodan, et minu kogemus sellel teemal aitab määrata, milline meetod sobib teie deployment’ide tüübile, ja oleksin rõõmus, kui saaksin teada teie arvamust.

P.S. Tõlkija märkus

Pull-mudeli miinustena on punkt, et on keeruline Gitisse panna renderdatud manifestid, kuid puudub miinus selles osas, et CD-pipeline pull-mudelis eksisteerib eraldi väljalaskest ning muutub seeläbi tegelikult kategoriseeritavaks pipeline'iks. Jätkuv rakendamine. Seetõttu läheb veel rohkem tööd selleks, et koguda kõigist väljalaskmiste seisunditest teavet ja kuidagi anda ligipääs logidele/seisundile, eelistatavalt seostatuna CD-süsteemiga.

Selles mõttes võimaldab push-mudel anda mingid garantii väljalaskmiseks, kuna pipeline'i eluiga saab teha võrdseks väljalaskmise elueaga.

Oleme proovinud mõlemat mudelit ning jõudnud samadele järeldustele, mis autor artiklis:

1. Pull-mudel sobib meile süsteemikomponentide uuendamise korraldamiseks suures koguses klastrites (vt. artiklit addon-operatorist).
2. Push-mudel, mis põhineb GitLab CI-l, sobib väga hästi rakenduste väljalaskmiseks Helm-tabelite kaudu. Samuti jälgitakse väljalaskeid pipeline'ide raames tööriista abil. werf. Muide, selle meie projekti kontekstis kuulsime pidevalt "GitOps", kui arutasime DevOps-ingeniiride pakilisi probleeme oma stendis KubeCon Europe'19.

P.P.S. tõlkijalt

Lugege ka meie blogist:

• «Kubernetesi näpunäited ja nipid: Helm 2 haldamine klastris töötavate ressursside jaoks»;
• «Tutvustame kubedogi raamatukogu Kubernetesi ressursside jälgimiseks»;
• «Kubernetesi laiendamine ja täiendamine (ülevaade ja video ettekandest)»;
• «Nõuanded kohandatud tööprotsesside loomiseks GitLab CI-s».

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.

Kas kasutate GitOps-i?

• Jah, pull lähenemine

• Jah, push

• Jah, pull + push

• Jah, midagi muud

• Ei

Hääletas 30 kasutajat. 10 kasutajat hoidusid.

Allikas: habr.com