Jednoduchý a bezpečný spôsob automatizácie nasadenia kanárikov pomocou Helm

Nasadenie Canary je veľmi efektívny spôsob testovania nového kódu na podskupine používateľov. Výrazne znižuje dopravné zaťaženie, ktoré môže byť problematické počas procesu nasadenia, pretože sa vyskytuje iba v rámci špecifickej podmnožiny. Táto poznámka je venovaná tomu, ako organizovať takéto nasadenie pomocou Kubernetes a automatizácie nasadenia. Predpokladáme, že viete niečo o zdrojoch Helm a Kubernetes.



Jednoduché nasadenie na Kubernetes obsahuje dva kľúčové zdroje: samotnú službu a nástroj na nasadenie. Nasadenie Canary funguje prostredníctvom jedinej služby, ktorá interaguje s dvoma rôznymi zdrojmi obsluhujúcimi aktualizačný prenos. Jeden z týchto zdrojov bude fungovať s verziou „kanárika“ a druhý bude fungovať so stabilnou verziou. V tejto situácii môžeme regulovať počet verzií kanárikov, aby sme znížili objem prevádzky potrebnej na obsluhu. Ak napríklad uprednostňujete používanie Yaml, v Kubernetes to bude vyzerať takto:

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.

Je ešte jednoduchšie predstaviť si túto možnosť pomocou kubectl a in Dokumentácia Kubernetes K tomuto scenáru existuje dokonca aj úplný návod. Ale hlavnou otázkou tohto príspevku je, ako automatizujeme tento proces pomocou Helm.

Automatizácia nasadenia kanárikov

Najprv potrebujeme mapu Helma, ktorá už obsahuje zdroje, o ktorých sme hovorili vyššie. Malo by to vyzerať asi takto:

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

Základom konceptu Helm je správa vydaní viacerých verzií. Stabilná verzia je našou hlavnou stabilnou vetvou kódu projektu. Ale s Helmom môžeme nasadiť kanárske vydanie s naším experimentálnym kódom. Hlavná vec je zachovať výmenu návštevnosti medzi stabilnou verziou a kanárikovým vydaním. Toto všetko zvládneme pomocou špeciálneho selektora:

selector:
  app.kubernetes.io/name: myapp

Naše „kanárik“ a zdroje stabilného nasadenia označia tento štítok na moduloch. Ak je všetko správne nakonfigurované, potom počas nasadenia kanárskej verzie našej mapy Helm grafu uvidíme, že prevádzka bude smerovať do novo nasadených modulov. Stabilná verzia tohto príkazu bude vyzerať takto:

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

Teraz sa pozrime na naše vypustenie kanárika. Na nasadenie kanárikovej verzie si musíme zapamätať dve veci. Názov vydania musí byť odlišný, aby sme nezaviedli aktualizáciu na aktuálnu stabilnú verziu. Verzia a značka musia byť tiež odlišné, aby sme mohli nasadiť iný kód a identifikovať rozdiely podľa značiek zdrojov.

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

To je všetko! Ak službu pingnete, uvidíte, že aktualizácia kanárika smeruje premávku iba časť času.

Ak hľadáte nástroje na automatizáciu nasadenia, ktoré obsahujú opísanú logiku, venujte pozornosť Deliverybot a Nástroje na automatizáciu Helm na GitHub. Helmove grafy používané na implementáciu vyššie opísanej metódy sú na Github, tu. Vo všeobecnosti išlo o teoretický prehľad o tom, ako implementovať automatizáciu nasadzovania verzií kanárikov v praxi, s konkrétnymi konceptmi a príkladmi.

Zdroj: hab.com