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.
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
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
Pinagmulan: www.habr.com