Tandaan. transl.: Pagkatapos ng kamakailang publikasyon tungkol sa mga paraan ng pull at push sa GitOps, nakita namin ang interes sa modelong ito sa pangkalahatan, ngunit kakaunti ang mga publikasyon sa wikang Ruso sa paksang ito (wala lang sa Habré). Samakatuwid, nalulugod kaming mag-alok sa iyong atensyon ng pagsasalin ng isa pang artikulo - kahit halos isang taon na ang nakalipas! — mula sa Weaveworks, ang pinuno kung saan nabuo ang terminong "GitOps." Ipinapaliwanag ng teksto ang kakanyahan ng diskarte at mga pangunahing pagkakaiba mula sa mga umiiral na.
Isang taon na ang nakalipas na-publish namin . Noon, ibinahagi namin kung paano inilunsad ng Weaveworks team ang isang SaaS na ganap na nakabatay sa Kubernetes at bumuo ng isang set ng mga prescriptive na pinakamahusay na kagawian para sa pag-deploy, pamamahala, at pagsubaybay sa isang cloud native na kapaligiran.
Ang artikulo ay naging popular. Nagsimulang magsalita ang ibang tao tungkol sa GitOps at nagsimulang mag-publish ng mga bagong tool para sa , , , , at iba pa. Lumitaw sa aming website mga publikasyon at mga kaso ng paggamit ng GitOps. Ngunit ang ilang mga tao ay may mga katanungan pa rin. Paano naiiba ang modelo mula sa tradisyonal? at patuloy na paghahatid ()? Kailangan bang gumamit ng Kubernetes?
Hindi nagtagal ay napagtanto namin na kailangan ang isang bagong paglalarawan, na nag-aalok ng:
- Isang malaking bilang ng mga halimbawa at kuwento;
- Tukoy na kahulugan ng GitOps;
- Paghahambing sa tradisyonal na tuluy-tuloy na paghahatid.
Sa artikulong ito sinubukan naming saklawin ang lahat ng mga paksang ito. Nagbibigay ito ng na-update na panimula sa GitOps at isang developer at pananaw ng CI/CD. Pangunahing tumutok kami sa mga Kubernetes, bagama't maaaring gawing pangkalahatan ang modelo.
Kilalanin ang GitOps
Isipin mo si Alice. Siya ang nagpapatakbo ng Family Insurance, na nag-aalok ng health, auto, home, at travel insurance sa mga taong masyadong abala para malaman ang mga ins and outs ng mga kontrata. Nagsimula ang kanyang negosyo bilang side project noong nagtatrabaho si Alice sa isang bangko bilang data scientist. Isang araw napagtanto niya na maaari niyang gamitin ang mga advanced na algorithm ng computer upang mas mabisang pag-aralan ang data at bumuo ng mga pakete ng insurance. Pinondohan ng mga mamumuhunan ang proyekto, at ngayon ang kanyang kumpanya ay nagdudulot ng higit sa $20 milyon sa isang taon at mabilis na lumalaki. Sa kasalukuyan, ito ay gumagamit ng 180 katao sa iba't ibang posisyon. Kabilang dito ang isang team ng teknolohiya na bubuo, nagpapanatili ng website, database, at sinusuri ang base ng customer. Ang pangkat ng 60 katao ay pinamumunuan ni Bob, ang teknikal na direktor ng kumpanya.
Nag-deploy ang team ni Bob ng mga production system sa cloud. Gumagana ang kanilang mga pangunahing application sa GKE, na sinasamantala ang Kubernetes sa Google Cloud. Bilang karagdagan, gumagamit sila ng iba't ibang data at analytics tool sa kanilang trabaho.
Ang Family Insurance ay hindi nagtakdang gumamit ng mga container, ngunit nahuli sa sigla ng Docker. Di-nagtagal, natuklasan ng kumpanya na pinadali ng GKE ang pag-deploy ng mga cluster upang subukan ang mga bagong feature. Idinagdag ang Jenkins para sa CI at Quay upang ayusin ang registry ng container, isinulat ang mga script para kay Jenkins na nagtulak ng mga bagong container at configuration sa GKE.
Lumipas ang ilang oras. Nabigo sina Alice at Bob sa pagganap ng kanilang napiling diskarte at epekto nito sa negosyo. Ang pagpapakilala ng mga lalagyan ay hindi nagpabuti ng pagiging produktibo gaya ng inaasahan ng koponan. Minsan masisira ang mga deployment, at hindi malinaw kung ang mga pagbabago sa code ang dapat sisihin. Ito rin ay naging mahirap na subaybayan ang mga pagbabago sa config. Kadalasan ay kinakailangan upang lumikha ng isang bagong kumpol at ilipat ang mga application dito, dahil ito ang pinakamadaling paraan upang maalis ang gulo na naging sistema. Natatakot si Alice na lalala ang sitwasyon habang nabuo ang application (bilang karagdagan, isang bagong proyektong batay sa machine learning ang namumuo). Na-automate ni Bob ang karamihan sa trabaho at hindi niya naiintindihan kung bakit hindi pa rin stable ang pipeline, hindi maayos ang sukat, at nangangailangan ng manu-manong interbensyon sa pana-panahon?
Pagkatapos ay natutunan nila ang tungkol sa GitOps. Ang desisyong ito ay naging eksakto kung ano ang kailangan nila upang may kumpiyansa na sumulong.
Naririnig nina Alice at Bob ang tungkol sa Git, DevOps, at imprastraktura bilang mga daloy ng trabaho ng code sa loob ng maraming taon. Ang natatangi sa GitOps ay nagdadala ito ng isang hanay ng pinakamahuhusay na kagawian—parehong depinitibo at normatibo—para sa pagpapatupad ng mga ideyang ito sa konteksto ng Kubernetes. Ang temang ito , kasama sa .
Nagpasya ang Family Insurance na ipatupad ang GitOps. Ang kumpanya ay mayroon na ngayong isang automated na modelo ng pagpapatakbo na tugma sa Kubernetes at pinagsama bilis may katatagandahil sila:
- natagpuan na ang pagiging produktibo ng koponan ay nadoble nang walang sinumang nababaliw;
- huminto sa paghahatid ng mga script. Sa halip, maaari na silang tumuon sa mga bagong feature at pahusayin ang mga pamamaraan ng engineering - halimbawa, pagpapakilala ng mga canary rollout at pagpapabuti ng pagsubok;
- pinahusay namin ang proseso ng pag-deploy upang madalang itong masira;
- nakakuha ng pagkakataong ibalik ang mga deployment pagkatapos ng bahagyang pagkabigo nang walang manu-manong interbensyon;
- binili gamitоHigit na kumpiyansa sa mga sistema ng paghahatid. Natuklasan nina Alice at Bob na maaari nilang hatiin ang koponan sa mga microservice team na nagtatrabaho nang magkatulad;
- maaaring gumawa ng 30-50 pagbabago sa proyekto araw-araw sa pamamagitan ng pagsisikap ng bawat grupo at sumubok ng mga bagong pamamaraan;
- madaling maakit ang mga bagong developer sa proyekto, na may pagkakataong maglunsad ng mga update sa produksyon gamit ang mga pull request sa loob ng ilang oras;
- madaling pumasa sa audit sa loob ng balangkas ng SOC2 (para sa pagsunod ng mga service provider sa mga kinakailangan para sa secure na pamamahala ng data; magbasa nang higit pa, halimbawa, — tinatayang. transl.).
Anong nangyari?
Ang GitOps ay dalawang bagay:
- Modelo ng pagpapatakbo para sa Kubernetes at cloud native. Nagbibigay ito ng hanay ng pinakamahuhusay na kagawian para sa pag-deploy, pamamahala, at pagsubaybay sa mga containerized na cluster at application. Elegant na kahulugan sa anyo mula sa :
- Ang landas sa paglikha ng kapaligiran ng pamamahala ng application na nakasentro sa developer. Inilapat namin ang daloy ng trabaho sa Git sa parehong mga operasyon at pag-unlad. Pakitandaan na ito ay hindi lamang tungkol sa Git push, ngunit tungkol sa pag-aayos ng buong set ng CI/CD at UI/UX na mga tool.
Ilang salita tungkol sa Git
Kung hindi ka pamilyar sa mga version control system at Git-based na workflow, lubos naming inirerekomenda ang pag-aaral tungkol sa mga ito. Ang pagtatrabaho sa mga branch at pull request ay maaaring mukhang black magic sa una, ngunit ang mga benepisyo ay sulit sa pagsisikap. Dito upang simulan ang.
Paano gumagana ang Kubernetes
Sa aming kuwento, bumaling sina Alice at Bob sa GitOps pagkatapos magtrabaho sa Kubernetes nang ilang sandali. Sa katunayan, ang GitOps ay malapit na nauugnay sa Kubernetes - ito ay isang modelo ng pagpapatakbo para sa imprastraktura at mga aplikasyon batay sa Kubernetes.
Ano ang ibinibigay ng Kubernetes sa mga user?
Narito ang ilang pangunahing tampok:
- Sa modelong Kubernetes, ang lahat ay maaaring ilarawan sa deklaratibong anyo.
- Kinukuha ng server ng Kubernetes API ang deklarasyon na ito bilang input at pagkatapos ay patuloy na sinusubukang dalhin ang cluster sa estado na inilarawan sa deklarasyon.
- Ang mga deklarasyon ay sapat upang ilarawan at pamahalaan ang isang malawak na iba't ibang mga workload—“mga aplikasyon.”
- Bilang resulta, nangyayari ang mga pagbabago sa application at cluster dahil sa:
- mga pagbabago sa mga imahe ng lalagyan;
- mga pagbabago sa deklaratibong detalye;
- mga error sa kapaligiran - halimbawa, mga pag-crash ng container.
Mahusay na Mga Kakayahang Pagsasama-sama ng Kubernetes
Kapag gumawa ng mga pagbabago sa configuration ang isang administrator, ilalapat ng Kubernetes orchestrator ang mga ito sa cluster hangga't ang estado nito ay ay hindi lalapit sa bagong configuration. Gumagana ang modelong ito para sa anumang mapagkukunan ng Kubernetes at maaaring mapalawak sa Mga Kahulugan ng Custom na Resource (CRD). Samakatuwid, ang mga pag-deploy ng Kubernetes ay may mga sumusunod na magagandang katangian:
- Pag-aautomat: Ang mga update ng Kubernetes ay nagbibigay ng mekanismo upang i-automate ang proseso ng paglalapat ng mga pagbabago nang maganda at sa isang napapanahong paraan.
- Convergence: Patuloy na susubukan ng Kubernetes ang mga update hanggang sa matagumpay.
- Idepotency: Ang paulit-ulit na paggamit ng convergence ay humahantong sa parehong resulta.
- Determinismo: Kapag sapat na ang mga mapagkukunan, ang estado ng na-update na cluster ay nakasalalay lamang sa nais na estado.
Paano gumagana ang GitOps
Sapat na ang aming natutunan tungkol sa Kubernetes upang ipaliwanag kung paano gumagana ang GitOps.
Bumalik tayo sa mga microservice team ng Family Insurance. Ano ang karaniwang kailangan nilang gawin? Tingnan ang listahan sa ibaba (kung ang anumang mga item dito ay tila kakaiba o hindi pamilyar, mangyaring huminto sa pagpuna at manatili sa amin). Ito ay mga halimbawa lamang ng mga workflow na nakabatay sa Jenkins. Mayroong maraming iba pang mga proseso kapag nagtatrabaho sa iba pang mga tool.
Ang pangunahing bagay ay nakikita namin na ang bawat pag-update ay nagtatapos sa mga pagbabago sa mga file ng pagsasaayos at mga repositoryo ng Git. Ang mga pagbabagong ito sa Git ay nagiging sanhi ng pag-update ng "GitOps operator" sa cluster:
1. Proseso ng pagtatrabaho: "Jenkins build - master branch'.
Listahan ng gawain:
- Itinulak ni Jenkins ang mga naka-tag na larawan sa Quay;
- Itinulak ni Jenkins ang mga config at Helm chart sa master storage bucket;
- Kinokopya ng cloud function ang config at mga chart mula sa master storage bucket patungo sa master Git repository;
- Ina-update ng operator ng GitOps ang cluster.
2. Jenkins build - release o hotfix branch:
- Itinulak ni Jenkins ang mga hindi naka-tag na larawan sa Quay;
- Itinulak ni Jenkins ang config at Helm chart sa staging storage bucket;
- Kinokopya ng cloud function ang config at mga chart mula sa staging storage bucket patungo sa staging Git repository;
- Ina-update ng operator ng GitOps ang cluster.
3. Jenkins build - bumuo o tampok na sangay:
- Itinulak ni Jenkins ang mga hindi naka-tag na larawan sa Quay;
- Itinulak ni Jenkins ang mga config at Helm chart sa bucket ng pag-develop ng storage;
- Kinokopya ng cloud function ang config at mga chart mula sa develop storage bucket patungo sa develop Git repository;
- Ina-update ng operator ng GitOps ang cluster.
4. Pagdaragdag ng bagong kliyente:
- Tinatawagan ng manager o administrator (LCM/ops) si Gradle para unang i-deploy at i-configure ang mga network load balancer (NLBs);
- Ang LCM/ops ay gumawa ng bagong config para ihanda ang deployment para sa mga update;
- Ina-update ng operator ng GitOps ang cluster.
Maikling paglalarawan ng GitOps
- Ilarawan ang gustong estado ng buong system gamit ang mga deklaratibong detalye para sa bawat kapaligiran (sa aming kuwento, tinukoy ng koponan ni Bob ang buong configuration ng system sa Git).
- Ang Git repository ay ang nag-iisang pinagmumulan ng katotohanan tungkol sa nais na estado ng buong system.
- Ang lahat ng mga pagbabago sa nais na estado ay ginawa sa pamamagitan ng mga commit sa Git.
- Ang lahat ng gustong mga parameter ng cluster ay makikita din sa cluster mismo. Sa ganitong paraan matutukoy natin kung tumutugma ang mga ito (nagtatagpo, magkasalubong) o magkaiba (magkaiba, diverge) ninanais at naobserbahang estado.
- Kung magkaiba ang nais at naobserbahang estado, kung gayon:
- Mayroong isang mekanismo ng convergence na maaga o huli ay awtomatikong nagsi-synchronize sa target at naobserbahang mga estado. Sa loob ng cluster, ginagawa ito ng Kubernetes.
- Magsisimula kaagad ang proseso sa isang alertong "nakagawa ng pagbabago".
- Pagkatapos ng ilang na-configure na yugto ng panahon, maaaring magpadala ng "diff" na alerto kung magkaiba ang mga estado.
- Sa ganitong paraan, ang lahat ng commit sa Git ay nagdudulot ng mga nabe-verify at idempotent na update sa cluster.
- Ang rollback ay convergence sa dating gustong estado.
- Ang convergence ay pangwakas. Ang paglitaw nito ay ipinahiwatig ng:
- Walang mga diff alert para sa isang tiyak na tagal ng panahon.
- "converged" na alerto (hal. webhook, Git writeback na kaganapan).
Ano ang divergence?
Ulitin natin muli: lahat ng ninanais na katangian ng kumpol ay dapat na nakikita sa mismong kumpol.
Ilang halimbawa ng divergence:
- Pagbabago sa configuration file dahil sa pagsasama ng mga sangay sa Git.
- Isang pagbabago sa configuration file dahil sa isang Git commit na ginawa ng GUI client.
- Maramihang mga pagbabago sa nais na estado dahil sa PR sa Git na sinusundan ng pagbuo ng imahe ng lalagyan at mga pagbabago sa config.
- Isang pagbabago sa estado ng cluster dahil sa isang error, salungatan sa mapagkukunan na nagreresulta sa "masamang pag-uugali", o simpleng random na paglihis mula sa orihinal na estado.
Ano ang mekanismo ng convergence?
Ilang halimbawa:
- Para sa mga container at cluster, ang mekanismo ng convergence ay ibinibigay ng Kubernetes.
- Maaaring gamitin ang parehong mekanismo para pamahalaan ang mga application at disenyong nakabatay sa Kubernetes (gaya ng Istio at Kubeflow).
- Isang mekanismo para sa pamamahala ng operational na pakikipag-ugnayan sa pagitan ng Kubernetes, mga imbakan ng imahe at ibinibigay ng Git , na bahagi .
- Para sa mga base machine, ang mekanismo ng convergence ay dapat na deklaratibo at nagsasarili. From our own experience masasabi natin yan pinakamalapit sa kahulugang ito, ngunit nangangailangan pa rin ng kontrol ng tao. Sa ganitong kahulugan, pinalawak ng GitOps ang tradisyon ng Infrastructure bilang Code.
Pinagsasama ng GitOps ang Git sa mahusay na convergence engine ng Kubernetes upang magbigay ng modelo para sa pagsasamantala.
Pinapayagan tayo ng GitOps na sabihin: Tanging ang mga system na maaaring ilarawan at maobserbahan ang maaaring awtomatiko at kontrolin.
Ang GitOps ay inilaan para sa buong cloud native stack (halimbawa, Terraform, atbp.)
Ang GitOps ay hindi lamang Kubernetes. Nais naming ang buong sistema ay mahikayat nang deklaratibo at gumamit ng convergence. Sa kabuuan ng system ang ibig naming sabihin ay isang koleksyon ng mga environment na nagtatrabaho sa Kubernetes - halimbawa, "dev cluster 1", "production", atbp. Kasama sa bawat environment ang mga machine, cluster, application, pati na rin ang mga interface para sa mga external na serbisyo na nagbibigay ng data, pagsubaybay at iba pa.
Pansinin kung gaano kahalaga ang Terraform sa problema sa bootstrapping sa kasong ito. Kailangang i-deploy ang Kubernetes sa isang lugar, at ang paggamit ng Terraform ay nangangahulugan na maaari naming ilapat ang parehong mga daloy ng trabaho sa GitOps upang lumikha ng control layer na sumasailalim sa Kubernetes at mga application. Ito ay isang kapaki-pakinabang na pinakamahusay na kasanayan.
May matinding pokus sa paglalapat ng mga konsepto ng GitOps sa mga layer sa ibabaw ng Kubernetes. Sa ngayon, may mga solusyon sa uri ng GitOps para sa Istio, Helm, Ksonnet, OpenFaaS at Kubeflow, pati na rin, halimbawa, para sa Pulumi, na lumikha ng isang layer para sa pagbuo ng mga application para sa cloud native.
Kubernetes CI/CD: paghahambing ng GitOps sa iba pang mga diskarte
Tulad ng sinabi, ang GitOps ay dalawang bagay:
- Ang operating model para sa Kubernetes at cloud native na inilarawan sa itaas.
- Ang landas patungo sa kapaligiran ng pamamahala ng application na nakasentro sa developer.
Para sa marami, ang GitOps ay pangunahing isang daloy ng trabaho batay sa mga pagtulak ng Git. Gusto rin namin siya. Ngunit hindi lang iyon: tingnan natin ngayon ang mga pipeline ng CI/CD.
Ang GitOps ay nagbibigay-daan sa tuluy-tuloy na pag-deploy (CD) para sa Kubernetes
Nag-aalok ang GitOps ng tuluy-tuloy na mekanismo sa pag-deploy na nag-aalis ng pangangailangan para sa hiwalay na "mga sistema ng pamamahala ng deployment." Ginagawa ng Kubernetes ang lahat ng gawain para sa iyo.
- Ang pag-update ng application ay nangangailangan ng pag-update sa Git. Isa itong transactional update sa gustong estado. Ang "Deployment" ay ginagawa sa loob ng cluster ng Kubernetes mismo batay sa na-update na paglalarawan.
- Dahil sa likas na katangian ng kung paano gumagana ang Kubernetes, ang mga update na ito ay nagtatagpo. Nagbibigay ito ng mekanismo para sa tuluy-tuloy na pag-deploy kung saan atomic ang lahat ng update.
- Tandaan: nag-aalok ng GitOps operator na nagsasama ng Git at Kubernetes at nagbibigay-daan sa CD na maisagawa sa pamamagitan ng pag-reconcile sa gusto at kasalukuyang estado ng cluster.
Nang walang kubectl at mga script
Dapat mong iwasan ang paggamit ng Kubectl upang i-update ang iyong cluster, at lalo na iwasan ang paggamit ng mga script sa pagpapangkat ng mga kubectl command. Sa halip, gamit ang pipeline ng GitOps, maaaring i-update ng isang user ang kanilang Kubernetes cluster sa pamamagitan ng Git.
Kasama sa mga benepisyo ang:
- Tama. Ang isang pangkat ng mga update ay maaaring ilapat, pagsama-samahin at sa wakas ay mapatunayan, na maglalapit sa amin sa layunin ng atomic deployment. Sa kaibahan, ang paggamit ng mga script ay hindi nagbibigay ng anumang garantiya ng convergence (higit pa dito sa ibaba).
- katiwasayan. Kelsey Hightower: “Paghigpitan ang pag-access sa iyong Kubernetes cluster sa mga automation tool at administrator na responsable sa pag-debug o pagpapanatili nito.” Tingnan din tungkol sa kaligtasan at pagsunod sa mga teknikal na detalye, pati na rin sa pamamagitan ng pagnanakaw ng mga kredensyal mula sa isang walang ingat na isinulat na script ng Jenkins.
- Karanasan ng Gumagamit. Inilalantad ng Kubectl ang mechanics ng object model ng Kubernetes, na medyo kumplikado. Sa isip, ang mga user ay dapat makipag-ugnayan sa system sa mas mataas na antas ng abstraction. Dito ay muling sasangguni ako kay Kelsey at inirerekumenda ang panonood .
Pagkakaiba sa pagitan ng CI at CD
Pinapabuti ng GitOps ang mga kasalukuyang modelo ng CI/CD.
Ang modernong CI server ay isang tool sa orkestrasyon. Sa partikular, ito ay isang tool para sa pag-orkestra ng mga pipeline ng CI. Kabilang dito ang build, test, merge sa trunk, atbp. Ang mga CI server ay nag-automate ng pamamahala ng mga kumplikadong multi-step na pipeline. Ang isang karaniwang tukso ay ang pag-script ng isang hanay ng mga update ng Kubernetes at patakbuhin ito bilang bahagi ng isang pipeline upang itulak ang mga pagbabago sa cluster. Sa katunayan, ito ang ginagawa ng maraming eksperto. Gayunpaman, hindi ito pinakamainam, at narito kung bakit.
Dapat gamitin ang CI upang itulak ang mga update sa trunk, at dapat baguhin ng Kubernetes cluster ang sarili nito batay sa mga update na iyon upang pamahalaan ang CD sa loob. Tinatawag namin ito , hindi katulad ng CI push model. Bahagi ang CD runtime orkestrasyon.
Bakit Hindi Dapat Gumawa ng mga CD ang Mga CI Server sa pamamagitan ng Mga Direktang Update sa Kubernetes
Huwag gumamit ng CI server para i-orchestrate ang mga direktang update sa Kubernetes bilang isang set ng mga trabaho sa CI. Ito ang anti-pattern na pinag-uusapan natin sa iyong blog.
Bumalik tayo kina Alice at Bob.
Anong mga problema ang kanilang kinaharap? Inilalapat ng CI server ni Bob ang mga pagbabago sa cluster, ngunit kung nag-crash ito sa proseso, hindi malalaman ni Bob kung anong estado ang cluster (o dapat ay) nasa o kung paano ito ayusin. Ang parehong ay totoo sa kaso ng tagumpay.
Ipagpalagay natin na ang koponan ni Bob ay bumuo ng isang bagong imahe at pagkatapos ay na-patch ang kanilang mga deployment upang i-deploy ang imahe (lahat mula sa pipeline ng CI).
Kung ang imahe ay nabuo nang normal, ngunit ang pipeline ay nabigo, ang koponan ay kailangang malaman:
- Inilunsad ba ang pag-update?
- Naglulunsad ba tayo ng bagong build? Ito ba ay hahantong sa hindi kinakailangang mga side effect - na may posibilidad na magkaroon ng dalawang build ng parehong hindi nababagong imahe?
- Dapat ba nating hintayin ang susunod na update bago patakbuhin ang build?
- Ano nga ba ang naging mali? Aling mga hakbang ang kailangang ulitin (at alin ang ligtas na ulitin)?
Ang pagtatatag ng isang Git-based na daloy ng trabaho ay hindi ginagarantiya na ang koponan ni Bob ay hindi makakaranas ng mga problemang ito. Maaari pa rin silang magkamali sa commit push, tag, o iba pang parameter; gayunpaman, ang diskarteng ito ay mas malapit pa rin sa isang tahasang all-or-nothing na diskarte.
Upang buod, narito kung bakit hindi dapat harapin ng mga server ng CI ang CD:
- Ang mga script sa pag-update ay hindi palaging deterministiko; Madaling magkamali sa kanila.
- Ang mga CI server ay hindi nagtatagpo sa declarative cluster model.
- Mahirap i-garantiya ang pagka-indempotidad. Dapat na maunawaan ng mga gumagamit ang malalim na semantika ng system.
- Ito ay mas mahirap na makabawi mula sa isang bahagyang pagkabigo.
Tandaan tungkol sa Helm: Kung gusto mong gumamit ng Helm, inirerekomenda namin na pagsamahin ito sa isang GitOps operator gaya ng . Makakatulong ito na matiyak ang convergence. Ang timon mismo ay hindi deterministiko o atomic.
Ang GitOps bilang ang pinakamahusay na paraan upang ipatupad ang Tuloy-tuloy na Paghahatid para sa Kubernetes
Ang koponan nina Alice at Bob ay nagpapatupad ng GitOps at natuklasan na naging mas madali ang pagtatrabaho sa mga produkto ng software, pagpapanatili ng mataas na pagganap at katatagan. Tapusin natin ang artikulong ito sa isang paglalarawang nagpapakita kung ano ang hitsura ng kanilang bagong diskarte. Tandaan na kadalasang pinag-uusapan natin ang tungkol sa mga application at serbisyo, ngunit maaaring gamitin ang GitOps upang pamahalaan ang isang buong platform.
Operating model para sa Kubernetes
Tingnan ang sumusunod na diagram. Itinatanghal nito ang Git at ang container image repository bilang shared resources para sa dalawang orchestrated lifecycles:
- Isang tuluy-tuloy na integration pipeline na nagbabasa at nagsusulat ng mga file sa Git at maaaring mag-update ng repositoryo ng mga imahe ng container.
- Isang Runtime GitOps pipeline na pinagsasama ang deployment sa pamamahala at observability. Nagbabasa at nagsusulat ito ng mga file sa Git at maaaring mag-download ng mga larawan ng lalagyan.
Ano ang mga pangunahing natuklasan?
- Paghihiwalay ng mga alalahanin: Pakitandaan na ang parehong mga pipeline ay maaari lamang makipag-ugnayan sa pamamagitan ng pag-update ng Git o ang repositoryo ng imahe. Sa madaling salita, mayroong isang firewall sa pagitan ng CI at ng runtime na kapaligiran. Tinatawag namin itong "immutability firewall" (hindi nababagong firewall), dahil ang lahat ng mga update sa repository ay lumilikha ng mga bagong bersyon. Para sa karagdagang impormasyon sa paksang ito, sumangguni sa mga slide 72-87 .
- Maaari kang gumamit ng anumang CI at Git server: Gumagana ang GitOps sa anumang bahagi. Maaari mong patuloy na gamitin ang iyong mga paboritong CI at Git server, mga repositoryo ng imahe, at mga suite ng pagsubok. Halos lahat ng iba pang mga tool sa Patuloy na Paghahatid sa merkado ay nangangailangan ng kanilang sariling CI/Git server o imbakan ng imahe. Ito ay maaaring maging isang limiting factor sa pagbuo ng cloud native. Sa GitOps, maaari kang gumamit ng mga pamilyar na tool.
- Mga kaganapan bilang isang tool sa pagsasama: Sa sandaling ma-update ang data sa Git, aabisuhan ng Weave Flux (o ang operator ng Weave Cloud) ang runtime. Sa tuwing tumatanggap ang Kubernetes ng set ng pagbabago, ina-update ang Git. Nagbibigay ito ng simpleng modelo ng pagsasama para sa pag-aayos ng mga daloy ng trabaho para sa GitOps, tulad ng ipinapakita sa ibaba.
Konklusyon
Nagbibigay ang GitOps ng malakas na mga garantiya sa pag-update na kinakailangan ng anumang modernong tool ng CI/CD:
- automation;
- tagpo;
- kawalan ng lakas;
- determinismo.
Mahalaga ito dahil nag-aalok ito ng operational na modelo para sa mga cloud native na developer.
- Ang mga tradisyonal na tool para sa pamamahala at pagsubaybay sa mga system ay nauugnay sa mga operations team na tumatakbo sa loob ng isang runbook (isang set ng mga nakagawiang pamamaraan at pagpapatakbo - tinatayang transl.), nakatali sa isang partikular na deployment.
- Sa cloud native na pamamahala, ang mga tool sa observability ay ang pinakamahusay na paraan upang sukatin ang mga resulta ng mga deployment upang mabilis na tumugon ang development team.
Isipin ang maraming kumpol na nakakalat sa iba't ibang ulap at maraming serbisyo na may sariling mga koponan at mga plano sa pag-deploy. Nag-aalok ang GitOps ng scale-invariant na modelo para sa pamamahala sa lahat ng kasaganaan na ito.
PS mula sa tagasalin
Basahin din sa aming blog:
- «";
- «";
- «'.
Ang mga rehistradong user lamang ang maaaring lumahok sa survey. , pakiusap
Alam mo ba ang tungkol sa GitOps bago lumabas ang dalawang pagsasaling ito sa Habré?
-
Oo, alam ko ang lahat
-
Mababaw lang
-
Hindi
35 user ang bumoto. 10 na user ang umiwas.
Pinagmulan: www.habr.com