Blue-Green y Canary deploy

Blue-Green y Canary deploy

1) Tarea e ideas clave

• Azul-Verde: mantenemos dos versiones paralelas (Azul - activo, Verde - nuevo), cambiamos el tráfico de forma atómica. Retroceso rápido → devolver al instante Blue.
• Canary: incorporamos la nueva versión por etapas (1% → 5% → 25% → 50% → 100%), las métricas SLO de monitor y detenemos/retrocedemos cuando se degradan.

Principio general: separar la «entrega del artefacto» de la «activación del tráfico» y automatizar la observabilidad + retrocesos.

2) Cuándo elegir

• necesita un cambio instantáneo (RTOs duros), servicios simples state-less;
• hay ventanas de liberación/congelación estrictas y controles de smoke comprensibles;
• Es costoso mantener una capacidad doble a largo plazo, pero es posible a corto plazo.

• cambios complejos, se requiere una validación escalonada en el tráfico real;
• hay telemetría madura (SLO, métricas de negocio), posibilidad de auto-parada;
• limitar de forma crítica el radio de la lesión (hilos fintech/iGaming).

Combo-patrón: deslizar Green y cambiarlo a través de las etapas canarias (Blue-Green como marco, Canary como método de transferencia de tráfico).

3) Arquitectura de enrutamiento de tráfico

1. El balanceador L4/L7 (AMB/NLB, Cloud Load Balancer) es un grupo de destino ponderado.

2. API-gateway/WAF - route/weight por versiones, encabezados, cookies, regiones.

3. Mesh de servicio (Istio/Linkerd/Consul) - distribución porcentual, inyección fault, bolígrafos/retraídas/restricciones.

4. Ingress/NGINX/Envoy - upstream-pesos y enrutamiento por atributos.

5. Argo Rollouts/Flagger - operador-controlador, progresión automática, integración con Prometheus/New Relic/Datadog.

4) Kubernetes: plantillas prácticas

4. 1 Azul-Verde (a través del selector de servicio)

Два Deployment: `app-blue` и `app-green`.
Un Servicio 'app-svc' con selector en la 'versión' deseada.

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: app-green, labels: { app: app, version: green } }
spec:
replicas: 4 selector: { matchLabels: { app: app, version: green } }
template:
metadata: { labels: { app: app, version: green } }
spec:
containers:
- name: app image: ghcr. io/org/app:1. 8. 0 apiVersion: v1 kind: Service metadata: { name: app-svc }
spec:
selector: {app: app, version: blue} # ← switch to green - change ports: [{port: 80, targetPort: 8080}]

Conmutación - Cambio atómico del selector (o etiquetas) con drain controlado.

4. 2 Canary (Istio VirtualService)

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService metadata: { name: app }
spec:
hosts: ["app. example. com"]
http:
- route:
- destination: { host: app. blue. svc. cluster. local, subset: v1 }
weight: 90
- destination: { host: app. green. svc. cluster. local, subset: v2 }
weight: 10

Cambie el 'peso' por escalones; añada retry, timeout, outlier-detector a DestinationRule.

4. 3 Argo Rollouts (corrida auto-canaria)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: app }
spec:
replicas: 6 strategy:
canary:
canaryService: app-canary stableService: app-stable steps:
- setWeight: 5
- pause: {duration: 300} # 5 min observation
- analysis:
templates:
- templateName: slo-guard
- setWeight: 25
- pause: { duration: 600 }
- analysis:
templates: [{ templateName: slo-guard }]
- setWeight: 50
- pause: {}
trafficRouting:
istio:
virtualService:
name: app routes: ["http-route"]

El patrón de análisis está relacionado con las métricas (ver más abajo).

5) SLO-gates y auto-retroceso

• Técnicos: 'p95 _ latency', '5xx _ rate', 'error _ budget _ burn',' CPU/Memory throttling '.
• Productos: 'CR (depósito)', 'éxito de pago', 'scoring froda', 'ARPPU' (en ventanas frías).

• Si '5xx _ rate' es la nueva versión> 0. 5% durante 10 min - pause y rollback.
• Si 'p95 _ latency' ↑> 20% de la base es rollback.
• Si va la promoción de Canarias, pero se quema el SLO del presupuesto> 2 %/hora es hold.

yaml apiVersion: argoproj. io/v1alpha1 kind: AnalysisTemplate metadata: { name: slo-guard }
spec:
metrics:
- name: http_5xx_rate interval: 1m successCondition: result < 0. 005 provider:
prometheus:
address: http://prometheus. monitoring:9090 query:
sum(rate(http_requests_total{app="app",status=~"5.."}[5m])) /
sum(rate(http_requests_total{app="app"}[5m]))

6) Datos y compatibilidad (la causa más frecuente del dolor)

• Expansión: añadir nuevos nullable-altavoces/índices, apoyar ambos esquemas.
• Migrate: doble escritura/lectura, back-fill.
• Contrato: elimina los campos/códigos antiguos después de cerrar sesión en el 100% del tráfico.
• Eventos/colas: versionar payload (v1/v2), admitir idempotency.
• Caché/sesiones: versione las claves; asegure la compatibilidad del formato.

7) Integración con CI/CD y GitOps

CI: ensamblaje de un solo artefacto (build once), firma de imagen, SBOM, pruebas.
CD: promoción del artefacto a través de los alrededores; Blue-Green/Canary se rigen por manifiestos.
GitOps: Merge MR → controlador (Argo CD/Flux) aplica pesos/selector.
Environments/Approvals: para prod steps: gate + auditoría manual de soluciones.

8) NGINX/Envoy y LB en la nube: ejemplos rápidos

8. 1 NGINX (peso de los ápice)

nginx upstream app_upstream {
server app-blue:8080 weight=90;
server app-green:8080 weight=10;
}
server {
location / { proxy_pass http://app_upstream; }
}

8. 2 AWS ALB (Weighted Target Groups)

TG-Blue: 90, TG-Green: 10 → cambiar de peso a través de IaC/CLI.
Vincule las alertas CloudWatch a los scripts de auto rollback (cambio de peso a 0/100).

9) Seguridad y cumplimiento

Confianza cero entre versiones: delimite los secretos/claves de encriptación de rolling.
Policy-as-Code: prohibición del despoy de imágenes no firmadas, 'no latest'.
Secretos y confecciones como artefactos de versiones; la reversión incluye la reversión de las configuraciones.
Auditoría: quién, cuando levantó el peso/cambió el selector, con qué ticket.

10) Costo y capacidad

Blue-Green requiere doble potencia para el período de lanzamiento → planificar una ventana.
Canary puede durar más tiempo → el costo de telemetría/observación, el contenido paralelo de las dos versiones.
Optimización: autoscaling por HPA/VPA, ventanas cortas de Blue-Green, lanzamientos nocturnos para servicios «pesados».

11) Revisiones (runbook)

1. Congelar el avance (pause).
2. Reducir el peso de Green a 0% (canario )/devolver el selector a Blue (azul-verde).
3. Comprobar: errores/latencia han vuelto a la base, drenar conexiones.
4. Abrir un incidente, recoger artefactos (registros, pistas, comparación de métricas).
5. Fix/reprodo en el escenario, ahuyentar el humo, reiniciar la progresión.

12) Anti-patrones

Reconfiguración del artefacto entre el escenario y el prod (infracción «build once»).
Un canario «sordo» sin SLO/métricas es una formalidad, no una defensa.
Ausencia de banderas de fichas: el lanzamiento se ve obligado a incluir un comportamiento al 100% a la vez.
Health-checks/liveness inoperantes → podas «empapadas» y falsa estabilidad.
Compatibilidad con el DB «por el tiempo»: el contrato se rompe cuando se cambia.
Etiquetas de imagen mutables/' latest 'en venta.

13) Lista de verificación de implementación (0-45 días)

0-10 días

Elija una estrategia para los servicios: B/G, Canario o combinado.
Habilitar la firma de imágenes, cheques de salud, muestras readiness, 'no latest'.
Preparar dashboards SLO (latency/error rate/métricas de negocio).

11-25 días

Automatizar pesos (Istio/Argo Rollouts/AMB-weights).
Configurar analysis templates, alertas y auto-rollback.
Plantilla los manifiestos (Helm/Kustomize), integra con GitOps.

26-45 días

Implementar la estrategia expand-migrate-contract para la DB.
Cubrir flow crítico kill-switch con banderas.
Celebrar el «día del juego»: simular un retroceso y un incidente.

14) Métricas de madurez

% de lanzamientos a través de Blue-Green/Canary (objetivo> 90%).
Tiempo medio de cambio/retroceso (objetivo <3 min).
Porcentaje de lanzamientos con parada automática por SLO (y sin incidentes).
Cobertura de servicios de telemetría (traces/logs/metrics)> 95%.
Porcentaje de migraciones de DB en el esquema expand-migrate-contract> 90%.

15) Aplicaciones: plantillas de políticas y pipelines

OPA (prohibición de imágenes sin firmar)

rego package admission. image

deny[msg] {
input. request. kind. kind == "Deployment"
some c img:= input. request. object. spec. template. spec. containers[c].image not startswith(img, "ghcr. io/org/")
msg:= sprintf("Image not from trusted registry: %v", [img])
}

Helm-values para Canarias (simplificado)

yaml canary:
enabled: true steps:
- weight: 5 pause: 300
- weight: 25 pause: 600
- weight: 50 pause: 900 sloGuards:
max5xxPct: 0. 5 maxP95IncreasePct: 20

GitHub Actions - Promoción de peso (pseudo)

yaml
- name: Promote canary to 25%
run: kubectl patch virtualservice app \
--type=json \
-p='[{"op":"replace","path":"/spec/http/0/route/1/weight","value":25}]'

16) Conclusión

Blue-Green y Canary no son estrategias mutuamente excluyentes, sino complementarias. Construirlos sobre los artefactos firmados, la observación de SLO, las gatitas automáticas y el control GitOps. Separe la entrega de la inclusión, mantenga la disciplina rápida y las migraciones, y las liberaciones serán predecibles, seguras y rápidas.