Isang simple at secure na paraan upang i-automate ang mga deployment ng canary gamit ang Helm

Isang simple at secure na paraan upang i-automate ang mga deployment ng canary gamit ang Helm

Ang pag-deploy ng Canary ay isang napaka-epektibong paraan upang subukan ang bagong code sa isang subset ng mga user. Lubos nitong binabawasan ang pagkarga ng trapiko na maaaring maging problema sa panahon ng proseso ng pag-deploy, dahil nangyayari lamang ito sa loob ng isang partikular na subset. Ang tala na ito ay nakatuon sa kung paano ayusin ang naturang deployment gamit ang Kubernetes at deployment automation. Ipinapalagay namin na may alam ka tungkol sa mga mapagkukunan ng Helm at Kubernetes.

Isang simple at secure na paraan upang i-automate ang mga deployment ng canary gamit ang Helm

Ang isang simpleng canary deployment sa Kubernetes ay may kasamang dalawang pangunahing mapagkukunan: ang serbisyo mismo at ang deployment tool. Gumagana ang pag-deploy ng Canary sa pamamagitan ng iisang serbisyo na nakikipag-ugnayan sa dalawang magkaibang mapagkukunan na naghahatid ng trapiko sa pag-update. Ang isa sa mga mapagkukunang ito ay gagana sa "canary" na bersyon, at ang pangalawa ay gagana sa matatag na bersyon. Sa sitwasyong ito, maaari naming i-regulate ang bilang ng mga bersyon ng canary upang mabawasan ang dami ng trapiko na kinakailangan upang maihatid. Kung, halimbawa, mas gusto mong gumamit ng Yaml, magiging ganito ito sa Kubernetes:

kind: Deployment
metadata:
  name: app-canary
  labels:
    app: app
spec:
  replicas: 1
  ...
    image: myapp:canary
---
kind: Deployment
metadata:
  name: app
  labels:
    app: app
spec:
  replicas: 5
  ...
    image: myapp:stable
---
kind: Service
selector:
  app: app # Selector will route traffic to both deployments.

Mas madaling isipin ang opsyong ito gamit ang kubectl, at in Dokumentasyon ng Kubernetes Mayroong kahit isang buong tutorial sa sitwasyong ito. Ngunit ang pangunahing tanong ng post na ito ay kung paano namin isa-automate ang prosesong ito gamit ang Helm.

Automation ng canary deployment

Una sa lahat, kailangan namin ng mapa ng Helm chart, na kasama na ang mga mapagkukunang tinalakay namin sa itaas. Dapat itong magmukhang ganito:

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

Ang batayan ng konsepto ng Helm ay ang pamamahala ng mga multi-bersyon na release. Ang matatag na bersyon ay ang aming pangunahing matatag na sangay ng code ng proyekto. Ngunit sa Helm makakapag-deploy kami ng canary release gamit ang aming experimental code. Ang pangunahing bagay ay upang mapanatili ang palitan ng trapiko sa pagitan ng matatag na bersyon at ang paglabas ng kanaryo. Pamamahalaan namin ang lahat ng ito gamit ang isang espesyal na tagapili:

selector:
  app.kubernetes.io/name: myapp

Ang aming "canary" at matatag na mga mapagkukunan sa pag-deploy ay magsasaad ng label na ito sa mga module. Kung ang lahat ay na-configure nang tama, pagkatapos ay sa panahon ng pag-deploy ng canary na bersyon ng aming Helm chart na mapa makikita namin na ang trapiko ay ididirekta sa mga bagong naka-deploy na module. Magiging ganito ang stable na bersyon ng command na ito:

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

Ngayon tingnan natin ang paglabas ng canary natin. Upang i-deploy ang bersyon ng canary, kailangan nating tandaan ang dalawang bagay. Dapat na iba ang pangalan ng release para hindi kami maglunsad ng update sa kasalukuyang stable na bersyon. Dapat ding magkaiba ang bersyon at tag upang makapag-deploy kami ng iba pang code at matukoy ang mga pagkakaiba sa pamamagitan ng mga tag ng mapagkukunan.

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

Iyon lang! Kung ipi-ping mo ang serbisyo, makikita mong bahagi lang ng oras ang ruta ng pag-update ng canary sa trapiko.

Kung naghahanap ka ng mga tool sa deployment automation na kasama ang inilarawang logic, pagkatapos ay bigyang pansin Deliverybot at Helm automation tool sa GitHub. Ang mga Helm chart na ginamit upang ipatupad ang pamamaraang inilarawan sa itaas ay nasa Github, dito. Sa pangkalahatan, ito ay isang teoretikal na pangkalahatang-ideya kung paano ipatupad ang automation ng pag-deploy ng mga bersyon ng canary sa pagsasanay, na may mga partikular na konsepto at halimbawa.

Pinagmulan: www.habr.com

Magdagdag ng komento