Czym są wdrożenia kanarkowe?

Wdrożenie kanarkowe to strategia wypuszczania nowej funkcjonalności, w której aktualizacja jest stopniowo wdrażana na niewielkiej części użytkowników, a następnie, przy braku problemów, rozprzestrzenia się na całą grupę odbiorców.

Główne etapy:

1. Wdrożenie grupy kanarkowej: Nowa wersja aplikacji jest wdrażana na niewielkiej podgrupie serwerów lub użytkowników.
2. Monitorowanie: Prowadzi się dokładne monitorowanie metryk (błędy, wydajność, zachowanie użytkowników) dla grupy kanarkowej.
3. Rozszerzenie lub wycofanie:
   • Jeśli monitorowanie pokazuje sukces, wdrożenie jest stopniowo rozszerzane na coraz większą grupę użytkowników.
   • W przypadku problemów, wdrożenie jest wycofywane dla grupy kanarkowej, chroniąc główną masę użytkowników.

Zalety:

• Minimalizacja ryzyka: Problemy wpływają na niewielką grupę użytkowników.
• Szybkie wycofanie: Łatwo wrócić do poprzedniej wersji.
• Testowanie w warunkach rzeczywistych: Ocena zachowania nowej funkcji pod obciążeniem rzeczywistym.

Wady:

• Złożoność infrastruktury: Wymaga obsługi wielu wersji aplikacji jednocześnie.
• Zarządzanie ruchem: Potrzebne mechanizmy do kierowania ruchu do różnych wersji.
• Analiza danych: Wymaga skutecznego zbierania i analizy metryk.

Przykład implementacji w Kubernetes:

// Deployment dla v1
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v1
spec:
  replicas: 10 // Główna liczba
  selector:
    matchLabels:
      app: my-app
      version: v1
  template:
    metadata:
      labels:
        app: my-app
        version: v1
    spec:
      containers:
      - name: my-app
        image: my-registry/my-app:v1

---

// Deployment dla kanarka v2
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v2-canary
spec:
  replicas: 1 // Grupa kanarkowa
  selector:
    matchLabels:
      app: my-app
      version: v2
  template:
    metadata:
      labels:
        app: my-app
        version: v2
    spec:
      containers:
      - name: my-app
        image: my-registry/my-app:v2

---

// Usługa do kierowania ruchem (z użyciem selectorów)
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Aby zarządzać rozkładem ruchu między v1 a v2, używa się kontrolerów Ingress (np. Nginx Ingress, Istio) z możliwością wagowego rozkładu ruchu.