Paprastas ir saugus būdas automatizuoti kanarėlių diegimą naudojant Helm

„Canary“ diegimas yra labai efektyvus būdas išbandyti naują kodą tam tikram vartotojų pogrupiui. Tai žymiai sumažina srauto apkrovą, kuri gali būti problemiška diegimo proceso metu, nes ji atsiranda tik tam tikrame pogrupyje. Ši pastaba skirta kaip organizuoti tokį diegimą naudojant Kubernetes ir diegimo automatizavimą. Manome, kad žinote ką nors apie Helm ir Kubernetes išteklius.



Paprastas „Kubernetes“ diegimas apima du pagrindinius išteklius: pačią paslaugą ir diegimo įrankį. „Canary“ diegimas veikia naudojant vieną paslaugą, kuri sąveikauja su dviem skirtingais ištekliais, aptarnaujančiais atnaujinimo srautą. Vienas iš šių išteklių veiks su „kanarėlės“ versija, o antrasis – su stabilia versija. Esant tokiai situacijai, galime reguliuoti „Canary“ versijų skaičių, kad sumažintume aptarnavimui reikalingą srautą. Pavyzdžiui, jei norite naudoti „Yaml“, „Kubernetes“ jis atrodys taip:

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.

Dar lengviau įsivaizduoti šią parinktį naudojant kubectl ir in Kubernetes dokumentacija Yra net visa šio scenarijaus mokymo programa. Tačiau pagrindinis šio įrašo klausimas yra tai, kaip mes ketiname automatizuoti šį procesą naudodami Helm.

Kanarų diegimo automatizavimas

Visų pirma, mums reikia Helm diagramos žemėlapio, kuriame jau yra ištekliai, apie kuriuos kalbėjome aukščiau. Tai turėtų atrodyti maždaug taip:

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

Helm koncepcijos pagrindas yra kelių versijų leidimų valdymas. Stabili versija yra mūsų pagrindinė stabili projekto kodo šaka. Tačiau naudodami „Helm“ galime įdiegti „canary“ leidimą naudodami eksperimentinį kodą. Svarbiausia yra palaikyti srauto mainus tarp stabilios versijos ir kanarėlės leidimo. Visa tai valdysime naudodami specialų selektorių:

selector:
  app.kubernetes.io/name: myapp

Mūsų „kanarėlės“ ir stabilaus diegimo ištekliai nurodys šią etiketę ant modulių. Jei viskas sukonfigūruota teisingai, tada diegdami mūsų Helm diagramos žemėlapio Canary versiją pamatysime, kad srautas bus nukreiptas į naujai įdiegtus modulius. Stabili šios komandos versija atrodys taip:

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

Dabar patikrinkime mūsų kanarėlių išleidimą. Norėdami įdiegti kanarėlių versiją, turime atsiminti du dalykus. Leidimo pavadinimas turi būti kitoks, kad mes neišleisime dabartinės stabilios versijos naujinimo. Versija ir žyma taip pat turi skirtis, kad galėtume įdiegti kitą kodą ir nustatyti skirtumus pagal išteklių žymas.

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

Tai viskas! Jei prisijungiate prie paslaugos, galite pamatyti, kad kanarėlių naujinimas nukreipia eismą tik dalį laiko.

Jei ieškote diegimo automatizavimo įrankių, apimančių aprašytą logiką, atkreipkite dėmesį į Deliverybot ir „GitHub“ vairo automatizavimo įrankiai. „Helm“ diagramos, naudojamos aukščiau aprašytam metodui įgyvendinti, yra „Github“, čia. Apskritai tai buvo teorinė apžvalga, kaip praktiškai įgyvendinti kanarinių versijų diegimo automatizavimą su konkrečiomis koncepcijomis ir pavyzdžiais.

Šaltinis: www.habr.com