Прост и безопасен начин за автоматизиране на канарийски деплойменти с помощта на 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

Нашите както "канарийски", така и стабилни ресурси за разгръщане ще посочват този етикет на модулите. Ако всичко е настроено правилно, по време на разгръщането на канарийната версия на нашата 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

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

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. Хелм чартовете, използвани за реализиране на описания по-горе начин, се намират в GitHub, са тук. Всъщност, това беше теоретичен преглед на начина за реализиране на автоматизация на разгръщането на канарийски версии на практика, с конкретни концепции и примери.

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

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