ProHoster > Blog > Administrimi > werf — mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes (pĂ«rmbledhje dhe video kĂ«rkese)

werf — mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes (pĂ«rmbledhje dhe video kĂ«rkese)

MĂ« 27 maj nĂ« sallĂ«n kryesore tĂ« konferencĂ«s DevOpsConf 2019, qĂ« zhvillohet brenda festivalit RIT++ 2019, nĂ« seksionin "ÇdoherĂ« nĂ« DĂ«rgesĂ«", u prezantua referati "werf - mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes". Aty diskutohet pĂ«r problemet dhe sfidat me tĂ« cilat pĂ«rballet çdo njeri gjatĂ« dĂ«rgimit nĂ« Kubernetes, po ashtu si dhe pĂ«r nuancat qĂ« mund tĂ« mos duken menjĂ«herĂ«. Duke analizuar mundĂ«sitĂ« e zgjidhjes, ne tregojmĂ« se si Ă«shtĂ« realizuar nĂ« mjetin Open Source werf.

QĂ« nga ajo paraqitje, utilitari ynĂ« (mĂ« parĂ« i njohur si dapp) ka kaluar pragun historik tĂ« 1000 yjeve nĂ« GitHub — shpresojmĂ« se komuniteti nĂ« rritje i pĂ«rdoruesve do t'i lehtĂ«sojĂ« jetĂ«n shumĂ« inxhinierĂ«ve DevOps.

werf — mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes (pĂ«rmbledhje dhe video kĂ«rkese)

Pra, prezantojmë video me referatin (~47 minuta, shumë më informuese se një artikull) dhe një përmbledhje të saj në formë tekstuale. Le të fillojmë!

Dërgimi i kodit në Kubernetes

NĂ« kĂ«tĂ« referat, do tĂ« flitet mĂ« sĂ« shumti jo pĂ«r werf, por pĂ«r CI/CD nĂ« Kubernetes, duke supozuar se softi ynĂ« Ă«shtĂ« paketuar nĂ« konteinerĂ« Docker (pĂ«r kĂ«tĂ« kam folur nĂ« referatin e vitit 2016), dhe K8s do tĂ« pĂ«rdoret pĂ«r ta nisur nĂ« prodhim (pĂ«r kĂ«tĂ« — nĂ« vitin 2017).

Si duket dërgimi në Kubernetes?

  • Ekziston njĂ« repo Git me kodin dhe udhĂ«zimet pĂ«r ndĂ«rtimin e tij. Aplikacioni ndĂ«rtohet nĂ« njĂ« imazh Docker dhe publikohet nĂ« Docker Registry.
  • NĂ« tĂ« njĂ«jtĂ«n repo ka udhĂ«zime gjithashtu pĂ«r si tĂ« dĂ«rgohet dhe tĂ« nisĂ« aplikacioni. NĂ« fazĂ«n e dĂ«rgimit, kĂ«to udhĂ«zime dĂ«rgohen nĂ« Kubernetes, i cili merr imazhin e nevojshĂ«m nga registry dhe e nis atĂ«.
  • PĂ«r mĂ« tepĂ«r, zakonisht ka teste. Disa prej tyre mund tĂ« ekzekutohen gjatĂ« publikimit tĂ« imazhit. Gjithashtu, mund tĂ« (sipĂ«rmarrĂ« nga tĂ« njĂ«jtat udhĂ«zime) tĂ« zhvillohet njĂ« kopje tĂ« aplikacionit (nĂ« njĂ« hapĂ«sirĂ« emrash K8s ose njĂ« klasĂ«r tĂ« veçantĂ«) dhe tĂ« ekzekutohen testet aty.
  • MĂ« nĂ« fund, nevoja pĂ«r njĂ« sistem CI, i cili merr ngjarjet nga Git (ose shtypjen e dĂŒtyrave) dhe thĂ«rret tĂ« gjitha fazat e caktuara: ndĂ«rtim, publikim, dĂ«rgim, testim.

werf — mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes (pĂ«rmbledhje dhe video kĂ«rkese)

