Blue-Green y reversiones

Cada despliegue en sh0 usa una estrategia blue-green para lanzamientos sin tiempo de inactividad. Si algo sale mal, revierte a cualquier versión anterior instantáneamente.

Despliegues blue-green

El despliegue blue-green es una estrategia de lanzamiento que elimina el tiempo de inactividad al ejecutar dos entornos idénticos en paralelo. En todo momento, un entorno (blue) atiende el tráfico en producción mientras el otro (green) está inactivo o siendo actualizado con la nueva versión.

Cuando despliegas una nueva versión, sh0 inicia el nuevo contenedor junto al actual. Una vez que el nuevo contenedor pasa las verificaciones de salud, el tráfico se cambia instantáneamente del contenedor anterior al nuevo. El contenedor anterior se mantiene en ejecución brevemente como respaldo antes de apagarse.

Cómo lo implementa sh0

Este es el proceso paso a paso que sh0 sigue para cada despliegue:

1. Compilación: La nueva imagen Docker se construye a partir de tu código fuente o se descarga de un registro
2. Iniciar contenedor green: Se inicia un nuevo contenedor con la imagen actualizada, conectado a la misma red y volúmenes que el contenedor actual
3. Verificación de salud: sh0 ejecuta verificaciones de salud contra el nuevo contenedor (endpoint HTTP, puerto TCP o comando personalizado)
4. Ejecutar hooks pre-despliegue: Si están configurados, los hooks pre-despliegue se ejecutan contra el nuevo contenedor (por ejemplo, migraciones de base de datos)
5. Cambio de tráfico: La configuración del proxy inverso de Caddy se actualiza para enrutar todo el tráfico al nuevo contenedor
6. Ejecutar hooks post-despliegue: Se ejecutan los hooks post-despliegue (por ejemplo, limpieza de caché, notificaciones)
7. Drenar contenedor anterior: El contenedor anterior tiene un período de gracia (predeterminado: 30 segundos) para terminar de procesar las solicitudes en curso
8. Detener contenedor anterior: El contenedor anterior se detiene y se elimina

El cambio de tráfico ocurre a nivel del proxy inverso (Caddy), lo que significa que es instantáneo. No hay brecha entre detener el contenedor anterior e iniciar el nuevo -- ambos se ejecutan simultáneamente durante la transición.

Despliegues sin tiempo de inactividad

Dado que el contenedor anterior continúa sirviendo tráfico hasta que el nuevo se verifica como saludable, tus usuarios nunca experimentan tiempo de inactividad durante los despliegues. La transición es fluida:

• Sin errores 502 durante el despliegue
• Sin conexiones caídas ni solicitudes perdidas
• Sin ventanas de mantenimiento requeridas
• Las conexiones WebSocket en el contenedor anterior se completan de forma natural

Verificaciones de salud

Las verificaciones de salud son críticas para los despliegues sin tiempo de inactividad. sh0 admite tres tipos de verificaciones de salud:

{
  "healthcheck": {
    "type": "http",
    "path": "/health",
    "interval": 10,
    "timeout": 5,
    "retries": 3,
    "start_period": 30
  }
}

Historial de despliegues

sh0 mantiene un historial completo de cada despliegue para cada aplicación. El historial de despliegues incluye:

• Estado del despliegue (exitoso, fallido, revertido)
• SHA del commit de Git y mensaje
• Etiqueta y digest de la imagen Docker
• Duración de la compilación y del despliegue
• Quién activó el despliegue (usuario, webhook o API)
• Registro completo de compilación

Haz clic en cualquier despliegue para ver su registro completo de compilación, resultados de ejecución de hooks y salida de verificaciones de salud. El despliegue actualmente en producción se resalta en la lista.

Reversión con un clic

Si un despliegue introduce un error o un problema de rendimiento, puedes revertir a cualquier versión anterior desde el historial de despliegues. Haz clic en el botón Revertir junto a cualquier despliegue exitoso anterior para redesplegar esa versión instantáneamente.

Una reversión sigue el mismo proceso blue-green que un despliegue regular: la imagen Docker de la versión anterior se usa para iniciar un nuevo contenedor, se ejecutan verificaciones de salud y se cambia el tráfico. Esto significa que las reversiones también son sin tiempo de inactividad.

Reversión vía API

También puedes activar reversiones programáticamente usando la API de sh0. Esto es útil para reversiones automáticas activadas por sistemas de monitoreo.

# Rollback to a specific deployment ID
curl -X POST https://your-sh0-server.com:9000/api/apps/{app_id}/rollback \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"deploy_id": "deploy_abc123"}'

# Rollback to the immediately previous version
curl -X POST https://your-sh0-server.com:9000/api/apps/{app_id}/rollback \
  -H "Authorization: Bearer YOUR_TOKEN"

Cuando no se especifica un deploy_id, sh0 revierte al despliegue exitoso más reciente anterior al actual.

Comportamiento de la reversión

Detalles importantes sobre cómo funcionan las reversiones:

• Solo código: Las reversiones revierten el código de la aplicación (imagen Docker) pero no revierten los cambios de base de datos. Si tu despliegue incluyó una migración de base de datos, es posible que necesites escribir una migración inversa manualmente.
• Variables de entorno: Las reversiones usan las variables de entorno actuales, no las variables del momento del despliegue original. Esto garantiza que los secretos y la configuración actualizados permanezcan vigentes.
• Los hooks se ejecutan: Los hooks pre-despliegue y post-despliegue se ejecutan durante una reversión, tal como lo harían durante un despliegue normal.
• Entrada en el historial: Las reversiones crean una nueva entrada en el historial de despliegues con una etiqueta de "reversión", mostrando qué despliegue se restauró.