Tandaan. transl.: Sa komunidad ng Kubernetes, ang isang trend na tinatawag na GitOps ay nakakakuha ng malinaw na katanyagan, gaya ng personal nating nakita, KubeCon Europe 2019. Ang terminong ito ay medyo kamakailan ng pinuno ng Weaveworks - Alexis Richardson - at nangangahulugan ng paggamit ng mga tool na pamilyar sa mga developer (pangunahin ang Git, kaya ang pangalan) upang malutas ang mga problema sa pagpapatakbo. Sa partikular, pinag-uusapan natin ang tungkol sa pagpapatakbo ng Kubernetes sa pamamagitan ng pag-iimbak ng mga configuration nito sa Git at awtomatikong paglulunsad ng mga pagbabago sa cluster. Si Matthias Jg ay nagsasalita tungkol sa dalawang diskarte sa paglulunsad na ito sa artikulong ito.
Nakaraang taon, (sa katunayan, pormal na nangyari ito noong Agosto 2017 - tinatayang transl.) May bagong diskarte sa pag-deploy ng mga application sa Kubernetes. Ito ay tinatawag na GitOps, at ito ay batay sa pangunahing ideya na ang pagsubaybay sa bersyon ng mga deployment ay ginagawa sa secure na kapaligiran ng isang Git repository.
Ang pangunahing bentahe ng diskarteng ito ay ang mga sumusunod::
- Pag-deploy ng bersyon at kasaysayan ng pagbabago. Ang estado ng buong cluster ay nakaimbak sa isang Git repository, at ang mga deployment ay ina-update lamang sa pamamagitan ng mga commit. Bilang karagdagan, ang lahat ng mga pagbabago ay maaaring masubaybayan gamit ang kasaysayan ng commit.
- Mga rollback gamit ang pamilyar na mga utos ng Git... Kapatagan
git resetnagbibigay-daan sa iyong i-reset ang mga pagbabago sa mga deployment; ang mga nakaraang estado ay palaging magagamit. - Handa nang kontrol sa pag-access. Karaniwan, ang isang Git system ay naglalaman ng maraming sensitibong data, kaya karamihan sa mga kumpanya ay nagbibigay ng espesyal na pansin sa pagprotekta nito. Alinsunod dito, nalalapat din ang proteksyong ito sa mga operasyong may mga deployment.
- Mga Patakaran para sa Mga Deployment. Karamihan sa mga Git system ay native na sumusuporta sa mga patakaran para sa iba't ibang branch - halimbawa, ang mga pull request lang ang makakapag-update ng master, at ang mga pagbabago ay dapat suriin at tanggapin ng isa pang miyembro ng team. Tulad ng kontrol sa pag-access, ang parehong mga patakaran ay nalalapat sa mga update sa deployment.
Gaya ng nakikita mo, maraming benepisyo ang paraan ng GitOps. Sa nakalipas na taon, dalawang diskarte ang nakakuha ng partikular na katanyagan. Ang isa ay push based, ang isa naman ay pull based. Bago tingnan ang mga ito, tingnan muna natin kung ano ang hitsura ng mga tipikal na deployment ng Kubernetes.
Mga Paraan ng Deployment
Sa mga nakalipas na taon, ang Kubernetes ay nagtatag ng iba't ibang pamamaraan at tool para sa mga deployment:
- Batay sa mga native na template ng Kubernetes/Kustomize. Ito ang pinakamadaling paraan upang mag-deploy ng mga application sa Kubernetes. Ginagawa ng developer ang mga pangunahing YAML file at inilalapat ang mga ito. Upang maalis ang patuloy na muling pagsusulat ng parehong mga template, binuo ang Kustomize (ginagawa nitong mga module ang mga template ng Kubernetes). Tandaan. transl.: Ang Kustomize ay isinama sa kubectl kasama ang .
- Mga Tsart ng Helm. Binibigyang-daan ka ng mga chart ng helm na lumikha ng mga hanay ng mga template, mga lalagyan ng init, mga sidecar, atbp., na ginagamit upang mag-deploy ng mga application na may mas nababaluktot na mga opsyon sa pag-customize kaysa sa diskarteng nakabatay sa template. Ang pamamaraang ito ay batay sa mga naka-template na YAML file. Pinupuno sila ng Helm ng iba't ibang parameter at pagkatapos ay ipapadala ang mga ito sa Tiller, isang cluster component na nagde-deploy sa kanila sa cluster at nagbibigay-daan sa mga update at rollback. Ang mahalagang bagay ay ang Helm ay mahalagang ipasok lamang ang nais na mga halaga sa mga template at pagkatapos ay inilalapat ang mga ito sa parehong paraan tulad ng ginagawa sa tradisyonal na diskarte (magbasa nang higit pa tungkol sa kung paano gumagana ang lahat at kung paano mo ito magagamit sa aming β tinatayang. transl.). Mayroong iba't ibang uri ng mga yari na Helm chart na sumasaklaw sa malawak na hanay ng mga gawain.
- Mga Alternatibong Tool. Mayroong maraming mga alternatibong tool. Ang pagkakapareho nilang lahat ay ginagawa nila ang ilang template file sa mga Kubernetes-readable na YAML file at pagkatapos ay ginagamit ang mga ito.
Sa aming trabaho, palagi kaming gumagamit ng mga Helm chart para sa mahahalagang tool (dahil marami na silang handa, na ginagawang mas madali ang buhay) at "puro" Kubernetes YAML file para sa pag-deploy ng sarili naming mga application.
Hila tulak
Sa isa sa aking kamakailang mga post sa blog, ipinakilala ko ang tool , na nagbibigay-daan sa iyong mag-commit ng mga template sa Git repository at i-update ang deployment pagkatapos ng bawat commit o push ng container. Ang aking karanasan ay nagpapakita na ang tool na ito ay isa sa mga pangunahing sa pagtataguyod ng pull approach, kaya madalas ko itong tinutukoy. Kung gusto mong malaman ang higit pa tungkol sa kung paano gamitin ito, dito .
NB! Ang lahat ng mga benepisyo ng paggamit ng GitOps ay nananatiling pareho para sa parehong mga diskarte.
Pull based na diskarte
Ang pull approach ay batay sa katotohanan na ang lahat ng mga pagbabago ay inilapat mula sa loob ng cluster. Mayroong operator sa loob ng cluster na regular na nagsusuri sa nauugnay na Git at Docker Registry repository. Kung may anumang pagbabagong nangyari sa kanila, internal na ina-update ang estado ng cluster. Ang prosesong ito ay karaniwang itinuturing na napaka-secure, dahil walang panlabas na kliyente ang may access sa mga karapatan ng administrator ng cluster.
Pros:
- Walang panlabas na kliyente ang may karapatang gumawa ng mga pagbabago sa cluster; lahat ng mga update ay inilunsad mula sa loob.
- Nagbibigay-daan din sa iyo ang ilang tool na i-synchronize ang mga update sa Helm chart at i-link ang mga ito sa cluster.
- Maaaring ma-scan ang Docker Registry para sa mga bagong bersyon. Kung may available na bagong larawan, ang Git repository at deployment ay ina-update sa bagong bersyon.
- Ang mga pull tool ay maaaring ipamahagi sa iba't ibang namespace na may iba't ibang Git repository at pahintulot. Salamat dito, maaaring magamit ang isang multitenant na modelo. Halimbawa, ang team A ay maaaring gumamit ng namespace A, ang team B ay maaaring gumamit ng namespace B, at ang infrastructure team ay maaaring gumamit ng global space.
- Bilang isang patakaran, ang mga tool ay napakagaan.
- Pinagsama sa mga tool tulad ng operator , ang mga lihim ay maaaring maimbak na naka-encrypt sa isang Git repository at makuha sa loob ng cluster.
- Walang koneksyon sa mga pipeline ng CD dahil nangyayari ang mga deployment sa loob ng cluster.
Cons:
- Ang pamamahala ng mga lihim ng deployment mula sa mga Helm chart ay mas mahirap kaysa sa mga regular, dahil kailangan munang buuin ang mga ito sa anyo ng, halimbawa, mga selyadong lihim, pagkatapos ay i-decrypt ng isang internal na operator, at pagkatapos lamang na magagamit ang mga ito sa tool ng paghila. Pagkatapos ay maaari mong patakbuhin ang paglabas sa Helm na may mga halaga sa na-deploy na mga lihim. Ang pinakamadaling paraan ay ang lumikha ng isang lihim sa lahat ng Helm value na ginamit para sa pag-deploy, i-decrypt ito at i-commit ito sa Git.
- Kapag kumuha ka ng isang pull approach, ikaw ay nakatali sa paghila ng mga tool. Nililimitahan nito ang kakayahang i-customize ang proseso ng pag-deploy sa isang cluster. Halimbawa, ang Kustomize ay kumplikado sa pamamagitan ng katotohanang dapat itong tumakbo bago ang mga huling template ay nakatuon sa Git. Hindi ko sinasabing hindi ka maaaring gumamit ng mga standalone na tool, ngunit mas mahirap silang isama sa iyong proseso ng pag-deploy.
Push based na diskarte
Sa push approach, isang external system (pangunahin ang mga CD pipeline) ay naglulunsad ng mga deployment sa cluster pagkatapos ng isang commit sa Git repository o kung matagumpay ang nakaraang CI pipeline. Sa diskarteng ito, ang system ay may access sa cluster.
Pros:
- Ang seguridad ay tinutukoy ng Git repository at bumuo ng pipeline.
- Ang pag-deploy ng mga chart ng Helm ay mas madali at sinusuportahan ang mga plugin ng Helm.
- Ang mga lihim ay mas madaling pamahalaan dahil ang mga lihim ay maaaring gamitin sa mga pipeline at maaari ding iimbak na naka-encrypt sa Git (depende sa mga kagustuhan ng user).
- Walang koneksyon sa isang partikular na tool, dahil maaaring gamitin ang anumang uri.
- Maaaring simulan ang mga update sa bersyon ng container sa pamamagitan ng build pipeline.
Cons:
- Ang cluster access data ay nasa loob ng build system.
- Ang pag-update ng mga deployment container ay mas madali pa rin sa proseso ng paghila.
- Ang matinding pag-asa sa CD system, dahil ang mga pipeline na kailangan namin ay maaaring orihinal na isinulat para sa Gitlab Runners, at pagkatapos ay nagpasya ang team na lumipat sa Azure DevOps o Jenkins... at kailangang mag-migrate ng malaking bilang ng mga build pipeline.
Mga Resulta: Itulak o Hilahin?
Gaya ng karaniwang nangyayari, ang bawat diskarte ay may mga kalamangan at kahinaan. Ang ilang mga gawain ay mas madaling magawa sa isa at mas mahirap sa isa pa. Sa una ay mano-mano akong gumagawa ng mga deployment, ngunit pagkatapos kong makakita ng ilang artikulo tungkol sa Weave Flux, nagpasya akong ipatupad ang mga proseso ng GitOps para sa lahat ng proyekto. Para sa mga pangunahing template ito ay madali, ngunit pagkatapos ay nagsimula akong magkaroon ng mga kahirapan sa mga Helm chart. Noong panahong iyon, ang Weave Flux ay nag-aalok lamang ng isang paunang bersyon ng Helm Chart Operator, ngunit kahit na ngayon ang ilang mga gawain ay mas mahirap dahil sa pangangailangan na manu-manong lumikha ng mga lihim at ilapat ang mga ito. Maaari kang magtaltalan na ang pull approach ay mas secure dahil ang mga kredensyal ng cluster ay hindi naa-access sa labas ng cluster, na ginagawa itong mas secure na sulit ang dagdag na pagsisikap.
Pagkatapos ng ilang pag-iisip, dumating ako sa hindi inaasahang konklusyon na hindi ito ganoon. Kung pag-uusapan natin ang mga bahagi na nangangailangan ng maximum na proteksyon, ang listahang ito ay magsasama ng sikretong storage, CI/CD system, at Git repository. Ang impormasyon sa loob ng mga ito ay lubhang mahina at nangangailangan ng maximum na proteksyon. Bukod pa rito, kung may pumasok sa iyong Git repository at makakapag-push ng code doon, maaari nilang i-deploy ang anumang gusto nila (pull man ito o itulak) at makalusot sa mga cluster system. Kaya, ang pinakamahalagang bahagi na kailangang protektahan ay ang Git repository at CI/CD system, hindi ang cluster credentials. Kung mayroon kang mahusay na na-configure na mga patakaran at mga kontrol sa seguridad para sa mga uri ng mga system na ito, at ang mga kredensyal ng cluster ay kinukuha lamang sa mga pipeline bilang mga sikreto, ang karagdagang seguridad ng isang pull approach ay maaaring hindi kasinghalaga ng orihinal na iniisip.
Kaya, kung ang pull approach ay mas labor intensive at hindi nagbibigay ng security benefit, hindi ba lohikal na gamitin lang ang push approach? Ngunit ang isang tao ay maaaring magtaltalan na sa push approach ay masyado kang nakatali sa CD system at, marahil, mas mainam na huwag gawin ito upang mas madaling magsagawa ng mga paglilipat sa hinaharap.
Sa aking opinyon (tulad ng nakasanayan), dapat mong gamitin kung ano ang pinaka-angkop para sa isang partikular na kaso o pagsamahin. Sa personal, gumagamit ako ng parehong diskarte: Weave Flux para sa mga pull-based na deployment na kadalasang kasama ang sarili naming mga serbisyo, at ang push approach sa Helm at mga plugin, na nagpapadali sa paglalapat ng mga Helm chart sa cluster at nagbibigay-daan sa iyong gumawa ng mga lihim nang walang anumang problema. . Sa palagay ko ay hindi magkakaroon ng isang solong solusyon na angkop para sa lahat ng mga kaso, dahil palaging maraming mga nuances at nakasalalay sila sa partikular na aplikasyon. Iyon ay sinabi, lubos kong inirerekumenda ang GitOps - pinapadali nito ang buhay at pinapabuti ang seguridad.
Umaasa ako na ang aking karanasan sa paksang ito ay makakatulong sa iyo na magpasya kung aling paraan ang mas angkop para sa iyong uri ng pag-deploy, at ikalulugod kong marinig ang iyong opinyon.
P.S. Tala mula sa tagasalin
Ang downside ng pull model ay mahirap ilagay ang mga nai-render na manifest sa Git, ngunit walang downside na ang CD pipeline sa pull model ay nabubuhay nang hiwalay mula sa rollout at talagang nagiging pipeline ng kategorya. Patuloy na Mag-apply. Samakatuwid, higit pang pagsisikap ang kakailanganin upang kolektahin ang kanilang status mula sa lahat ng deployment at kahit papaano ay magbigay ng access sa mga log/status, mas mainam na maiugnay sa CD system.
Sa ganitong kahulugan, binibigyang-daan kami ng push model na magbigay ng hindi bababa sa ilang mga garantiya ng paglulunsad, dahil ang haba ng pipeline ay maaaring gawing katumbas ng haba ng panahon ng paglulunsad.
Sinubukan namin ang parehong mga modelo at dumating sa parehong mga konklusyon bilang ang may-akda ng artikulo:
- Ang modelo ng pull ay angkop para sa amin upang ayusin ang mga update ng mga bahagi ng system sa isang malaking bilang ng mga kumpol (tingnan. ).
- Ang modelo ng push batay sa GitLab CI ay angkop para sa paglulunsad ng mga application gamit ang mga Helm chart. Kasabay nito, ang paglulunsad ng mga deployment sa loob ng mga pipeline ay sinusubaybayan gamit ang tool . Oo nga pala, sa konteksto ng aming proyektong ito, narinig namin ang patuloy na "GitOps" noong tinalakay namin ang mga problema ng mga inhinyero ng DevOps sa aming stand sa KubeCon Europe'19.
PPS mula sa tagasalin
Basahin din sa aming blog:
- Β«";
- Β«";
- Β«";
- Β«'.
Ang mga rehistradong user lamang ang maaaring lumahok sa survey. , pakiusap
Gumagamit ka ba ng GitOps?
-
Oo, pull approach
-
Oo, itulak
-
Oo, hilahin + itulak
-
Oo, iba pa
-
Hindi
30 user ang bumoto. 10 na user ang umiwas.
Pinagmulan: www.habr.com