RousselTMLEARNING

TP · DevOps: del descubrimiento a la experiencia

Práctica: Promoción de una imagen y despliegue blue/green

Lo que vas a aprender en este TP
  • Aplicar «build once, deploy many»
  • Desplegar en blue/green con smoke test
  • Volver atrás al instante

Introducción #

Lo que vas a aprender en esta sección
  • Aplicar «build once, deploy many»
  • Desplegar en blue/green con smoke test
  • Volver atrás al instante

Contexto. Las puestas en producción provocan diez minutos de interrupción y una vuelta atrás tarda una hora. Implantas un despliegue blue/green con scripts, utilizable tal cual por un pipeline.

Requisitos previos: Docker y Git instalados en tu equipo  ·  Duración estimada: 45 min

Un cambio sin interrupción y una vuelta atrás en segundos.

Puesta en práctica #

Pasos guiados, con su corrección.

  1. 1. Construir y versionar la imagen

    ¿Por qué? La imagen se construye una vez y se identifica con el SHA del commit; la versión nunca se sobrescribe.

    Crea una pequeña aplicación que muestre su versión (leída de una variable de entorno), construye la imagen shop:v1 y arranca un registro local para publicarla.
  2. 2. Montar el enrutador

    ¿Por qué? El enrutador es lo único que se modifica para cambiar: las dos versiones funcionan en paralelo.

    Crea una red Docker, lanza el contenedor blue y un nginx cuyo archivo upstream.conf apunte a blue.
  3. 3. Escribir el script de despliegue

    ¿Por qué? Un script idempotente es lo que llamará un pipeline: arrancar el color inactivo, probar, cambiar o abandonar.

    Escribe deploy.sh IMAGE VERSION: arranca el color inactivo, hace un smoke test sobre /health, cambia nginx con nginx -s reload si todo va bien, o elimina el nuevo contenedor y falla en caso contrario.
  4. 4. Desplegar la v2 sin interrupción

    ¿Por qué? Un bucle de peticiones durante el despliegue demuestra que no hay interrupción.

    En un segundo terminal, consulta el enrutador en bucle. Despliega la imagen con VERSION=v2 (misma imagen, configuración distinta) y observa el cambio.
  5. 5. Bloquear una versión defectuosa

    ¿Por qué? El smoke test es la puerta de salida: una versión rota nunca recibe tráfico.

    Despliega una v3 cuyo control de salud falla (BROKEN=1). El script debe fallar con un código distinto de cero y la v2 debe seguir en servicio.
  6. 6. Volver atrás

    ¿Por qué? En blue/green, la versión anterior sigue ahí: volver atrás es un simple cambio.

    Cambia manualmente el enrutador al color anterior, comprueba y limpia el entorno.

Nivel de dificultad : ●●●○○ (3/5)

Mi seguimiento

  • ⏱ Duración estimada : ≈ 45 min

Inicia sesión para seguir tu progreso y tomar notas. Iniciar sesión

✉️ Hacer una pregunta

Artículos recomendados

CI/CD de bout en bout (3/5) : artefacts, registres et environnements

Livrer en continu : artefacts immuables et versionnés, registres d'images et de paquets, promotio...

CI/CD de bout en bout (4/5) : stratégies de déploiement et retour arrière

Déployer sans interruption et sans risque : recreate, rolling update, blue/green, canary, feature...