Nota. transl.: Sa komunidad sa Kubernetes, usa ka uso nga gitawag og GitOps nagkaanam og kabantog, sama sa personal natong nakita, KubeCon Europe 2019. Kini nga termino bag-o lang sa ulo sa Weaveworks - Alexis Richardson - ug nagpasabot sa paggamit sa mga himan nga pamilyar sa mga developers (panguna nga Git, busa ang ngalan) aron masulbad ang mga problema sa operasyon. Sa partikular, naghisgot kami bahin sa operasyon sa Kubernetes pinaagi sa pagtipig sa mga pag-configure niini sa Git ug awtomatiko nga naglansad sa mga pagbag-o sa cluster. Si Matthias Jg naghisgot bahin sa duha ka pamaagi sa kini nga paglusad niini nga artikulo.
Niaging tuig (sa tinuud, pormal nga nahitabo kini kaniadtong Agosto 2017 - gibanabana nga transl.) Adunay bag-ong pamaagi sa pag-deploy sa mga aplikasyon sa Kubernetes. Gitawag kini nga GitOps, ug gibase kini sa batakang ideya nga ang mga bersyon sa pag-deploy gisubay sa luwas nga palibot sa usa ka Git repository.
Ang nag-unang bentaha niini nga pamaagi mao ang mosunod::
- Pag-deploy nga bersyon ug pagbag-o sa kasaysayan. Ang estado sa tibuok cluster gitipigan sa usa ka Git repository, ug ang mga deployment gi-update lamang pinaagi sa mga commit. Dugang pa, ang tanan nga mga pagbag-o mahimong masubay gamit ang kasaysayan sa commit.
- Mga rollback gamit ang pamilyar nga Git nga mga sugo. Yano
git resetnagtugot kanimo sa pag-reset sa mga pagbag-o sa mga deployment; ang nangaging mga estado kanunay nga magamit. - Andam nga kontrol sa pag-access. Kasagaran, ang usa ka sistema sa Git adunay daghang mga sensitibo nga datos, mao nga kadaghanan sa mga kompanya naghatag espesyal nga atensyon sa pagpanalipod niini. Tungod niini, kini nga proteksyon magamit usab sa mga operasyon nga adunay mga pag-deploy.
- Mga Patakaran alang sa mga Deployment. Kadaghanan sa mga sistema sa Git lumad nga nagsuporta sa mga palisiya sa branch-by-branch—pananglitan, ang mga pull request lang ang maka-update sa master, ug ang mga kausaban kinahanglang susihon ug dawaton sa laing miyembro sa team. Sama sa kontrol sa pag-access, ang parehas nga mga palisiya magamit sa mga update sa pag-deploy.
Sama sa imong nakita, adunay daghang mga benepisyo sa pamaagi sa GitOps. Sa miaging tuig, duha ka mga pamaagi ang nakakuha sa partikular nga pagkapopular. Ang usa kay push based, ang usa kay pull based. Sa dili pa nato sila tan-awon, atong tan-awon una kung unsa ang hitsura sa kasagaran nga mga pag-deploy sa Kubernetes.
Mga Pamaagi sa Pag-deploy
Sa bag-ohay nga mga tuig, lain-laing mga pamaagi ug mga himan alang sa deployment natukod sa Kubernetes:
- Base sa lumad nga Kubernetes/Kustomize templates. Kini ang pinakasayon nga paagi sa pag-deploy sa mga aplikasyon sa Kubernetes. Ang developer nagmugna sa mga batakang YAML file ug gipadapat kini. Aron matangtang ang kanunay nga pagsulat pag-usab sa parehas nga mga templates, ang Kustomize gihimo (gihimo niini ang mga template sa Kubernetes nga mga module). Nota. transl.: Ang Kustomize gisagol sa kubectl uban sa .
- Mga Tsart sa Helm. Ang mga tsart sa helm nagtugot kanimo sa paghimo og mga set sa mga templates, init nga mga sudlanan, mga sidecar, ug uban pa, nga gigamit sa pag-deploy sa mga aplikasyon nga adunay mas flexible nga mga kapilian sa pag-customize kaysa sa usa ka template-based nga pamaagi. Kini nga pamaagi gibase sa templated YAML files. Gipuno sila sa Helm sa lainlaing mga parameter ug dayon ipadala kini sa Tiller, usa ka sangkap sa cluster nga nag-deploy niini sa cluster ug gitugotan ang mga update ug rollback. Ang hinungdanon nga butang mao nga ang Helm hinungdanon nga gisulud ra ang gitinguha nga mga kantidad sa mga template ug dayon gipadapat kini sa parehas nga paagi sama sa gihimo sa tradisyonal nga pamaagi. (basaha ang dugang bahin sa kung giunsa kini tanan molihok ug kung giunsa nimo kini magamit sa among - gibanabana. transl.). Adunay usa ka halapad nga lainlain nga andam na nga mga tsart sa Helm nga naglangkob sa usa ka halapad nga mga buluhaton.
- Alternatibo nga mga Himan. Adunay daghang alternatibo nga mga himan. Ang managsama nilang tanan mao nga ilang gihimo ang pipila ka mga template file ngadto sa Kubernetes-readable YAML files ug dayon gamiton kini.
Sa among trabaho, kanunay namong gigamit ang mga Helm chart para sa importanteng mga himan (tungod kay daghan na silag mga butang nga andam na, nga nakapasayon sa kinabuhi) ug "puro" Kubernetes YAML file para sa pagdeploy sa among kaugalingong mga aplikasyon.
Ibira ug Iduso
Sa usa sa akong bag-o nga mga post sa blog, akong gipaila ang himan , nga nagtugot kanimo sa pag-commit sa mga templates sa Git repository ug pag-update sa deployment human sa matag commit o pagduso sa sudlanan. Ang akong kasinatian nagpakita nga kini nga himan mao ang usa sa mga nag-una sa pagpasiugda sa pagbitad nga pamaagi, mao nga ako sa kanunay nagtumong niini. Kung gusto nimo mahibal-an ang dugang kung giunsa kini paggamit, dinhi .
NB! Ang tanan nga mga benepisyo sa paggamit sa GitOps nagpabilin nga parehas alang sa duha nga mga pamaagi.
Pull based nga pamaagi
Ang pamaagi sa pagbitad gibase sa kamatuoran nga ang tanan nga mga pagbag-o gipadapat gikan sa sulod sa cluster. Adunay usa ka operator sa sulod sa cluster nga kanunay nga nagsusi sa kaubang Git ug Docker Registry repository. Kung adunay mga pagbag-o nga mahitabo sa kanila, ang kahimtang sa cluster gi-update sa sulod. Kini nga proseso sa kasagaran giisip nga luwas kaayo, tungod kay walay eksternal nga kliyente ang adunay access sa mga katungod sa tagdumala sa cluster.
Mga Pro:
- Wala’y gawas nga kliyente nga adunay katungod sa paghimo og mga pagbag-o sa cluster; ang tanan nga mga update gilunsad gikan sa sulod.
- Gitugotan ka usab sa ubang mga himan nga i-synchronize ang mga update sa tsart sa Helm ug i-link kini sa cluster.
- Ang Docker Registry mahimong ma-scan alang sa mga bag-ong bersyon. Kung adunay bag-ong imahe, ang Git repository ug pag-deploy gi-update sa bag-ong bersyon.
- Ang mga gamit sa pagbitad mahimong maapod-apod sa lainlaing mga namespace nga adunay lainlaing mga repositoryo ug pagtugot sa Git. Salamat niini, ang usa ka multitenant nga modelo mahimong magamit. Pananglitan, ang team A mahimong mogamit sa namespace A, ang team B mahimong mogamit sa namespace B, ug ang team sa imprastraktura mahimong mogamit sa global space.
- Ingon sa usa ka lagda, ang mga himan gaan kaayo.
- Gihiusa sa mga himan sama sa operator , ang mga sekreto mahimong tipigan nga naka-encrypt sa usa ka Git repository ug makuha sulod sa cluster.
- Wala’y koneksyon sa mga pipeline sa CD tungod kay ang mga pag-deploy nahitabo sa sulod sa cluster.
Минусы:
- Ang pagdumala sa mga sekreto sa pag-deploy gikan sa mga tsart sa Helm mas lisud kay sa mga regular, tungod kay sila kinahanglan una nga mamugna sa porma sa, ingnon ta, mga tinago nga mga sekreto, dayon gi-decrypt sa usa ka internal nga operator, ug pagkahuman lamang kini magamit sa tool sa pagbitad. Pagkahuman mahimo nimong ipadagan ang pagpagawas sa Helm nga adunay mga kantidad sa na-deploy na nga mga sekreto. Ang labing kadali nga paagi mao ang paghimo usa ka sekreto sa tanan nga mga kantidad sa Helm nga gigamit alang sa pag-deploy, pag-decrypt niini ug itugyan kini sa Git.
- Kung mokuha ka ug paagi sa pagbitad, mahigot ka sa pagbitad sa mga himan. Gilimitahan niini ang abilidad sa pag-customize sa proseso sa pag-deploy sa usa ka cluster. Pananglitan, ang Kustomize komplikado sa kamatuoran nga kini kinahanglan nga modagan sa dili pa ang katapusan nga mga templates itugyan ngadto sa Git. Wala ako nag-ingon nga dili ka makagamit sa mga gamit nga nag-inusara, apan mas lisud kini nga i-integrate sa imong proseso sa pag-deploy.
Push based nga pamaagi
Sa pamaagi sa pagduso, ang usa ka eksternal nga sistema (kadaghanan sa mga pipeline sa CD) naglansad sa mga deployment sa cluster pagkahuman sa usa ka commit sa Git repository o kung ang miaging CI pipeline malampuson. Niini nga pamaagi, ang sistema adunay access sa cluster.
Плюсы:
- Ang seguridad gitino sa Git repository ug pagtukod sa pipeline.
- Ang pag-deploy sa mga tsart sa Helm mas sayon ug nagsuporta sa mga plugin sa Helm.
- Ang mga sekreto mas dali madumala tungod kay ang mga sekreto magamit sa mga pipeline ug mahimo usab nga tipigan nga naka-encrypt sa Git (depende sa gusto sa tiggamit).
- Wala’y koneksyon sa usa ka piho nga himan, tungod kay ang bisan unsang klase mahimong magamit.
- Ang mga pag-update sa bersyon sa sudlanan mahimong masugdan pinaagi sa pipeline sa pagtukod.
Минусы:
- Ang datos sa pag-access sa cluster naa sa sulod sa sistema sa pagtukod.
- Ang pag-update sa mga sudlanan sa pag-deploy mas sayon pa sa proseso sa pagbitad.
- Ang bug-at nga pagsalig sa sistema sa CD, tungod kay ang mga pipeline nga atong gikinahanglan mahimo nga orihinal nga gisulat alang sa Gitlab Runners, ug dayon ang team mihukom nga mobalhin sa Azure DevOps o Jenkins ...
Resulta: Iduso o Ibira?
Sama sa kasagaran nga kaso, ang matag pamaagi adunay mga bentaha ug disbentaha. Ang ubang mga buluhaton mas sayon nga matuman sa usa ug mas lisud sa lain. Sa sinugdan naghimo ako og mga deployment nga mano-mano, apan pagkahuman nako makit-an ang pipila ka mga artikulo bahin sa Weave Flux, nakahukom ko nga ipatuman ang mga proseso sa GitOps alang sa tanan nga mga proyekto. Para sa mga batakang templates sayon ra kini, apan nagsugod ako sa pagdagan sa mga kalisud sa mga tsart sa Helm. Niadtong panahona, ang Weave Flux nagtanyag lamang og usa ka bag-o nga bersyon sa Helm Chart Operator, apan bisan karon ang pipila ka mga buluhaton mas lisud tungod sa panginahanglan nga mano-mano ang paghimo sa mga sekreto ug paggamit niini. Mahimo kang makiglalis nga ang pamaagi sa pagbitad mas luwas tungod kay ang mga kredensyal sa cluster dili ma-access sa gawas sa cluster, nga naghimo niini nga mas luwas nga kini takus sa dugang nga paningkamot.
Human sa pipila ka paghunahuna, miabut ako sa wala damha nga konklusyon nga kini dili mao. Kung maghisgot kita bahin sa mga sangkap nga nanginahanglan labing taas nga proteksyon, kini nga lista maglakip sa sekreto nga pagtipig, mga sistema sa CI / CD, ug mga repositoryo sa Git. Ang kasayuran sa sulod niini huyang kaayo ug nanginahanglan labing taas nga proteksyon. Dugang pa, kung adunay mosulod sa imong Git repository ug makaduso sa code didto, mahimo nilang i-deploy ang bisan unsang gusto nila (pagbira man o pagduso) ug pag-infiltrate sa mga sistema sa cluster. Sa ingon, ang labing hinungdanon nga sangkap nga kinahanglan panalipdan mao ang Git repository ug mga sistema sa CI / CD, dili ang mga kredensyal sa cluster. Kung ikaw adunay maayong pagka-configure nga mga palisiya ug mga kontrol sa seguridad alang sa kini nga mga matang sa mga sistema, ug ang mga kredensyal sa cluster gikuha lamang sa mga linya sa tubo ingon mga sekreto, ang dugang nga seguridad sa usa ka pamaagi sa pagbira mahimong dili ingon ka bililhon sama sa orihinal nga gihunahuna.
Busa, kon ang pull approach kay labor intensive ug dili makahatag ug security benefit, dili ba makatarunganon nga gamiton lang ang push approach? Apan ang usa ka tawo mahimong makiglalis nga sa pagduso nga pamaagi ikaw nahigot kaayo sa sistema sa CD ug, tingali, mas maayo nga dili kini buhaton aron mas sayon ang pagpahigayon sa mga paglalin sa umaabot.
Sa akong opinyon (sama sa kanunay), kinahanglan nimo gamiton kung unsa ang labing angay alang sa usa ka partikular nga kaso o kombinasyon. Sa personal, gigamit nako ang duha ka mga pamaagi: Weave Flux para sa mga pull-based deployment nga kasagaran naglakip sa among kaugalingong mga serbisyo, ug usa ka push approach uban sa Helm ug mga plugins, nga makapasayon sa paggamit sa mga Helm chart sa cluster ug nagtugot kanimo sa paghimo sa mga sekreto nga hapsay. Sa akong hunahuna wala’y usa ka solusyon nga angay alang sa tanan nga mga kaso, tungod kay kanunay adunay daghang mga nuances ug nagdepende sila sa piho nga aplikasyon. Ingon niana, girekomenda ko kaayo ang GitOps - gipadali niini ang kinabuhi ug gipauswag ang seguridad.
Nanghinaut ko nga ang akong kasinatian sa kini nga hilisgutan makatabang kanimo sa pagdesisyon kung unsang pamaagi ang mas angay alang sa imong tipo sa pag-deploy, ug malipay ako nga makadungog sa imong opinyon.
PS Note gikan sa tighubad
Ang downside sa pull model mao nga lisud ang pagbutang sa gihubad nga mga manifests ngadto sa Git, apan walay downside nga ang CD pipeline sa pull model nagpuyo nga bulag gikan sa rollout ug sa esensya nahimong usa ka category pipeline. Padayon nga Pag-aplay. Busa, mas daghang paningkamot ang gikinahanglan aron makolekta ang ilang status gikan sa tanang deployment ug sa usa ka paagi maghatag ug access sa mga log/status, mas maayo nga may kalabotan sa CD system.
Niini nga pagsabut, ang modelo sa pagduso nagtugot kanamo sa paghatag labing menos pipila ka mga garantiya sa rollout, tungod kay ang tibuok kinabuhi sa pipeline mahimo nga katumbas sa tibuok kinabuhi sa rollout.
Gisulayan namon ang duha nga mga modelo ug nakaabut sa parehas nga mga konklusyon sama sa tagsulat sa artikulo:
- Ang modelo sa pagbitad angay alang kanamo aron ma-organisar ang mga pag-update sa mga sangkap sa sistema sa daghang gidaghanon sa mga kumpol (tan-awa. ).
- Ang modelo sa pagduso nga gibase sa GitLab CI haum kaayo alang sa pagpalupad sa mga aplikasyon gamit ang mga tsart sa Helm. Sa parehas nga oras, ang paglansad sa mga pag-deploy sa sulod sa mga pipeline gibantayan gamit ang himan . Pinaagi sa dalan, sa konteksto niining among proyekto, nakadungog kami sa kanunay nga "GitOps" sa dihang among gihisgutan ang dinalian nga mga problema sa mga inhenyero sa DevOps sa among baroganan sa KubeCon Europe'19.
PPS gikan sa tighubad
Basaha usab sa among blog:
- «";
- «";
- «";
- «".
Ang mga rehistradong tiggamit lamang ang makaapil sa survey. , walay sapayan.
Gigamit ba nimo ang GitOps?
-
Oo, pull approach
-
Oo, push
-
Oo, pagbitad + pagduso
-
Oo, laing butang
-
Dili
30 ka tiggamit ang nagboto. 10 ka tiggamit ang nag-abstain.
Source: www.habr.com