
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ë 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ë 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.yamlThelbi 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: myappBurimet 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=5Tani 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=1Ja, 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 dhe te . Grafikat e Helm që përdoren për të realizuar metodën e përshkruar më sipër ndodhen në GitHub, . 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
