🥇werf - among himan para sa CI/CD sa Kubernetes (review ug video report)

Mayo 27 sa main hall sa DevOpsConf 2019 nga komperensya, nga gihimo isip bahin sa pista RIT++ 2019, isip kabahin sa seksyon nga "Padayon nga Paghatud", usa ka taho ang gihatag nga "werf - among himan alang sa CI/CD sa Kubernetes". Naghisgot kini bahin sa mga mga problema ug mga hagit nga giatubang sa tanan sa pag-deploy sa Kubernetes, ingon man mahitungod sa mga nuances nga mahimong dili dayon mamatikdan. Pag-analisar sa posible nga mga solusyon, among gipakita kung giunsa kini gipatuman sa usa ka tool sa Open Source werf.

Sukad sa presentasyon, ang atong utility (kaniadto nailhan nga dapp) nakaabot sa usa ka makasaysayanon nga milestone sa 1000 ka bituon sa GitHub — nanghinaut kami nga ang nagkadako nga komunidad sa mga tiggamit niini makapasayon sa kinabuhi alang sa daghang mga inhenyero sa DevOps.

So, magpaila ta video sa report (~47 ka minuto, labi pa ka impormasyon kaysa sa artikulo) ug ang panguna nga kinuha gikan niini sa porma sa teksto. Lakaw!

Paghatud sa code sa Kubernetes

Ang pakigpulong dili na mahitungod sa werf, apan mahitungod sa CI / CD sa Kubernetes, nagpasabot nga ang among software giputos sa mga sudlanan sa Docker (Gihisgotan nako kini sa 2016 nga report), ug K8s gamiton sa pagpadagan niini sa produksyon (dugang bahin niini sa 2017 nga tuig).

Unsa ang hitsura sa paghatud sa Kubernetes?

Adunay usa ka Git repository nga adunay code ug mga panudlo alang sa pagtukod niini. Ang aplikasyon gitukod sa usa ka Docker nga imahe ug gipatik sa Docker Registry.
Ang parehas nga repository adunay usab mga panudlo kung giunsa ang pag-deploy ug pagpadagan sa aplikasyon. Sa yugto sa pag-deploy, kini nga mga panudlo ipadala sa Kubernetes, nga makadawat sa gusto nga imahe gikan sa rehistro ug ilunsad kini.
Dugang pa, kasagaran adunay mga pagsulay. Ang uban niini mahimo kung mag-publish og usa ka imahe. Mahimo usab nimo (pagsunod sa parehas nga mga panudlo) mag-deploy og usa ka kopya sa aplikasyon (sa usa ka lahi nga namespace sa K8 o usa ka lahi nga kumpol) ug pagdagan ang mga pagsulay didto.
Sa katapusan, kinahanglan nimo ang usa ka sistema sa CI nga makadawat mga panghitabo gikan sa Git (o mga pag-klik sa buton) ug tawagan ang tanan nga gitudlo nga mga yugto: pagtukod, pagmantala, pag-deploy, pagsulay.

Adunay pipila ka importante nga mga nota dinhi:

Tungod kay kita adunay usa ka dili mausab nga imprastraktura (dili mausab nga imprastraktura), ang imahe sa aplikasyon nga gigamit sa tanan nga mga yugto (staging, produksiyon, ug uban pa), kinahanglan adunay usa. Gihisgotan nako kini sa mas detalyado ug uban ang mga pananglitan. dinhi.
Tungod kay nagsunod kita sa imprastraktura isip pamaagi sa code (IaC), ang code sa aplikasyon, mga panudlo alang sa pag-assemble ug paglansad niini kinahanglan eksakto sa usa ka repository. Alang sa dugang nga impormasyon bahin niini, tan-awa parehas nga report.
Delivery chain (paghatud) kasagaran atong makita nga ingon niini: ang aplikasyon gitigum, gisulayan, gibuhian (yugto sa pagpagawas) ug mao kana - ang paghatud nahitabo. Apan sa tinuud, nakuha sa tiggamit ang imong gilusad, dili unya sa dihang gihatod nimo kini sa produksiyon, ug sa dihang nakaadto siya didto ug kini nga produksyon nagtrabaho. Mao nga nagtuo ko nga ang kadena sa pagpadala natapos lamang sa operational stage (dagan), o mas tukma, bisan sa higayon nga ang code gikuha gikan sa produksyon (ilisan kini og bag-o).

