Простий та безпечний спосіб автоматизації канаркових деплоїв за допомогою Helm

Канарковий деплой - це дуже ефективний спосіб тестування нового коду на якомусь підмножині користувачів. Він значно знижує трафік-навантаження, з якого можуть виникнути проблеми в процесі розгортання, оскільки відбувається лише в межах певної підгрупи. Ця нотатка присвячена тому, як організувати подібний деплой засобами Kubernetes та автоматизації деплою. Передбачається, що ви дещо знаєте про Helm та ресурси Kubernetes.



Простий канарковий деплой в 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 # Selector will route traffic to both deployments.

Ще простіше уявити такий варіант можна на kubectl, а в документації по Kubernetes навіть є повноцінний туторіал за цим сценарієм. Але головне питання цієї посади у тому, як ми збираємося автоматизувати цей процес, використовуючи Helm.

Автоматизація канаркового деплою

Насамперед нам знадобиться карта чартів Helm, до якої вже внесені обговорювані нами ресурси. Виглядати вона має бути приблизно так:

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

Основа концепції Helm – управління мультиверсіями релізів. Stable-версія - це наша основна стабільна гілка коду проекту. Але за допомогою Helm ми можемо розгорнути канарковий реліз із нашим експериментальним кодом. Головне — зберегти обмін трафіком між стабільною версією та канарковим релізом. Керувати всім цим ми за допомогою спеціального селектора:

selector:
  app.kubernetes.io/name: myapp

Наші як «канарокові», так і stable-ресурси деплою будуть вказувати цю мітку на модулях. Якщо все налаштувати правильно, то під час деплою канаркової версії нашої карти чартів Helm ми побачимо, що трафік спрямовуватиметься на свіжорозгорнуті модулі. Стабільна версія цієї команди виглядатиме так:

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

Тепер перевіримо наш канарковий реліз. Щоб задеплоїти канаркову версію, нам треба пам'ятати про дві речі. Назва релізу має відрізнятись, щоб ми не накотили апдейт на поточну stable-версію. Версія та тег також повинні відрізнятися, щоб ми могли розгорнути інший код та визначити відмінності за мітками ресурсів.

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

Ось, власне, і все! Якщо пінганути службу, можна побачити, що канаркове оновлення маршрутизує трафік лише частину часу.

Якщо ви шукайте інструменти автоматизації деплою, які включають описану логіку, то зверніть увагу на Deliverybot і на інструменти автоматизації Helm на GitHub. Чарти Helm, що використовуються для реалізації описаного вище способу, лежать на Github, ось тут. Взагалі, це був теоретичний огляд того, як реалізувати автоматизацію деплою канаркових версій на практиці, з конкретними концепціями та прикладами.

Джерело: habr.com