Prosty i bezpieczny sposób automatyzacji kanarkowych wdrożeń za pomocą Helm

Deployment kanaryjny to bardzo skuteczna metoda testowania nowego kodu w podzbiorze użytkowników. Znacznie zmniejsza obciążenie ruchem, które mogą powodować problemy podczas wdrażania, ponieważ odbywa się to tylko w obrębie określonej podgrupy. Niniejsza notatka dotyczy tego, jak zorganizować takie wdrożenie za pomocą Kubernetes i automatyzacji wdrażania. Zakłada się, że masz podstawową wiedzę na temat Helm i zasobów Kubernetes..



Proste wdrożenie kanaryjne w Kubernetes obejmuje dwa kluczowe zasoby: samą usługę i narzędzie do wdrażania. Wdrożenie kanaryjne działa przez jedną usługę, która współdziała z dwoma różnymi zasobami, obsługującymi ruch aktualizacji. Jeden z tych zasobów będzie działać z wersją «kanaryjną», a drugi — ze stabilną. W tej sytuacji możemy regulować liczbę wersji kanaryjnych, aby zmniejszyć ilość wymaganych zasobów do obsługi ruchu. Na przykład, jeśli wolisz używać Yaml, będzie to wyglądać następująco w 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 przekieruje ruch do obu wdrożeń.

Jeszcze łatwiej jest przedstawić ten wariant na kubectl, a w dokumentacji Kubernetes jest nawet pełnoprawny samouczek dotyczący tego scenariusza. Ale główne pytanie tego posta brzmi, jak zamierzamy zautomatyzować ten proces, używając Helm.

Automatyzacja wdrożenia kanaryjnego

Przede wszystkim potrzebna nam będzie mapa chartów Helm, w którą już zapisano zasoby omawiane powyżej. Powinna wyglądać mniej więcej tak:

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

Podstawą koncepcji Helm jest zarządzanie wersjami wydań. Wersja Stable to nasza główna stabilna gałąź kodu projektu. Ale za pomocą Helm możemy wdrożyć wersję kanaryjną z naszym eksperymentalnym kodem. Najważniejsze jest utrzymanie wymiany ruchu między stabilną wersją a wersją kanaryjną. Zarządzać tym wszystkim będziemy za pomocą specjalnego selektora:

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

Nasze zasoby do wdrożeń zarówno typu „kanarkowego”, jak i stabilnego będą wskazywać tę etykietę w modułach. Jeśli wszystko zostanie prawidłowo skonfigurowane, podczas wdrażania kanarkowej wersji naszej mapy chartów Helm zobaczymy, że ruch będzie kierowany do świeżo wdrożonych modułów. Stabilna wersja tej komendy będzie wyglądać tak:

helm upgrade
  --install myapp 
  --namespace default 
  --set app.name=myapp       # Przechodzi do app.kubernetes.io/name
  --set app.version=v1       # Przechodzi do app.kubernetes.io/version
  --set image.tag=stable 
  --set replicaCount=5

Teraz sprawdźmy nasze kanarkowe wydanie. Aby wdrożyć kanarkową wersję, musimy pamiętać o dwóch rzeczach. Nazwa wydania musi się różnić, abyśmy nie nadpisali aktualnej wersji stabilnej. Wersja i tag również muszą być różne, abyśmy mogli wdrożyć inny kod i określić różnice według etykiet zasobów.

helm upgrade
  --install myapp-canary 
  --namespace default 
  --set app.name=myapp       # Przechodzi do app.kubernetes.io/name
  --set app.version=v2       # Przechodzi do app.kubernetes.io/version
  --set image.tag=canary 
  --set replicaCount=1

I to wszystko! Jeśli pingniemy usługę, można zauważyć, że kanarkowe wdrożenie kieruje ruch tylko część czasu.

Jeśli szukasz narzędzi do automatyzacji wdrożeń, które zawierają opisaną logikę, zwróć uwagę na Deliverybot i na narzędzia do automatyzacji Helm na GitHubie. Charty Helm używane do wdrożenia opisanego powyżej sposobu znajdują się na Githubie, tutaj. Ogólnie rzecz biorąc, był to teoretyczny przegląd tego, jak praktycznie wdrożyć automatyzację wdrożeń kanarkowych z konkretnymi koncepcjami i przykładami.

Źródło: habr.com