Balikan nato ang plano sa pagpadala sa ibabaw sa Kubernetes: kini giimbento dili lamang kanato, kondili sa literal nga tanan nga nag-atubang niini nga problema. Sa tinuud, kini nga sumbanan gitawag karon nga GitOps (Mahimo nimong basahon ang dugang bahin sa termino ug ang mga ideya sa luyo niini dinhi). Atong tan-awon ang mga yugto sa laraw.

Pagtukod sa entablado

Mopatim-aw nga mahimo nimong hisgutan ang bahin sa paghimo sa mga imahe sa Docker sa 2019, kung nahibal-an sa tanan kung giunsa pagsulat ang Dockerfiles ug pagdagan. docker build?.. Ania ang mga nuances nga gusto nakong hatagan ug pagtagad:

gibug-aton sa hulagway importante, busa gamita multi-stagenga ibilin sa imahe lamang ang aplikasyon nga kinahanglan gyud alang sa operasyon.
Gidaghanon sa mga lut-od kinahanglan nga maminusan pinaagi sa paghiusa sa mga kadena sa RUN-mga sugo sumala sa kahulogan.
Bisan pa, kini nagdugang mga problema pag-debug, tungod kay kung nahagsa ang asembliya, kinahanglan nimo pangitaon ang husto nga mando gikan sa kadena nga hinungdan sa problema.
Katulin sa asembliya hinungdanon tungod kay gusto namon nga dali nga ilunsad ang mga pagbag-o ug makita ang mga sangputanan. Pananglitan, dili nimo gusto nga magtukod pag-usab sa mga dependency sa mga librarya sa pinulongan matag higayon nga maghimo ka og aplikasyon.
Kasagaran gikan sa usa ka Git repository nga imong gikinahanglan daghang mga imahe, nga mahimong masulbad pinaagi sa usa ka set sa Dockerfiles (o ginganlan nga mga yugto sa usa ka file) ug usa ka Bash script uban sa ilang sequential assembly.

Kini mao lamang ang tumoy sa iceberg nga giatubang sa tanan. Apan adunay uban pang mga problema, labi na:

Kasagaran sa yugto sa asembliya kinahanglan naton ang usa ka butang bukid (pananglitan, i-cache ang resulta sa usa ka command sama sa apt sa usa ka third-party nga direktoryo).
Gusto namo Ansible imbes nga isulat sa kabhang.
Gusto namo pagtukod nga walay Docker (nganong nagkinahanglan man kita og dugang nga virtual machine diin kinahanglan natong i-configure ang tanan alang niini, kung aduna na kitay Kubernetes cluster diin kita makadagan sa mga sudlanan?).
Parallel nga asembliya, nga masabtan sa lain-laing mga paagi: lain-laing mga sugo gikan sa Dockerfile (kon multi-stage gigamit), pipila commits sa sama nga repository, daghang Dockerfiles.
Gipanagtag nga asembliya: Gusto namong mangolekta og mga butang sa pod nga "ephemeral" kay nawala ang ilang cache, nga nagpasabut nga kini kinahanglan nga tipigan sa usa ka lugar nga gilain.
Sa kataposan, akong ginganlan ang kinapungkayan sa mga tinguha awtomatik: Kini mao ang sulundon nga sa pag-adto sa repository, type sa pipila ka sugo ug sa pagkuha sa usa ka andam-naghimo nga larawan, gitigum uban sa usa ka pagsabut kon sa unsang paagi ug unsa ang buhaton sa husto nga paagi. Bisan pa, ako mismo dili sigurado nga ang tanan nga mga nuances mahimong makita sa ingon niini nga paagi.

Ug ania ang mga proyekto:

moby/buildkit - usa ka magtutukod gikan sa Docker Inc (nahiusa na sa karon nga mga bersyon sa Docker), nga naningkamot sa pagsulbad sa tanan niini nga mga problema;
kani - usa ka magtutukod gikan sa Google nga nagtugot kanimo sa pagtukod nga wala ang Docker;
Buildpacks.io - Ang pagsulay sa CNCF nga maghimo awtomatik nga salamangka ug, labi na, usa ka makapaikag nga solusyon nga adunay rebase alang sa mga layer;
ug usa ka hugpong sa ubang mga utilities, sama sa pagtukod, genuinetools/img...

