In ienfâldige en feilige manier om kanaryske ynset te automatisearjen mei Helm

Kanaryske ynset is in heul effisjinte manier om nije koade te testen op in subset fan brûkers. It ferminderet de ferkearsbelesting gâns dy't problematysk wêze kin tidens it ynsetproses, om't it allinich binnen in bepaalde subgroep foarkomt. Dizze notysje giet oer hoe't jo sa'n ynset organisearje mei Kubernetes en ynsetautomatisaasje. Dit giet derfan út dat jo wat kennis hawwe fan Helm- en Kubernetes-boarnen..



In ienfâldige kanaryske ynset nei Kubernetes omfettet twa wichtige boarnen: de tsjinst sels en it ynset ark. Kanaryske ynset wurket fia ien tsjinst dy't kommunisearret mei twa ferskillende boarnen dy't updateferkear betsjinje. Ien fan dizze boarnen sil wurkje mei de "kanaryske" ferzje, en de twadde - mei de stabile. Yn dizze situaasje kinne wy ​​​​it oantal kanaryske ferzjes oanpasse om it bedrach fan ferkear nedich foar ûnderhâld te ferminderjen. As jo ​​bygelyks Yaml leaver brûke, dan soe it der sa útsjen yn 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.

It is noch makliker om sa'n opsje foar te stellen op kubectl, en yn dokumintaasje foar Kubernetes d'r is sels in folsleine tutorial oer dit senario. Mar de haadfraach fan dit post is hoe't wy dit proses sille automatisearje mei Helm.

Canary Deployment Automatisearring

Alderearst hawwe wy in Helm-kaartkaart nedich, dy't de hjirboppe besprutsen boarnen al befettet. It moat der sa útsjen:

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

De basis fan it Helm konsept is it behear fan multiversion releases. De stabile ferzje is ús wichtichste stabile koadetûke foar it projekt. Mar mei help fan Helm kinne wy ​​​​de kanaryske release ynsette mei ús eksperimintele koade. It wichtichste is om de ferkearsútwikseling te hâlden tusken de stabile ferzje en de kanaryske release. Wy sille dit alles beheare mei in spesjale selector:

selector:
  app.kubernetes.io/name: myapp

Us sawol "kanaryske" as stabile ynsetboarnen sille dit label oanjaan op 'e modules. As alles goed is konfigureare, sille wy tidens de ynset fan 'e kanaryske ferzje fan ús Helm-kaartkaart sjen dat it ferkear wurdt rjochte nei de nij ynset modules. De stabile ferzje fan dit kommando soe der sa útsjen:

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

Litte wy no ús canary release besjen. Om de kanaryske ferzje yn te setten, moatte wy twa dingen betinke. De namme fan 'e release moat oars wêze, sadat wy de hjoeddeistige stabile ferzje net bywurkje. De ferzje en tag moatte ek oars wêze, sadat wy oare koade kinne ynsette en ferskillen yn boarnetags identifisearje.

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

Dat is trouwens alles! As jo ​​​​de tsjinst pinge, kinne jo sjen dat de kanaryske update allinich in part fan 'e tiid ferkear rûtes.

As jo ​​​​op syk binne nei ark foar ynsetautomatisaasje dy't de beskreaune logika omfetsje, sjoch dan ris nei deliverybot en oan Helm automatisearring ark op GitHub. De Helm charts brûkt om de hjirboppe beskreaune metoade út te fieren binne op Github, krekt hjir. Yn it algemien, it wie in teoretysk oersjoch fan hoe't te fieren ynset automatisearring fan kanaryske ferzjes yn de praktyk, mei spesifike begripen en foarbylden.

Boarne: www.habr.com