werf - ang aming tool para sa CI / CD sa Kubernetes (pangkalahatang-ideya at ulat ng video)

Mayo 27 sa pangunahing bulwagan ng kumperensya ng DevOpsConf 2019, na ginanap bilang bahagi ng pagdiriwang RIT++ 2019, bilang bahagi ng seksyong “Patuloy na Paghahatid,” isang ulat ang ibinigay na “werf - ang aming tool para sa CI/CD sa Kubernetes”. Pinag-uusapan ang mga iyon mga problema at hamon na kinakaharap ng lahat kapag nagde-deploy sa Kubernetes, pati na rin ang tungkol sa mga nuances na maaaring hindi agad na mapapansin. Sinusuri ang mga posibleng solusyon, ipinapakita namin kung paano ito ipinapatupad sa isang tool na Open Source werf.

Mula noong pagtatanghal, ang aming utility (dating kilala bilang isang dapp) ay umabot sa isang makasaysayang milestone ng 1000 bituin sa GitHub — umaasa kami na ang lumalaking komunidad ng mga user nito ay magpapadali sa buhay para sa maraming mga inhinyero ng DevOps.

So, present kami video ng ulat (~47 minuto, higit na nagbibigay-kaalaman kaysa sa artikulo) at ang pangunahing katas mula dito sa anyo ng teksto. Go!

Naghahatid ng code sa Kubernetes

Ang usapan ay hindi na tungkol sa werf, ngunit tungkol sa CI/CD sa Kubernetes, na nagpapahiwatig na ang aming software ay naka-package sa mga container ng Docker (Napag-usapan ko ito sa 2016 ulat), at ang mga K8 ay gagamitin upang patakbuhin ito sa produksyon (higit pa tungkol dito sa 2017 taon).

Ano ang hitsura ng paghahatid sa Kubernetes?

• Mayroong isang Git repository na may code at mga tagubilin para sa pagbuo nito. Ang application ay binuo sa isang imahe ng Docker at na-publish sa Docker Registry.
• Naglalaman din ang parehong repository ng mga tagubilin kung paano i-deploy at patakbuhin ang application. Sa yugto ng deployment, ipinapadala ang mga tagubiling ito sa Kubernetes, na tumatanggap ng gustong larawan mula sa registry at naglulunsad nito.
• Dagdag pa, karaniwang may mga pagsubok. Ang ilan sa mga ito ay maaaring gawin kapag nag-publish ng isang larawan. Maaari ka ring (pagsunod sa parehong mga tagubilin) ​​mag-deploy ng kopya ng application (sa isang hiwalay na namespace ng K8 o isang hiwalay na cluster) at magpatakbo ng mga pagsubok doon.
• Panghuli, kailangan mo ng CI system na tumatanggap ng mga kaganapan mula sa Git (o mga pag-click sa button) at tumatawag sa lahat ng mga itinalagang yugto: bumuo, mag-publish, mag-deploy, sumubok.

Mayroong ilang mahahalagang tala dito:

1. Dahil mayroon tayong hindi nababagong imprastraktura (hindi nababagong imprastraktura), ang larawan ng application na ginagamit sa lahat ng mga yugto (staging, produksyon, atbp.), dapat meron. Pinag-usapan ko ito nang mas detalyado at may mga halimbawa. dito.
2. Dahil sinusunod namin ang imprastraktura bilang diskarte sa code (IaC), ang application code, mga tagubilin para sa pag-assemble at paglulunsad nito ay dapat eksakto sa isang imbakan. Para sa karagdagang impormasyon tungkol dito, tingnan ang parehong ulat.
3. Delivery chain (delivery) karaniwan naming nakikita ito tulad nito: ang application ay binuo, sinubukan, inilabas (yugto ng paglabas) at iyon lang - naganap na ang paghahatid. Ngunit sa katotohanan, nakukuha ng user ang iyong inilunsad, hindi tapos nung pinadeliver mo sa production, at nung nakapunta na siya dun at gumana itong production. Kaya naniniwala akong matatapos na ang delivery chain lamang sa yugto ng pagpapatakbo (tumakbo), o mas tiyak, kahit na sa sandaling inalis ang code mula sa produksyon (pinapalitan ito ng bago).

