27. maijÄ DevOpsConf 2019 konferences galvenajÄ zÄlÄ, kas notika festivÄla ietvaros , kÄ daļa no sadaļas "NepÄrtraukta piegÄde", tika sniegts ziÅojums "werf - mÅ«su rÄ«ks CI/CD in Kubernetes". Tas runÄ par tiem problÄmas un izaicinÄjumi, ar kuriem saskaras ikviens, izvietojot Kubernetes, kÄ arÄ« par niansÄm, kas var nebÅ«t uzreiz pamanÄmas. AnalizÄjot iespÄjamos risinÄjumus, mÄs parÄdÄm, kÄ tas tiek Ä«stenots atvÄrtÄ pirmkoda rÄ«kÄ .
KopÅ” prezentÄcijas mÅ«su utilÄ«ta (agrÄk pazÄ«stama kÄ dapp) ir sasniegusi vÄsturisku pavÄrsienu 1000 zvaigžÅu vietnÄ GitHub ā mÄs ceram, ka tÄ augoÅ”Ä lietotÄju kopiena atvieglos dzÄ«vi daudziem DevOps inženieriem.
TÄtad, mÄs piedÄvÄjam (~47 minÅ«tes, daudz informatÄ«vÄks par rakstu) un galvenais izraksts no tÄ teksta formÄ. Aiziet!
Koda piegÄde Kubernetes
Runa vairs nebÅ«s par werf, bet gan par CI/CD Kubernetes, norÄdot, ka mÅ«su programmatÅ«ra ir iepakota Docker konteineros (Es par to runÄju ), un K8s tiks izmantoti, lai to palaistu ražoÅ”anÄ (vairÄk par to sadaÄ¼Ä ).
KÄ izskatÄs piegÄde Kubernetes?
- Ir Git repozitorijs ar kodu un instrukcijÄm tÄ izveidei. Lietojumprogramma ir iebÅ«vÄta Docker attÄlÄ un publicÄta Docker reÄ£istrÄ.
- TajÄ paÅ”Ä repozitorijÄ ir arÄ« norÄdÄ«jumi par lietojumprogrammas izvietoÅ”anu un palaiÅ”anu. IzvietoÅ”anas stadijÄ Å”ie norÄdÄ«jumi tiek nosÅ«tÄ«ti Kubernetes, kas saÅem vajadzÄ«go attÄlu no reÄ£istra un palaiž to.
- TurklÄt parasti ir testi. Dažus no tiem var izdarÄ«t, publicÄjot attÄlu. Varat arÄ« (ievÄrojot tos paÅ”us norÄdÄ«jumus) izvietot lietojumprogrammas kopiju (atseviÅ”Ä·Ä K8s nosaukumvietÄ vai atseviÅ”Ä·Ä klasterÄ«) un tur veikt testus.
- Visbeidzot, jums ir nepiecieÅ”ama CI sistÄma, kas saÅem notikumus no Git (vai pogu klikŔķus) un izsauc visus norÄdÄ«tos posmus: izveidojiet, publicÄjiet, izvietojiet, pÄrbaudiet.
Šeit ir dažas svarīgas piezīmes:
- Jo mums ir nemainÄ«ga infrastruktÅ«ra (nemainÄ«ga infrastruktÅ«ra), lietojumprogrammas attÄls, kas tiek izmantots visos posmos (iestudÄÅ”ana, ražoÅ”ana utt.), tÄdam jÄbÅ«t. Es par to runÄju sÄ«kÄk un ar piemÄriem. .
- Jo mÄs sekojam infrastruktÅ«rai kÄ koda pieejai (IaC), lietojumprogrammas kodam, instrukcijÄm tÄ montÄžai un palaiÅ”anai jÄbÅ«t tieÅ”i vienÄ repozitorijÄ. PlaÅ”Äku informÄciju par to skatiet .
- PiegÄdes Ä·Äde (PiegÄde) mÄs parasti to redzam Å”Ädi: lietojumprogramma tika samontÄta, pÄrbaudÄ«ta, izlaista (izlaiduma posms) un viss - piegÄde ir notikusi. TaÄu patiesÄ«bÄ lietotÄjs saÅem to, ko jÅ«s izlaidÄt, nÄ tad, kad jÅ«s to piegÄdÄjÄt ražoÅ”anai, un kad viÅÅ” varÄja tur aizbraukt, un Ŕī ražoÅ”ana strÄdÄja. TÄpÄc es uzskatu, ka piegÄdes Ä·Äde beidzas tikai ekspluatÄcijas stadijÄ (skriet), vai precÄ«zÄk, pat tajÄ brÄ«dÄ«, kad kods tika izÅemts no ražoÅ”anas (aizvietojot to ar jaunu).
AtgriezÄ«simies pie iepriekÅ” minÄtÄs piegÄdes shÄmas Kubernetes: to izgudrojÄm ne tikai mÄs, bet burtiski visi, kas nodarbojÄs ar Å”o problÄmu. Faktiski Å”o modeli tagad sauc par GitOps (jÅ«s varat lasÄ«t vairÄk par terminu un tÄ idejÄm ). ApskatÄ«sim shÄmas posmus.
Celtniecības posms
Å Ä·iet, ka jÅ«s varat runÄt par Docker attÄlu veidoÅ”anu 2019. gadÄ, kad visi zina, kÄ rakstÄ«t Dockerfiles un palaist docker build?.. LÅ«k, nianses, kurÄm vÄlos pievÄrst uzmanÄ«bu:
- AttÄla svars svarÄ«gi, tÄpÄc izmantojiet atstÄt attÄlÄ tikai to aplikÄciju, kas patieÅ”Äm ir nepiecieÅ”ama darbÄ«bai.
- SlÄÅu skaits jÄsamazina, apvienojot Ä·Ädes
RUN-pavÄles pÄc nozÄ«mes. - TomÄr tas rada papildu problÄmas atkļūdoÅ”ana, jo, kad montÄža avarÄ, jums ir jÄatrod pareizÄ komanda no Ä·Ädes, kas izraisÄ«ja problÄmu.
- MontÄžas Ätrums svarÄ«gi, jo mÄs vÄlamies Ätri ieviest izmaiÅas un redzÄt rezultÄtus. PiemÄram, jÅ«s nevÄlaties atjaunot atkarÄ«bas valodu bibliotÄkÄs katru reizi, kad veidojat lietojumprogrammu.
- Bieži vien no viena Git repozitorija jums ir nepiecieÅ”ams daudz attÄlu, ko var atrisinÄt ar Dockerfailu kopu (vai nosauktiem posmiem vienÄ failÄ) un Bash skriptu ar to secÄ«go montÄžu.
TÄ bija tikai aisberga redzamÄ daļa, ar ko saskaras ikviens. Bet ir arÄ« citas problÄmas, jo Ä«paÅ”i:
- Bieži vien montÄžas stadijÄ mums kaut kas ir vajadzÄ«gs mount (piemÄram, treÅ”Äs puses direktorijÄ saglabÄjiet tÄdas komandas rezultÄtu kÄ apt).
- MÄs gribam IespÄjams tÄ vietÄ, lai rakstÄ«tu ÄaulÄ.
- MÄs gribam veidot bez Docker (kÄpÄc mums ir vajadzÄ«ga papildu virtuÄlÄ maŔīna, kurÄ mums viss ir jÄkonfigurÄ, ja mums jau ir Kubernetes klasteris, kurÄ mÄs varam palaist konteinerus?).
- ParalÄlÄ montÄža, ko var saprast dažÄdi: dažÄdas komandas no Dockerfile (ja tiek izmantots vairÄkpakÄpju), vairÄkas vienas un tÄs paÅ”as repozitorijas commits, vairÄki Dockerfile.
- SadalÄ«ta montÄža: MÄs vÄlamies savÄkt lietas pÄkstÄ«s, kas ir "Ä«slaicÄ«gas", jo to keÅ”atmiÅa pazÅ«d, kas nozÄ«mÄ, ka tÄ ir jÄglabÄ kaut kur atseviŔķi.
- Visbeidzot es nosaucu vÄlmju virsotni automÄtiska: IdeÄli bÅ«tu aiziet uz repozitoriju, ierakstÄ«t kÄdu komandu un iegÅ«t gatavu attÄlu, kas samontÄts ar izpratni, kÄ un ko pareizi darÄ«t. TaÄu es personÄ«gi neesmu pÄrliecinÄts, ka visas nianses Å”Ädi var paredzÄt.
Un Ŕeit ir projekti:
- ā celtnieks no Docker Inc (jau integrÄts paÅ”reizÄjÄs Docker versijÄs), kas cenÅ”as atrisinÄt visas Ŕīs problÄmas;
- ā Google celtnieks, kas ļauj bÅ«vÄt bez Docker;
- ā CNCF mÄÄ£inÄjums radÄ«t automÄtisku maÄ£iju un jo Ä«paÅ”i interesantu risinÄjumu ar slÄÅu pÄrbÄzi;
- un virkni citu komunÄlo pakalpojumu, piemÄram , ...
...un paskatieties, cik daudz zvaigžÅu viÅiem ir GitHub. Tas ir, no vienas puses, docker build pastÄv un var kaut ko darÄ«t, bet patiesÄ«bÄ problÄma nav pilnÄ«bÄ atrisinÄta - pierÄdÄ«jums tam ir paralÄla alternatÄ«vu kolektoru attÄ«stÄ«ba, no kuriem katrs atrisina kÄdu daļu problÄmu.
MontÄža werf
TÄtad mums ir jÄdara (agrÄk kÄ dapp) ā AtvÄrtÄ koda utilÄ«ta no uzÅÄmuma Flant, ko esam ražojuÅ”i jau daudzus gadus. Viss sÄkÄs pirms 5 gadiem ar Bash skriptiem, kas optimizÄja Dockerfiles montÄžu, un pÄdÄjos 3 gadus ir veikta pilnvÄrtÄ«ga izstrÄde viena projekta ietvaros ar savu Git repozitoriju (vispirms RubÄ«nÄ un pÄc tam to Go, un tajÄ paÅ”Ä laikÄ pÄrdÄvÄja). KÄdas montÄžas problÄmas tiek atrisinÄtas werf?
ProblÄmas, kas iekrÄsotas zilÄ krÄsÄ, jau ir Ä«stenotas, paralÄlÄ bÅ«vÄÅ”ana tika veikta tajÄ paÅ”Ä resursdatorÄ, un dzeltenÄ iezÄ«mÄtÄs problÄmas plÄnots pabeigt lÄ«dz vasaras beigÄm.
PublicÄÅ”anas posms reÄ£istrÄ (publicÄÅ”ana)
MÄs zvanÄ«jÄm docker push... - kas varÄtu bÅ«t grÅ«ti augÅ”upielÄdÄjot attÄlu reÄ£istrÄ? Un tad rodas jautÄjums: "KÄdu tagu man vajadzÄtu pievienot attÄlam?" Tas rodas tÄ iemesla dÄļ, kÄds mums ir Gitflow (vai cita Git stratÄÄ£ija) un Kubernetes, un nozare cenÅ”as nodroÅ”inÄt, lai tas, kas notiek Kubernetes, atbilstu tam, kas notiek Git. Galu galÄ Gits ir mÅ«su vienÄ«gais patiesÄ«bas avots.
Kas tur tik grÅ«ts? NodroÅ”iniet reproducÄjamÄ«bu: no apÅemÅ”anÄs GitÄ, kas pÄc bÅ«tÄ«bas ir nemainÄ«gs (nemainÄ«gs), uz Docker attÄlu, kas ir jÄsaglabÄ tÄds pats.
Tas ir svarÄ«gi arÄ« mums noteikt izcelsmi, jo gribam saprast, no kura commit ir uzbÅ«vÄta Kubernetes darbojoÅ”Ä aplikÄcija (tad varam veikt diffus un tamlÄ«dzÄ«gas lietas).
AtzÄ«mÄÅ”anas stratÄÄ£ijas
Pirmais ir vienkÄrÅ”s git diena. Mums ir reÄ£istrs ar attÄlu, kas atzÄ«mÄts kÄ 1.0. Kubernetes ir skatuve un producÄÅ”ana, kur tiek augÅ”upielÄdÄts Å”is attÄls. ProgrammÄ Git mÄs veicam saistÄ«bas un kÄdÄ brÄ«dÄ« atzÄ«mÄjam 2.0. MÄs to savÄcam saskaÅÄ ar repozitorija norÄdÄ«jumiem un ievietojam to reÄ£istrÄ ar tagu 2.0. MÄs to izrullÄjam uz skatuves un, ja viss ir kÄrtÄ«bÄ, tad uz ražoÅ”anu.
Å Ä«s pieejas problÄma ir tÄda, ka mÄs vispirms ievietojÄm tagu un tikai pÄc tam to pÄrbaudÄ«jÄm un izlaidÄm. KÄpÄc? PirmkÄrt, tas ir vienkÄrÅ”i neloÄ£iski: mÄs izdodam programmatÅ«ras versiju, kuru vÄl neesam pat pÄrbaudÄ«juÅ”i (citÄdi nevaram, jo, lai pÄrbaudÄ«tu, ir jÄievieto tags). OtrkÄrt, Å”is ceļŔ nav saderÄ«gs ar Gitflow.
OtrÄ iespÄja - git commit + tag. GalvenÄ filiÄlei ir atzÄ«me 1.0; par to reÄ£istrÄ - attÄls, kas izvietots ražoÅ”anÄ. TurklÄt Kubernetes klasterim ir priekÅ”skatÄ«juma un iestudÄjuma kontÅ«ras. TÄlÄk mÄs sekojam Gitflow: galvenajÄ attÄ«stÄ«bas filiÄlÄ (develop) mÄs izveidojam jaunus lÄ«dzekļus, kÄ rezultÄtÄ tiek veikta apÅemÅ”anÄs ar identifikatoru #c1. MÄs to apkopojam un publicÄjam reÄ£istrÄ, izmantojot Å”o identifikatoru (#c1). Ar to paÅ”u identifikatoru mÄs izlaižam priekÅ”skatÄ«jumu. MÄs darÄm to paÅ”u ar saistÄ«bÄm #c2 Šø #c3.
Kad mÄs sapratÄm, ka ir pietiekami daudz funkciju, mÄs sÄkam visu stabilizÄt. Izveidojiet filiÄli programmÄ Git release_1.1 (uz pamatnes #c3 no develop). Nav nepiecieÅ”ams vÄkt Å”o izlaidumu, jo... tas tika darÄ«ts iepriekÅ”ÄjÄ darbÄ«bÄ. TÄpÄc mÄs varam to vienkÄrÅ”i izvÄrst iestudÄÅ”anai. MÄs izlabojam kļūdas #c4 un lÄ«dzÄ«gi izrullÄt iestudÄÅ”anai. TajÄ paÅ”Ä laikÄ notiek attÄ«stÄ«ba develop, kur periodiski tiek veiktas izmaiÅas no release_1.1. KÄdÄ brÄ«dÄ« mÄs saÅemam apÅemÅ”anos, kas tiek apkopota un augÅ”upielÄdÄta inscenÄÅ”anai, un mÄs esam apmierinÄti ar (#c25).
PÄc tam mÄs sapludinÄm (ar Ätri pÄrtÄ«Å”anu) atbrÄ«voÅ”anas zaru (release_1.1) meistarÄ. MÄs ievietojÄm tagu ar jauno versiju Å”ai apÅemÅ”anai (1.1). Bet Å”is attÄls jau ir savÄkts reÄ£istrÄ, tÄpÄc, lai tas vairs netiktu savÄkts, mÄs vienkÄrÅ”i pievienojam otru tagu esoÅ”ajam attÄlam (tagad tam ir tagi reÄ£istrÄ #c25 Šø 1.1). PÄc tam mÄs to izrullÄjam uz ražoÅ”anu.
Ir trÅ«kums, ka inscenÄÅ”anai tiek augÅ”upielÄdÄts tikai viens attÄls (#c25), un ražoÅ”anÄ tas ir savÄdÄk (1.1), taÄu mÄs zinÄm, ka āfiziskiā tie ir viens un tas pats attÄls no reÄ£istra.
Patiesais trÅ«kums ir tas, ka nav atbalsta sapludinÄÅ”anas saistÄ«bÄm, jums ir jÄdara Ätri uz priekÅ”u.
MÄs varam iet tÄlÄk un veikt triku... ApskatÄ«sim vienkÄrÅ”a Dockerfile piemÄru:
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/publicIzveidosim no tÄ failu pÄc Å”Äda principa:
- SHA256 no izmantoto attÄlu identifikatoriem (
ruby:2.3Šønginx:alpine), kas ir to satura kontrolsummas; - visas komandas (
RUN,CMDun tÄ tÄlÄk.); - SHA256 no failiem, kas tika pievienoti.
... un paÅemiet kontrolsummu (atkal SHA256) no Å”Äda faila. Å is parakstu viss, kas nosaka Docker attÄla saturu.
AtgriezÄ«simies pie diagrammas un apÅemÅ”anos vietÄ izmantosim Å”Ädus parakstus, t.i. atzÄ«mÄjiet attÄlus ar parakstiem.
Tagad, kad ir nepiecieÅ”ams, piemÄram, sapludinÄt izmaiÅas no laidiena uz galveno, mÄs varam veikt reÄlu sapludinÄÅ”anas apÅemÅ”anos: tai bÅ«s cits identifikators, bet tas pats paraksts. Ar to paÅ”u identifikatoru mÄs izlaidÄ«sim attÄlu ražoÅ”anÄ.
TrÅ«kums ir tÄds, ka tagad nebÅ«s iespÄjams noteikt, kÄda veida saistÄ«bas tika virzÄ«tas uz ražoÅ”anu - kontrolsummas darbojas tikai vienÄ virzienÄ. Å o problÄmu atrisina papildu slÄnis ar metadatiem ā es jums pastÄstÄ«Å”u vairÄk vÄlÄk.
AtzÄ«mÄÅ”ana werf
werf mÄs gÄjÄm vÄl tÄlÄk un gatavojamies veikt izkliedÄtu bÅ«vÄÅ”anu ar keÅ”atmiÅu, kas netiek glabÄta vienÄ maŔīnÄ... TÄtad, mÄs veidojam divu veidu Docker attÄlus, mÄs tos saucam posms Šø attÄls.
werf Git repozitorijÄ tiek glabÄti bÅ«vÄjumam specifiski norÄdÄ«jumi, kas apraksta dažÄdus bÅ«vÄÅ”anas posmus (pirms instalÄÅ”anas, uzstÄdÄ«t, pirms iestatÄ«Å”anas, iestatÄ«Å”ana). MÄs apkopojam pirmÄ posma attÄlu ar parakstu, kas definÄts kÄ pirmo soļu kontrolsumma. Tad pievienojam pirmkodu, jaunajam skatuves attÄlam aprÄÄ·inÄm tÄ kontrolsummu... Å Ä«s darbÄ«bas atkÄrtojas visiem posmiem, kÄ rezultÄtÄ iegÅ«stam skatuves attÄlu kopu. Tad mÄs izveidojam galÄ«go attÄlu, kurÄ ir arÄ« metadati par tÄ izcelsmi. Un mÄs atzÄ«mÄjam Å”o attÄlu dažÄdos veidos (sÄ«kÄka informÄcija vÄlÄk).
PieÅemsim, ka pÄc tam parÄdÄs jauna apÅemÅ”anÄs, kurÄ ir mainÄ«ts tikai lietojumprogrammas kods. Kas notiks? Koda izmaiÅÄm tiks izveidots ielÄps un sagatavots jauns skatuves attÄls. TÄs paraksts tiks noteikts kÄ vecÄ skatuves tÄla un jaunÄ ielÄpa kontrolsumma. No Ŕī attÄla tiks izveidots jauns galÄ«gais attÄls. LÄ«dzÄ«ga uzvedÄ«ba notiks ar izmaiÅÄm citos posmos.
TÄdÄjÄdi skatuves attÄli ir keÅ”atmiÅa, kuru var glabÄt izplatÄ«ti, un no tÄs jau izveidotie attÄli tiek augÅ”upielÄdÄti Docker reÄ£istrÄ.
Reģistra tīrīŔana
MÄs nerunÄjam par slÄÅu dzÄÅ”anu, kas palika karÄjuÅ”ies pÄc dzÄstiem tagiem - tÄ ir paÅ”a Docker reÄ£istra standarta funkcija. MÄs runÄjam par situÄciju, kad sakrÄjas daudz Docker tagu un saprotam, ka daļa no tiem mums vairs nav vajadzÄ«gi, bet tie aizÅem vietu (un/vai mÄs par to maksÄjam).
KÄdas ir tÄ«rÄ«Å”anas stratÄÄ£ijas?
- JÅ«s varat vienkÄrÅ”i neko nedarÄ«t netÄ«rÄ«t. ReizÄm patieÅ”Äm ir vieglÄk nedaudz samaksÄt par papildu vietu, nekÄ izjaukt milzÄ«gu tagu mudžekli. Bet tas darbojas tikai lÄ«dz noteiktam brÄ«dim.
- PilnÄ«ga atiestatÄ«Å”ana. Ja izdzÄÅ”at visus attÄlus un atjaunojat tikai paÅ”reizÄjos attÄlus CI sistÄmÄ, var rasties problÄma. Ja konteiners tiek restartÄts ražoÅ”anÄ, tam tiks ielÄdÄts jauns attÄls - tÄds, kuru vÄl neviens nav pÄrbaudÄ«jis. Tas nogalina ideju par nemainÄ«gu infrastruktÅ«ru.
- Zils zaļŔ. Viens reÄ£istrs sÄka pÄrpildÄ«t - mÄs augÅ”upielÄdÄjam attÄlus citÄ. TÄda pati problÄma kÄ iepriekÅ”ÄjÄ metodÄ: kurÄ brÄ«dÄ« jÅ«s varat notÄ«rÄ«t reÄ£istru, kas ir sÄcis pÄrpildÄ«t?
- Ar laiku. Vai dzÄst visus attÄlus, kas vecÄki par 1 mÄnesi? Bet noteikti bÅ«s kÄds serviss, kas mÄnesi nav atjauninÄts...
- ar rokÄm noteikt, ko jau var izdzÄst.
Ir divas patiesi dzÄ«votspÄjÄ«gas iespÄjas: netÄ«rÄ«t vai zili zaļa + kombinÄcija manuÄli. PÄdÄjÄ gadÄ«jumÄ mÄs runÄjam par sekojoÅ”o: kad saprotat, ka ir pienÄcis laiks tÄ«rÄ«t reÄ£istru, izveidojiet jaunu un pievienojiet tam visus jaunos attÄlus, piemÄram, mÄneÅ”a laikÄ. Un pÄc mÄneÅ”a skatiet, kuri Kubernetes podi joprojÄm izmanto veco reÄ£istru, un pÄrsÅ«tiet tos arÄ« uz jauno reÄ£istru.
Pie kÄ esam nonÄkuÅ”i werf? MÄs savÄcam:
- Git head: visi tagi, visi zari - pieÅemot, ka mums ir nepiecieÅ”ams viss, kas attÄlos ir atzÄ«mÄts Git (un ja nÄ, tad mums tas ir jÄizdzÄÅ” paÅ”Ä GitÄ);
- visas pÄkstis, kas Å”obrÄ«d tiek izsÅ«knÄtas uz Kubernetes;
- vecie ReplicaSets (kas nesen tika izlaists), un mÄs arÄ« plÄnojam skenÄt Helm izlaidumus un atlasÄ«t tur jaunÄkos attÄlus.
... un izveidojiet balto sarakstu no Ŕīs kopas - attÄlu sarakstu, kurus mÄs neizdzÄsÄ«sim. MÄs iztÄ«rÄm visu pÄrÄjo, pÄc tam atrodam bÄreÅu skatuves attÄlus un arÄ« tos izdzÄÅ”am.
IzvietoŔanas stadija
Uzticama deklarativitÄte
Pirmais punkts, kam vÄlos pievÄrst uzmanÄ«bu izvietoÅ”anÄ, ir atjauninÄtÄs resursa konfigurÄcijas izvÄrÅ”ana, kas deklaratÄ«vi deklarÄta. SÄkotnÄjais YAML dokuments, kurÄ aprakstÄ«ti Kubernetes resursi, vienmÄr ļoti atŔķiras no rezultÄta, kas faktiski darbojas klasterÄ«. TÄ kÄ Kubernetes papildina konfigurÄciju:
- identifikatori;
- pakalpojumu informÄcija;
- daudzas noklusÄjuma vÄrtÄ«bas;
- sadaļa ar paÅ”reizÄjo statusu;
- izmaiÅas, kas veiktas uzÅemÅ”anas tÄ«mekļa aizÄ·eres ietvaros;
- dažÄdu kontrolieru (un plÄnotÄja) darba rezultÄts.
TÄpÄc, kad parÄdÄs jauna resursa konfigurÄcija (jauns), mÄs nevaram vienkÄrÅ”i Åemt un pÄrrakstÄ«t paÅ”reizÄjo, ātieÅ”oā konfigurÄciju ar to (dzÄ«vot). Lai to izdarÄ«tu, mums bÅ«s jÄsalÄ«dzina jauns ar pÄdÄjo lietoto konfigurÄciju (pÄdÄjo reizi lietots) un ritiniet uz dzÄ«vot saÅÄma plÄksteri.
Å o pieeju sauc Divvirzienu sapludinÄÅ”ana. To lieto, piemÄram, HelmÄ.
Ir arÄ« Divvirzienu sapludinÄÅ”ana, kas atŔķiras ar to:
- salÄ«dzinot pÄdÄjo reizi lietots Šø jauns, mÄs skatÄmies, kas tika izdzÄsts;
- salÄ«dzinot jauns Šø dzÄ«vot, mÄs skatÄmies, kas ir pievienots vai mainÄ«ts;
- uzlikts summÄtais plÄksteris dzÄ«vot.
Ar Helm mÄs izvietojam vairÄk nekÄ 1000 lietojumprogrammu, tÄpÄc mÄs faktiski izmantojam divvirzienu sapludinÄÅ”anu. TomÄr tam ir vairÄkas problÄmas, kuras esam atrisinÄjuÅ”i ar saviem ielÄpiem, kas palÄ«dz Helmam normÄli strÄdÄt.
ReÄls izlaiÅ”anas statuss
Kad mÅ«su CI sistÄma Ä£enerÄ jaunu Kubernetes konfigurÄciju, pamatojoties uz nÄkamo notikumu, tÄ nosÅ«ta to lietoÅ”anai (pieteikties) uz kopu - izmantojot Helm vai kubectl apply. TÄlÄk notiek jau aprakstÄ«tÄ N-way sapludinÄÅ”ana, uz kuru Kubernetes API apstiprinoÅ”i reaÄ£Ä uz CI sistÄmu un tÄ ā uz tÄs lietotÄju.
TomÄr ir milzÄ«ga problÄma: galu galÄ veiksmÄ«ga pieteikÅ”anÄs nenozÄ«mÄ veiksmÄ«gu izlaiÅ”anu. Ja Kubernetes saprot, kÄdas izmaiÅas ir jÄpiemÄro, un piemÄro tÄs, mÄs joprojÄm nezinÄm, kÄds bÅ«s rezultÄts. PiemÄram, podziÅu atjauninÄÅ”ana un restartÄÅ”ana priekÅ”galÄ var bÅ«t veiksmÄ«ga, bet ne aizmugursistÄmÄ, un mÄs iegÅ«sim dažÄdas darbojoÅ”os lietojumprogrammu attÄlu versijas.
Lai visu izdarÄ«tu pareizi, Å”ai shÄmai ir nepiecieÅ”ama papildu saite - Ä«paÅ”s izsekotÄjs, kas saÅems statusa informÄciju no Kubernetes API un pÄrsÅ«tÄ«s to tÄlÄkai lietas reÄlÄ stÄvokļa analÄ«zei. MÄs izveidojÄm atvÄrtÄ pirmkoda bibliotÄku pakalpojumÄ Go - (skatiet tÄs paziÅojumu ), kas atrisina Å”o problÄmu un ir iebÅ«vÄts werf.
Å Ä« izsekotÄja darbÄ«ba werf lÄ«menÄ« tiek konfigurÄta, izmantojot anotÄcijas, kas tiek ievietotas izvietojumos vai StatefulSets. GalvenÄ anotÄcija - fail-mode - saprot Å”Ädas nozÄ«mes:
-
IgnoreAndContinueDeployProcessā mÄs ignorÄjam Ŕīs sastÄvdaļas ievieÅ”anas problÄmas un turpinÄm izvÄrÅ”anu; -
FailWholeDeployProcessImmediatelyā kļūda Å”ajÄ komponentÄ aptur izvietoÅ”anas procesu; -
HopeUntilEndOfDeployProcessā mÄs ceram, ka Å”is komponents darbosies lÄ«dz izvietoÅ”anas beigÄm.
PiemÄram, Ŕī resursu un anotÄcijas vÄrtÄ«bu kombinÄcija fail-mode:
Kad mÄs izvietojam pirmo reizi, datubÄze (MongoDB) var vÄl nebÅ«t gatava ā izvietoÅ”ana neizdosies. Bet jÅ«s varat gaidÄ«t brÄ«di, kad tas sÄksies, un izvietoÅ”ana joprojÄm notiks.
Ir vÄl divas anotÄcijas kubedog in werf:
-
failures-allowed-per-replicaā katras kopijas pieļaujamo kritienu skaits; -
show-logs-untilā regulÄ brÄ«di, lÄ«dz kuram werf rÄda (in stdout) baļķus no visÄm izritinÄtajÄm pÄkstÄ«m. NoklusÄjums irPodIsReady(lai ignorÄtu ziÅojumus, kurus mÄs, iespÄjams, nevÄlamies, kad satiksme sÄk plÅ«st uz podziÅu), taÄu ir derÄ«gas arÄ« vÄrtÄ«bas:ControllerIsReadyŠøEndOfDeploy.
Ko vÄl mÄs vÄlamies no izvietoÅ”anas?
Papildus diviem jau aprakstÄ«tajiem punktiem mÄs vÄlÄtos:
- redzÄt baļķi - un tikai nepiecieÅ”amÄs, un ne visu pÄc kÄrtas;
- dziesmu progresu, jo, ja darbs āpa klusoā karÄjas vairÄkas minÅ«tes, ir svarÄ«gi saprast, kas tur notiek;
- ir automÄtiska atgrieÅ”ana ja kaut kas nogÄja greizi (un tÄpÄc ir ļoti svarÄ«gi zinÄt izvietoÅ”anas patieso statusu). IzlaiÅ”anai ir jÄbÅ«t kodolÄ«gai: vai nu tas iet lÄ«dz galam, vai arÄ« viss atgriežas iepriekÅ”ÄjÄ stÄvoklÄ«.
RezultÄti
Mums kÄ uzÅÄmumam, lai ieviestu visas aprakstÄ«tÄs nianses dažÄdos piegÄdes posmos (veidot, publicÄt, izvietot), pietiek ar CI sistÄmu un utilÄ«tu .
SecinÄjuma vietÄ:
Ar werf palÄ«dzÄ«bu mÄs esam guvuÅ”i labus panÄkumus daudzu DevOps inženieru problÄmu risinÄÅ”anÄ un bÅ«tu priecÄ«gi, ja plaÅ”Äka sabiedrÄ«ba vismaz izmÄÄ£inÄtu Å”o utilÄ«tu darbÄ«bÄ. KopÄ bÅ«s vieglÄk sasniegt labu rezultÄtu.
Videoklipi un slaidi
Video no izrÄdes (~47 minÅ«tes):
ZiÅojuma prezentÄcija:
PS
Citi ziÅojumi par Kubernetes mÅ«su emuÄrÄ:
- Ā«Ā» (Dmitrijs Stoļarovs; 27. gada 2019. aprÄ«lis kanÄlÄ āStreiksā);
- Ā«Ā» (Andrijs Polovs; 8. gada 2019. aprÄ«lis pakalpojumÄ Saint HighLoad++);
- Ā«Ā» (Dmitrijs Stoļarovs; 8. gada 2018. novembris vietnÄ HighLoad++);
- Ā«Ā» (Dmitrijs Stoļarovs; 28. gada 2018. maijÄ, RootConf);
- Ā«Ā» (Dmitrijs Stoļarovs; 7. gada 2017. novembris vietnÄ HighLoad++);
- Ā«Ā» (Dmitrijs Stoļarovs; 6. gada 2017. jÅ«nijs, RootConf).
Avots: www.habr.com