El despliegue que no podía recrear su propio contenedor

Dos despliegues seguidos fallaron con el mismo error de Docker, y ninguno fue culpa de nuestro código. Un conflicto de nombre de contenedor atascó toda la pila. Esto es lo que lo deja atrás, y cómo hacer que el despliegue se repare solo.

El error

Container app  Recreate
Error response from daemon: Conflict. The container name
"/ab03b9ef_app" is already in use by container "4619ca...".

La imagen se construyó bien. La falla ocurrió en el paso de recreación, y detuvo el despliegue en seco.

Qué lo deja atrás

Cuando docker compose up recrea un servicio, renombra el contenedor antiguo a un <hash>_<name> temporal antes de crear el nuevo y eliminar el antiguo. Si esa secuencia se interrumpe —un despliegue cancelado, un reinicio del host, un OOM—, el contenedor renombrado sobrevive. Ahora un contenedor ocupa un nombre que Compose espera que esté libre, y el siguiente up no puede reclamarlo. Todos los despliegues posteriores chocan con el mismo conflicto hasta que alguien elimina el huérfano a mano.

La solución de una línea

Compose puede limpiar esto por sí mismo:

docker compose up -d --build --remove-orphans

--remove-orphans elimina los contenedores del proyecto que no están en el archivo compose actual —incluido el residuo renombrado extraviado— antes de recrear. Como defensa en profundidad, añada una comprobación previa que elimine a la fuerza cualquier contenedor cuyo nombre coincida con el servicio pero que no sea el gestionado por compose.

Por qué vale la pena automatizarlo

• No es su código. Una versión perfectamente buena falla por el estado del host que dejó una ejecución anterior interrumpida. Sin autorreparación, cada despliegue está a una mala interrupción de una visita manual al host.
• Falla en el peor momento. La compilación tiene éxito, así que usted cree que está desplegando; entonces la recreación se atasca y, si tiene reversión automática, esta se activa y la versión silenciosamente no se lanza.
• La solución manual no escala. "Entrar por SSH y hacer docker rm del huérfano" está bien una vez. No es una estrategia de despliegue.

Conclusión

Un despliegue debería poder recuperarse de su propia ejecución anterior interrumpida. Si su paso de recreación puede atascarse por un contenedor residual, añada --remove-orphans (o una limpieza previa) para que el siguiente despliegue repare la pila en lugar de fallar por ella.