...ug tan-awa kung pila ang ilang mga bituon sa GitHub. Sa ato pa, sa usa ka bahin, docker build anaa ug makahimo sa usa ka butang, apan sa pagkatinuod ang isyu dili hingpit nga masulbad - ang pamatuod niini mao ang parallel development sa alternatibong mga collectors, nga ang matag usa makasulbad sa pipila ka bahin sa mga problema.

Asembliya sa werf

So naa mi werf (kaniadto bantog ingon dapp) - Usa ka bukas nga gigikanan nga gamit gikan sa kompanya sa Flant, nga among gihimo sa daghang mga tuig. Nagsugod ang tanan 5 ka tuig na ang milabay sa mga script sa Bash nga nag-optimize sa asembliya sa Dockerfiles, ug sa miaging 3 ka tuig ang hingpit nga pag-uswag nahimo sa sulud sa usa ka proyekto nga adunay kaugalingon nga Git repository. (una sa Ruby, ug dayon gisulat pag-usab sa Go, ug sa samang higayon giilisan ang ngalan). Unsa nga mga isyu sa asembliya ang nasulbad sa werf?

Ang mga problema nga gilandongan sa asul napatuman na, ang parallel build gihimo sulod sa samang host, ug ang mga isyu nga gipasiugda sa yellow giplanohan nga mahuman sa katapusan sa ting-init.

Yugto sa publikasyon sa rehistro (pagmantala)

Nag-dial mi docker push... - unsa ang mahimong lisud bahin sa pag-upload sa usa ka imahe sa registry? Ug unya mitungha ang pangutana: "Unsa nga tag ang akong ibutang sa imahe?" Kini mitungha tungod sa rason nga kita adunay Gitflow (o uban pang estratehiya sa Git) ug Kubernetes, ug ang industriya naningkamot sa pagsiguro nga kung unsa ang mahitabo sa Kubernetes nagsunod sa mahitabo sa Git. Human sa tanan, ang Git mao lamang ang atong tinubdan sa kamatuoran.

Unsay lisod ani? Siguroha ang reproducibility: gikan sa usa ka commit sa Git, nga dili mausab sa kinaiyahan (dili mausab), sa usa ka imahe sa Docker, nga kinahanglan nga huptan nga parehas.

Importante usab kini kanato pagtino sa gigikanan, tungod kay gusto namon nga masabtan kung diin gihimo ang aplikasyon nga nagdagan sa Kubernetes natukod (unya mahimo namon ang mga diff ug parehas nga mga butang).

Mga Estratehiya sa Pag-tag

Ang una kay simple git tag. Kami adunay usa ka rehistro nga adunay usa ka imahe nga gi-tag ingon 1.0. Ang Kubernetes adunay entablado ug produksyon, diin kini nga hulagway gi-upload. Sa Git naghimo kami og mga pasalig ug sa usa ka punto kami nag-tag 2.0. Gikolekta namo kini sumala sa mga instruksyon gikan sa repository ug gibutang kini sa registry nga adunay tag 2.0. Gi-roll namo kini sa entablado ug, kung maayo ang tanan, dayon sa produksiyon.

Ang problema sa kini nga pamaagi mao nga una namon nga gibutang ang tag, ug pagkahuman gisulayan ug gilukot kini. Ngano man? Una, dili makatarunganon: nag-isyu kami usa ka bersyon sa software nga wala pa namon nasulayan (dili namon mahimo kung dili, tungod kay aron masusi, kinahanglan namon nga magbutang usa ka tag). Ikaduha, kini nga dalan dili compatible sa Gitflow.

