werf - zana yetu ya CI/CD katika Kubernetes (hakiki na ripoti ya video)

Mei 27 katika ukumbi kuu wa mkutano wa DevOpsConf 2019, uliofanyika kama sehemu ya tamasha RIT++ 2019, kama sehemu ya sehemu ya "Utoaji Unaoendelea", ripoti ilitolewa "werf - zana yetu ya CI/CD katika Kubernetes". Inazungumza juu ya hizo matatizo na changamoto ambazo kila mtu hukabiliana nazo wakati wa kupeleka Kubernetes, na pia juu ya nuances ambayo inaweza kutoonekana mara moja. Kuchambua masuluhisho yanayowezekana, tunaonyesha jinsi hii inatekelezwa katika zana ya Open Source werf.

Tangu wasilisho, matumizi yetu (yaliyojulikana awali kama dapp) yamefikia hatua ya kihistoria ya Nyota 1000 kwenye GitHub - tunatumai kuwa jumuiya yake inayokua ya watumiaji itarahisisha maisha kwa wahandisi wengi wa DevOps.

Hivyo, hebu kuanzisha video ya ripoti hiyo (~dakika 47, taarifa zaidi kuliko makala) na dondoo kuu kutoka humo katika fomu ya maandishi. Nenda!

Inatuma nambari ya kuthibitisha kwa Kubernetes

Mazungumzo hayatakuwa tena kuhusu werf, lakini kuhusu CI/CD katika Kubernetes, ikimaanisha kuwa programu yetu imewekwa kwenye vyombo vya Docker. (Nilizungumza juu ya hii katika ripoti ya 2016), na K8s zitatumika kuiendesha katika uzalishaji (zaidi kuhusu hili katika Mwaka wa 2017).

Uwasilishaji unaonekanaje katika Kubernetes?

• Kuna hazina ya Git iliyo na nambari na maagizo ya kuijenga. Programu imejengwa ndani ya picha ya Docker na kuchapishwa kwenye Usajili wa Docker.
• Hifadhi hiyo hiyo pia ina maagizo ya jinsi ya kupeleka na kuendesha programu. Katika hatua ya kupeleka, maagizo haya yanatumwa kwa Kubernetes, ambayo hupokea picha inayotaka kutoka kwa Usajili na kuizindua.
• Kwa kuongeza, kawaida kuna vipimo. Baadhi ya haya yanaweza kufanywa wakati wa kuchapisha picha. Unaweza pia (kufuata maagizo sawa) kupeleka nakala ya programu (katika nafasi tofauti ya majina ya K8s au nguzo tofauti) na kufanya majaribio hapo.
• Hatimaye, unahitaji mfumo wa CI unaopokea matukio kutoka kwa Git (au kubofya kitufe) na kupiga hatua zote zilizoteuliwa: kujenga, kuchapisha, kupeleka, kupima.

Kuna vidokezo vichache muhimu hapa:

1. Kwa sababu tuna miundombinu isiyobadilika (miundombinu isiyobadilika), picha ya programu ambayo inatumika katika hatua zote (hatua, uzalishaji, n.k.), lazima kuwe na mmoja. Nilizungumza juu ya hili kwa undani zaidi na kwa mifano. hapa.
2. Kwa sababu tunafuata miundombinu kama mbinu ya kanuni (IaC), msimbo wa maombi, maagizo ya kukusanyika na kuzindua inapaswa kuwa haswa katika hazina moja. Kwa habari zaidi kuhusu hili, ona ripoti hiyo hiyo.
3. Mlolongo wa utoaji (uwasilishaji) kwa kawaida tunaiona kama hii: maombi yalikusanywa, kujaribiwa, kutolewa (hatua ya kutolewa) na ndivyo ilivyo - utoaji umefanyika. Lakini kwa ukweli, mtumiaji anapata kile ulichotoa, hakuna basi ulipoifikisha kwenye uzalishaji, na alipoweza kwenda huko na uzalishaji huu ukafanya kazi. Kwa hivyo naamini mlolongo wa utoaji unaisha tu katika hatua ya uendeshaji (kimbia), au kwa usahihi zaidi, hata wakati msimbo uliondolewa kutoka kwa uzalishaji (kuibadilisha na mpya).

