Enkel og sikker måde at automatisere kanariefugle-deploys med Helm

Kanarideployering er en meget effektiv metode til at teste ny kode på en delmængde af brugere. Det reducerer betydeligt den trafikbelastning, som kan forårsage problemer under udrulningen, da det kun finder sted inden for en bestemt undergruppe. Denne note handler om, hvordan man organiserer en sådan deployment ved hjælp af Kubernetes og automatisering af deployment. Det antages, at du allerede ved noget om Helm og Kubernetes-ressourcer..



En enkel kanarideployering i Kubernetes involverer to nøgle ressourcer: selve servicen og udrulningsværktøjet. Kanarideployeringen fungerer gennem en tjeneste, der interagerer med to forskellige ressourcer, der håndterer opdateringstrafikken. En af disse ressourcer vil arbejde med den 'kanariefarvede' version, mens den anden vil arbejde med den stabile version. I denne situation kan vi regulere antallet af kanariefarvede versioner for at reducere den nødvendige mængde trafik, der skal håndteres. Hvis du for eksempel foretrækker at bruge Yaml, ser det sådan ud i 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 vil rute trafik til begge udrulninger.

En endnu lettere måde at forestille sig denne variant er via kubectl, mens i dokumentationen for Kubernetes faktisk findes der en komplet tutorial til dette scenarie. Men det hovedspørgsmål, som dette indlæg handler om, er, hvordan vi planlægger at automatisere denne proces ved hjælp af Helm.

Automatisering af kanarideployering

Først og fremmest har vi brug for et Helm chart, som allerede indeholder de ressourcer, vi har diskuteret ovenfor. Det skal se nogenlunde sådan ud:

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

Kernen i Helm-koncepterne er håndtering af multi-versioner af releases. Den stabile version er vores primære stabile kodegren for projektet. Men ved hjælp af Helm kan vi udrulle en kanarirelease med vores eksperimentelle kode. Det vigtigste er at bevare trafikudvekslingen mellem den stabile version og kanarireleasen. Alt dette vil vi styre med en særlig selector:

selector:
  app.kubernetes.io\/name: myapp

Vores både "kanariefugle" og stabile deployments vil angive denne label på modulerne. Hvis alt er konfigureret korrekt, vil trafikken under deployment af den kanariefugle version af vores Helm chart blive dirigeret til de nyoprettede moduler. Den stabile version af denne kommando vil se sådan ud:

helm upgrade
  --install myapp 
  --namespace default 
  --set app.name=myapp       # Går ind i app.kubernetes.io/name
  --set app.version=v1       # Går ind i app.kubernetes.io/version
  --set image.tag=stable 
  --set replicaCount=5

Nu lad os tjekke vores kanariefugle release. For at deployere den kanariefugle version, skal vi huske to ting. Navnet på releasen skal adskille sig, så vi ikke overskriver den nuværende stabile version. Versionen og tagget skal også adskille sig, så vi kan deployere anden kode og identificere forskelle baseret på ressource-tags.

helm upgrade
  --install myapp-canary 
  --namespace default 
  --set app.name=myapp       # Går ind i app.kubernetes.io/name
  --set app.version=v2       # Går ind i app.kubernetes.io/version
  --set image.tag=canary 
  --set replicaCount=1

Og det er egentlig det! Hvis man pinger tjenesten, kan man se, at den kanariefugle opdatering kun dirigerer trafikken noget af tiden.

Hvis du leder efter automatiseringsværktøjer til deployment, der inkluderer den beskrevne logik, så tjek Deliverybot og på automatiseringsværktøjer til Helm på GitHub. Helm charts, der anvendes til implementeringen af den beskrevne metode, ligger på GitHub, her. Generelt var dette en teoretisk gennemgang af, hvordan man praktisk implementerer automatisering af kanariefugle deployments med specifikke koncepter og eksempler.

Kilde: habr.com