Bumalik tayo sa scheme ng paghahatid sa itaas sa Kubernetes: naimbento ito hindi lamang sa amin, ngunit sa literal ng lahat na humarap sa problemang ito. Sa katunayan, ang pattern na ito ay tinatawag na ngayong GitOps (maaari kang magbasa nang higit pa tungkol sa termino at mga ideya sa likod nito dito). Tingnan natin ang mga yugto ng scheme.

Bumuo ng entablado

Mukhang maaari kang makipag-usap tungkol sa pagbuo ng mga imahe ng Docker sa 2019, kapag alam ng lahat kung paano magsulat ng Dockerfiles at tumakbo docker build?.. Narito ang mga nuances na gusto kong bigyang pansin:

1. Timbang ng larawan mahalaga, kaya gamitin multi-entabladona iwanan lamang sa larawan ang application na talagang kinakailangan para sa operasyon.
2. Bilang ng mga layer dapat mabawasan sa pamamagitan ng pagsasama-sama ng mga kadena ng RUN-mga utos ayon sa kahulugan.
3. Gayunpaman, nagdaragdag ito ng mga problema pag-debug, dahil kapag nag-crash ang assembly, kailangan mong hanapin ang tamang command mula sa chain na naging sanhi ng problema.
4. Bilis ng pagpupulong mahalaga dahil gusto naming mabilis na ilunsad ang mga pagbabago at makita ang mga resulta. Halimbawa, hindi mo gustong buuin muli ang mga dependency sa mga library ng wika sa tuwing gagawa ka ng application.
5. Kadalasan mula sa isang Git repository na kailangan mo maraming larawan, na maaaring lutasin sa pamamagitan ng isang set ng Dockerfiles (o pinangalanang mga yugto sa isang file) at isang Bash script kasama ang kanilang sequential assembly.

Ito lamang ang dulo ng malaking bato ng yelo na kinakaharap ng lahat. Ngunit may iba pang mga problema, lalo na:

1. Kadalasan sa yugto ng pagpupulong kailangan namin ng isang bagay bundok (halimbawa, i-cache ang resulta ng isang command tulad ng apt sa isang third-party na direktoryo).
2. Gusto namin Ansible sa halip na isulat sa shell.
3. Gusto namin bumuo nang walang Docker (bakit kailangan natin ng karagdagang virtual machine kung saan kailangan nating i-configure ang lahat para dito, kung mayroon na tayong Kubernetes cluster kung saan maaari tayong magpatakbo ng mga container?).
4. Parallel na pagpupulong, na mauunawaan sa iba't ibang paraan: iba't ibang mga utos mula sa Dockerfile (kung multi-stage ang ginagamit), maraming commit ng parehong repository, maraming Dockerfiles.
5. Ibinahagi ang pagpupulong: Gusto naming mangolekta ng mga bagay sa mga pod na "ephemeral" dahil nawawala ang kanilang cache, na nangangahulugang kailangan itong maiimbak sa isang lugar nang hiwalay.
6. Sa wakas, pinangalanan ko ang tugatog ng mga pagnanasa automatic: Mainam na pumunta sa repositoryo, mag-type ng ilang utos at kumuha ng yari na imahe, na binuo nang may pag-unawa sa kung paano at kung ano ang gagawin nang tama. Gayunpaman, ako mismo ay hindi sigurado na ang lahat ng mga nuances ay maaaring makita sa ganitong paraan.

At narito ang mga proyekto:

• moby/buildkit — isang tagabuo mula sa Docker Inc (naisama na sa kasalukuyang mga bersyon ng Docker), na sinusubukang lutasin ang lahat ng mga problemang ito;
• kaniko — isang tagabuo mula sa Google na nagbibigay-daan sa iyong bumuo nang walang Docker;
• Buildpacks.io — Ang pagtatangka ng CNCF na gumawa ng awtomatikong magic at, sa partikular, isang kawili-wiling solusyon na may rebase para sa mga layer;
• at isang grupo ng iba pang mga utility, tulad ng buildah, genuinetools/img...

