Freigabe ohne Angst: Kanarienvogel, blau-grüne und Flaggen

Es gibt eine besondere Art von Stille in einem Team-Chat direkt nach einem großen Produktions-Einsatz. Alle sehen auf das Armaturenbrett. Niemand möchte der Erste sein, der sagt: "Ist es nur ich, oder steigen die Fehler an?"

Progressive Delivery ersetzt dieses Schweigen durch einen Plan: erst ein paar Benutzer freigeben, verfolgen, was passiert, und erst dann entscheiden, ob man weitermacht. Wenn etwas nicht stimmt, merkt nur eine kleine Gruppe das, und das System kann die Änderung automatisch rückgängig machen.

Die Strategien wurden verglichen

- Das ist ein Update. Kubernetes' Standard: Ersetzen Sie ein paar Kapseln nach dem anderen. Einfach, aber sobald die Einführung beginnt, mischen sich neue und alte Versionen und Sie haben wenig Kontrolle darüber, wer was sieht.

Blau-grün. Die neue Version (grün) neben der alten (blau) ausführen. Test grün, dann alle Verkehrsmittel gleichzeitig. Zurückrollen bedeutet, zurück zu wechseln. Die Kosten: Verdoppelung der Ressourcen während des Wechselns und ein "Big Bang"-Moment für die Nutzer.

- Ein Kanarienvogel. Ein kleiner Prozentsatz des Traffics wird an die neue Version geschickt, z. B. 5%, dann 25%, dann 50%, dann 100%, wobei die Metriken in jedem Schritt überprüft werden. Langsamer, aber sicherer, um Probleme zu erkennen, die nur im realen Verkehr auftreten.

- Das ist ein Flaggen-Feature. Code mit der neuen Funktion ausgeschaltet bereitstellen, dann für bestimmte Benutzer, einen Prozentsatz oder alle aktivieren, ohne erneut zu bereitstellen. Das trennt Einsatz (code in die Produktion bringen) von Freisetzung (den Benutzern das zu zeigen).

	mit einem Durchmesser von	Blau-grün	Kanarienvögel	Merkmale der Flagge
Kontrolle der Exposition	Niedrig	Alles oder nichts .	Nach dem Verkehr schrittweise	Sehr gut, je nach Benutzer
Rückwärtsgeschwindigkeit	Langsam .	- Ich bin gleich da.	Schnell .	- Ich bin gleich da.
Zusätzliche Infrastruktur	Keine	Verdoppeln während des Umschaltens	Einige	Flaggendienst
Am besten für	Veränderungen mit geringem Risiko	Große Schalter	Risikogene Änderungen im Backend	Merkmale des Produkts

Das Einsatzwesen sollte langweilig sein. Die Freilassung sollte eine Entscheidung sein.

Argo-Rollouts in der Praxis

Auf Kubernetes, Argo-Rollouts (und - Das ist Flagger., sein Gegenstück im Flux-Ökosystem) ergänzt Kanarien- und blau-grüne Strategien mit automatischer Analyse.

A Rollout ersetzt eine Deployment:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: shop-api
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 5
      - pause: { duration: 5m }
      - analysis:
          templates:
          - templateName: error-rate
      - setWeight: 25
      - pause: { duration: 10m }
      - setWeight: 50
      - pause: { duration: 10m }
  selector:
    matchLabels: { app: shop-api }
  template:
    # same pod template as a Deployment

Die Analyse step führt eine Prometheus-Abfrage aus, zum Beispiel die Fehlerquote des Kanarienvögels, und vergleicht sie mit einem Schwellenwert:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate
spec:
  metrics:
  - name: error-rate
    interval: 1m
    count: 5
    successCondition: result[0] < 0.01
    provider:
      prometheus:
        address: http://prometheus.monitoring:9090
        query: |
          sum(rate(http_requests_total{app="shop-api",version="canary",code=~"5.."}[2m]))
          /
          sum(rate(http_requests_total{app="shop-api",version="canary"}[2m]))

Wenn die Fehlerquote über 1% liegt, wird die Einführung abgebrochen und der Datenverkehr geht zurück zur stabilen Version. Niemand musste wach sein.

Für präzise Verkehrsprosente integriert sich Rollouts mit Gateway-API-Implementierungen, Service-Meshes und Eingangscontrollern. Ohne sie wird das Gewicht mit Hilfe der Replikenzahl annähernd ermittelt.

Feature-Flaggen mit OpenFeature

Die Flaggen bedeuteten früher entweder eine hausgemachte if Eine Umgebungsvariable oder ein kommerzieller Dienst mit einem eigenen SDK überall. OpenFeature wird nicht verwendet, ein CNCF-Projekt, standardisiert die API: Ihr Code verwendet ein SDK, und Sie können verschiedene Flag-Anbieter dahinter (flagd, LaunchDarkly, Flagsmith, Unleash, GrowthBook und andere) einbinden.

enabled, _ := client.BooleanValue(ctx, "new-checkout", false, evalCtx)
if enabled {
    return newCheckout(w, r)
}
return oldCheckout(w, r)

Gute Flaggengewohnheiten:

• Geben Sie jeder Fahne einen Besitzer und ein Verfallsdatum. Alte Fahnen werden schnell zu technischen Schulden.
• Sauber machen. wenn eine Funktion vollständig freigegeben ist.
• Flags von kritischen Pfaden fernhalten Wenn der Flaggendienst nicht funktioniert, bricht es oder es gibt sinnvolle Standardeinstellungen.

Automatischer Rücklauf bei Verletzung der SLO

Die besten Einrichtungen verknüpfen Releases mit Ihren Service-Level-Zielen. Wenn eine neue Version das Fehlerbudget schneller als normal verbraucht, stoppt und rückläuft die Einführung. Das macht "die Dashboards nervös beobachten" zu einem automatischen Sicherheitsnetz, basierend auf dem, was Benutzer tatsächlich erleben.

Also, welche solltest du benutzen?

Beginnen Sie mit Feature-Flags für Produktänderungen, sie sind der einfachste Gewinn. Fügen Sie Kanarien-Veröffentlichungen mit automatischer Analyse für Ihre wichtigsten Dienste hinzu. Verwenden Sie blau-grün, wenn Sie einen sauberen Schalter brauchen, wie eine große Versionänderung. Und halten Sie Updates für alles mit geringem Risiko.

Meine Meinung: Loslassen in kleinen Schritten, lassen die Metriken die erste Entscheidung treffen, und stellen Sie sicher, dass Sie immer einen Klick zurück sind.

Desly