En enkel og sikker måte å automatisere kanarie-utplasseringer med Helm

Canary-distribusjon er en veldig effektiv måte å teste ny kode på en undergruppe av brukere. Det reduserer trafikkbelastningen betraktelig som kan være problematisk under distribusjonsprosessen, siden den bare skjer innenfor en bestemt undergruppe. Dette notatet handler om hvordan du organiserer en slik distribusjon ved hjelp av Kubernetes og distribusjonsautomatisering. Dette forutsetter at du har litt kunnskap om Helm- og Kubernetes-ressurser..



En enkel kanarie-distribusjon til Kubernetes inkluderer to nøkkelressurser: selve tjenesten og distribusjonsverktøyet. Canary-distribusjon fungerer gjennom én enkelt tjeneste som kommuniserer med to forskjellige ressurser som betjener oppdateringstrafikk. En av disse ressursene vil fungere med "kanarifugl"-versjonen, og den andre - med den stabile. I denne situasjonen kan vi justere antall kanarieversjoner for å redusere mengden trafikk som kreves for vedlikehold. Hvis du for eksempel foretrekker å bruke Yaml, vil det se slik ut 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 will route traffic to both deployments.

Det er enda lettere å forestille seg et slikt alternativ på kubectl, og i dokumentasjon for Kubernetes det er til og med en fullstendig opplæring om dette scenariet. Men hovedspørsmålet i dette innlegget er hvordan vi skal automatisere denne prosessen ved å bruke Helm.

Canary Deployment Automation

Først av alt trenger vi et Helm-kart, som allerede inneholder ressursene som er diskutert ovenfor. Det skal se omtrent slik ut:

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

Grunnlaget for Helm-konseptet er håndtering av multiversjonsutgivelser. Den stabile versjonen er vår viktigste stabile kodegren for prosjektet. Men ved hjelp av Helm kan vi distribuere kanari-utgivelsen med vår eksperimentelle kode. Det viktigste er å beholde trafikkutvekslingen mellom den stabile versjonen og Canary-utgivelsen. Vi vil administrere alt dette ved å bruke en spesiell velger:

selector:
  app.kubernetes.io/name: myapp

Våre både "kanarifugl" og stabile distribusjonsressurser vil indikere denne etiketten på modulene. Hvis alt er riktig konfigurert, vil vi under distribusjonen av kanarieversjonen av vårt Helm-kart se at trafikken vil bli dirigert til de nylig utplasserte modulene. Den stabile versjonen av denne kommandoen vil se slik ut:

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

La oss nå sjekke ut vår kanari-utgivelse. For å distribuere kanarieversjonen må vi huske to ting. Navnet på utgivelsen må være et annet slik at vi ikke oppdaterer den nåværende stabile versjonen. Versjonen og taggen må også være forskjellige slik at vi kan distribuere annen kode og identifisere forskjeller i ressurstagger.

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

Det er faktisk alt! Hvis du pinger tjenesten, kan du se at Canary-oppdateringen bare ruter trafikk deler av tiden.

Hvis du ser etter automatiseringsverktøy for distribusjon som inkluderer den beskrevne logikken, så ta en titt på leveringsbot og Helm automatiseringsverktøy på GitHub. Helm-diagrammene som brukes til å implementere metoden beskrevet ovenfor er på Github, her. Generelt var det en teoretisk oversikt over hvordan man implementerer distribusjonsautomatisering av kanarieversjoner i praksis, med spesifikke konsepter og eksempler.

Kilde: www.habr.com