Vienkāršs un drošs veids, kā automatizēt kanārijputnu izvietošanu ar Helm

Canary izvietošana ir ļoti efektīvs veids, kā pārbaudīt jaunu kodu lietotāju apakškopai. Tas ievērojami samazina satiksmes slodzi, kas var būt problemātiska izvietošanas procesa laikā, jo tā notiek tikai noteiktā apakšgrupā. Šī piezīme ir par to, kā organizēt šādu izvietošanu, izmantojot Kubernetes un izvietošanas automatizāciju. Tas nozīmē, ka jums ir zināmas zināšanas par Helm un Kubernetes resursiem..



Vienkārša izvietošana Kubernetes ietver divus galvenos resursus: pašu pakalpojumu un izvietošanas rīku. Canary izvietošana darbojas, izmantojot vienu pakalpojumu, kas sazinās ar diviem dažādiem resursiem, kas apkalpo atjaunināšanas trafiku. Viens no šiem resursiem darbosies ar "kanārijputniņu" versiju, bet otrs - ar stabilo. Šādā situācijā varam pielāgot kanāriju versiju skaitu, lai samazinātu apkopei nepieciešamo satiksmes apjomu. Ja, piemēram, vēlaties izmantot Yaml, Kubernetes tas izskatītos šādi:

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.

Vēl vieglāk ir iedomāties šādu iespēju vietnē kubectl un in dokumentācija par Kubernetes ir pat pilna apmācība par šo scenāriju. Bet šīs ziņas galvenais jautājums ir par to, kā mēs automatizēsim šo procesu, izmantojot Helm.

Kanāriju izvietošanas automatizācija

Pirmkārt, mums ir nepieciešama Helm diagrammas karte, kurā jau ir iepriekš apspriestie resursi. Tam vajadzētu izskatīties apmēram šādi:

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

Helm koncepcijas pamatā ir vairāku versiju izlaidumu pārvaldība. Stabilā versija ir mūsu galvenā stabilā koda filiāle projektam. Bet ar Helm palīdzību mēs varam izvietot Canary versiju ar mūsu eksperimentālo kodu. Galvenais ir saglabāt trafika apmaiņu starp stabilo versiju un kanārijputnu izlaidumu. Mēs to visu pārvaldīsim, izmantojot īpašu selektoru:

selector:
  app.kubernetes.io/name: myapp

Mūsu gan "kanārijputnu", gan stabilās izvietošanas resursi uz moduļiem norādīs šo etiķeti. Ja viss ir pareizi konfigurēts, mūsu Helm diagrammas kartes kanāriju versijas izvietošanas laikā mēs redzēsim, ka satiksme tiks novirzīta uz tikko izvietotajiem moduļiem. Šīs komandas stabilā versija izskatītos šādi:

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

Tagad apskatīsim mūsu Kanāriju izlaidumu. Lai izvietotu Kanāriju versiju, mums jāatceras divas lietas. Izlaiduma nosaukumam ir jābūt citam, lai mēs neatjauninātu pašreizējo stabilo versiju. Arī versijai un tagam ir jāatšķiras, lai mēs varētu izvietot citu kodu un identificēt resursu tagu atšķirības.

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

Tas patiesībā arī viss! Ja veicat pakalpojuma ping, jūs varat redzēt, ka kanārijputnu atjauninājums tikai daļu laika novirza satiksmi.

Ja meklējat izvietošanas automatizācijas rīkus, kas ietver aprakstīto loģiku, apskatiet to piegādes robots un Stūres automatizācijas rīki vietnē GitHub. Iepriekš aprakstītās metodes ieviešanai izmantotās Helm diagrammas atrodas vietnē Github, šeit. Kopumā tas bija teorētisks pārskats par to, kā praksē ieviest kanāriju versiju izvietošanas automatizāciju, ar konkrētām koncepcijām un piemēriem.

Avots: www.habr.com