Këtu janë disa vërejtje të rëndësishme:

  1. Pasi kemi një infrastrukturë të pandryshueshme (infrastructure e pandryshueshme), imazhi i aplikacionit, që përdoret në të gjitha fazat (staging, prodhim, etj.), duhet të jetë një. Për më shumë rreth kësaj dhe me shembuj, kam folur këtu.
  2. Pasi ndjekim qasjen e infrastrukturĂ«s si kod (IaC), kodi i aplikacionit, udhĂ«zimet pĂ«r ndĂ«rtimin dhe nisjen e tij duhet tĂ« jenĂ« pikĂ«risht nĂ« njĂ« repo. PĂ«r mĂ« shumĂ« rreth kĂ«saj — shihni nĂ« atĂ« referat.
  3. TĂ« gjitha fazat e dĂ«rgimit (delivery) ne zakonisht i shohim si tĂ« tilla: aplikacioni u ndĂ«rtua, u testua, u publikua (fazĂ«n e publikimit) dhe kjo — dĂ«rgimi u realizua. Por nĂ« tĂ« vĂ«rtetĂ«, pĂ«rdoruesi merr atĂ« qĂ« ju nxorrĂ«t, nuk atĂ«herĂ« kur ju e dĂ«rguat nĂ« prodhim, dhe kur ai arriti tĂ« hyjĂ« atje dhe ai prodhim funksiononte. Prandaj, unĂ« mendoj se zinxhiri i dĂ«rgimit pĂ«rfundon vetĂ«m nĂ« fazĂ«n e operimit (running), dhe nĂ«se flasim me saktĂ«si, edhe nĂ« momentin kur kodi u hoq nga prodhimi (duke e zĂ«vendĂ«suar atĂ« me njĂ« tĂ« ri).

Le të kthehemi në skemën e dërgimit në Kubernetes të përmendur më lart: ajo nuk është shpikur vetëm nga ne, por nga çdo njeri që është marrë me këtë problem. Faktikisht, ky model tani njihet si GitOps (për më shumë rreth termit dhe ideve që qëndrojnë pas tij, mund të lexoni këtu). Le të shikojmë fazat e skemës.

Faza e ndërtimit

(build) docker build?.. Đ’ĐŸŃ‚ ĐœŃŽĐ°ĐœŃŃ‹, ĐœĐ° ĐșĐŸŃ‚ĐŸŃ€Ń‹Đ” Ń…ĐŸŃ‚Đ”Đ»ĐŸŃŃŒ бы ĐŸĐ±Ń€Đ°Ń‚ĐžŃ‚ŃŒ ĐČĐœĐžĐŒĐ°ĐœĐžĐ”:

  1. Duket se çfarë mund të thuhet në vitin 2019 rreth ndërtimit të imazheve Docker, kur të gjithë dinë të shkruajnë Dockerfile dhe të ekzekutojnë Pesha e imazhit ka rëndësi, prandaj përdornimulti-stage
  2. , për të lënë vetëm ata që janë vërtet të nevojshëm për funksionimin e aplikacionit. Numri i shtresave RUNduhet të jetë minimal, duke bashkuar zinxhirët e
  3. komandave sipas kuptimit. Megjithatë, kjo sjell problemegjatë depurimit
  4. , pasi kur ndodhin gabime në ndërtim, është e nevojshme të gjendet komandë të caktuar nga zinxhiri që shkaktoi problemin. Shpejtësia e ndërtimit
  5. është e rëndësishme, sepse ne duam të nxjerrim shpejt ndryshimet dhe të shohim rezultatet. Për shembull, nuk dëshirojmë të ribëjmë varësitë në bibliotekat e gjuhës me çdo ndërtim të aplikacionit. Shpesh nga një repo Git kërkohenshumë imazhe

