Ett enkelt och säkert sätt att automatisera kanariefågelinstallationer med Helm

Ett enkelt och säkert sätt att automatisera kanariefågelinstallationer med Helm

Canary-distribution är ett mycket effektivt sätt att testa ny kod på en undergrupp av användare. Det minskar avsevärt trafikbelastningen som kan vara problematisk under driftsättningsprocessen, eftersom den bara förekommer inom en viss undergrupp. Den här anteckningen handlar om hur man organiserar en sådan distribution med Kubernetes och distributionsautomatisering. Detta förutsätter att du har viss kunskap om Helm och Kubernetes resurser..

Ett enkelt och säkert sätt att automatisera kanariefågelinstallationer med Helm

En enkel kanarie-distribution till Kubernetes inkluderar två nyckelresurser: själva tjänsten och distributionsverktyget. Canary-distribution fungerar genom en enda tjänst som kommunicerar med två olika resurser som betjänar uppdateringstrafik. En av dessa resurser kommer att fungera med versionen "kanariefågel" och den andra - med den stabila. I den här situationen kan vi justera antalet kanariefågelversioner för att minska mängden trafik som krävs för underhåll. Om du till exempel föredrar att använda Yaml, så skulle det se ut så här 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 är ännu lättare att föreställa sig ett sådant alternativ på kubectl och in dokumentation för Kubernetes det finns till och med en fullständig handledning om detta scenario. Men huvudfrågan i det här inlägget är hur vi ska automatisera den här processen med hjälp av Helm.

Canary Deployment Automation

Först och främst behöver vi en Helm-karta, som redan innehåller resurserna som diskuterats ovan. Det borde se ut ungefär så här:

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

Grunden för Helm-konceptet är hanteringen av multiversionsutgåvor. Den stabila versionen är vår huvudsakliga stabila kodgren för projektet. Men med hjälp av Helm kan vi distribuera kanariefågeln med vår experimentella kod. Huvudsaken är att behålla trafikutbytet mellan den stabila versionen och Canary-releasen. Vi kommer att hantera allt detta med hjälp av en speciell väljare:

selector:
  app.kubernetes.io/name: myapp

Våra både "canary" och stabila distributionsresurser kommer att ange denna etikett på modulerna. Om allt är korrekt konfigurerat kommer vi att se att trafiken kommer att dirigeras till de nyligen utplacerade modulerna under distributionen av kanariefågelversionen av vår Helm-karta. Den stabila versionen av detta kommando skulle se ut så här:

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

Låt oss nu kolla in vår kanariefågel release. För att distribuera kanariefågelversionen måste vi komma ihåg två saker. Namnet på releasen måste vara annorlunda så att vi inte uppdaterar den nuvarande stabila versionen. Versionen och taggen måste också vara olika så att vi kan distribuera annan kod och identifiera skillnader i resurstaggar.

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 är faktiskt allt! Om du plingar tjänsten kan du se att kanariefågeluppdateringen bara dirigerar trafik en del av tiden.

Om du letar efter automatiseringsverktyg för distribution som inkluderar den beskrivna logiken, ta en titt på leveransbot och Helm automationsverktyg på GitHub. Helm-diagrammen som används för att implementera metoden som beskrivs ovan finns på Github, just här. Generellt sett var det en teoretisk översikt av hur man implementerar automatisering av driftsättning av kanariefågelversioner i praktiken, med specifika koncept och exempel.

Källa: will.com

Lägg en kommentar