Ang ikaduha nga kapilian mao git commit + tag. Ang master branch adunay tag 1.0; alang niini sa rehistro - usa ka imahe nga gipakatap sa produksiyon. Dugang pa, ang Kubernetes cluster adunay preview ug staging contours. Sunod among gisundan ang Gitflow: sa panguna nga sanga alang sa kalamboan (develop) naghimo kami og mga bag-ong feature, nga miresulta sa usa ka commit sa identifier #c1. Gikolekta namo kini ug gimantala kini sa rehistro gamit kini nga identifier (#c1). Uban sa parehas nga identifier nga among gilusad aron ma-preview. Mao usab ang among gibuhat sa mga pasalig #c2 и #c3.

Kung nahibal-an namon nga adunay igo nga mga bahin, nagsugod kami sa pagpalig-on sa tanan. Paghimo og branch sa Git release_1.1 (sa base #c3 gikan sa develop). Dili kinahanglan nga kolektahon kini nga pagpagawas, tungod kay ... gihimo kini sa miaging lakang. Busa, mahimo ra naton kini i-roll out sa dula. Giayo namon ang mga bug sa #c4 ug susamang roll out ngadto sa staging. Sa samang higayon, ang pag-uswag nagpadayon develop, diin ang mga pagbag-o matag karon ug unya gikuha gikan release_1.1. Sa pila ka punto, nakakuha kami usa ka pasalig nga giipon ug gi-upload sa dula, nga nalipay kami (#c25).

Dayon among i-merge (uban ang fast-forward) ang release branch (release_1.1) sa master. Nagbutang kami og tag nga adunay bag-ong bersyon niini nga commit (1.1). Apan kini nga imahe nakolekta na sa rehistro, mao nga aron dili na makolekta kini pag-usab, magdugang kami usa ka ikaduha nga tag sa naglungtad nga imahe (karon kini adunay mga tag sa rehistro #c25 и 1.1). Pagkahuman niana, gi-roll namon kini sa produksiyon.

Adunay usa ka disbentaha nga usa ra ka imahe ang gi-upload sa dula (#c25), ug sa produksiyon lahi kini (1.1), apan nahibal-an namon nga "pisikal" kini parehas nga imahe gikan sa rehistro.

Ang tinuod nga disbentaha mao nga walay suporta alang sa merge commits, kinahanglan nimo nga buhaton ang fast-forward.

Makapadayon pa kita ug makahimo ug limbong... Atong tan-awon ang usa ka pananglitan sa usa ka yano nga Dockerfile:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

Magtukod kita og usa ka file gikan niini sumala sa mosunod nga prinsipyo:

SHA256 gikan sa mga identifier sa mga imahe nga gigamit (ruby:2.3 и nginx:alpine), nga maoy mga checksum sa ilang sulod;
tanang team (RUN, CMD ug uban pa.);
SHA256 gikan sa mga file nga gidugang.

... ug kuhaa ang checksum (pag-usab SHA256) gikan sa ingon nga file. Kini pirma tanan nga naghubit sa mga sulud sa imahe sa Docker.

Balik ta sa diagram ug imbes nga commit atong gamiton ang maong mga pirma, i.e. tag mga imahe nga adunay mga pirma.

Karon, kung gikinahanglan, pananglitan, ang paghiusa sa mga pagbag-o gikan sa usa ka pagpagawas ngadto sa master, mahimo naton ang usa ka tinuud nga paghiusa nga nahimo: kini adunay lahi nga identifier, apan parehas nga pirma. Uban sa parehas nga identifier among i-roll out ang imahe sa produksiyon.

Ang disbentaha mao nga karon dili na posible nga mahibal-an kung unsang klase nga pasalig ang giduso sa produksiyon - ang mga checksum nagtrabaho lamang sa usa ka direksyon. Ang kini nga problema nasulbad pinaagi sa usa ka dugang nga layer nga adunay metadata - isulti ko kanimo ang labi pa sa ulahi.

Pag-tag sa werf

Sa werf mipadayon pa kami ug nangandam sa paghimo sa usa ka gipang-apod-apod nga pagtukod nga adunay cache nga wala gitipigan sa usa ka makina ... Busa, nagtukod kami og duha ka matang sa mga imahe sa Docker, gitawag namo sila stage и larawan.

Ang werf Git repository nagtipig sa piho nga mga panudlo sa pagtukod nga naghulagway sa lainlaing mga yugto sa pagtukod (sa dili pa i-install, pag-instalar, sa wala pa ang Setup, setup). Gikolekta namo ang unang yugto nga hulagway nga adunay pirma nga gihubit isip checksum sa unang mga lakang. Dayon atong idugang ang source code, alang sa bag-ong stage image atong kuwentahon ang checksum niini... Kini nga mga operasyon gisubli alang sa tanan nga mga yugto, isip resulta diin kita makakuha og usa ka hugpong sa mga hulagway sa entablado. Dayon atong himoon ang katapusang hulagway, nga naglangkob usab sa metadata mahitungod sa gigikanan niini. Ug among gi-tag kini nga imahe sa lainlaing mga paagi (mga detalye sa ulahi).

Ibutang ta nga pagkahuman niini usa ka bag-ong commit ang makita diin ang code sa aplikasyon ra ang giusab. Unsay mahitabo? Alang sa mga pagbag-o sa code, usa ka patch ang pagabuhaton ug usa ka bag-ong imahe sa entablado ang maandam. Ang pirma niini madeterminar isip checksum sa daan nga hulagway sa entablado ug sa bag-ong patch. Usa ka bag-ong katapusang imahe ang maporma gikan niini nga imahe. Ang susamang kinaiya mahitabo sa mga kausaban sa ubang mga yugto.

Busa, ang mga hulagway sa entablado usa ka cache nga mahimong tipigan nga giapod-apod, ug ang mga hulagway nga nahimo na gikan niini gi-upload sa Docker Registry.

Paglimpyo sa rehistro

Wala kami maghisgot bahin sa pagtangtang sa mga layer nga nagpabilin nga nagbitay pagkahuman natangtang ang mga tag - kini usa ka sukaranan nga bahin sa Docker Registry mismo. Naghisgot kami bahin sa usa ka kahimtang kung daghang mga tag sa Docker ang natipon ug nahibal-an namon nga dili na namon kinahanglan ang pipila niini, apan nagkuha sila og wanang (ug / o gibayran namon kini).

Unsa ang mga estratehiya sa pagpanglimpyo?

Wala ka nay mahimo ayaw paglimpyo. Usahay mas sayon ang pagbayad og gamay alang sa dugang nga luna kay sa paghubad sa usa ka dako nga tangle sa mga tag. Apan kini molihok lamang hangtod sa usa ka punto.
Bug-os nga pag-reset. Kung imong tangtangon ang tanan nga mga imahe ug tukuron pag-usab ang mga karon sa sistema sa CI, mahimo’g motungha ang usa ka problema. Kung ang sudlanan gi-restart sa produksiyon, usa ka bag-ong imahe ang i-load alang niini - usa nga wala pa masulayan ni bisan kinsa. Gipatay niini ang ideya sa dili mausab nga imprastraktura.
Asul-berde. Ang usa ka rehistro nagsugod sa pag-awas - nag-upload kami og mga imahe sa lain. Ang sama nga problema sama sa miaging pamaagi: sa unsa nga punto mahimo nimong malimpyohan ang rehistro nga nagsugod sa pag-awas?
Pinaagi sa oras. Pagtangtang sa tanan nga mga imahe nga mas tigulang sa 1 ka bulan? Apan adunay usa ka serbisyo nga wala ma-update sulod sa usa ka bulan ...
Sa matag usa tinoa kung unsa ang mahimo nang matanggal.

Adunay duha ka tinuod nga mahimo nga kapilian: ayaw paglimpyo o usa ka kombinasyon sa asul-berde + nga mano-mano. Sa ulahi nga kaso, naghisgot kami bahin sa mga musunud: kung nasabtan nimo nga panahon na aron limpyohan ang rehistro, maghimo ka usa ka bag-o ug idugang ang tanan nga bag-ong mga imahe sa kini sa dagan sa, pananglitan, usa ka bulan. Ug pagkahuman sa usa ka bulan, tan-awa kung unsang mga pod sa Kubernetes ang naggamit gihapon sa daan nga rehistro, ug ibalhin usab kini sa bag-ong rehistro.

Unsa ang atong naabot werf? Gikolekta namo:

Git ulo: tanan nga mga tag, tanan nga mga sanga - sa paghunahuna nga kinahanglan naton ang tanan nga gi-tag sa Git sa mga imahe (ug kung dili, kinahanglan naton nga papason kini sa Git mismo);
tanang pods nga kasamtangang gibomba sa Kubernetes;
daan nga ReplicaSets (unsay bag-o lang gipagawas), ug nagplano usab kami nga i-scan ang mga gipagawas nga Helm ug pilion ang labing bag-ong mga imahe didto.

... ug paghimo og whitelist gikan niini nga set - usa ka lista sa mga hulagway nga dili namo papason. Gilimpyohan namo ang tanan, pagkahuman nakit-an namon ang mga imahe sa entablado sa ilo ug gitangtang usab kini.

I-deploy nga yugto

Masaligan nga pagdeklara

Ang unang punto nga gusto nakong hatagan ug pagtagad sa pag-deploy mao ang paglusad sa updated nga resource configuration, nga gideklarar nga deklaratibo. Ang orihinal nga dokumento sa YAML nga naghulagway sa mga kapanguhaan sa Kubernetes kanunay nga lahi kaayo sa resulta nga aktwal nga nagdagan sa cluster. Tungod kay ang Kubernetes midugang sa configuration:

mga identifier;
impormasyon sa serbisyo;
daghang mga default nga kantidad;
seksyon nga adunay kasamtangan nga kahimtang;
mga pagbag-o nga gihimo isip bahin sa admission webhook;
ang resulta sa trabaho sa nagkalain-laing controllers (ug ang scheduler).

Busa, sa diha nga ang usa ka bag-ong resource configuration makita (bag-o nga), dili lang nato makuha ug i-overwrite ang kasamtangan, "live" nga configuration niini (mabuhi). Aron mahimo kini kinahanglan naton itandi bag-o nga uban sa katapusang gipadapat nga configuration (katapusang gi-apply) ug roll ngadto mabuhi nakadawat patch.

Kini nga pamaagi gitawag 2-way nga paghiusa. Gigamit kini, pananglitan, sa Helm.

Adunay usab 3-way nga paghiusa, nga lahi niana:

pagtandi katapusang gi-apply и bag-o nga, atong tan-awon kung unsa ang natangtang;
pagtandi bag-o nga и mabuhi, atong tan-awon kon unsay gidugang o giusab;
ang summed patch gipadapat sa mabuhi.

Nag-deploy kami og 1000+ ka aplikasyon gamit ang Helm, mao nga nagkinabuhi gyud mi sa 2-way merge. Bisan pa, kini adunay daghang mga problema nga among nasulbad sa among mga patch, nga makatabang sa Helm nga molihok nga normal.

Tinuod nga kahimtang sa rollout

Human makamugna ang among CI system og bag-ong configuration para sa Kubernetes base sa sunod nga panghitabo, ipasa kini aron magamit (aplay) sa usa ka cluster - gamit ang Helm o kubectl apply. Sunod, mahitabo ang gihulagway na nga N-way merge, diin ang Kubernetes API motubag nga aprobahan sa CI system, ug kana sa tiggamit niini.

Bisan pa, adunay usa ka dako nga problema: pagkahuman sa tanan malampuson nga aplikasyon wala magpasabot nga malampuson nga rollout. Kung nasabtan sa Kubernetes kung unsa nga mga pagbag-o ang kinahanglan i-apply ug ipadapat kini, wala gihapon kami kahibalo kung unsa ang sangputanan. Pananglitan, ang pag-update ug pag-restart sa mga pod sa frontend mahimong magmalampuson, apan dili sa backend, ug makakuha kami og lain-laing mga bersyon sa nagdagan nga mga hulagway sa aplikasyon.

Aron mahimo ang tanan nga husto, kini nga laraw nanginahanglan usa ka dugang nga link - usa ka espesyal nga tracker nga makadawat sa impormasyon sa status gikan sa Kubernetes API ug ipadala kini alang sa dugang nga pagtuki sa tinuod nga kahimtang sa mga butang. Naghimo kami og Open Source library sa Go - cubedog (tan-awa ang pahibalo niini dinhi), nga nagsulbad niini nga problema ug gitukod sa werf.

Ang pamatasan sa kini nga tracker sa lebel sa werf gi-configure gamit ang mga anotasyon nga gibutang sa Mga Deployment o StatefulSets. Panguna nga anotasyon - fail-mode - nakasabot sa mosunod nga mga kahulogan:

IgnoreAndContinueDeployProcess — wala namo gibalewala ang mga problema sa pagpalupad niini nga component ug ipadayon ang deployment;
FailWholeDeployProcessImmediately — usa ka sayup sa kini nga sangkap nagpahunong sa proseso sa pag-deploy;
HopeUntilEndOfDeployProcess — nanghinaut kami nga kini nga sangkap molihok sa katapusan sa pag-deploy.

Pananglitan, kini nga kombinasyon sa mga kapanguhaan ug mga kantidad sa anotasyon fail-mode:

Kung nag-deploy kami sa unang higayon, ang database (MongoDB) mahimong dili pa andam - Mapakyas ang mga deployment. Apan makahulat ka sa higayon nga kini magsugod, ug ang pag-deploy mahitabo gihapon.

Adunay duha pa ka anotasyon alang sa kubedog sa werf:

failures-allowed-per-replica - ang gidaghanon sa gitugotan nga pagkahulog alang sa matag kopya;
show-logs-until - nag-regulate sa higayon hangtod nga gipakita sa werf (sa stdout) ang mga log gikan sa tanan nga gilukot nga mga pod. Ang default mao ang PodIsReady (aron ibaliwala ang mga mensahe nga tingali dili namon gusto kung ang trapiko magsugod sa pag-abut sa pod), apan ang mga kantidad balido usab: ControllerIsReady и EndOfDeploy.

Unsa pa ang atong gusto gikan sa pag-deploy?

Dugang pa sa duha ka punto nga gihulagway na, gusto namo:

aron makita mga troso - ug ang mga kinahanglanon lamang, ug dili ang tanan nga sunud-sunod;
track pag-uswag, tungod kay kung ang trabaho nagbitay "sa hilom" sulod sa pipila ka mga minuto, importante nga masabtan kung unsa ang nahitabo didto;
aron makabaton awtomatik nga rollback kung adunay nahitabo nga sayup (ug busa hinungdanon nga mahibal-an ang tinuud nga kahimtang sa pag-deploy). Ang rollout kinahanglan nga atomic: bisan kini moagi sa katapusan, o ang tanan mobalik sa iyang kanhing kahimtang.

Mga resulta

Alang kanamo ingon usa ka kompanya, aron ipatuman ang tanan nga gihulagway nga mga nuances sa lainlaing mga yugto sa paghatud (pagtukod, pagmantala, pag-deploy), igo na ang usa ka sistema sa CI ug utility. werf.

Imbis nga konklusyon:

Uban sa tabang sa werf, nakahimo kami og maayo nga pag-uswag sa pagsulbad sa daghang mga problema alang sa mga inhenyero sa DevOps ug malipay kung ang mas lapad nga komunidad labing menos sulayan kini nga gamit sa aksyon. Mas sayon nga makab-ot ang maayong resulta nga magkauban.

Mga video ug mga slide

Video gikan sa pasundayag (~47 ka minuto):

Presentasyon sa report:

PS

Ang ubang mga taho bahin sa Kubernetes sa among blog:

«Autoscaling ug pagdumala sa kapanguhaan sa Kubernetes» (Dmitry Stolyarov; Abril 27, 2019 sa “Strike”);
«Pagpalapad ug pagpuno sa Kubernetes» (Andrey Polovov; Abril 8, 2019 sa Saint HighLoad++);
«Mga database ug Kubernetes» (Dmitry Stolyarov; Nobyembre 8, 2018 sa HighLoad++);
«Pag-monitor ug Kubernetes» (Dmitry Stolyarov; Mayo 28, 2018 sa RootConf);
«CI/CD Best Practices uban sa Kubernetes ug GitLab» (Dmitry Stolyarov; Nobyembre 7, 2017 sa HighLoad++);
«Ang among kasinatian sa Kubernetes sa gagmay nga mga proyekto» (Dmitry Stolyarov; Hunyo 6, 2017 sa RootConf).

Source: www.habr.com

werf - among himan alang sa CI / CD sa Kubernetes (kinatibuk-ang pagtan-aw ug taho sa video)