, që mund të zgjidhet me një grup Dockerfile-in (ose me etapa të emërtuara brenda një skedari) dhe me skript Bash për ndërtimin e tyre në radhë.

  1. Kjo ishte vetëm maja e ajsbergut, me të cilin përballen të gjithë. Por ka edhe probleme të tjera, veçanërisht: Shpesh gjatë fazës së ndërtimit kemi nevojë të montohemi
  2. (për shembull, për të ruajtur rezultatin e komandës si apt në një direktore të jashtme). Ansible Ne duam
  3. (për shembull, për të ruajtur rezultatin e komandës si apt në një direktore të jashtme). të vendosim për të shkruar në Shell, të ndërtojmë pa Docker
  4. (pse të kemi një makinë virtuale të tepërt, ku duhet të konfigurohen të gjitha për këtë, kur është një klasër Kubernetes që mund të nisë konteinerët?).Ndërtimi Paralel
  5. , i cili mund tĂ« kuptohet nĂ« mĂ«nyra tĂ« ndryshme: komanda tĂ« ndryshme nga Dockerfile (nĂ«se pĂ«rdoret multi-stage), disa komitete nga njĂ« repo, disa Dockerfile.: dĂ«shirojmĂ« tĂ« mbledhim diçka nĂ« pod’ nĂ« mĂ«nyrĂ« tĂ« pĂ«rkohshme, pasi ata humbin cache-n, dhe pĂ«r kĂ«tĂ« arsye — duhet ta ruajmĂ« diku ndryshe.
  6. Së fundmi, e quajta kulmin e dëshirave automagji: do të ishte ideale të hysh në depo, të shkruash një komandë dhe të marrësh një imazh të gatshëm, të ndërtuar me kuptimin e asaj si duhet bërë. Megjithatë, personalisht nuk jam i sigurt se të gjitha nuancat mund të parashikohen kështu.

Dhe kështu ka projekte:

  • moby/buildkit — njĂ« ndĂ«rtues nga kompania Docker Inc (qĂ« tashmĂ« Ă«shtĂ« integruar nĂ« versionet aktuale tĂ« Docker), e cila pĂ«rpiqet tĂ« zgjidhĂ« tĂ« gjitha kĂ«to probleme;
  • kaniko — njĂ« ndĂ«rtues nga Google, qĂ« lejon ndĂ«rtimin pa Docker;
  • Buildpacks.io — pĂ«rpjekja e CNCF pĂ«r tĂ« bĂ«rĂ« automagji dhe, nĂ« veçanti, njĂ« zgjidhje interesante me rebase pĂ«r shtresa;
  • dhe shumĂ« utilitete tĂ« tjera si buildah, genuinetools/img



 dhe shikoni sa yje kanĂ« nĂ« GitHub. Pra, nga njĂ«ra anĂ«, docker build ka dhe mund tĂ« bĂ«jĂ« diçka, por nĂ« tĂ« vĂ«rtetĂ« pyetja nuk Ă«shtĂ« zgjidhur plotĂ«sisht — njĂ« provĂ« pĂ«r kĂ«tĂ« Ă«shtĂ« zhvillimi paralel i ndĂ«rtuesve alternativĂ«, secili prej tĂ« cilĂ«ve zgjidh njĂ« pjesĂ« tĂ« problemeve.

Ndërtimi në werf

KĂ«shtu arritĂ«m tek werf (mĂ« parĂ« i njohur si dapp) — njĂ« mjet Open Source nga kompania Flant, tĂ« cilin e kemi bĂ«rĂ« pĂ«r shumĂ« vite. E gjithĂ« kjo filloi 5 vjet mĂ« parĂ« me skripte Bash, tĂ« cilat optimizuan ndĂ«rtimin e Dockerfile, dhe tre vitet e fundit zhvillohet nĂ« njĂ« projekt tĂ« plotĂ« me njĂ« depo Git (fillimisht nĂ« Ruby, dhe mĂ« pas u riprogramua nĂ« Go, dhe po ashtu u riemĂ«rua). Cilat probleme ndĂ«rtimi zgjidhen nĂ« werf?

werf — mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes (pĂ«rmbledhje dhe video kĂ«rkese)

Problemet e theksuara me të bluara janë realizuar, ndërtimi paralel është bërë brenda një hosti, ndërsa pyetjet e theksuara me të verdhë planifikojmë t'i përfundojmë deri në fund të verës.

Faza e publikimit në registry (publish)

Kemi marrĂ« docker push
 — çfarĂ« mund tĂ« ketĂ« tĂ« vĂ«shtirĂ« nĂ« ngarkimin e njĂ« imazhi nĂ« registry? Dhe kĂ«tu lind pyetja: «Cili tag duhet t'i vihet imazhit?» Kjo lind pĂ«r shkak se kemi Gitflow (ose njĂ« strategji tjetĂ«r Git) dhe Kubernetes, dhe industria synon qĂ« çdo gjĂ« qĂ« ndodh nĂ« Kubernetes tĂ« ndjekĂ« atĂ« qĂ« bĂ«het nĂ« Git. Sepse Git Ă«shtĂ« burimi ynĂ« i vetĂ«m i sĂ« vĂ«rtetĂ«s.

