Cara sing gampang lan aman kanggo ngotomatisasi penyebaran kenari nganggo Helm

Penyebaran Canary minangka cara sing efektif banget kanggo nguji kode anyar ing subset pangguna. Iki nyuda beban lalu lintas sing bisa dadi masalah sajrone proses penyebaran, amarga mung ana ing subset tartamtu. Cathetan iki dikhususake kanggo ngatur penyebaran kasebut nggunakake Kubernetes lan otomatisasi penyebaran. Kita nganggep sampeyan ngerti babagan sumber Helm lan Kubernetes.



Penyebaran kenari sing prasaja menyang Kubernetes kalebu rong sumber daya utama: layanan kasebut dhewe lan alat panyebaran. Penyebaran Canary bisa digunakake liwat layanan siji sing sesambungan karo rong sumber daya sing beda kanggo lalu lintas nganyari. Salah sawijining sumber daya kasebut bakal bisa digunakake karo versi "kanari", lan sing kapindho bakal digunakake karo versi stabil. Ing kahanan iki, kita bisa ngatur jumlah versi kenari kanggo ngurangi jumlah lalu lintas sing dibutuhake kanggo ngawula. Yen, contone, sampeyan luwih seneng nggunakake Yaml, mula bakal katon kaya iki ing 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.

Luwih gampang mbayangno pilihan iki nggunakake kubectl, lan ing Dokumentasi Kubernetes Malah ana tutorial lengkap babagan skenario iki. Nanging pitakonan utama kirim iki carane kita arep ngotomatisasi proses iki nggunakake Helm.

Otomasi penyebaran kenari

Kaping pisanan, kita butuh peta grafik Helm, sing wis kalebu sumber daya sing kita rembugan ing ndhuwur. Iku kudu katon kaya iki:

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

Basis konsep Helm yaiku manajemen rilis multi-versi. Versi stabil minangka cabang stabil utama saka kode proyek. Nanging kanthi Helm, kita bisa nyebarake rilis kenari kanthi kode eksperimen. Sing utama yaiku njaga ijol-ijolan lalu lintas antarane versi stabil lan rilis kenari. Kita bakal ngatur kabeh iki nggunakake pamilih khusus:

selector:
  app.kubernetes.io/name: myapp

"Kanari" lan sumber daya penyebaran stabil bakal nuduhake label iki ing modul. Yen kabeh wis dikonfigurasi kanthi bener, banjur sajrone panyebaran versi kenari saka peta grafik Helm kita bakal weruh yen lalu lintas bakal diarahake menyang modul sing mentas disebarake. Versi stabil saka printah iki bakal katon kaya iki:

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

Saiki ayo mriksa release kenari kita. Kanggo masang versi kenari, kita kudu ngelingi rong perkara. Jeneng rilis kudu beda supaya kita ora ngluncurake nganyari menyang versi stabil saiki. Versi lan tag uga kudu beda supaya kita bisa masang kode liyane lan ngenali beda dening tag sumber daya.

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

Iku kabeh! Yen sampeyan ping layanan kasebut, sampeyan bisa ndeleng manawa nganyari kenari mung ngarahake lalu lintas mung sawetara wektu.

Yen sampeyan nggoleki alat otomatisasi penyebaran sing kalebu logika sing diterangake, mula digatekake Deliverybot lan ing Alat otomatisasi helm ing GitHub. Bagan Helm sing digunakake kanggo ngetrapake metode sing kasebut ing ndhuwur yaiku ing Github, tengen kene. Umumé, iki minangka gambaran teoritis babagan cara ngleksanakake otomatisasi penyebaran versi kenari ing praktik, kanthi konsep lan conto tartamtu.

Source: www.habr.com