Lihtne ja turvaline viis kanaari juurutamise automatiseerimiseks Helmiga

Canary juurutamine on väga tõhus viis uue koodi testimiseks teatud kasutajate hulgas. See vähendab märkimisväärselt liikluskoormust, mis võib juurutusprotsessi ajal olla problemaatiline, kuna see esineb ainult teatud alamhulga piires. See märkus on pühendatud sellele, kuidas korraldada sellist juurutamist Kubernetese ja juurutamise automatiseerimise abil. Eeldame, et teate midagi Helmi ja Kubernetese ressurssidest.



Lihtne Kubernetese juurutamine sisaldab kahte peamist ressurssi: teenust ennast ja juurutustööriista. Canary juurutamine toimib ühe teenuse kaudu, mis suhtleb kahe erineva värskendusliiklust teenindava ressursiga. Üks neist ressurssidest töötab "kanaari" versiooniga ja teine ​​töötab stabiilse versiooniga. Sellises olukorras saame reguleerida Canary versioonide arvu, et vähendada teenindamiseks vajalikku liiklust. Kui eelistate näiteks Yamli kasutada, näeb see Kubernetesis välja selline:

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.

Seda valikut on veelgi lihtsam ette kujutada, kasutades kubectli ja sisse Kubernetese dokumentatsioon Selle stsenaariumi kohta on isegi täielik õpetus. Kuid selle postituse põhiküsimus on, kuidas me seda protsessi Helmi abil automatiseerime.

Kanaari juurutamise automatiseerimine

Kõigepealt vajame Helmi diagrammi kaarti, mis sisaldab juba ülalpool käsitletud ressursse. See peaks välja nägema umbes selline:

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

Helmi kontseptsiooni aluseks on mitmeversiooniliste väljaannete haldamine. Stabiilne versioon on meie projekti koodi peamine stabiilne haru. Kuid Helmi abil saame oma eksperimentaalse koodiga juurutada Canary versiooni. Peamine on säilitada liiklusvahetus stabiilse versiooni ja kanaari väljalaske vahel. Seda kõike juhime spetsiaalse valija abil:

selector:
  app.kubernetes.io/name: myapp

Meie "kanaari" ja stabiilsed juurutusressursid tähistavad seda silti moodulitel. Kui kõik on õigesti konfigureeritud, siis meie Helmi diagrammi kaardi kanaari versiooni juurutamisel näeme, et liiklus suunatakse äsja juurutatud moodulitesse. Selle käsu stabiilne versioon näeb välja järgmine:

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

Nüüd kontrollime oma kanaari saarte vabastamist. Kanaari versiooni juurutamiseks peame meeles pidama kahte asja. Väljalase nimi peab olema erinev, et me ei avaldaks värskendust praegusele stabiilsele versioonile. Versioon ja silt peavad samuti olema erinevad, et saaksime juurutada muud koodi ja tuvastada erinevused ressursimärgendite järgi.

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

See on kõik! Teenuse pingimisel näete, et kanaari värskenduste marsruudid suunavad liiklust ainult osa ajast.

Kui otsite juurutamise automatiseerimise tööriistu, mis sisaldavad kirjeldatud loogikat, siis pöörake tähelepanu Deliverybot ja Helmi automatiseerimistööriistad GitHubis. Ülalkirjeldatud meetodi rakendamiseks kasutatud Helmi diagrammid on Githubis, siin. Üldiselt oli see konkreetsete kontseptsioonide ja näidetega teoreetiline ülevaade, kuidas rakendada praktikas kanaari versioonide juurutamise automatiseerimist.

Allikas: www.habr.com