ÇfarĂ« Ă«shtĂ« e vĂ«shtirĂ« nĂ« kĂ«tĂ«? TĂ« garantojmĂ« riprodhueshmĂ«rinĂ«: nga commit-i nĂ« Git, i cili natyrshĂ«m Ă«shtĂ« i pandryshueshĂ«m (immutable), deri nĂ« imazhin Docker, i cili duhet tĂ« mbetet i njĂ«jtĂ«.

ËshtĂ« gjithashtu e rĂ«ndĂ«sishme pĂ«r ne tĂ« pĂ«rcaktojmĂ« origjinĂ«n, sepse duam tĂ« kuptojmĂ« nga cili commit Ă«shtĂ« ndĂ«rtuar aplikacioni, i cili Ă«shtĂ« aktivizuar nĂ« Kubernetes (atĂ«herĂ« mund tĂ« bĂ«jmĂ« diff-e dhe gjĂ«ra tĂ« ngjashme).

Strategjitë e tag-imit

E para është e thjeshtë git tag.Kemi një registry me një imazh, i tag-uar si 1.0. Në Kubernetes ka stage dhe production, ku ky imazh është shkarkuar. Në Git ne bëjmë commit-e dhe në një moment i vendosim një tag 2.0. E ndërtuam atë sipas udhëzimeve nga depoja dhe e vendosëm në registry me tag-un 2.0. E shtojmë në stage dhe, nëse gjithçka shkon mirë, atëherë në production.

werf — mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes (pĂ«rmbledhje dhe video kĂ«rkese)

Problemi me këtë qasje është se ne fillimisht vendosëm një tag, dhe pastaj e testuam dhe e publikuan. Pse? Së pari, kjo është thjesht e pakuptimtë: ne lëshojmë një version të softuerit që nuk e kemi kontrolluar ende (nuk mund ta bëjmë ndryshe, sepse për ta verifikuar, kërkohet të vendosim një tag). Së dyti, ky rrugë nuk përputhet me Gitflow.

Variant i dytĂ« — git commit + tag.NĂ« degĂ«n master ka njĂ« tag 1.0; pĂ«r tĂ« nĂ« registry — njĂ« imazh, i vendosur nĂ« production. PĂ«rveç kĂ«saj, nĂ« Kubernetes-kluster ka konture preview dhe staging. MĂ« pas ne ndjekim Gitflow: nĂ« degĂ«n kryesore pĂ«r zhvillim (develop) bĂ«jmĂ« funksionalitete tĂ« reja, qĂ« rezultojnĂ« nĂ« njĂ« commit me identifikuesin #c1. Ne e ndĂ«rtuam atĂ« dhe e publikojmĂ« nĂ« registry, duke pĂ«rdorur kĂ«tĂ« identifikues (#c1). Me tĂ« njĂ«jtin identifikues e publikohet nĂ« preview. NĂ« mĂ«nyrĂ« tĂ« ngjashme e bĂ«jmĂ« me commit-et #c2 dhe #c3.