Wacha turudi kwenye mpango wa uwasilishaji hapo juu huko Kubernetes: haukugunduliwa na sisi tu, bali na kila mtu ambaye alishughulikia shida hii. Kwa kweli, muundo huu sasa unaitwa GitOps (unaweza kusoma zaidi kuhusu neno na mawazo nyuma yake hapa). Wacha tuangalie hatua za mpango.

Kujenga hatua

Inaweza kuonekana kuwa unaweza kuzungumza juu ya kujenga picha za Docker mnamo 2019, wakati kila mtu anajua jinsi ya kuandika Dockerfiles na kukimbia. docker build?.. Hapa kuna nuances ambayo ningependa kuzingatia:

1. Uzito wa picha mambo, hivyo tumia hatua mbalimbalikuacha katika picha tu programu ambayo ni muhimu kwa uendeshaji.
2. Idadi ya tabaka lazima ipunguzwe kwa kuchanganya minyororo ya RUN-amuru kulingana na maana.
3. Hata hivyo, hii inaongeza matatizo utatuzi, kwa sababu wakati kusanyiko linaanguka, unapaswa kupata amri sahihi kutoka kwa mlolongo uliosababisha tatizo.
4. Kasi ya mkusanyiko muhimu kwa sababu tunataka kuzindua mabadiliko kwa haraka na kuona matokeo. Kwa mfano, hutaki kuunda upya vitegemezi katika maktaba za lugha kila wakati unapounda programu.
5. Mara nyingi kutoka kwa hazina moja ya Git unahitaji picha nyingi, ambayo inaweza kutatuliwa na seti ya Dockerfiles (au hatua zilizopewa jina katika faili moja) na hati ya Bash na mkusanyiko wao wa mfululizo.

Hii ilikuwa ni ncha tu ya barafu ambayo kila mtu anakabiliwa nayo. Lakini kuna shida zingine, haswa:

1. Mara nyingi katika hatua ya kusanyiko tunahitaji kitu mlima (kwa mfano, kache matokeo ya amri kama apt kwenye saraka ya mtu wa tatu).
2. Tunataka Inawezekana badala ya kuandika kwenye ganda.
3. Tunataka jenga bila Docker (kwa nini tunahitaji mashine ya ziada ambayo tunahitaji kusanidi kila kitu kwa hili, wakati tayari tunayo nguzo ya Kubernetes ambayo tunaweza kuendesha vyombo?).
4. Mkutano wa sambamba, ambayo inaweza kueleweka kwa njia tofauti: amri tofauti kutoka kwa Dockerfile (ikiwa hatua nyingi hutumiwa), ahadi kadhaa za hazina moja, Dockerfiles kadhaa.
5. Mkutano uliosambazwa: Tunataka kukusanya vitu katika maganda ambayo ni "ephemeral" kwa sababu cache yao hupotea, ambayo ina maana inahitaji kuhifadhiwa mahali fulani tofauti.
6. Hatimaye, nilitaja kilele cha tamaa kiotomatiki: Itakuwa bora kwenda kwenye hazina, chapa amri fulani na upate picha iliyotengenezwa tayari, iliyokusanywa na ufahamu wa jinsi na nini cha kufanya kwa usahihi. Walakini, mimi binafsi sina uhakika kuwa nuances zote zinaweza kutabiriwa kwa njia hii.

Na hapa kuna miradi:

• moby/buildkit - mjenzi kutoka Docker Inc (tayari imeunganishwa katika matoleo ya sasa ya Docker), ambayo inajaribu kutatua matatizo haya yote;
• kaniko - mjenzi kutoka Google anayekuruhusu kujenga bila Docker;
• Buildpacks.io - Jaribio la CNCF kufanya uchawi wa moja kwa moja na, hasa, ufumbuzi wa kuvutia na rebase kwa tabaka;
• na rundo la huduma zingine, kama vile kujenga, zana za kweli/img...

... na angalia wana nyota ngapi kwenye GitHub. Hiyo ni, kwa upande mmoja, docker build ipo na inaweza kufanya kitu, lakini kwa ukweli suala hilo halijatatuliwa kabisa - uthibitisho wa hili ni maendeleo ya sambamba ya watoza mbadala, ambayo kila mmoja hutatua sehemu fulani ya matatizo.

Mkutano katika werf

Kwa hivyo tulifika werf (hapo awali maarufu kama dapp) - Huduma ya chanzo wazi kutoka kwa kampuni ya Flant, ambayo tumekuwa tukifanya kwa miaka mingi. Yote ilianza miaka 5 iliyopita na maandishi ya Bash ambayo yaliboresha mkusanyiko wa Dockerfiles, na kwa miaka 3 iliyopita maendeleo kamili yamefanywa ndani ya mfumo wa mradi mmoja na hazina yake ya Git. (kwanza katika Ruby, na kisha imeandikwa upya kwenda, na wakati huo huo kubadilishwa jina). Ni maswala gani ya kusanyiko yanatatuliwa katika werf?

Matatizo ya kivuli katika rangi ya bluu tayari yametekelezwa, ujenzi wa sambamba ulifanyika ndani ya mwenyeji mmoja, na masuala yaliyoonyeshwa kwa njano yanapangwa kukamilika mwishoni mwa majira ya joto.

Hatua ya uchapishaji katika sajili (chapisha)

Tulipiga docker push... - nini inaweza kuwa vigumu kuhusu kupakia picha kwenye Usajili? Na kisha swali linatokea: "Niweke lebo gani kwenye picha?" Inatokea kwa sababu tuliyo nayo Mtiririko (au mkakati mwingine wa Git) na Kubernetes, na tasnia inajaribu kuhakikisha kuwa kile kinachotokea Kubernetes kinafuata kile kinachotokea katika Git. Baada ya yote, Git ndio chanzo chetu cha ukweli.

Ni nini kigumu katika hili? Hakikisha unazalisha: kutoka kwa ahadi katika Git, ambayo haiwezi kubadilika kwa asili (isiyobadilika), kwa picha ya Docker, ambayo inapaswa kuwekwa sawa.

Pia ni muhimu kwetu kuamua asili, kwa sababu tunataka kuelewa ni kutoka kwa ahadi gani ambayo programu inayoendesha Kubernetes ilijengwa (basi tunaweza kufanya tofauti na vitu sawa).

Mikakati ya Kuweka Tagi

Ya kwanza ni rahisi git tag. Tuna sajili iliyo na picha iliyotambulishwa kama 1.0. Kubernetes ina jukwaa na uzalishaji, ambapo picha hii imepakiwa. Katika Git tunafanya ahadi na wakati fulani tunaweka lebo 2.0. Tunakusanya kulingana na maagizo kutoka kwa hifadhi na kuiweka kwenye Usajili na lebo 2.0. Tunaipeleka kwa hatua na, ikiwa kila kitu kiko sawa, basi kwa uzalishaji.

Tatizo la mbinu hii ni kwamba sisi kwanza kuweka tag, na kisha tu majaribio na rolled nje. Kwa nini? Kwanza, haina mantiki: tunatoa toleo la programu ambalo hata hatujajaribu (hatuwezi kufanya vinginevyo, kwa sababu ili kuangalia, tunahitaji kuweka lebo). Pili, njia hii haiendani na Gitflow.

Chaguo la pili ni git commit + tag. Tawi kuu lina lebo 1.0; kwa ajili yake katika Usajili - picha iliyotumwa kwa uzalishaji. Kwa kuongezea, nguzo ya Kubernetes ina hakikisho na mtaro wa hatua. Ifuatayo tunafuata Gitflow: katika tawi kuu la maendeleo (develop) tunatengeneza vipengele vipya, na hivyo kusababisha ahadi na kitambulisho #c1. Tunaikusanya na kuichapisha kwenye sajili kwa kutumia kitambulisho hiki (#c1) Kwa kitambulisho sawa tunasambaza ili kuhakiki. Tunafanya vivyo hivyo na ahadi #c2 и #c3.

Tulipogundua kuwa kuna vipengele vya kutosha, tunaanza kuimarisha kila kitu. Unda tawi katika Git release_1.1 (kwenye msingi #c3 ya develop) Hakuna haja ya kukusanya toleo hili, kwa sababu ... hii ilifanyika katika hatua ya awali. Kwa hivyo, tunaweza kuipeleka kwa jukwaa. Tunarekebisha makosa ndani #c4 na vivyo hivyo kwenye jukwaa. Wakati huo huo, maendeleo yanaendelea develop, ambapo mabadiliko huchukuliwa mara kwa mara release_1.1. Wakati fulani, tunapata ahadi iliyokusanywa na kupakiwa kwenye jukwaa, ambayo tunafurahiya (#c25).

Kisha tunaunganisha (na kusonga mbele haraka) tawi la kutolewa (release_1.1) katika bwana. Tunaweka lebo na toleo jipya kwenye ahadi hii (1.1) Lakini picha hii tayari imekusanywa kwenye Usajili, kwa hivyo ili tusiikusanye tena, tunaongeza tu lebo ya pili kwenye picha iliyopo (sasa ina vitambulisho kwenye Usajili. #c25 и 1.1) Baada ya hayo, tunaisambaza kwa uzalishaji.

Kuna shida kwamba picha moja pekee hupakiwa kwenye jukwaa (#c25), na katika uzalishaji ni aina tofauti (1.1), lakini tunajua kwamba "kimwili" hizi ni picha sawa kutoka kwa usajili.

Ubaya wa kweli ni kwamba hakuna msaada wa kuunganisha ahadi, lazima ufanye haraka-mbele.

Tunaweza kwenda mbali zaidi na kufanya hila... Hebu tuangalie mfano wa Dockerfile rahisi:

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

Wacha tujenge faili kutoka kwayo kulingana na kanuni ifuatayo:

• SHA256 kutoka kwa vitambulisho vya picha zilizotumiwa (ruby:2.3 и nginx:alpine), ambazo ni cheki za yaliyomo;
• timu zote (RUN, CMD Nakadhalika.);
• SHA256 kutoka kwa faili ambazo ziliongezwa.

... na uchukue hundi (tena SHA256) kutoka kwa faili kama hiyo. Hii Sahihi kila kitu kinachofafanua yaliyomo kwenye picha ya Docker.

Hebu turudi kwenye mchoro na badala ya ahadi tutatumia sahihi hizo, i.e. tag picha zilizo na saini.

Sasa, inapohitajika, kwa mfano, kuunganisha mabadiliko kutoka kwa toleo hadi bwana, tunaweza kufanya ahadi halisi ya kuunganisha: itakuwa na kitambulisho tofauti, lakini sahihi sawa. Kwa kitambulisho sawa tutasambaza picha kwenye toleo la umma.

Ubaya ni kwamba sasa haitawezekana kuamua ni aina gani ya ahadi iliyosukumwa kwa uzalishaji - ukaguzi hufanya kazi kwa mwelekeo mmoja tu. Tatizo hili linatatuliwa na safu ya ziada iliyo na metadata - nitakuambia zaidi baadaye.

Kuweka alama kwenye werf

Katika werf tulienda mbali zaidi na tunajiandaa kufanya ujenzi uliosambazwa na kashe ambayo haijahifadhiwa kwenye mashine moja ... Kwa hivyo, tunaunda picha za aina mbili za Docker, tunaziita. hatua и picha.

Hifadhi ya werf Git huhifadhi maagizo maalum ambayo yanaelezea hatua tofauti za ujenzi (kabla ya Kusakinisha, kufunga, kabla ya Kuweka, kuanzisha) Tunakusanya picha ya hatua ya kwanza na sahihi iliyofafanuliwa kama hesabu ya hatua za kwanza. Kisha tunaongeza msimbo wa chanzo, kwa picha ya hatua mpya tunahesabu checksum yake ... Shughuli hizi zinarudiwa kwa hatua zote, kwa sababu hiyo tunapata seti ya picha za hatua. Kisha tunafanya picha ya mwisho, ambayo pia ina metadata kuhusu asili yake. Na tunaweka tagi picha hii kwa njia tofauti (maelezo baadaye).

Tuseme baada ya hii ahadi mpya inaonekana ambayo msimbo wa maombi pekee ndio umebadilishwa. Nini kitatokea? Kwa mabadiliko ya msimbo, kiraka kitaundwa na picha mpya ya hatua itatayarishwa. Sahihi yake itabainishwa kama hesabu ya picha ya hatua ya zamani na kiraka kipya. Picha mpya ya mwisho itaundwa kutoka kwa picha hii. Tabia kama hiyo itatokea na mabadiliko katika hatua zingine.

Kwa hivyo, picha za hatua ni cache ambayo inaweza kuhifadhiwa kwa kusambazwa, na picha zilizoundwa tayari kutoka humo zinapakiwa kwenye Usajili wa Docker.

Kusafisha Usajili

Hatuzungumzii juu ya kufuta tabaka ambazo zilibaki kunyongwa baada ya vitambulisho vilivyofutwa - hii ni kipengele cha kawaida cha Usajili wa Docker yenyewe. Tunazungumza juu ya hali wakati vitambulisho vingi vya Docker hujilimbikiza na tunaelewa kuwa hatuhitaji tena baadhi yao, lakini huchukua nafasi (na/au tunalipa).

Je, ni mikakati gani ya kusafisha?

1. Unaweza tu kufanya chochote usisafishe. Wakati mwingine ni rahisi sana kulipa kidogo kwa nafasi ya ziada kuliko kufunua tangle kubwa ya vitambulisho. Lakini hii inafanya kazi tu hadi hatua fulani.
2. Weka upya kamili. Ikiwa utafuta picha zote na kujenga upya sasa tu katika mfumo wa CI, tatizo linaweza kutokea. Ikiwa kontena itaanzishwa upya katika uzalishaji, picha mpya itapakiwa kwa ajili yake - ambayo bado haijajaribiwa na mtu yeyote. Hii inaua wazo la miundombinu isiyobadilika.
3. Bluu-kijani. Usajili mmoja ulianza kufurika - tunapakia picha kwa mwingine. Tatizo sawa na katika njia ya awali: kwa wakati gani unaweza kufuta Usajili ambao umeanza kufurika?
4. Kwa wakati. Ungependa kufuta picha zote ambazo zimehifadhiwa zaidi ya mwezi 1? Lakini bila shaka kutakuwa na huduma ambayo haijasasishwa kwa mwezi...
5. Binafsi kuamua ni nini kinaweza kufutwa.

Kuna chaguzi mbili zinazowezekana: usisafishe au mchanganyiko wa bluu-kijani + kwa mikono. Katika kesi ya mwisho, tunazungumza juu ya yafuatayo: unapoelewa kuwa ni wakati wa kusafisha Usajili, unaunda mpya na kuongeza picha zote mpya ndani yake, kwa mfano, mwezi. Na baada ya mwezi, angalia ni maganda gani katika Kubernetes ambayo bado yanatumia sajili ya zamani, na uhamishe pia kwenye sajili mpya.

Tumefika nini werf? Tunakusanya:

1. Kichwa cha Git: vitambulisho vyote, matawi yote - kwa kudhani kuwa tunahitaji kila kitu ambacho kimewekwa alama kwenye Git kwenye picha (na ikiwa sivyo, basi tunahitaji kuifuta kwenye Git yenyewe);
2. maganda yote ambayo kwa sasa yanasukumwa hadi Kubernetes;
3. old ReplicaSets (kilichotolewa hivi majuzi), na pia tunapanga kuchanganua matoleo ya Helm na kuchagua picha za hivi punde hapo.

... na ufanye orodha iliyoidhinishwa kutoka kwa seti hii - orodha ya picha ambazo hatutazifuta. Tunasafisha kila kitu kingine, kisha tunapata picha za jukwaa la watoto yatima na kuzifuta pia.

Hatua ya kupeleka

Utangazaji wa kuaminika

Hoja ya kwanza ambayo ningependa kuangazia katika uwekaji ni uchapishaji wa usanidi uliosasishwa wa rasilimali, uliotangazwa kwa kutangaza. Hati asili ya YAML inayoelezea rasilimali za Kubernetes daima ni tofauti sana na matokeo yanayoendelea kwenye nguzo. Kwa sababu Kubernetes anaongeza kwenye usanidi:

1. vitambulisho;
2. habari ya huduma;
3. maadili mengi chaguo-msingi;
4. sehemu na hali ya sasa;
5. mabadiliko yaliyofanywa kama sehemu ya webhook ya uandikishaji;
6. matokeo ya kazi ya watawala mbalimbali (na mpangilio).

Kwa hivyo, wakati usanidi mpya wa rasilimali unaonekana (mpya), hatuwezi tu kuchukua na kubatilisha usanidi wa sasa, "live" nayo (kuishi) Ili kufanya hivyo itabidi kulinganisha mpya na usanidi wa mwisho uliotumika (mara ya mwisho kutumika) na uingie kwenye kuishi kupokea kiraka.

Njia hii inaitwa 2-njia kuunganisha. Inatumika, kwa mfano, katika Helm.

Kuna pia 3-njia kuunganisha, ambayo inatofautiana kwa kuwa:

• kulinganisha mara ya mwisho kutumika и mpya, tunaangalia kile kilichofutwa;
• kulinganisha mpya и kuishi, tunaangalia kile ambacho kimeongezwa au kubadilishwa;
• kiraka kilichofupishwa kinatumika kwa kuishi.

Tunapeleka maombi 1000+ na Helm, kwa hivyo tunaishi kwa kuunganisha kwa njia 2. Walakini, ina shida kadhaa ambazo tumetatua na viraka vyetu, ambavyo vinasaidia Helm kufanya kazi kawaida.

Hali halisi ya uchapishaji

Baada ya mfumo wetu wa CI kutengeneza usanidi mpya wa Kubernetes kulingana na tukio linalofuata, huisambaza kwa matumizi. (tuma maombi) kwa nguzo - kwa kutumia Helm au kubectl apply. Ifuatayo, muunganisho ulioelezewa wa N-njia hutokea, ambapo Kubernetes API hujibu kwa kuidhinisha mfumo wa CI, na kwamba kwa mtumiaji wake.

Walakini, kuna shida kubwa: baada ya yote utumaji uliofaulu haumaanishi uchapishaji uliofaulu. Iwapo Kubernetes anaelewa ni mabadiliko gani yanahitajika kutumika na kuyatumia, bado hatujui matokeo yatakuwa nini. Kwa mfano, kusasisha na kuanzisha upya ganda kwenye sehemu ya mbele kunaweza kufanikiwa, lakini si kwa nyuma, na tutapata matoleo tofauti ya picha za programu zinazoendesha.

Ili kufanya kila kitu kwa usahihi, mpango huu unahitaji kiungo cha ziada - tracker maalum ambayo itapokea taarifa ya hali kutoka kwa Kubernetes API na kuisambaza kwa uchambuzi zaidi wa hali halisi ya mambo. Tuliunda maktaba ya Open Source katika Go - mbwa wa mchemraba (tazama tangazo lake hapa), ambayo hutatua tatizo hili na imejengwa ndani ya werf.

Tabia ya kifuatiliaji hiki katika kiwango cha werf imesanidiwa kwa kutumia vidokezo ambavyo vimewekwa kwenye Deployments au StatefulSets. Dokezo kuu - fail-mode - anaelewa maana zifuatazo:

• IgnoreAndContinueDeployProcess - tunapuuza matatizo ya kusambaza sehemu hii na kuendelea kupeleka;
• FailWholeDeployProcessImmediately - hitilafu katika sehemu hii inasimamisha mchakato wa kupeleka;
• HopeUntilEndOfDeployProcess - tunatumai kuwa sehemu hii itafanya kazi mwishoni mwa utumaji.

Kwa mfano, mchanganyiko huu wa rasilimali na maadili ya ufafanuzi fail-mode:

Tunapotuma kwa mara ya kwanza, hifadhidata (MongoDB) inaweza kuwa bado haijawa tayari - Usambazaji hautafaulu. Lakini unaweza kusubiri kwa muda ili ianze, na upelekaji bado utafanyika.

Kuna vidokezo viwili zaidi vya kubedog katika werf:

• failures-allowed-per-replica - idadi ya maporomoko yanayoruhusiwa kwa kila nakala;
• show-logs-until - hudhibiti muda hadi ambapo werf inaonyesha (katika stdout) magogo kutoka kwenye maganda yote yaliyoviringishwa. Chaguo msingi ni PodIsReady (kupuuza ujumbe ambao labda hatutaki trafiki inapoanza kuja kwenye ganda), lakini maadili pia ni halali: ControllerIsReady и EndOfDeploy.

Je, ni nini kingine tunachotaka kutoka kwa kupelekwa?

Mbali na mambo mawili yaliyoelezwa tayari, tungependa:

• kuona magogo - na ni muhimu tu, na sio kila kitu mfululizo;
• wimbo maendeleo, kwa sababu ikiwa kazi hutegemea "kimya" kwa dakika kadhaa, ni muhimu kuelewa kinachotokea huko;
• иметь urejeshaji wa moja kwa moja ikiwa kitu kitaenda vibaya (na kwa hivyo ni muhimu kujua hali halisi ya kupelekwa). Utoaji lazima uwe wa atomiki: ama utapita hadi mwisho, au kila kitu kirudi katika hali yake ya awali.

Matokeo ya

Kwa sisi kama kampuni, kutekeleza nuances zote zilizoelezewa katika hatua tofauti za utoaji (kujenga, kuchapisha, kupeleka), mfumo wa CI na matumizi yanatosha. werf.

Badala ya hitimisho:

Kwa usaidizi wa werf, tumepata maendeleo mazuri katika kutatua idadi kubwa ya matatizo kwa wahandisi wa DevOps na tungefurahi ikiwa jumuiya pana angalau ingejaribu shirika hili kwa vitendo. Itakuwa rahisi kufikia matokeo mazuri pamoja.

Video na slaidi

Video kutoka kwa utendakazi (~dakika 47):

Uwasilishaji wa ripoti:

PS

Ripoti zingine kuhusu Kubernetes kwenye blogi yetu:

• «Kuongeza kasi kiotomatiki na usimamizi wa rasilimali katika Kubernetes» (Dmitry Stolyarov; Aprili 27, 2019 kwenye "Mgomo");
• «Kupanua na kukamilisha Kubernetes» (Andrey Polovov; Aprili 8, 2019 kwenye Saint HighLoad++);
• «Hifadhidata na Kubernetes» (Dmitry Stolyarov; Novemba 8, 2018 kwenye HighLoad++);
• «Ufuatiliaji na Kubernetes» (Dmitry Stolyarov; Mei 28, 2018 katika RootConf);
• «Mbinu Bora za CI/CD na Kubernetes na GitLab» (Dmitry Stolyarov; Novemba 7, 2017 kwenye HighLoad++);
• «Uzoefu wetu na Kubernetes katika miradi midogo» (Dmitry Stolyarov; Juni 6, 2017 katika RootConf).

Chanzo: mapenzi.com