Lihtne ja turvaline viis kanarbikute kasutuselevõtu automatiseerimiseks Helmiga

Kanaldeploy on väga tõhus viis uue koodi testimiseks väikese kasutajate alamhulga peal. See vähendab oluliselt liiklust, mis võib tekitada probleeme juurutamise protsessis, kuna see toimub ainult kindlas alagruppis. See märkus käsitleb, kuidas sellist juurutamist Kubernetes ja juurutamise automatiseerimise vahenditega korraldada. Eeldatakse, et teil on vähemalt põhiline arusaam Helm'ist ja Kubernetes'i ressurssidest..



Lihtne kanaldeploy Kubernetes'is sisaldab kahte peamist ressurssi: teenust ja juurutamisvahendit. Kanaldeploy töötab läbi ühe teenuse, mis suhtleb kahe erineva ressursiga, mis teenindavad uuenduste liiklust. Üks neist ressurssidest töötab "kanal" versiooniga, teine aga stabiilsega. Sel juhul saame reguleerida kanalversioonide arvu, et vähendada vajaliku teenindatava liikluse mahtu. Näiteks, kui eelistate Yaml'i kasutada, näeb see Kubernetes'is välja järgmiselt:

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 suunab liikluse mõlemasse juurutusse.

Seda varianti on veel lihtsam esitada kubectl'i abil ja Kubernetes'i dokumentatsioonis on isegi täielik juhend selle stsenaariumi jaoks. Kuid selle postituse peamine küsimus on, kuidas me kavatseme seda protsessi automatiseerida, kasutades Helm'i.

Kanaldeploy automatiseerimine

Esiteks vajame Helm'i chartide kaarti, kuhu on juba lisatud eespool arutatud ressursid. See peaks välja nägema umbes nii:

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

Helm'i kontseptsiooni aluseks on mitme versiooni haldamine. Stabiilne versioon on meie põhialgse stabiilse koodiharu. Kuid Helm'i abil saame juurutada kanali väljaande koos eksperimentaalse koodiga. Peamine prioriteet on säilitada liikluse vahetus stabiilse versiooni ja kanali väljaande vahel. Kogu seda haldame spetsiaalse valijaga:

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

Meie nii „kanarilõhe“ kui ka stable-deploy ressursid osutavad sellele sildile moodulites. Kui kõik õigesti seadistada, näeme, et kanariversiooni juurutamise ajal meie Helm charti liiklust suunatakse värskelt juurutatud moodulitele. Selle käsu stabiilne versioon näeb välja selline:

helm upgrade
  --install myapp 
  --namespace default 
  --set app.name=myapp       # Läheb app.kubernetes.io/name
  --set app.version=v1       # Läheb app.kubernetes.io/version
  --set image.tag=stable 
  --set replicaCount=5

Nüüd kontrollime meie kanaride väljaannet. Kanariversiooni juurutamiseks peame meeles pidama kahte asja. Väljaande nimi peab olema erinev, et me ei kataks üle praegust stabiilset versiooni. Versioon ja silt peavad samuti olema erinevad, et saaksime juurutada teistsugust koodi ja määrata ressursside siltide erinevusi.

helm upgrade
  --install myapp-canary 
  --namespace default 
  --set app.name=myapp       # Läheb app.kubernetes.io/name
  --set app.version=v2       # Läheb app.kubernetes.io/version
  --set image.tag=canary 
  --set replicaCount=1

Noh, see ongi kõik! Kui teenust pingida, saab näha, et kanaride versiooniuuendus suunab liiklust ainult osa ajast.

Kui otsite juurutamise automatiseerimise tööriistu, mis hõlmavad kirjeldatud loogikat, pöörake tähelepanu Deliverybot ja Helm automatiseerimise tööriistadele GitHubis. Helm chart'id, mida kasutatakse ülalpool kirjeldatud meetodi rakendamiseks, asuvad GitHubis, siit. Tegelikult oli see teoreetiline ülevaade, kuidas praktikas juurutada kanariversioonide automatiseerimist, koos konkreetsete kontseptsioonide ja näidetega.

Allikas: habr.com