Jednoduchý a bezpečný způsob automatizace nasazení Canary s Helm

Nasazení Canary je velmi efektivní způsob, jak otestovat nový kód na podmnožině uživatelů. Výrazně snižuje zatížení provozu, které může být problematické během nasazení, protože k němu dochází pouze v rámci konkrétní podmnožiny. Tato poznámka je věnována tomu, jak zorganizovat takové nasazení pomocí Kubernetes a automatizace nasazení. Předpokládáme, že víte něco o zdrojích Helm a Kubernetes.



Jednoduché nasazení do Kubernetes zahrnuje dva klíčové zdroje: samotnou službu a nástroj pro nasazení. Nasazení Canary funguje prostřednictvím jediné služby, která spolupracuje se dvěma různými prostředky obsluhujícími aktualizační provoz. Jeden z těchto zdrojů bude fungovat s verzí „kanárek“ a druhý bude fungovat se stabilní verzí. V této situaci můžeme regulovat počet verzí kanárků, abychom snížili objem provozu potřebný k obsluhování. Pokud například dáváte přednost použití Yaml, bude to v Kubernetes vypadat 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ště jednodušší je představit si tuto možnost pomocí kubectl a in Dokumentace Kubernetes K tomuto scénáři je dokonce kompletní návod. Ale hlavní otázkou tohoto příspěvku je, jak tento proces zautomatizujeme pomocí Helm.

Automatizace nasazení kanárků

Nejprve potřebujeme mapu Helm, která již obsahuje zdroje, o kterých jsme hovořili výše. Mělo by to vypadat nějak takto:

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

Základem konceptu Helm je správa víceverzí. Stabilní verze je naší hlavní stabilní větví kódu projektu. Ale s Helm můžeme nasadit kanárkovou verzi s naším experimentálním kódem. Hlavní věc je zachovat výměnu provozu mezi stabilní verzí a verzí canary. To vše zvládneme pomocí speciálního selektoru:

selector:
  app.kubernetes.io/name: myapp

Naše „kanárek“ a zdroje stabilního nasazení označí tento štítek na modulech. Pokud je vše správně nakonfigurováno, pak během nasazení kanárské verze naší mapy Helm grafu uvidíme, že provoz bude směrován do nově nasazených modulů. Stabilní verze tohoto příkazu bude vypadat 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

Nyní se podíváme na naše vypuštění kanárků. Pro nasazení kanárkové verze si musíme pamatovat dvě věci. Název vydání se musí lišit, abychom nezavedli aktualizaci na aktuální stabilní verzi. Verze a značka se také musí lišit, abychom mohli nasadit jiný kód a identifikovat rozdíly podle značek zdrojů.

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še! Pokud službu pingnete, uvidíte, že aktualizace Canary směruje provoz pouze po část času.

Pokud hledáte nástroje pro automatizaci nasazení, které zahrnují popsanou logiku, věnujte pozornost Deliverybot a Nástroje pro automatizaci Helm na GitHubu. Helmovy grafy použité k implementaci výše popsané metody jsou na Github, zde. Obecně se jednalo o teoretický přehled toho, jak implementovat automatizaci nasazení kanárských verzí v praxi, s konkrétními koncepty a příklady.

Zdroj: www.habr.com