1. ¿Por qué mi servidor se detiene en cada despliegue?

Al trabajar en proyectos personales, a menudo me topo con entornos de recursos limitados (instancias micro de GCP, Raspberry Pi, etc.). Yo administro varias máquinas: desde servidores potentes para inferencia y entrenamiento de IA hasta VMs diminutas que apenas mantienen un servidor de nombres. En particular, adoro la Raspberry Pi 5. Es barata de operar las 24 horas del día y su rendimiento me parece sólido. Si los demás servidores se sienten como ganado bajo cuidado, la Pi es más como una mascota a la que le tienes cariño.

Sin embargo, al sobrecargar a esta “mascota” surgió un problema: durante el despliegue el CPU llegaba al 100 %. El culpable era el Celery Worker. Al lanzar simultáneamente los grupos Blue y Green para un despliegue sin tiempo de inactividad, el número de workers se duplicaba y el sistema no podía absorber la carga. Reducir la cantidad de workers degradaba el rendimiento, pero dejarlos activos hacía que el servidor colapsara. Un verdadero dilema.

Imagen que simboliza el script de automatización en un PC de bajas especificaciones

Para resolverlo creé un script de despliegue Blue‑Green personalizado que minimiza el consumo de recursos y mantiene la estabilidad.

2. Estrategia: ahorrar recursos y elevar la fiabilidad

El despliegue Blue‑Green tradicional levanta ambos entornos al mismo tiempo, pero yo diseñé una variante que reduce la carga del CPU:

  1. Parada preventiva de servicios en segundo plano (Celery): antes de iniciar la nueva versión del servidor web, detengo los procesos pesados (Worker, Beat) de la versión anterior para liberar CPU.
  2. Arranque por etapas: en lugar de levantar todo de una vez, inicio primero Web + Redis y realizo un health‑check.
  3. Human‑in‑the‑loop: una vez finalizada la automatización, el administrador verifica visualmente y, tras su aprobación, elimina la versión anterior.

Al analizar los fallos, descubrí que el pico de CPU ocurre justo cuando los workers de Celery se reinician y comienzan a procesar tareas inmediatamente. Bajar la concurrencia del worker habría sido una solución, pero ralentizaría el procesamiento asíncrono durante el despliegue, lo cual no deseaba.

La idea surgió: mantener la continuidad del despliegue sin tiempo de inactividad, pero detener temporalmente a los workers de Celery para liberar CPU antes de lanzar el nuevo código.

3. Código esencial

Todo el script está disponible en mi repositorio de GitHub. A continuación, algunos fragmentos clave.

① Aislamiento de proyectos con Docker Compose

Uso la opción -p de docker compose para crear dos proyectos (o namespaces) llamados blue y green a partir del mismo archivo de configuración.

dc() {
  # Define dinámicamente el nombre del proyecto (-p) para aislar entornos
  docker compose -f "$COMPOSE_FILE" "$@"
}

② Health Check exhaustivo

No se cambia el tráfico hasta que la nueva versión pasa todas las verificaciones.

health_check() {
  # Reintenta hasta 10 veces hasta que el puerto responde 200 OK
  if curl -fsSIL --max-time "$HEALTH_TIMEOUT" "$url"; then
    ok "Health check passed"
    return 0
  fi
}

③ Recuperación silenciosa en caso de fallo

Si la nueva versión falla, se reactiva inmediatamente la anterior para que el usuario no perciba interrupciones. En lugar de eliminar por completo los workers y beat de la versión previa, los detengo con stop para poder volver aIZER rápidamente y liberar CPU.

4. Buenas prácticas operativas: la estética de “verificar antes de eliminar”

El script finaliza mostrando un mensaje al administrador en lugar de borrar automáticamente la versión antigua.

"El despliegue se completó con éxito. Por favor, verifica manualmente. Si todo está correcto, copia el comando abajo para limpiar la versión anterior."

Esta pequeña medida previene el 1 % de errores que la automatización podría pasar por alto.

5. Conclusión

Este script encierra la reflexión y los ajustes necesarios para obtener el máximo rendimiento con recursos limitados. Aunque es un código sencillo, lo utilizo a diario y confío en que otros desarrolladores con entornos similares lo encontrarán útil.

Enlaces relacionados: