1. Choosing a strategy #
Risk, cost and rollback speed.
Comparison #
| Strategy | Principle | Rollback | Cost |
|---|---|---|---|
| Rolling | Instances are replaced progressively | New deployment of the old version | Low |
| Blue/green | Two complete environments, traffic switch | Instant (switch back) | Double capacity during the switch |
| Canary | A small share of traffic on the new version, then increased | Set the weight back to 0 | Low; requires good metrics |
| Mirroring | Traffic copied to the new version, responses ignored | No user impact | Double load |
2. Implementation #
Weighted services and switching.
Canary with the file provider #
http:
services:
app:
weighted:
services:
- name: app-v1@docker
weight: 90
- name: app-v2@docker
weight: 10
sticky:
cookie: { name: version } # un utilisateur reste sur la même version
routers:
app:
rule: Host(`app.exemple.fr`)
service: appCanary in Kubernetes (TraefikService) #
apiVersion: traefik.io/v1alpha1
kind: TraefikService
metadata: { name: app-canary, namespace: app }
spec:
weighted:
services:
- { name: app-v1, port: 80, weight: 90 }
- { name: app-v2, port: 80, weight: 10 }Blue/green and mirroring #
For blue/green, you change the service targeted by the router (app-blue → app-green); with the file provider, the switch is applied on the fly. Mirroring copies a share of traffic to a test version:
http:
services:
app-miroir:
mirroring:
service: app-v1@docker
mirrors:
- { name: app-v2@docker, percent: 20 }3. Best practices #
Deploying without fear.
Rules #
- Define success criteria in advance (error rate, p95 latency) and monitor them per service.
- Make database migrations compatible with both versions (expand / contract).
- Automate progression and rollback rather than changing weights by hand: that is Flagger's role (next article).
- Health checks on services so that Traefik automatically removes a failing instance.
