Blue-green deployment: dwie wersje, jeden ruch

data

2025-06-24

kategoria

CI/CD

także w

Reliability Engineering

czytanie

1 min / 183 słów

Rolling update wymienia system po kawałku.

Czasem to nie wystarcza.

Jeżeli rollback przez ponowny rollout trwa zbyt długo, prostszy pomysł brzmi:

text

utrzymuj starą wersję gotową
uruchom nową wersję obok
przełącz ruch jednym ruchem

To jest blue-green deployment.

Jedna wersja obsługuje użytkowników.

Druga czeka gotowa do przejęcia ruchu.

Minimalny przykład

Mamy dwa Deployment.

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
      version: blue
  template:
    metadata:
      labels:
        app: api
        version: blue
    spec:
      containers:
        - name: api
          image: ghcr.io/example/api:1.9.0

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
      version: green
  template:
    metadata:
      labels:
        app: api
        version: green
    spec:
      containers:
        - name: api
          image: ghcr.io/example/api:2.0.0

Ruch wybiera Service.

yaml

apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
    version: blue
  ports:
    - port: 80
      targetPort: 3000

Przełączenie na green to zmiana selektora:

yaml

selector:
  app: api
  version: green

W praktyce robi się to przez GitOps, patch, rollout orchestration albo zmianę routingu wyżej.

Mechanizm jest ten sam:

text

nowa wersja była gotowa przed przełączeniem

Do czego to realnie służy

Blue-green jest dobre, kiedy chcemy oddzielić:

text

deploy nowej wersji
przełączenie użytkowników

Można przetestować green przed ruchem produkcyjnym.

Można szybko wrócić na blue, jeśli błąd jest w kodzie albo konfiguracji aplikacji.

To pomaga przy usługach, gdzie koszt zimnego startu jest duży albo rollback przez ponowny rollout jest za wolny.

Gdzie nazwa kłamie

Blue-green brzmi jak pełny rollback.

Często jest tylko rollbackiem ruchu.

Jeżeli obie wersje używają tej samej bazy danych, przełączenie Service nie cofnie:

text

migracji schematu
nowych rekordów
zmienionych formatów
opublikowanych eventów
zadań w kolejce

Blue-green potrzebuje tej samej dyscypliny kompatybilności co rolling update.

Różnica polega na tym, że nie mieszamy wersji za jednym Service przez długi czas.

Ale dane nadal są wspólne, jeśli sami ich nie rozdzielimy.

Dlatego blue-green jest strategią przełączania ruchu.

Nie magicznym cofaniem systemu.