Kur kuptuam se ka mjaft funksionalitete, fillojmë të stabilizojmë gjithçka. Në Git krijojmë një degë release_1.1 (në bazë të #c3 nga develop). Nuk do të nevojitet ndërtimi i këtij rrelease, pasi kjo është bërë në fazën e kaluar. Prandaj mund të thjesht e publikojmë atë në staging. Rregullojmë bugs në #c4 dhe po ashtu e publikojmë në staging. Në të njëjtën kohë po vazhdon zhvillimi në develop, ku herë pas here kopjohen ndryshime nga release_1.1. Në një moment ne kemi një commit të ndërtuar dhe të lëshuar në staging, të cilin jemi të kënaqur me (#c25).

Atëherë bëjmë merge (me fast-forward) të degës së lëshimit (release_1.1) në master. Vendosim një tag në këtë commit me versionin e ri (1.1). Por ky imazh tashmë është ndërtuar në registry, prandaj, për të mos e ndërtuar atë sërish, ne thjesht shtojmë një tag të dytë në imazhin ekzistues (tani ai në registry ka tag-ët #c25 dhe 1.1). Pas kësaj e publikojmë në production.

Ka njĂ« mangĂ«si qĂ« nĂ« staging Ă«shtĂ« shkarkuar njĂ« imazh (#c25), ndĂ«rsa nĂ« production — dikush tjetĂ«r (1.1), por ne e dimĂ« qĂ« «fizikisht» ky Ă«shtĂ« i njĂ«jti imazh nga registry.

werf — mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes (pĂ«rmbledhje dhe video kĂ«rkese)

Mangësi e vërtetë është se nuk ka mbështetje për merge commits, duhet të bësh fast-forward.

Mund të shkojmë përpara dhe të bëjmë një truk... Le të shqyrtojmë shembullin e një Dockerfile të thjeshtë:

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

Do të ndërtosh një skedar sipas këtij parimi, që do të marrim:

  • SHA256 nga identifikuesit e imazheve tĂ« pĂ«rdorura (ruby:2.3 dhe nginx:alpine), qĂ« janĂ« kontrollet e pĂ«rmbajtjes sĂ« tyre;
  • tĂ« gjitha komandat (RUN, CMD etj.);
  • SHA256 nga skedarĂ«t qĂ« janĂ« shtuar.


 dhe do tĂ« marrim kontrollin e pĂ«rmbajtjes (sĂ«rish SHA256) nga njĂ« skedar tĂ« tillĂ«. Kjo Ă«shtĂ« nĂ«nshkrimi i gjithçkaje qĂ« pĂ«rcakton pĂ«rmbajtjen e imazhit Docker.

werf — mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes (pĂ«rmbledhje dhe video kĂ«rkese)

Të kthehemi te skema dhe në vend të komiteve do të përdorim këto nënshkrime, dmth. të etiketojmë imazhet me nënshkrime.

werf — mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes (pĂ«rmbledhje dhe video kĂ«rkese)

Tani, kur tĂ« nevojitet, pĂ«r shembull, tĂ« ‘bashkosh’ ndryshimet nga lĂ«shimi nĂ« master, mund tĂ« bĂ«jmĂ« njĂ« komit tĂ« vĂ«rtetĂ« tĂ« bashkimit: ai do tĂ« ketĂ« njĂ« identifikues tjetĂ«r, por tĂ« njĂ«jtin nĂ«nshkrim. Me tĂ« njĂ«jtin identifikues do tĂ« publikojmĂ« imazhin edhe nĂ« prodhim.

Disavantazhi Ă«shtĂ« se tani nuk do tĂ« mund tĂ« pĂ«rcaktojmĂ« se cilin komit e kemi hequr nĂ« prodhim — kontrollet punojnĂ« vetĂ«m nĂ« njĂ« drejtim. Ky problem zgjidhet me njĂ« shtresĂ« shtesĂ« me metadata — do tĂ« flas mĂ« shumĂ« mĂ« vonĂ«.

Etiketimi në werf

Në werf kemi shkuar edhe më tej dhe po përgatitemi për ndërtim të shpërndarë me cache, i cili nuk ruhet në një makinë vetëm
 Pra, ne po ndërtojmë imazhe Docker të dy llojeve, që i quajmë stage dhe image.

Në repo Git të werf ruhen instruksionet specifike për ndërtim, që përshkruajnë fazat e ndryshme të ndërtimit (beforeInstall, install, beforeSetup, setup). Faza e parë e imazhit e ndërtuar ka nënshkrimin e përcaktuar si kontrolli i hapave të parë. Më pas shtojmë kodin burimor, për imazhin e ri të fazës e llogarisim kontrollin e tij
 Këto operacione përsëriten për të gjitha fazat, duke rezultuar në një grup imazhesh të fazave. Më pas krijojmë imazhin përfundimtar, i cili gjithashtu përmban metadata mbi prejardhjen e tij. Dhe ky imazh e etiketojmë në mënyra të ndryshme (detaje më vonë).

werf — mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes (pĂ«rmbledhje dhe video kĂ«rkese)

Le tĂ« ndodhĂ« pas kĂ«saj njĂ« komit i ri, nĂ« tĂ« cilin Ă«shtĂ« ndryshuar vetĂ«m kodi i aplikacionit. ÇfarĂ« do tĂ« ndodhĂ«? PĂ«r ndryshimet nĂ« kod do tĂ« krijohet njĂ« patch, do tĂ« pĂ«rgatitet njĂ« imazh i ri i fazĂ«s. NĂ«nshkrimi i tij do tĂ« pĂ«rcaktohet si kontrolli i imazhit tĂ« vjetĂ«r tĂ« fazĂ«s dhe patches tĂ« ri. Nga ky imazh do tĂ« formohet edhe njĂ« imazh i ri pĂ«rfundimtar. NjĂ« sjellje e ngjashme do tĂ« ndodhĂ« pĂ«r ndryshimet nĂ« faza tĂ« tjera.

KĂ«shtu, imazhet e fazave — janĂ« cache qĂ« mund tĂ« ruhen nĂ« mĂ«nyrĂ« tĂ« shpĂ«rndarĂ«, ndĂ«rsa imazhet qĂ« krijohen nga ato ngarkohen nĂ« Docker Registry.

werf — mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes (pĂ«rmbledhje dhe video kĂ«rkese)

Pastrimi i registry

Kjo nuk ka tĂ« bĂ«jĂ« me ndalimin e shtresave qĂ« mbeten tĂ« varura pas etiketimeve tĂ« fshirĂ« — kjo Ă«shtĂ« njĂ« mundĂ«si standarde e vetĂ« Docker Registry. Kjo ka tĂ« bĂ«jĂ« me situatĂ«n kur akumulojnĂ« shumĂ« etiketa Docker dhe ne kuptojmĂ« se njĂ« pjesĂ« e tyre nuk na nevojitet mĂ«, por ato zĂ«nĂ« hapĂ«sirĂ« (dhe/ose ne paguajmĂ« pĂ«r tĂ«).

Cilat janë strategjitë e pastrimit?

  1. Mund të mos bësh asgjë në pastrim. Ndonjëherë është më e thjeshtë të paguash pak për hapësirë të tepërt sesa të deshifrosh një kafaz të madh me etiketa. Por kjo funksionon vetëm deri në një pikë të caktuar.
  2. Rikthimi i plotĂ«. NĂ«se fshihen tĂ« gjitha imazhet dhe rindĂ«rtohen vetĂ«m ato aktuale nĂ« sistemin CI, mund tĂ« ndodhĂ« njĂ« problem. NĂ«se njĂ« kontejner ri-renditet nĂ« prodhim, pĂ«r tĂ« do tĂ« ngarkohet njĂ« imazh i ri — njĂ« qĂ« nuk Ă«shtĂ« provuar nga askush. Kjo shkatĂ«rron idenĂ« e infrastrukturĂ«s tĂ« pakthyeshme.
  3. Blue-green. NjĂ« registry filloi tĂ« mbushej — ngarkojmĂ« imazhet nĂ« njĂ« tjetĂ«r. I njĂ«jti problem si nĂ« mĂ«nyrĂ«n e mĂ«parshme: nĂ« cilin moment mund tĂ« pastroni atĂ« registry qĂ« filloi tĂ« mbushej?
  4. Në kohë. Të fshihen të gjitha imazhet më të vjetra se 1 muaj? Por gjithmonë do të ketë një shërbim që nuk është azhurnuar për një muaj

  5. Dora dorës të përcaktojë se çfarë mund të fshihet.

Janë dy opsione realisht të shkëlqyera: të mos pastroni fare ose një kombinim i blue-green + manual. Në rastin e fundit kemi të bëjmë me këtë: kur kuptoni se është koha për të pastruar registry, krijoni një të re dhe shtoni të gjitha imazhet e reja në të gjatë, për shembull, një muaji. Dhe pas një muaji shikoni se cilat pod janë ende duke përdorur registry e vjetër në Kubernetes, dhe i kaloni ata gjithashtu në registry të ri.

KĂ«nduam nĂ« werf? Мы ŃĐŸĐ±ĐžŃ€Đ°Đ”ĐŒ:

  1. Git head: tĂ« gjitha etiketat, tĂ« gjitha degĂ«t, — duke supozuar se çdo gjĂ« qĂ« Ă«shtĂ« etiketuar nĂ« Git, na nevojitet dhe nĂ« imazhe (ndĂ«rsa nĂ«se jo, atĂ«herĂ« duhet ta fshijmĂ« nĂ« vetĂ« Git);
  2. tĂ« gjitha pod’ët qĂ« janĂ« shkarkuar aktualisht nĂ« Kubernetes;
  3. ReplicaSet më të vjetra (ato që sapo janë shkarkuar), ashtu si do të planifikojmë të skanojmë lëshimet Helm dhe të marrim imazhet më të fundit aty.


 dhe tĂ« bĂ«jmĂ« njĂ« listĂ« tĂ« zezĂ« nga ky grup — njĂ« listĂ« imazhesh qĂ« nuk do tĂ« fshijmĂ«. TĂ« gjitha tĂ« tjerat i pastrojmĂ«, dhe mĂ« pas gjejmĂ« imazhet e fazave jetim dhe i fshijmĂ« ato gjithashtu.

Faza e ndarjes (deploy)

Deklarativitet i besueshëm

Momentin e parë që duam të theksojmë në deploi është publikimi i konfiguracionit të përmirësuar të burimeve, i shpallur në mënyrë deklarative. Dokumenti origjinal YAML me përshkrimin e burimeve Kubernetes gjithmonë diferon ndjeshëm nga rezultati, i cili funksionon realisht në klaster. Kjo për shkak se Kubernetes shton në konfigurim:

  1. identifikuesit;
  2. informacionin shërbim;
  3. shumë vlera të paracaktuara;
  4. seksionin me statusin aktual;
  5. ndryshimet e bëra gjatë funksionimit të admission webhook;
  6. rezultatin e punës së kontrollorëve të ndryshëm (dhe planifikuesit).

Prandaj, kur shfaqet një konfigurim i ri burimi (e re), nuk mund ta marrim dhe ta shkruajmë përsëri konfigurimin aktual, "të gjallë", (live). Për këtë do të na duhet të krahasojmë e re me konfigurimin e kaluar të aplikuar ("last-applied") dhe të aplikojmë live patch-in e marrë.

Ky qasje quhet "2-way merge". Ai përdoret, për shembull, në Helm.

Ka edhe një "3-way merge", i cili ndryshon në atë që:

  • duke krahasuar "last-applied" dhe e re, shikojmĂ« çfarĂ« Ă«shtĂ« fshirĂ«;
  • duke krahasuar e re dhe live, shikojmĂ« çfarĂ« Ă«shtĂ« e shtuar ose ndryshuar;
  • patch-i i pĂ«rmbledhur aplikohet nĂ« live.

Ne përdorim mbi 1000 aplikacione me Helm, kështu që faktikisht jetojmë me "2-way merge". Megjithatë, ka disa probleme që i kemi zgjidhur me patch-et tona, që ndihmojnë Helm-in të funksionojë siç duhet.

Statusi aktual i publikimit

Pas ngjarjes sĂ« radhĂ«s, sistemi ynĂ« CI ka gjeneruar njĂ« konfigurim tĂ« ri pĂ«r Kubernetes, dhe ai e dĂ«rgon pĂ«r aplikim (apply) nĂ« klaster — pĂ«rmes Helm ose kubectl aplikoni. MĂ« pas ndodh "N-way merge", qĂ« Kubernetes API e miraton me kĂ«naqĂ«si pĂ«r sistemin CI, dhe ky i fundit pĂ«r pĂ«rdoruesin e tij.

werf — mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes (pĂ«rmbledhje dhe video kĂ«rkese)

MegjithatĂ«, ka njĂ« problem tĂ« madh: sepse njĂ« aplikim i suksesshĂ«m nuk do tĂ« thotĂ« njĂ« publikim tĂ« suksesshĂ«m.NĂ«se Kubernetes e kupton se çfarĂ« ndryshimesh duhet tĂ« aplikojĂ«, dhe e aplikon atĂ« — ne ende nuk e dimĂ« se çfarĂ« do tĂ« rezultojĂ«. PĂ«r shembull, pĂ«rditĂ«simi dhe rinisja e pod-ve nĂ« frontend mund tĂ« shkojnĂ« me sukses, ndĂ«rsa nĂ« backend ndoshta jo, dhe ne do tĂ« marrim versione tĂ« ndryshme tĂ« imazheve tĂ« aplikacionit tĂ« nisura.

PĂ«r tĂ« bĂ«rĂ« gjithçka siç duhet, nĂ« kĂ«tĂ« skemĂ« ndihmon njĂ« lidhĂ«s tĂ« veçantĂ« — njĂ« tracker i cili do tĂ« marrĂ« informacionin pĂ«r statusin nga Kubernetes API dhe do ta transmetojĂ« atĂ« pĂ«r analizĂ« tĂ« mĂ«tejshme tĂ« realitetit. Ne krijuam njĂ« bibliotekĂ« Open Source nĂ« Go — "kubedog" (shih njoftimin e saj kĂ«tu), — e cila e zgjidh kĂ«tĂ« problem dhe Ă«shtĂ« e integruar nĂ« werf.

Komportimi i kĂ«tij tracker-i nĂ« nivelin e werf konfigurohet pĂ«rmes anotacioneve, tĂ« cilat vendosen nĂ« Deployments ose StatefulSets. Anotacioni kryesor — "fail-mode" kupton vlerat e mĂ«poshtme:

  • "IgnoreAndContinueDeployProcess" — injorojmĂ« problemet e publikimit tĂ« kĂ«tij komponenti dhe vazhdojmĂ« me publikimin;
  • "FailWholeDeployProcessImmediately" — njĂ« gabim nĂ« kĂ«tĂ« komponent ndalon procesin e publikimit;
  • "HopeUntilEndOfDeployProcess" — shpresojmĂ« se ky komponent do tĂ« funksionojĂ« deri nĂ« fund tĂ« publikimit.

Për shembull, një kombinim i tillë i burimeve dhe vlerave të anotacionit "fail-mode":

werf — mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes (pĂ«rmbledhje dhe video kĂ«rkese)

Kur publikojmĂ« pĂ«r herĂ« tĂ« parĂ«, baza e tĂ« dhĂ«nave (MongoDB) mund tĂ« mos jetĂ« e gatshme — Deployment-et do tĂ« dĂ«shtojnĂ«. Por mund tĂ« presim qĂ« ajo tĂ« ndizet, dhe publikimi gjithsesi do tĂ« kalojĂ«.

Ka edhe dy anotacione për kubedog në werf:

  • "failures-allowed-per-replica" — numri i dĂ«shtimeve tĂ« lejuara pĂ«r çdo replikĂ«;
  • "show-logs-until" — rregullon momentin deri nĂ« tĂ« cilin werf tregon (nĂ« stdout) log-et nga tĂ« gjithĂ« pod-et qĂ« po publikohen. Sipas parazgjedhjes kjo Ă«shtĂ« "PodIsReady" (pĂ«r tĂ« injoruar mesazhet, qĂ« ndoshta nuk na nevojiten, kur pod-i fillon tĂ« merr trafik), megjithatĂ« janĂ« tĂ« lejuara edhe vlera si "ControllerIsReady" dhe "EndOfDeploy".

ÇfarĂ« tjetĂ«r duam nga publikimi?

Përveç dy pikave të përshkruara më parë, ne do të dëshironim:

  • tĂ« shohim log-et — dhe vetĂ«m ato tĂ« nevojshme, e jo tĂ« gjitha;
  • tĂ« ndjekim progresin,sepse nĂ«se njĂ« punĂ« "nuk reagon" pĂ«r disa minuta, Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« kuptojmĂ« se çfarĂ« po ndodh;
  • tĂ« kemi rrotullim automatik nĂ«se ndodhi ndonjĂ« problem (dhe pĂ«r kĂ«tĂ« Ă«shtĂ« kritike tĂ« dihet statusi real i publikimit). Publikimi duhet tĂ« jetĂ« atomar: ose pĂ«rfundon deri nĂ« fund, ose gjithçka kthehet nĂ« gjendjen e mĂ«parshme.

PĂ«rfundimet

Ne si kompani për realizimin e të gjitha nuancave të përshkruara në faza të ndryshme të dërgimit (ndërtimi, publikimi, publikimi) kemi nevojë për një sistem CI dhe utilitarin werf.

Në përfundim:

werf — mjeti ynĂ« pĂ«r CI/CD nĂ« Kubernetes (pĂ«rmbledhje dhe video kĂ«rkese)

Me ndihmën e werf kemi bërë përparim të mirë në zgjidhjen e një numri të madh problemesh për inxhinierët DevOps dhe do të ishim të lumtur nëse një komunitet më i gjerë të paktën ta provojë këtë utilitar në veprim. Të arrihet një rezultat i mirë së bashku do të jetë më e lehtë.

Video dhe prezentime

Video e prezantimit (~47 minuta):

Luaj videon

Prezantimi i referatit:

P.S.

Prezantime të tjera mbi Kubernetes në blogun tonë:

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster