Një mënyrë e thjeshtë dhe e sigurt për automatizimin e deployve kanar nëpërmjet Helm

Një mënyrë e thjeshtë dhe e sigurt për automatizimin e deployve kanar nëpërmjet Helm

Deployimi kanadever është një mënyrë shumë efektive për të testuar kodin e ri mbi një nëngrup të caktuar përdoruesish. Ai redukton ndjeshëm ngarkesën e trafikut, e cila mund të shkaktojë probleme gjatë procesit të zbatimit, pasi ndodh vetëm brenda një nëngrupi të caktuar. Ky shënim i kushtohet mënyrës se si të organizoni një deploy të tillë duke përdorur Kubernetes dhe automatizimin e deploy-it. Supozoni se dini disa gjëra mbi Helm dhe burimet e Kubernetes..

Një mënyrë e thjeshtë dhe e sigurt për automatizimin e deployve kanar nëpërmjet Helm

Një deploy i thjeshtë kanadever në Kubernetes përfshin dy burime kyçe: shërbimin vetë dhe mjetin e zbatimit. Deployimi kanadever funksionon përmes një shërbimi, i cili ndërvepron me dy burime të ndryshme që shërbejnë trafikun e azhurnimit. Një prej këtyre burimeve do të punojë me versionin "kanadever", ndërsa tjetri me versionin e qëndrueshëm. Në këtë situatë, ne mund ta rregullojmë numrin e versioneve kanadever për të reduktuar volumet e trafikut që nevojitet për t'u shërbyer. Nëse, për shembull, preferoni të përdorni Yaml, atëherë në Kubernetes do të duket kështu:

lloji: Zhvillim
metadata:
  emri: app-canary
  etiketat:
    app: app
spec:
  replika: 1
  ...
    imazhi: myapp:canary
---
lloji: Zhvillim
metadata:
  emri: app
  etiketat:
    app: app
spec:
  replika: 5
  ...
    imazhi: myapp:stable
---
lloji: Shërbim
selekton:
  app: app # Selektoni do të drejtojë trafikun në të dy zhvillimet.

Edhe më thjeshtë mund të paraqitet një variant i tillë në kubectl, dhe në dokumentacionin për Kubernetes madje ka një udhëzues të plotë për këtë skenar. Por pyetja kryesore e këtij postimi është se si do ta automatizojmë këtë proces, duke përdorur Helm.

Automatizimi i lançimit kanar

Së pari, do të na nevojitet një hartë chart-esh Helm, në të cilën janë përfshirë burimet që diskutëm më sipër. Ajo duhet të duket më pak kështu:

~/charts/app
├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

Thelbi i konceptit tĂ« Helm — menaxhimi i shumĂ«versioneve tĂ« lĂ«shimeve. Versioni Stable Ă«shtĂ« degĂ«za jonĂ« e stabilizuar e kodit tĂ« projektit. Por me ndihmĂ«n e Helm mund tĂ« lĂ«shojmĂ« njĂ« version kanar me kodin tonĂ« eksperimental. E rĂ«ndĂ«sishme Ă«shtĂ« tĂ« ruajmĂ« shkĂ«mbimin e trafikut midis versionit tĂ« qĂ«ndrueshĂ«m dhe versionit kanar. Ne do ta menaxhojmĂ« tĂ« gjithĂ« kĂ«tĂ« me njĂ« selektor tĂ« veçantĂ«:

selektoni:
  app.kubernetes.io/name: myapp

Burimet tona të deploy-it, si «kanare» ashtu edhe të stabilit, do të tregojnë këtë etiketë në module. Nëse gjithçka është konfiguruar siç duhet, gjatë deploy-it të versionit kanare të hartës sonë Helm, ne do të shohim që trafik do të drejtohet te modulat e sapoimplementuara. Versioni stabil i kësaj komande do të duket kështu:

helm upgrade
  --install myapp 
  --namespace default 
  --set app.name=myapp       # Shkon në app.kubernetes.io/name
  --set app.version=v1       # Shkon në app.kubernetes.io/version
  --set image.tag=stable 
  --set replicaCount=5

Tani le të kontrollojmë versionin tonë kanare. Për të implementuar versionin kanare, duhet të mbajmë mend dy gjëra. Emri i lëshimit duhet të jetë i ndryshëm, në mënyrë që të mos kryejmë një azhurnim në versionin aktual stabil. Versioni dhe etiketat gjithashtu duhet të jenë të ndryshme, në mënyrë që të mund të implementojmë kod tjetër dhe të përcaktojmë ndryshimet sipas etiketave të burimeve.

helm upgrade
  --install myapp-canary 
  --namespace default 
  --set app.name=myapp       # Shkon në app.kubernetes.io/name
  --set app.version=v2       # Shkon në app.kubernetes.io/version
  --set image.tag=canary 
  --set replicaCount=1

Ja, në fakt, kjo është gjithçka! Nëse pingoni shërbimin, mund të shihni se përditësimi kanare drejtton trafik vetëm për një pjesë të kohës.

Nëse po kërkoni mjete për automatizimin e shpërndarjes që përfshijnë logjikën e përshkruar, shkoni te Deliverybot dhe te mjetet për automatizimin e Helm në GitHub. Grafikat e Helm që përdoren për të realizuar metodën e përshkruar më sipër ndodhen në GitHub, këtu. Në përgjithësi, ky ishte një përmbledhje teorike mbi atë se si të realizoni automatizimin e shpërndarjes së versioneve kanar, me koncepte dhe shembuj konkretë.

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster