27ê Gulanê li salona sereke ya konferansa DevOpsConf 2019, ku di çarçoveya festîvalê de pêk hat. , wekî beşek ji beşa "Radestkirina Berdewam", raporek hate dayîn "werf - amûra me ya CI/CD li Kubernetes". Li ser wan diaxive pirsgirêk û kêşeyên ku her kes dema ku li Kubernetes bicîh dike rû bi rû dimîne, û her weha li ser hûrgelên ku dibe ku tavilê neyên dîtin. Bi analîzkirina çareseriyên gengaz, em destnîşan dikin ka ev çawa di amûrek Çavkaniya Vekirî de tête bicîh kirin .
Ji dema pêşkêşkirinê ve, karanîna me (berê wekî dapp tê zanîn) gihîştiye qonaxek dîrokî ya 1000 stêrk li ser GitHub - em hêvî dikin ku civata wê ya mezin a bikarhêneran dê jiyanê ji gelek endezyarên DevOps re hêsantir bike.
Ji ber vê yekê, em bidin nasîn (~ 47 hûrdem, ji gotarê pir agahdartir) û jêdera bingehîn a wê di forma nivîsê de. Ajotin!
Radestkirina kodê ji Kubernetes re
Axaftin dê êdî ne li ser werf be, lê li ser CI/CD-ê li Kubernetes be, tê vê wateyê ku nermalava me di konteynerên Docker de tête pak kirin. (Min li ser vê yekê axivî ), û K8 dê werin bikar anîn da ku wê di hilberînê de bimeşînin (li ser vê yekê bêtir di ).
Radestkirina li Kubernetes çawa xuya dike?
- Ji bo avakirina wê depoyek Git bi kod û rêwerzan heye. Serlêdan di nav wêneyek Docker de hatî çêkirin û di Registry Docker de tê weşandin.
- Di heman depoyê de rêwerzên li ser çawaniya danîn û meşandina serîlêdanê jî dihewîne. Di qonaxa bicîhkirinê de, van rêwerzan ji Kubernetes re têne şandin, ku wêneya xwestinê ji qeydê werdigire û wê dest pê dike.
- Wekî din, bi gelemperî ceribandin hene. Hin ji van dikarin dema weşandina wêneyek bêne kirin. Her weha hûn dikarin (li pey heman rêwerzan) kopiyek serîlêdanê (di nav cîhek cihêreng a K8s an komek cûda de) bicîh bikin û li wir ceribandinan bimeşînin.
- Di dawiyê de, we pêdivî bi pergalek CI heye ku bûyeran ji Git (an klîkên bişkojkê) werdigire û bangî hemî qonaxên destnîşankirî dike: avakirin, weşandin, bicihkirin, ceribandin.
Li vir çend notên girîng hene:
- Ji ber ku binesaziyek me ya neguherbar heye (binesaziya neguhêrbar), wêneya serîlêdanê ya ku di hemî qonaxan de tê bikar anîn (qonaxa, hilberîn, hwd.), divê yek hebe. Min li ser vê yekê bi berfirehî û bi mînakan axivî. .
- Ji ber ku em binesaziyê wekî nêzîkatiya kodê dişopînin (IaC), koda serîlêdanê, talîmatên ji bo komkirin û destpêkirina wê divê hebe tam di yek depoyê de. Ji bo bêtir agahdarî li ser vê, binêre .
- Zincîra radestkirinê (şandinî) em bi gelemperî weha dibînin: serîlêdan hate civandin, ceribandin, berdan (qonaxa berdanê) û ew e - radestkirin pêk hat. Lê di rastiyê de, bikarhêner tiştê ku we derxistiye distîne, ne wê demê dema ku we ew radestî hilberînê kir, û dema ku ew karîbû biçe wir û ev berhem kar kir. Ji ber vê yekê ez bawer dikim zincîra radestkirinê bi dawî dibe tenê di qonaxa operasyonê de (rev), an jî rasttir, tewra di dema ku kod ji hilberînê hate derxistin (li şûna wê ya nû).
Ka em vegerin ser pilana radestkirina jorîn li Kubernetes: ew ne tenê ji hêla me ve, lê bi rastî ji hêla her kesê ku bi vê pirsgirêkê re mijûl bûye ve hatî vedîtin. Bi rastî, ev nimûne nuha GitOps tê gotin (hûn dikarin li ser term û ramanên li pişt wê bêtir bixwînin ). Ka em li qonaxên nexşeyê binêrin.
Qonaxa avakirin
Wusa dixuye ku hûn dikarin di sala 2019-an de li ser avakirina wêneyên Docker biaxivin, dema ku her kes zane meriv çawa Dockerfiles dinivîse û dimeşîne. docker build?.. Li vir hûrgelên ku ez dixwazim balê bikişînim hene:
- Giraniya wêneyê girîng e, ji ber vê yekê bikar bînin ku di wêneyê de tenê serîlêdana ku bi rastî ji bo operasyonê hewce ye bihêle.
- Hejmara qatan divê bi berhevkirina zincîreyan kêm bibe
RUN- li gorî wateyê ferman dike. - Lêbelê, ev pirsgirêkan zêde dike debugging, ji ber ku dema ku meclîs têk diçe, divê hûn fermana rast ji zincîra ku bûye sedema pirsgirêkê bibînin.
- Leza meclîsê girîng e ji ber ku em dixwazin zû guhertinan derxînin û encaman bibînin. Mînakî, hûn naxwazin her gava ku hûn serîlêdanek ava dikin ve girêdayî di pirtûkxaneyên ziman de ji nû ve ava bikin.
- Pir caran ji yek depoyek Git ku hûn hewce ne gelek wêne, ku dikare bi komek Dockerfiles (an qonaxên navên di yek pelê de) û skrîptek Bash bi kombûna wan a rêzdar ve were çareser kirin.
Ev tenê serê befrê bû ku her kes pê re rû bi rû dimîne. Lê pirsgirêkên din hene, bi taybetî:
- Gelek caran di qonaxa meclîsê de em hewceyê tiştek e mount (Mînakî, encamek fermanek mîna apt di pelrêçek sêyemîn de cache bike).
- Em dixwazin Ansible şûna nivîsandina bi şêlê.
- Em dixwazin bêyî Docker ava bikin (Gava ku me berê komek Kubernetes heye ku tê de em dikarin konteyneran bimeşînin, çima pêdivî bi makîneyek virtual ya zêde heye ku tê de pêdivî ye ku em her tiştî ji bo vê yekê mîheng bikin?).
- Civîna paralel, ku dikare bi awayên cihêreng were fêm kirin: Fermanên cihêreng ên ji Dockerfile (heke pir-qonax were bikar anîn), çend peywirên heman depoyê, çend Dockerfiles.
- Meclîsa belav kirin: Em dixwazin tiştên ku "tevdîr" in di nav potan de berhev bikin ji ber ku cache wan winda dibe, ku tê vê wateyê ku pêdivî ye ku ew li cîhek cûda were hilanîn.
- Di dawiyê de, min navê lûtkeya xwestekan kir otomagic: Dê îdeal be ku hûn biçin depoyê, fermanek binivîsin û wêneyek amade bistînin, ku bi têgihîştina ka meriv çawa û çi rast bikin were berhev kirin. Lêbelê, ez bi xwe ne bawer im ku hemî nuwaze dikarin bi vî rengî bêne pêşbînî kirin.
Û li vir projeyên hene:
- - avakerek ji Docker Inc (jixwe di guhertoyên heyî yên Docker de yekgirtî ye), ku hewl dide van hemî pirsgirêkan çareser bike;
- - avakerek ji Google-ê ku dihêle hûn bêyî Docker ava bikin;
- - Hewldana CNCF ji bo çêkirina sêrbaziya otomatîkî û, bi taybetî, çareseriyek balkêş bi rebaskirina ji bo qatan;
- û komek karûbarên din, wek , ...
...û binerin ka çend stêrkên wan li ser GitHub hene. Yanî ji aliyekî ve, docker build heye û dikare tiştekî bike, lê di rastiyê de mesele bi temamî çareser nabe - îsbata vê yekê pêşveçûna paralel a berhevkarên alternatîf e, ku her yek ji wan beşek ji pirsgirêkan çareser dike.
Civîna li werf
Ji ber vê yekê em gihîştin (berê wek dapp) - Karûbarek çavkaniyek vekirî ya ji pargîdaniya Flant, ku em gelek sal in çêdikin. Hemî 5 sal berê bi nivîsarên Bash-ê yên ku kombûna Dockerfiles xweştir kirin dest pê kir, û 3 salên dawîn de pêşkeftina bêkêmasî di çarçoveya yek projeyê de bi depoya xweya Git-ê ve hatî çêkirin. (Pêşî li Ruby, û paşê biçe, û di heman demê de navê wî hate guhertin). Çi pirsgirêkên meclîsê di werfê de têne çareser kirin?
Pirsgirêkên ku bi şîn hatine xêzkirin jixwe hatine bicîh kirin, avakirina paralel di hundurê heman mêvandar de hate çêkirin, û pirsgirêkên ku bi zer hatine destnîşan kirin tê plan kirin ku heya dawiya havînê bêne qedandin.
Qonaxa weşanê di qeydê de (weşandin)
Me telefon kir docker push... - di derbarê barkirina wêneyek li qeydê de çi dikare dijwar be? Û dûv re pirs derdikeve: "Divê ez kîjan etîketê deynim ser wêneyê?" Ew ji ber sedema ku me heye derdikeve holê Gitflow (an jî stratejiya Git ya din) û Kubernetes, û pîşesazî hewl dide ku tiştê ku li Kubernetes diqewime li pey tiştê ku li Git diqewime. Jixwe, Git tenê çavkaniya me ya rastiyê ye.
Di vê yekê de çi zehmet e? Ji nû ve hilberandinê piştrast bikin: ji commitek li Git, ku di xwezayê de neguhêrbar e (neguherbar), ji wêneyek Docker re, ku divê heman bimîne.
Ji bo me jî girîng e eslê xwe diyar bike, ji ber ku em dixwazin fam bikin ku serîlêdana ku li Kubernetes tê xebitandin ji kîjan commitê hatî çêkirin (wê hingê em dikarin cûda û tiştên mîna wan bikin).
Tagging Stratejiyên
Ya yekem hêsan e git tag. Registryek me heye ku wêneyek wekî wekî nîşankirî ye 1.0. Kubernetes xwedan qonax û hilberînê ye, ku ev wêne lê tê barkirin. Di Git de em peymanan çêdikin û li hin deqan em tag dikin 2.0. Em wê li gorî rêwerzên ji depoyê berhev dikin û bi etîketê di nav qeydê de bi cih dikin 2.0. Em wê derdixin sehneyê û, ger her tişt baş be, wê hingê berbi hilberînê ve diçe.
Pirsgirêka vê nêzîkbûnê ev e ku me pêşî tag danî, û tenê dûv re ew ceribandin û derxistin. Çima? Pêşîn, ew bi tenê ne mentiqî ye: em guhertoyek nermalava ku me hîna jî ceribandî derdixe (em nekarin wekî din bikin, ji ber ku ji bo kontrolkirinê, pêdivî ye ku em nîşanek deynin). Ya duyemîn, ev rê bi Gitflow re ne hevaheng e.
Vebijarka duyemîn e git commit + tag. Şaxa masterê etîketek heye 1.0; ji bo wê di qeydê de - wêneyek ku ji hilberînê re hatî şandin. Wekî din, koma Kubernetes xwedan pêşdîtin û qonaxên qonaxê ye. Piştre em Gitflow dişopînin: di şaxê sereke de ji bo pêşkeftinê (develop) em taybetmendiyên nû çêdikin, ku di encamê de bi nasnameyê ve girêdayî ye #c1. Em wê berhev dikin û bi karanîna vê nasnameyê di qeydê de diweşînin (#c1). Bi heman nasnameyê em ji bo pêşdîtinê derdixin. Em jî heman tiştî bi peymanan dikin #c2 и #c3.
Dema ku me fêm kir ku têra xwe taybetmendiyên hene, em dest pê dikin ku her tiştî aram bikin. Di Git de şaxek çêbikin release_1.1 (li ser bingehê #c3 ji develop). Ne hewce ye ku vê serbestberdanê berhev bike, ji ber ku ... ev di gava berê de hate kirin. Ji ber vê yekê, em dikarin bi hêsanî wê bixin nav qonaxê. Em xeletiyan rast dikin #c4 û bi heman awayî ber bi qonaxê ve diçin. Di heman demê de, pêşveçûna pêşveçûnê ye develop, ku guhertinên demkî jê têne girtin release_1.1. Di hin xalan de, em commitek distînin ku li ser sehneyê hatî berhev kirin û barkirin, ku em pê kêfxweş in (#c25).
Dûv re em (bi lez-pêşveçûn) şaxê berdanê (release_1.1) di master de. Me bi guhertoya nû etîketek li ser vê komîteyê danî (1.1). Lê ev wêne jixwe di qeydê de hatî berhev kirin, ji ber vê yekê ji bo ku ew careke din neyê berhev kirin, em tenê etîketek duyemîn li wêneya heyî zêde dikin (niha di qeydê de etîketên wê hene #c25 и 1.1). Piştî vê yekê, em wê berbi hilberînê vekin.
Kêmasiyek heye ku tenê wêneyek ji bo sehneyê tê barkirin (#c25), û di hilberînê de ew cûreyek cûda ye (1.1), lê em dizanin ku "fizîkî" ev heman wêneyê ji qeydê ne.
Kêmasiya rastîn ev e ku ji bo peywirên hevgirtinê piştgirî tune, divê hûn zû-pêşverû bikin.
Em dikarin pêşdetir biçin û hîleyek bikin... Ka em li mînakek Dockerfile-ya hêsan binêrin:
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/publicKa em pelê jê re li gorî prensîba jêrîn ava bikin:
- SHA256 ji nasnameyên wêneyên ku hatine bikar anîn (
ruby:2.3иnginx:alpine), ku kontrolên naveroka wan in; - hemû tîm (
RUN,CMDwate ya vê çîye.); - SHA256 ji pelên ku hatine zêdekirin.
... û kontrolê (dîsa SHA256) ji pelek wusa bistînin. Ev destnîşan her tiştê ku naveroka wêneya Docker diyar dike.
Ka em vegerin ser diagram û ji dêvla erkan em ê îmzeyên wiha bikar bînin, yanî wêneyên bi îmzeyan etîket bikin.
Naha, gava ku hewce be, mînakî, meriv guheztinên ji serbestberdanê berbi masterê ve bike yek, em dikarin bihevrekheviyek rastîn bikin: ew ê nasnameyek cûda hebe, lê heman îmze. Bi heman nasnameyê em ê wêneyê berbi hilberînê vekin.
Kêmasî ev e ku naha ew ê nekare were destnîşankirin ka çi cûre soz ji hilberînê re hate kişandin - kontrol tenê di yek alî de dixebitin. Ev pirsgirêk bi qatek pêvek bi metadata tê çareser kirin - ez ê paşê ji we re bêtir bibêjim.
Tagging li werf
Di werfê de em hê wêdetir çûn û xwe amade dikin ku bi cacheyek ku li ser yek makîneyê nayê hilanîn avahiyek belavkirî bikin... Ji ber vê yekê, em du celeb wêneyên Docker ava dikin, em ji wan re dibêjin. şanocî и wêne.
Depoya werf Git rêwerzên avahîsaziyê yên ku qonaxên cihêreng ên çêkirinê vedibêjin hildide (berî Sazkirinê, lêkirin, berî Setup, damezirandin). Em wêneya qonaxa yekem bi îmzeyek ku wekî kontrolkirina gavên yekem têne destnîşan kirin berhev dikin. Dûv re em koda çavkaniyê lê zêde dikin, ji bo wêneya qonaxa nû em jimareya kontrolê ya wê dihejmêrin... Ev kar ji bo hemî qonaxan têne dubare kirin, di encamê de em komek wêneyên qonaxê distînin. Dûv re em wêneya paşîn çêdikin, ku di heman demê de metadata li ser eslê xwe jî vedihewîne. Û em vê wêneyê bi awayên cihêreng etîket dikin (detayên paşê).
Bifikirin ku piştî vê yekê komîteyek nû xuya dike ku tê de tenê koda serîlêdanê hatiye guhertin. Wê çi bibe? Ji bo guhertinên kodê, dê patchek were çêkirin û wêneyek qonaxek nû were amadekirin. Îmzeya wê dê wekî kontrolkirina wêneya qonaxa kevin û paçeya nû were destnîşankirin. Wêneyek nû ya dawî ji vê wêneyê çêbibe. Tevgerên bi vî rengî dê bi guhertinên di qonaxên din de jî çêbibin.
Bi vî rengî, wêneyên qonaxê cacheyek in ku dikare bi belavkirinê were hilanîn, û wêneyên ku berê jê hatine afirandin li Registry Docker têne barkirin.
Paqijkirina qeydê
Em nabêjin jêbirina qatên ku piştî tagên jêbirin daliqandî mane - ev taybetmendiyek standard a Docker Registry bixwe ye. Em li ser rewşek dipeyivin ku gelek etîketên Docker berhev dibin û em fam dikin ku êdî em ne hewceyî hin ji wan in, lê ew cîh digirin (û/an em ji bo wê didin).
Stratejiyên paqijkirinê çi ne?
- Hûn tenê nikarin tiştek bikin paqij neke. Carinan bi rastî hêsantir e ku meriv hinekî ji bo cîhek zêde bide ji derxistina tevliheviyek mezin a nîşanan. Lê ev tenê heya xalek diyarkirî dixebite.
- Reset Full. Ger hûn hemî wêneyan jêbirin û tenê yên heyî yên di pergala CI de ji nû ve ava bikin, dibe ku pirsgirêk derkeve. Ger konteynir di hilberînê de ji nû ve were destpêkirin, dê wêneyek nû jê re were barkirin - ya ku hêj ji hêla kesî ve nehatiye ceribandin. Ev ramana binesaziya neguhêrbar dikuje.
- Şîn-şîn. Qeydek dest bi zêdebûnê kir - em wêneyan li yekî din bar dikin. Heman pirsgirêk wekî di rêbaza berê de: di kîjan xalê de hûn dikarin qeyda ku dest bi zêdebûnê kiriye paqij bikin?
- Bi demê re. Hemî wêneyên ji 1 mehan kevintir jê bibin? Lê bê guman dê xizmetek hebe ku mehek nehatiye nûve kirin...
- Mirovan diyar bike ka çi jixwe dikare were jêbirin.
Du vebijarkên bi rastî guncan hene: bi destan paqij nekin an tevliheviya şîn-kesk + bi destan nekin. Di rewşa paşîn de, em li ser van tiştan dipeyivin: gava ku hûn fêm dikin ku wextê paqijkirina qeydê ye, hûn yeke nû diafirînin û di nav mehekê de, mînakî, mehekê, hemî wêneyên nû lê zêde dikin. Û piştî mehekê, bibînin ka kîjan podên li Kubernetes hîn jî qeyda kevn bikar tînin, û wan jî veguhezînin qeyda nû.
Em hatine çi werf? Em berhev dikin:
- Serê Git: hemî etîket, hemî şax - bihesibînin ku em hewceyê her tiştê ku di Git-ê de di wêneyan de hatî nîşankirin (û heke na, wê hingê pêdivî ye ku em wê di Git bixwe de jêbirin);
- hemî podên ku niha li Kubernetes têne derxistin;
- ReplicaSets kevn (ya ku vê dawiyê hate berdan), û em jî plan dikin ku weşanên Helm bişopînin û wêneyên herî dawî li wir hilbijêrin.
... û ji vê setê navnîşek spî çêbikin - navnîşek wêneyan ku em ê jê nekin. Em her tiştê din paqij dikin, pişt re em wêneyên qonaxa sêwî dibînin û wan jî jê dikin.
Qonaxa bicihkirinê
Daxuyaniya pêbawer
Xala yekem a ku ez dixwazim di bicîhkirinê de balê bikişînim ser vekêşana veavakirina çavkaniya nûvekirî ye, ku bi eşkereyî hatî ragihandin. Belgeya orîjînal a YAML ku çavkaniyên Kubernetes vedibêje her gav ji encama ku bi rastî di komê de dimeşe pir cûda ye. Ji ber ku Kubernetes li veavakirinê zêde dike:
- nasnameyan;
- agahdariya xizmetê;
- gelek nirxên xwerû;
- beşa bi rewşa heyî;
- guhertinên ku wekî beşek ji webhook pejirandinê hatine çêkirin;
- encama xebata kontrolkerên cihêreng (û plansazker).
Ji ber vê yekê, dema ku veavakirina çavkaniyek nû xuya dibe (nşh), em nekarin tenê bi wê veavakirina heyî, "bijî" bistînin û binivîsînin (jîyan). Ji bo vê yekê em ê neçar bibin ku bidin ber hev nşh bi veavakirina dawîn a sepandî (dawî- sepandin) û bixin ser jîyan paç wergirtiye.
Ev nêzîkatî tê gotin Yekbûna 2-alî. Ji bo nimûne, di Helmê de tê bikaranîn.
Her weha heye Yekbûna 3-alî, ku di wê de cûda dibe:
- berhevkirin dawî- sepandin и nşh, em li tiştên ku hatine jêbirin dinêrin;
- berhevkirin nşh и jîyan, em li tiştên ku hatine zêdekirin an guherandin dinêrin;
- paçeya kurtkirî li ser tê sepandin jîyan.
Em bi Helm re 1000+ sepanan bicîh dikin, ji ber vê yekê em bi rastî bi hevgirtina 2-alî re dijîn. Lêbelê, wê hejmarek pirsgirêk hene ku me bi paçên xwe çareser kirine, ku ji Helm re dibe alîkar ku bi gelemperî bixebite.
Rewşa pêşandana rastîn
Piştî ku pergala meya CI-yê ji bo Kubernetes li ser bingeha bûyera din vesazkirinek nû çêdike, ew wê ji bo karanîna dişîne. (bikaranîn) to komek - bikaranîna Helm an kubectl apply. Dûv re, hevgirtina N-rêya ku ji berê ve hatî destnîşan kirin pêk tê, ku Kubernetes API bi pejirandina pergala CI, û wê ji bikarhênerê wê re bersiv dide.
Lêbelê, pirsgirêkek mezin heye: paşê serîlêdana serketî nayê wateya pêşkeftina serketî. Ger Kubernetes fêm bike ka çi guhertin divê bêne sepandin û wê bicîh bîne, em hîn jî nizanin dê encam çi be. Mînakî, nûvekirin û ji nû ve destpêkirina podên li pêşiyê dibe ku serketî be, lê ne di paşîn de, û em ê guhertoyên cihêreng ên wêneyên serîlêdana xebitandinê bistînin.
Ji bo ku her tiştî rast bikin, ev nexşe pêvekek pêvek hewce dike - şopek taybetî ya ku dê agahdariya statûyê ji Kubernetes API bistîne û wê ji bo analîzkirina bêtir rewşa rastîn a tiştan veguhezîne. Me pirtûkxaneyek Çavkaniya Vekirî li Go çêkir - (li daxuyaniya wê binêre ), ku vê pirsgirêkê çareser dike û di nav werfê de hatî çêkirin.
Tevgera vê şopgerê di asta werfê de bi karanîna annotasyonên ku li ser Deployments an StatefulSets têne danîn têne mîheng kirin. Şîrovekirina sereke - fail-mode - wateyên jêrîn fam dike:
-
IgnoreAndContinueDeployProcess- em guh nadin pirsgirêkên derxistina vê pêkhateyê û bicihkirina xwe didomînin; -
FailWholeDeployProcessImmediately- xeletiyek di vê hêmanê de pêvajoya bicîhkirinê rawestîne; -
HopeUntilEndOfDeployProcess- Em hêvîdar in ku ev pêkhate dê heta dawiya belavbûnê kar bike.
Mînakî, ev berhevoka çavkaniyan û nirxên şîrovekirinê fail-mode:
Dema ku em ji bo yekem car bicîh dikin, dibe ku databas (MongoDB) hîn ne amade be - Dê bicîhkirin têk biçin. Lê hûn dikarin li benda wê gavê bisekinin ku ew dest pê bike, û bicîhkirin dê hîn jî pêk were.
Di werfê de ji bo kubedog du şîroveyên din jî hene:
-
failures-allowed-per-replica- hejmara destûr ji bo her replica dikeve; -
show-logs-until- wextê ku werf têketinên ji hemî pelên pelçiqandî nîşan dide (di stdout) de rê dide. Vebijêrk ePodIsReady(ji bo paşguhkirina peyamên ku em belkî naxwazin gava ku seyrûsefer dest pê dike ku tê ser pod), lê nirx jî derbasdar in:ControllerIsReadyиEndOfDeploy.
Ma em ji bicîkirinê wekî din çi dixwazin?
Ji bilî du xalên ku berê hatine destnîşan kirin, em dixwazin:
- dîtina têketin - û tenê yên pêwîst, û ne her tişt li pey hev;
- şop pêşverûtî, ji ber ku heke kar çend deqeyan "bêdeng" raweste, girîng e ku meriv fêm bike ka li wir çi diqewime;
- иметь rollback otomatîk heke tiştek xelet derket (û ji ber vê yekê girîng e ku hûn statûya rastîn a bicîhkirinê zanibin). Pêvek divê atomî be: an ew heya dawiyê derbas dibe, an jî her tişt vedigere rewşa xwe ya berê.
Encam
Ji bo me wekî pargîdaniyek, ji bo pêkanîna hemî nuwazeyên diyarkirî di qonaxên cûda yên radestkirinê de (avakirin, weşandin, bicîhkirin), pergalek CI û kargêrî bes e. .
Li şûna encamnameyê:
Bi alîkariya werf, me di çareserkirina hejmareke mezin a pirsgirêkan de ji bo endezyarên DevOps pêşkeftinek baş çêkiriye û em ê kêfxweş bibin ku civata berfireh bi kêmanî vê amûreyê di çalakiyê de biceribîne. Dê hêsantir bi hev re encamek baş bi dest bixin.
Vîdyo û slaytên
Vîdyo ji performansê (~ 47 hûrdem):
Pêşkêşkirina raporê:
PS
Raporên din ên di derbarê Kubernetes de li ser bloga me:
- «» (Dmitry Stolyarov; 27ê Avrêl, 2019 li ser "Strike");
- «» (Andrey Polovov; 8ê Avrêl, 2019 li Saint HighLoad ++);
- «» (Dmitry Stolyarov; 8 Mijdar 2018 li ser HighLoad ++);
- «» (Dmitry Stolyarov; 28 Gulan 2018 li RootConf);
- «» (Dmitry Stolyarov; 7 Mijdar 2017 li ser HighLoad ++);
- «» (Dmitry Stolyarov; 6 Hezîran, 2017 li RootConf).
Source: www.habr.com