¿Qué estrategia de despliegue funciona en un único host con Docker Compose y proxy inverso?

Pregunta abierta

Las estrategias de despliegue de los orquestadores presuponen varias instancias, un controlador y una distribución del tráfico que se puede gobernar. En un único host con Docker Compose se dispone de poco de todo eso: docker compose up -d normalmente sustituye al contenedor en marcha, y entre que el antiguo se detiene y el nuevo está listo, el proxy responde con un error. La especificación de Compose sí conoce, en la sección deploy, update_config con order: start-first (la nueva tarea arranca primero, con una breve superposición) y un rollback_config; si el modo de operación de Compose que cada equipo usa —sin orquestador— llega a implementar esto, y cómo, forma parte de la pregunta. Los proxies inversos como Traefik ofrecen una distribución ponderada (weighted round robin) entre servicios, con la que podría imitarse un canary. En concreto:

• ¿Qué imitación han mantenido en producción durante meses los equipos pequeños en la práctica: dos contenedores con nombre (azul/verde) con la regla del proxy conmutada, un segundo contenedor con healthcheck y comportamiento start-first, distribución ponderada en el proxy, o sencillamente una breve interrupción con página de mantenimiento?
• ¿Qué se ha roto con ello: migraciones de base de datos que no toleran ambas versiones a la vez; volúmenes que solo puede mantener un contenedor; conexiones largas (WebSockets, subidas de archivos) que se cortan al conmutar; configuración del proxy que se mantiene a la vez por archivo y por etiqueta del contenedor?
• ¿Cómo se probó la vuelta atrás (rollback): como ensayo antes de un caso real, o solo en el caso real?
• ¿A partir de qué número de servicios, de despliegues por semana o de usuarios han vivido los equipos el paso a un orquestador como algo que compensa, y qué los frenaba antes de eso?
• ¿Existen mediciones de la duración real de la interrupción con un simple up -d con healthcheck, frente a una imitación de blue-green?

Qué contiene una respuesta útil

El tamaño del host y de los servicios, el proxy y la versión de Compose, la imitación exacta con un fragmento de configuración, el tiempo que lleva en producción, las roturas que se han producido con su causa, la duración de la interrupción medida o estimada (indicando qué se midió), y si la solución ha sobrevivido a un cambio de personal. Las propuestas sin experiencia real en producción son bienvenidas si se señalan como tales.