...at tingnan kung gaano karaming mga bituin ang mayroon sila sa GitHub. Ibig sabihin, sa isang banda, docker build umiiral at maaaring gawin ang isang bagay, ngunit sa katotohanan ang isyu ay hindi ganap na nalutas - ang patunay nito ay ang magkatulad na pag-unlad ng mga alternatibong kolektor, na ang bawat isa ay nalulutas ang ilang bahagi ng mga problema.

Assembly sa werf

Kaya nakuha namin werf (mas maaga sikat parang dapp) — Isang open source na utility mula sa kumpanya ng Flant, na ginagawa namin sa loob ng maraming taon. Nagsimula ang lahat 5 taon na ang nakalilipas sa mga script ng Bash na nag-optimize sa pagpupulong ng Dockerfiles, at sa huling 3 taon ang ganap na pag-unlad ay isinagawa sa loob ng balangkas ng isang proyekto na may sariling Git repository. (una sa Ruby, at pagkatapos muling isinulat to Go, at sabay na pinalitan ng pangalan). Anong mga isyu sa pagpupulong ang nalutas sa werf?

Naipatupad na ang mga problemang may kulay na asul, ang parallel build ay ginawa sa loob ng parehong host, at ang mga isyung naka-highlight sa dilaw ay binalak na makumpleto sa pagtatapos ng tag-araw.

Yugto ng publikasyon sa pagpapatala (publish)

Nag-dial kami docker push... - ano ang maaaring maging mahirap sa pag-upload ng imahe sa registry? At pagkatapos ay lumitaw ang tanong: "Anong tag ang dapat kong ilagay sa larawan?" Ito ay bumangon sa kadahilanang mayroon tayo Gitflow (o iba pang diskarte sa Git) at Kubernetes, at sinusubukan ng industriya na tiyakin na ang nangyayari sa Kubernetes ay sumusunod sa kung ano ang nangyayari sa Git. Pagkatapos ng lahat, ang Git lamang ang aming pinagmumulan ng katotohanan.

Ano ang mahirap dito? Tiyakin ang reproducibility: mula sa isang commit sa Git, na hindi nababago sa kalikasan (hindi nababago), sa isang imahe ng Docker, na dapat panatilihing pareho.

Mahalaga rin ito sa atin tukuyin ang pinanggalingan, dahil gusto naming maunawaan kung saan ginawa ang application na tumatakbo sa Kubernetes (pagkatapos ay maaari kaming gumawa ng mga diff at mga katulad na bagay).

Mga Istratehiya sa Pag-tag

Ang una ay simple git tag. Mayroon kaming registry na may larawang naka-tag bilang 1.0. May stage at production ang Kubernetes, kung saan ina-upload ang larawang ito. Sa Git gumawa kami ng mga commit at sa isang punto ay nag-tag kami 2.0. Kinokolekta namin ito ayon sa mga tagubilin mula sa repository at inilalagay ito sa registry na may tag 2.0. Inilunsad namin ito sa entablado at, kung maayos ang lahat, pagkatapos ay sa produksyon.

Ang problema sa diskarteng ito ay inilagay muna namin ang tag, at pagkatapos ay sinubukan at inilunsad ito. Bakit? Una, ito ay hindi makatwiran: naglalabas kami ng isang bersyon ng software na hindi pa namin nasusuri (hindi namin magagawa kung hindi man, dahil para masuri, kailangan naming maglagay ng tag). Pangalawa, ang landas na ito ay hindi tugma sa Gitflow.

Ang ikalawang opsyon - git commit + tag. May tag ang master branch 1.0; para dito sa registry - isang imahe na na-deploy sa produksyon. Bilang karagdagan, ang Kubernetes cluster ay may preview at staging contours. Susunod na sinusundan namin ang Gitflow: sa pangunahing sangay para sa pag-unlad (develop) gumawa kami ng mga bagong feature, na nagreresulta sa isang commit sa identifier #c1. Kinokolekta namin ito at ini-publish sa registry gamit ang identifier na ito (#c1). Gamit ang parehong identifier inilunsad namin upang i-preview. Ganoon din ang ginagawa namin sa mga commit #c2 и #c3.

Kapag napagtanto namin na may sapat na mga tampok, sinimulan naming patatagin ang lahat. Lumikha ng isang sangay sa Git release_1.1 (sa base #c3 ng develop). Hindi na kailangang kolektahin ang release na ito, dahil... ito ay ginawa sa nakaraang hakbang. Samakatuwid, maaari lamang nating ilunsad ito sa pagtatanghal. Inaayos namin ang mga bug #c4 at katulad na ilunsad sa pagtatanghal ng dula. Kasabay nito, ang pag-unlad ay isinasagawa develop, kung saan pana-panahong kinukuha ang mga pagbabago release_1.1. Sa ilang mga punto, nakakakuha kami ng isang commit na naipon at na-upload sa pagtatanghal, na kung saan kami ay masaya (#c25).

Pagkatapos ay pinagsama namin (na may fast-forward) ang release branch (release_1.1) sa master. Naglagay kami ng tag na may bagong bersyon sa commit na ito (1.1). Ngunit ang larawang ito ay nakolekta na sa registry, kaya upang hindi na ito makolekta muli, nagdagdag lang kami ng pangalawang tag sa umiiral na larawan (ngayon ay mayroon na itong mga tag sa registry. #c25 и 1.1). Pagkatapos nito, inilunsad namin ito sa produksyon.

May isang disbentaha na isang larawan lamang ang na-upload sa pagtatanghal ng dula (#c25), at sa produksyon ito ay medyo naiiba (1.1), ngunit alam namin na "pisikal" ang mga ito ay ang parehong imahe mula sa registry.

Ang talagang disadvantage ay walang suporta para sa merge commits, kailangan mong gawin ang fast-forward.

Maaari tayong magpatuloy at gumawa ng isang trick... Tingnan natin ang isang halimbawa ng isang simpleng 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

Bumuo tayo ng isang file mula dito ayon sa sumusunod na prinsipyo:

• SHA256 mula sa mga identifier ng mga larawang ginamit (ruby:2.3 и nginx:alpine), na mga checksum ng kanilang mga nilalaman;
• lahat ng koponan (RUN, CMD at iba pa.);
• SHA256 mula sa mga file na idinagdag.

... at kunin ang checksum (muli SHA256) mula sa naturang file. Ito pirma lahat ng bagay na tumutukoy sa mga nilalaman ng imahe ng Docker.

Bumalik tayo sa diagram at sa halip na mag-commit ay gagamit tayo ng mga ganoong lagda, ibig sabihin. i-tag ang mga larawang may mga lagda.

Ngayon, kapag kinakailangan, halimbawa, upang pagsamahin ang mga pagbabago mula sa isang release sa master, maaari tayong gumawa ng isang tunay na merge commit: magkakaroon ito ng ibang identifier, ngunit ang parehong lagda. Gamit ang parehong identifier, ilalabas namin ang imahe sa produksyon.

Ang kawalan ay na ngayon ay hindi posible na matukoy kung anong uri ng pangako ang itinulak sa produksyon - gumagana lamang ang mga checksum sa isang direksyon. Ang problemang ito ay nalutas sa pamamagitan ng isang karagdagang layer na may metadata - sasabihin ko sa iyo ang higit pa sa ibang pagkakataon.

Pag-tag sa werf

Sa werf, lumayo pa kami at naghahanda na gumawa ng distributed build na may cache na hindi nakaimbak sa isang makina... Kaya, gumagawa kami ng dalawang uri ng mga imahe ng Docker, tinatawag namin sila yugto и larawan.

Ang werf Git repository ay nag-iimbak ng mga tagubiling tukoy sa build na naglalarawan sa iba't ibang yugto ng build (bago Mag-install, install, bago ang Setup, setup). Kinokolekta namin ang unang yugto ng imahe na may pirma na tinukoy bilang ang checksum ng mga unang hakbang. Pagkatapos ay idinagdag namin ang source code, para sa bagong yugto ng imahe kinakalkula namin ang checksum nito... Ang mga operasyong ito ay paulit-ulit para sa lahat ng mga yugto, bilang isang resulta kung saan nakakakuha kami ng isang hanay ng mga larawan sa entablado. Pagkatapos ay gagawin namin ang panghuling larawan, na naglalaman din ng metadata tungkol sa pinagmulan nito. At itina-tag namin ang larawang ito sa iba't ibang paraan (mga detalye sa ibang pagkakataon).

Ipagpalagay na pagkatapos nito ay may lalabas na bagong commit kung saan ang application code lang ang nabago. Ano ang mangyayari? Para sa mga pagbabago sa code, gagawa ng patch at maghahanda ng bagong stage image. Ang pirma nito ay tutukuyin bilang checksum ng lumang stage image at ang bagong patch. Isang bagong huling larawan ang bubuo mula sa larawang ito. Ang katulad na pag-uugali ay magaganap sa mga pagbabago sa iba pang mga yugto.

Kaya, ang mga larawan sa entablado ay isang cache na maaaring maiimbak nang distributed, at ang mga larawang nalikha na mula rito ay ina-upload sa Docker Registry.

Nililinis ang pagpapatala

Hindi namin pinag-uusapan ang pagtanggal ng mga layer na nanatiling nakabitin pagkatapos ng mga tinanggal na tag - ito ay isang karaniwang tampok ng Docker Registry mismo. Pinag-uusapan natin ang isang sitwasyon kung saan maraming mga tag ng Docker ang naipon at naiintindihan namin na hindi na namin kailangan ang ilan sa mga ito, ngunit kumukuha sila ng espasyo (at/o binabayaran namin ito).

Ano ang mga diskarte sa paglilinis?

1. Wala ka lang magagawa huwag maglinis. Minsan mas madaling magbayad ng kaunti para sa dagdag na espasyo kaysa mag-alis ng malaking gusot ng mga tag. Ngunit ito ay gumagana lamang hanggang sa isang tiyak na punto.
2. Buong pag-reset. Kung tatanggalin mo ang lahat ng mga imahe at muling itayo ang mga kasalukuyang nasa CI system, maaaring magkaroon ng problema. Kung ang lalagyan ay na-restart sa produksyon, isang bagong larawan ang ilo-load para dito - isa na hindi pa nasusuri ng sinuman. Pinapatay nito ang ideya ng hindi nababagong imprastraktura.
3. Asul-berde. Nagsimulang umapaw ang isang registry - nag-upload kami ng mga larawan sa isa pa. Ang parehong problema tulad ng sa nakaraang pamamaraan: sa anong punto maaari mong i-clear ang pagpapatala na nagsimulang umapaw?
4. Sa oras. Tanggalin ang lahat ng mga larawang mas matanda sa 1 buwan? Ngunit tiyak na magkakaroon ng serbisyo na hindi na-update sa loob ng isang buwan...
5. Mano-mano tukuyin kung ano ang maaari nang tanggalin.

Mayroong dalawang tunay na mabubuhay na opsyon: huwag maglinis o isang kumbinasyon ng asul-berde + nang manu-mano. Sa huling kaso, pinag-uusapan natin ang mga sumusunod: kapag naunawaan mo na oras na upang linisin ang pagpapatala, lumikha ka ng bago at idagdag ang lahat ng mga bagong larawan dito sa loob ng, halimbawa, isang buwan. At pagkatapos ng isang buwan, tingnan kung aling mga pod sa Kubernetes ang gumagamit pa rin ng lumang registry, at ilipat din ang mga ito sa bagong registry.

Ano ang narating natin werf? Kinokolekta namin:

1. Git head: lahat ng tag, lahat ng branch - sa pag-aakalang kailangan natin ang lahat ng naka-tag sa Git sa mga imahe (at kung hindi, kailangan nating tanggalin ito sa Git mismo);
2. lahat ng mga pod na kasalukuyang ipino-pump out sa Kubernetes;
3. lumang ReplicaSets (kung ano ang kamakailang inilabas), at plano rin naming i-scan ang mga release ng Helm at piliin ang mga pinakabagong larawan doon.

... at gumawa ng whitelist mula sa set na ito - isang listahan ng mga larawan na hindi namin tatanggalin. Nililinis namin ang lahat ng iba pa, pagkatapos ay nahanap namin ang mga imahe ng orphan stage at tinanggal din ang mga ito.

I-deploy ang yugto

Maaasahang pagpapahayag

Ang unang punto na gusto kong bigyang pansin sa deployment ay ang paglulunsad ng na-update na pagsasaayos ng mapagkukunan, na ipinahayag nang deklaratibo. Ang orihinal na dokumento ng YAML na naglalarawan sa mga mapagkukunan ng Kubernetes ay palaging ibang-iba sa resulta na aktwal na tumatakbo sa cluster. Dahil nagdaragdag ang Kubernetes sa configuration:

1. mga identifier;
2. impormasyon ng serbisyo;
3. maraming mga default na halaga;
4. seksyon na may kasalukuyang katayuan;
5. mga pagbabagong ginawa bilang bahagi ng admission webhook;
6. ang resulta ng gawain ng iba't ibang mga controllers (at ang scheduler).

Samakatuwid, kapag lumitaw ang isang bagong pagsasaayos ng mapagkukunan (bago), hindi lang natin maaaring kunin at i-overwrite ang kasalukuyang, "live" na configuration dito (mabuhay). Upang gawin ito, kailangan nating ihambing bago gamit ang huling inilapat na pagsasaayos (huling inilapat) at gumulong sa mabuhay nakatanggap ng patch.

Ang pamamaraang ito ay tinatawag na 2-way na pagsasama. Ito ay ginagamit, halimbawa, sa Helm.

meron din 3-way na pagsasama, na naiiba sa:

• paghahambing huling inilapat и bago, tinitingnan namin kung ano ang tinanggal;
• paghahambing bago и mabuhay, tinitingnan namin kung ano ang idinagdag o binago;
• ang summed patch ay inilapat sa mabuhay.

Nag-deploy kami ng 1000+ application gamit ang Helm, kaya talagang nabubuhay kami sa 2-way merge. Gayunpaman, mayroon itong ilang mga problema na nalutas namin sa aming mga patch, na tumutulong sa Helm na gumana nang normal.

Real rollout status

Pagkatapos makabuo ng bagong configuration ang aming CI system para sa Kubernetes batay sa susunod na kaganapan, ipinapadala nito ito para magamit (mag-apply) sa isang cluster - gamit ang Helm o kubectl apply. Susunod, nangyayari ang inilarawan nang N-way merge, kung saan ang Kubernetes API ay tumutugon nang may pag-apruba sa CI system, at iyon sa user nito.

Gayunpaman, mayroong isang malaking problema: pagkatapos ng lahat ang matagumpay na aplikasyon ay hindi nangangahulugan ng matagumpay na paglulunsad. Kung nauunawaan ng Kubernetes kung anong mga pagbabago ang kailangang ilapat at ilalapat ito, hindi pa rin namin alam kung ano ang magiging resulta. Halimbawa, ang pag-update at pag-restart ng mga pod sa frontend ay maaaring maging matagumpay, ngunit hindi sa backend, at makakakuha kami ng iba't ibang bersyon ng tumatakbong mga larawan ng application.

Upang magawa nang tama ang lahat, ang scheme na ito ay nangangailangan ng karagdagang link - isang espesyal na tracker na tatanggap ng impormasyon ng katayuan mula sa Kubernetes API at ipapadala ito para sa karagdagang pagsusuri ng tunay na estado ng mga bagay. Gumawa kami ng Open Source library sa Go - cubedog (tingnan ang anunsyo nito dito), na lumulutas sa problemang ito at binuo sa werf.

Ang pag-uugali ng tracker na ito sa antas ng werf ay na-configure gamit ang mga anotasyon na inilalagay sa Mga Deployment o StatefulSets. Pangunahing anotasyon - fail-mode - nauunawaan ang mga sumusunod na kahulugan:

• IgnoreAndContinueDeployProcess — binabalewala namin ang mga problema sa paglulunsad ng bahaging ito at ipagpatuloy ang pag-deploy;
• FailWholeDeployProcessImmediately — ang isang error sa bahaging ito ay huminto sa proseso ng pag-deploy;
• HopeUntilEndOfDeployProcess — umaasa kaming gagana ang bahaging ito sa pagtatapos ng deployment.

Halimbawa, ang kumbinasyong ito ng mga mapagkukunan at mga halaga ng anotasyon fail-mode:

Kapag nag-deploy kami sa unang pagkakataon, maaaring hindi pa handa ang database (MongoDB) - Mabibigo ang mga deployment. Ngunit maaari mong hintayin ang sandali para magsimula ito, at magaganap pa rin ang deployment.

May dalawa pang anotasyon para sa kubedog sa werf:

• failures-allowed-per-replica — ang bilang ng mga pinapayagang pagbagsak para sa bawat replika;
• show-logs-until — kinokontrol ang sandali hanggang sa kung saan ipinapakita ng werf (sa stdout) ang mga log mula sa lahat ng inilunsad na pod. Ang default ay PodIsReady (upang huwag pansinin ang mga mensahe na malamang na hindi namin gusto kapag nagsimula ang trapiko sa pod), ngunit ang mga halaga ay may bisa din: ControllerIsReady и EndOfDeploy.

Ano pa ang gusto natin mula sa pag-deploy?

Bilang karagdagan sa dalawang puntos na inilarawan na, nais naming:

• upang makita mga log - at ang mga kinakailangan lamang, at hindi lahat ng magkakasunod;
• subaybayan pag-unlad, dahil kung ang trabaho ay nakabitin nang "tahimik" ng ilang minuto, mahalagang maunawaan kung ano ang nangyayari doon;
• иметь awtomatikong rollback kung sakaling may nagkamali (at samakatuwid ay kritikal na malaman ang tunay na katayuan ng deployment). Ang paglulunsad ay dapat na atomic: ito ay magpapatuloy hanggang sa wakas, o lahat ay bumalik sa dati nitong estado.

Mga resulta ng

Para sa amin bilang isang kumpanya, upang ipatupad ang lahat ng inilarawan na mga nuances sa iba't ibang yugto ng paghahatid (bumuo, mag-publish, mag-deploy), sapat na ang isang CI system at utility. werf.

Sa halip na isang konklusyon:

Sa tulong ng werf, gumawa kami ng mahusay na pag-unlad sa paglutas ng malaking bilang ng mga problema para sa mga inhinyero ng DevOps at matutuwa kung sinubukan man lang ng mas malawak na komunidad ang utility na ito sa pagkilos. Magiging mas madaling makamit ang isang magandang resulta nang magkasama.

Mga video at slide

Video mula sa pagganap (~47 minuto):

Presentasyon ng ulat:

PS

Iba pang mga ulat tungkol sa Kubernetes sa aming blog:

• «Autoscaling at pamamahala ng mapagkukunan sa Kubernetes» (Dmitry Stolyarov; Abril 27, 2019 sa “Strike”);
• «Pagpapalawak at pagpupuno sa Kubernetes» (Andrey Polovov; Abril 8, 2019 sa Saint HighLoad++);
• «Mga Database at Kubernetes» (Dmitry Stolyarov; Nobyembre 8, 2018 sa HighLoad++);
• «Pagsubaybay at Kubernetes» (Dmitry Stolyarov; Mayo 28, 2018 sa RootConf);
• «Pinakamahuhusay na Kasanayan sa CI/CD kasama ang Kubernetes at GitLab» (Dmitry Stolyarov; Nobyembre 7, 2017 sa HighLoad++);
• «Ang aming karanasan sa Kubernetes sa maliliit na proyekto» (Dmitry Stolyarov; Hunyo 6, 2017 sa RootConf).

Pinagmulan: www.habr.com