Прост и безопасен начин за автоматизация на канарийните деплои с помощта на Helm

Прост и безопасен начин за автоматизация на канарийните деплои с помощта на Helm

Канаречен деплой е много ефективен начин за тестване на нов код на определена подгрупа потребители. Той значително намалява трафик-натоварването, с което могат да възникнат проблеми по време на разгръщането, тъй като се случва само в рамките на определена подгрупа. Тази бележка е посветена на това как да организираме такъв деплой с помощта на Kubernetes и автоматизация на деплоя. Предполага се, че знаете нещо за Helm и ресурсите на Kubernetes.

Прост и безопасен начин за автоматизация на канарийните деплои с помощта на Helm

Простият канаречен деплой в Kubernetes включва два основни ресурса: самата услуга и инструмента за разгръщане. Канаречният деплой работи чрез една служба, която взаимодейства с два различни ресурса, обслужващи трафика на обновленията. Един от тези ресурси ще работи с "канаречната" версия, а другият — с стабилната. В тази ситуация можем да регулираме броя на канаречните версии, за да намалим обема на необходимия за обслужване трафик. Ако, например, предпочитате да използвате Yaml, то в Kubernetes то ще изглежда по следния начин:

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 # Селекторът ще маршрутизира трафика към двете разгръщания.

Още по-просто може да се представи такъв вариант на kubectl, а в документацията на Kubernetes има дори пълен туториал за този сценарий. Но основният въпрос на този пост е как ще автоматизираме този процес, използвайки Helm.

Автоматизация на канаречния деплой

Преди всичко ще ни е необходима карта с чартовете на Helm, в която вече са включени разглежданите от нас ресурси. Тя трябва да изглежда приблизително така:

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

Основата на концепцията Helm е управлението на мултиверсии на релизите. Стабилната версия е нашата основна стабилна версия на кода на проекта. Но с помощта на Helm можем да разгръщаме канаречен релиз с нашия експериментален код. Най-важното е да запазим обмена на трафик между стабилната версия и канаречния релиз. Управлението на всичко това ще се осъществява чрез специален селектор:

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

Нашите как „канаречни“, така и stable-ресурси за деплой ще указват този етикет на модулите. Ако всичко е настроено правилно, то по време на деплой на канаречната версия на нашата Helm карта ще видим, че трафикът ще бъде насочен към новосъздадените модули. Стабилната версия на тази команда ще изглежда така:

helm upgrade
  --install myapp 
  --namespace default 
  --set app.name=myapp       # Отива в app.kubernetes.io/name
  --set app.version=v1       # Отива в app.kubernetes.io/version
  --set image.tag=stable 
  --set replicaCount=5

Сега нека проверим нашия канаречен релиз. За да деплойнем канаречната версия, трябва да помним две неща. Името на релиза трябва да е различно, за да не актуализираме текущата stable-версия. Версията и етикетът също трябва да са различни, за да можем да развернем различен код и да определим разликите по етикетите на ресурсите.

helm upgrade
  --install myapp-canary 
  --namespace default 
  --set app.name=myapp       # Отива в app.kubernetes.io/name
  --set app.version=v2       # Отива в app.kubernetes.io/version
  --set image.tag=canary 
  --set replicaCount=1

Ето, всъщност и всичко! Ако пинганете услугата, можете да видите, че канаречното обновление маршрутизира трафика само за част от времето.

Ако търсите инструменти за автоматизация на деплоите, които включват описаната логика, обърнете внимание на Deliverybot и на инструменти за автоматизация Helm на GitHub. Чартовете на Helm, използвани за реализиране на описания по-горе метод, се намират на GitHub, тук. Всъщност, това беше теоретичен преглед на това как да реализирате автоматизация на деплоя на канаречни версии на практика, с конкретни концепции и примери.

Източник: habr.com

Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри 🔥 Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри | ProHoster