Noat. transl.: Yn 'e Kubernetes-mienskip wint in trend neamd GitOps foar de hân lizzende populariteit, lykas wy persoanlik hawwe sjoen, KubeCon Europe 2019. Dizze term wie relatyf resint troch it haad fan Weaveworks - Alexis Richardson - en betsjut it gebrûk fan ark bekend foar ûntwikkelders (primêr Git, fandêr de namme) om operasjonele problemen op te lossen. Yn 't bysûnder prate wy oer de wurking fan Kubernetes troch har konfiguraasjes yn Git op te slaan en automatysk wizigingen nei it kluster út te rollen. Matthias Jg fertelt oer twa oanpakken foar dizze útrol yn dit artikel.
Yn it ôfrûne jier (yn feite, formeel barde dit yn augustus 2017 - sawat oerset.) D'r is in nije oanpak foar it ynsetten fan applikaasjes yn Kubernetes. It hjit GitOps, en it is basearre op it basisidee dat ynsetferzjes wurde folge yn 'e feilige omjouwing fan in Git-repository.
De wichtichste foardielen fan dizze oanpak binne as folget::
- Ynset ferzje en feroaring skiednis. De steat fan it hiele kluster wurdt opslein yn in Git-repository, en ynset wurde allinich bywurke fia commits. Derneist kinne alle wizigingen wurde folge mei de commit-histoarje.
- Rollbacks mei fertroude Git-kommando's. Ienfâldich
git resetkinne jo feroarings yn ynset weromsette; ferline steaten binne altyd beskikber. - Klear tagong kontrôle. Typysk befettet in Git-systeem in protte gefoelige gegevens, sadat de measte bedriuwen spesjaal omtinken jouwe oan it beskermjen. Sadwaande jildt dizze beskerming ek foar operaasjes mei ynset.
- Belied foar ynset. De measte Git-systemen stypje natuerlik branch-by-branch-belied - bygelyks allinich pull-oanfragen kinne master bywurkje, en wizigingen moatte wurde hifke en akseptearre troch in oar teamlid. Lykas by tagongskontrôle jildt itselde belied foar ynsetupdates.
Sa't jo sjen kinne, binne d'r in protte foardielen foar de GitOps-metoade. Yn it ôfrûne jier hawwe twa oanpak benammen populêr wurden. Ien is push-basearre, de oare is pull-basearre. Foardat wy nei harren sjogge, litte wy earst sjen hoe typyske Kubernetes-ynsetsen der útsjen.
Ynset Metoaden
Yn 'e ôfrûne jierren binne ferskate metoaden en ark foar ynset fêststeld yn Kubernetes:
- Basearre op native Kubernetes/Customize-sjabloanen. Dit is de maklikste manier om applikaasjes op Kubernetes yn te setten. De ûntwikkelder makket de basis YAML-bestannen en tapasse se. Om ôf te kommen fan it hieltyd werskriuwen fan deselde sjabloanen, waard Kustomize ûntwikkele (it feroaret Kubernetes-sjabloanen yn modules). Noat. transl.: Kustomize is yntegrearre yn kubectl mei .
- Helm Charts. Helm charts kinne jo meitsje sets fan sjabloanen, init containers, sidecars, ensfh, dy't wurde brûkt om te ynsetten applikaasjes mei mear fleksibele oanpassing opsjes dan yn in sjabloan-basearre oanpak. Dizze metoade is basearre op sjabloan YAML-bestannen. Helm folt se mei ferskate parameters en dan stjoert se nei Tiller, in kluster komponint dy't ynset se oan it kluster en jout updates en rollbacks. It wichtige ding is dat Helm yn essinsje gewoan de winske wearden ynfoeget yn 'e sjabloanen en se dan tapast op deselde manier as it wurdt dien yn' e tradisjonele oanpak (lês mear oer hoe't it allegear wurket en hoe't jo it kinne brûke yn ús - ca. oerset.). D'r binne in breed ferskaat oan klearmakke Helm-kaarten dy't in breed skala oan taken befetsje.
- Alternative Tools. D'r binne in protte alternative ark. Wat se allegear mienskiplik hawwe is dat se guon sjabloanbestannen omsette yn Kubernetes-lêsbere YAML-bestannen en se dan brûke.
Yn ús wurk brûke wy konstant Helm-diagrammen foar wichtige ark (om't se al in protte dingen klear hawwe, wat it libben folle makliker makket) en "suvere" Kubernetes YAML-bestannen foar it ynsetten fan ús eigen applikaasjes.
Lûke triuwe
Yn ien fan myn resinte blogposten haw ik it ark yntrodusearre . Myn ûnderfining lit sjen dat dit ark ien fan 'e wichtichste is by it befoarderjen fan' e pull-oanpak, dus ik sil der faaks nei ferwize. As jo mear witte wolle oer hoe't jo it brûke, hjir .
NB! Alle foardielen fan it brûken fan GitOps bliuwe itselde foar beide oanpak.
Pull basearre oanpak
De pull-oanpak is basearre op it feit dat alle feroarings tapast wurde fanút it kluster. D'r is in operator yn it kluster dy't de byhearrende Git- en Docker Registry-repositories regelmjittich kontrolearret. As der feroaringen foarkomme, wurdt de tastân fan it kluster yntern bywurke. Dit proses wurdt algemien beskôge as heul feilich, om't gjin eksterne kliïnt tagong hat ta klusterbehearderrjochten.
Pros:
- Gjin eksterne kliïnt hat rjochten om wizigingen oan it kluster te meitsjen; alle updates wurde fan binnen útrôle.
- Guon ark kinne jo ek syngronisearje Helm chart updates en keppelje se oan it kluster.
- Docker Registry kin wurde skansearre foar nije ferzjes. As in nije ôfbylding beskikber is, wurde de Git-repository en ynset bywurke nei de nije ferzje.
- Pull-ark kinne wurde ferdield oer ferskate nammeromten mei ferskate Git-repositories en tagongsrjochten. Hjirmei kin in multitenant-model brûkt wurde. Bygelyks, team A kin nammeromte A brûke, team B kin nammeromte B brûke, en it ynfrastruktuerteam kin globale romte brûke.
- As regel binne de ark tige lichtgewicht.
- Kombinearre mei ark lykas operator , kinne geheimen fersifere wurde opslein yn in Git-repository en ophelle binnen it kluster.
- D'r is gjin ferbining mei CD-pipelines, om't ynset binnen it kluster foarkomme.
Минусы:
- It behearen fan ynsetgeheimen fan Helm-kaarten is dreger as gewoane, om't se earst moatte wurde oanmakke yn 'e foarm fan, bygelyks, fersegele geheimen, dan ûntsifere troch in ynterne operator, en pas dêrnei wurde se beskikber foar it pull-ark. Dan kinne jo de release útfiere yn Helm mei de wearden yn 'e al ynset geheimen. De maklikste manier is om in geheim te meitsjen mei alle Helm-wearden dy't brûkt wurde foar ynset, it ûntsiferje en ynsette foar Git.
- As jo in pull-oanpak nimme, wurde jo bûn oan ark te lûken. Dit beheint de mooglikheid om it ynsetproses yn in kluster oan te passen. Bygelyks, Kustomize is komplisearre troch it feit dat it moat rinne foardat de definitive sjabloanen ynsette foar Git. Ik sis net dat jo gjin standalone ark kinne brûke, mar se binne dreger om te yntegrearjen yn jo ynsetproses.
Push basearre oanpak
Yn 'e push-oanpak lanseart in ekstern systeem (benammen CD-pipelines) ynset nei it kluster nei in ynset foar it Git-repository of as de foarige CI-pipeline suksesfol is. Yn dizze oanpak hat it systeem tagong ta it kluster.
Плюсы:
- Feiligens wurdt bepaald troch de Git repository en build pipeline.
- It ynsetten fan Helm-diagrammen is makliker en stipet Helm-plugins.
- Geheimen binne makliker te behearjen, om't geheimen kinne wurde brûkt yn pipelines en kinne ek fersifere wurde opslein yn Git (ôfhinklik fan de foarkar fan de brûker).
- D'r is gjin ferbining mei in spesifyk ark, om't elk type kin wurde brûkt.
- Updates fan kontenerferzje kinne wurde inisjearre troch de buildpipeline.
Минусы:
- De kluster tagongsgegevens binne binnen it bousysteem.
- It bywurkjen fan ynsetkonteners is noch makliker mei in pull-proses.
- Swiere ôfhinklikens fan it CD-systeem, om't de pipelines dy't wy nedich binne miskien oarspronklik skreaun binne foar Gitlab Runners, en dan beslút it team om te ferhúzjen nei Azure DevOps of Jenkins ... en sil in grut oantal boupipelines moatte migrearje.
Resultaten: Push of Pull?
As gewoanlik it gefal is, hat elke oanpak syn foar- en neidielen. Guon taken binne makliker te realisearjen mei ien en dreger mei in oar. Yn 't earstoan die ik ynset mei de hân, mar nei't ik in pear artikels oer Weave Flux kaam, besleat ik GitOps-prosessen foar alle projekten út te fieren. Foar basis sjabloanen dit wie maklik, mar doe ik begûn te rinnen yn swierrichheden mei Helm charts. Destiids bea Weave Flux allinich in rudimentêre ferzje fan 'e Helm Chart Operator oan, mar sels no binne guon taken dreger fanwegen de needsaak om geheimen mei de hân te meitsjen en se oan te passen. Jo kinne stelle dat de pull-oanpak folle feiliger is, om't de bewiisbrieven fan it kluster net bûten it kluster tagonklik binne, wat it safolle feiliger makket dat it de ekstra muoite wurdich is.
Nei wat tinken kaam ik ta de ûnferwachte konklúzje dat dit net sa is. As wy prate oer komponinten dy't maksimale beskerming nedich binne, sil dizze list geheime opslach, CI / CD-systemen en Git-repositories omfetsje. De ynformaasje yn har is heul kwetsber en hat maksimale beskerming nedich. Derneist, as immen yn jo Git-repository komt en dêr koade kin triuwe, kinne se ynsette wat se wolle (as it no pull of push is) en de systemen fan it kluster ynfiltrearje. Sa binne de wichtichste komponinten dy't moatte wurde beskerme de Git-repository en CI / CD-systemen, net de klusterbewizen. As jo goed konfigurearre belied en feiligens kontrôles hawwe foar dizze soarten systemen, en kluster credentials wurde allinne extracted yn pipelines as geheimen, de tafoege feiligens fan in pull oanpak kin net sa weardefol as oarspronklik tocht.
Dat, as de pull-oanpak mear arbeidsyntinsiver is en gjin feiligensfoardiel leveret, is it dan net logysk om allinich de push-oanpak te brûken? Mar immen kin stelle dat jo yn 'e push-oanpak te bûn binne oan it CD-systeem en, miskien, it is better om dit net te dwaan, sadat it makliker sil wêze om migraasjes yn' e takomst út te fieren.
Yn myn miening (lykas altyd), moatte jo brûke wat it meast geskikt is foar in bepaalde saak of kombinearje. Persoanlik brûk ik beide oanpakken: Weave Flux foar pull-basearre ynset dy't meastentiids ús eigen tsjinsten befetsje, en in push-oanpak mei Helm en plugins, dy't it maklik makket om Helm-diagrammen oan te passen op it kluster en jo kinne geheimen naadloos meitsje. Ik tink dat d'r foar alle gefallen noait ien oplossing komt dy't geskikt is, om't der altyd in protte nuânses binne en dy binne ôfhinklik fan 'e spesifike tapassing. Dat wurdt sein, ik riede GitOps tige oan - it makket it libben in stik makliker en ferbetteret feiligens.
Ik hoopje dat myn ûnderfining op dit ûnderwerp sil helpe jo beslute hokker metoade is mear geskikt foar jo soarte fan ynset, en ik soe graach hearre jo miening.
PS Notysje fan de oersetter
It neidiel fan it pull-model is dat it lestich is om werjûn manifesten yn Git te pleatsen, mar d'r is gjin nadeel dat de CD-pipeline yn it pull-model apart libbet fan 'e útrol en yn wêzen in kategorypipeline wurdt Trochrinnende Tapasse. Dêrom sil noch mear ynspanning nedich wêze om har status te sammeljen fan alle ynset en op ien of oare manier tagong te jaan ta logs / status, leafst mei ferwizing nei it CD-systeem.
Yn dizze sin lit it push-model ús op syn minst wat garânsjes foar útrol leverje, om't it libben fan 'e pipeline lykweardich makke wurde kin oan it libben fan' e útrol.
Wy hawwe beide modellen besocht en kamen ta deselde konklúzjes as de skriuwer fan it artikel:
- It pull-model is geskikt foar ús om updates fan systeemkomponinten te organisearjen op in grut oantal klusters (sjoch. ).
- It push-model basearre op GitLab CI is goed geskikt foar it útroljen fan applikaasjes mei help fan Helm-diagrammen. Tagelyk wurdt de útrol fan ynset binnen pipelines kontrolearre mei it ark . Trouwens, yn 'e kontekst fan dit projekt fan ús, hearden wy de konstante "GitOps" doe't wy de driuwende problemen fan DevOps-yngenieurs besprutsen op ús stand by KubeCon Europe'19.
PPS fan oersetter
Lês ek op ús blog:
- «";
- «";
- «";
- «".
Allinnich registrearre brûkers kinne meidwaan oan 'e enkête. , asjebleaft.
Brûk jo GitOps?
-
Ja, pull approach
-
Ja, druk
-
Ja, pull + push
-
Ja, wat oars
-
gjin
30 brûkers stimden. 10 brûkers ûntholden har.
Boarne: www.habr.com