El equipo implementó en producción con docker compose up -d en un servidor privado virtual: aplicación, trabajador, caché, proxy inverso. Está funcionando. Seis meses después, el primer incidente real (disco lleno en un único nodo) apagó todo: web, colas, monitoreo. El plan de recuperación habla de "conmutación por error al segundo servidor", pero Compose nunca se configuró para orquestar dos hosts.
Docker Compose se destaca al describir múltiples contenedores y sus enlaces. No es un orquestador de centros de datos. Confundir "Tengo un archivo yaml en funcionamiento" con "Tengo una infraestructura resistente" es costoso en el primer punto único de falla.
Qué hace bien Compose y dónde termina
Compose v2 gestiona dependencias, comprobaciones de estado, volúmenes y redes superpuestas en el mismo motor Docker. Ideal para reproducir la producción localmente y lanzar una pila coherente.
| Necesidad | Redactar | Orquestador (Kubernetes, Nomad) |
|---|---|---|
| Contenedor múltiple en 1 host | ✅ | ✅ (sobredimensionado) |
| Actualización continua sin interrupciones | ⚠️ manual/guión | ✅ nativo |
| Multinodo/anti punto único | ❌ | ✅ |
| Escalado automático horizontal | ❌ | ✅ |
| Secretos de rotación | ⚠️ limitado | ✅ integrado |
En un único servidor con un host europeo, Compose sigue siendo honesto si asume el mantenimiento y las copias de seguridad fuera de Compose.
Componga documentos en su pila; no lo hace mágicamente disponible.
Host único, volúmenes olvidados y copias de seguridad
Los volúmenes con nombre sobreviven a los apagados sin eliminarse: conveniente, pero peligroso si nadie toma instantáneas de la base de datos. Una actualización de imagen actualiza la aplicación pero no actualiza automáticamente la política de copia de seguridad del volumen de PostgreSQL.
Verifique: copias de seguridad probadas fuera del nodo, alertas y monitoreo de disco, registros centralizados, no solo registros de contenedores locales. La subcontratación de la base de datos reduce el riesgo sin necesidad de cambiar inmediatamente a Kubernetes.
Implementación, indisponibilidad y verificación de estado
Sin una verificación de estado, el proxy puede enrutarse a un contenedor que aún se está iniciando: errores temporales del servidor. Patrón: control HTTP en el punto final de la aplicación, proxy que solo envía tráfico a backends en buen estado, script de implementación con espera de estado.
La actualización fluida de múltiples instancias en un solo host sigue siendo artesanal. Aquí es donde los límites se vuelven concretos: estás reinventando lo que los orquestadores hacen de forma nativa.
Red, TLS y exposición de puertos
La publicación del puerto de la base de datos expone PostgreSQL a Internet si el firewall del host es laxo. Prefiere marcaciones de red interna más proxy inverso único en un puerto seguro.
Observabilidad y restricción nocturna.
Compose no proporciona un panel de clúster. Las métricas del contenedor pasan por un agente dedicado, los registros a través de un recopilador, que se agregan explícitamente. Documente quién accede al servidor, cómo reiniciar un servicio, dónde están los archivos del entorno y quién responde a una alerta a las 3 a. m.
La cumbre: Compone como deuda diferida
Decide y avanza sin puntos ciegos
Si permanece en Compose, trate estos puntos como una auditoría antes del próximo incidente:
- Subcontrate la base de datos a una oferta administrada o a copias de seguridad probadas fuera del nodo: el volumen de Docker por sí solo no protege sus datos.
- Agregue comprobaciones de estado en cada servicio expuesto y configure el proxy para enviar tráfico solo a backends en buen estado.
- Pruebe las copias de seguridad con una restauración programada, no solo con la presencia de un script cron.
- Programe la implementación con expectativas de estado y ventana de mantenimiento documentada.
- **Implemente monitoreo centralizado de discos, contenedores y registros. Compose no hace esto de forma nativa.
- Planifique el umbral de migración según el tráfico, el tamaño del equipo y el nivel de servicio prometido a los clientes.
- Simular una falla de disco: ¿cuánto tiempo lleva restaurar el servicio y los datos? Si la respuesta no está clara, Compose aún no está listo para usted.
Compare los hosts adecuados a través del directorio y la comparación.
Preguntas frecuentes
¿Está prevista la producción de Docker Compose?
Compose apunta principalmente a desarrollos e implementaciones simples en uno o varios hosts. En la producción a gran escala, faltan primitivas nativas para la actualización continua de múltiples nodos, el escalado automático y la rotación secreta detallada. Esto no lo prohíbe, pero fija sus límites.
¿Cuándo Compose sigue siendo una buena opción?
En un solo servidor, con un equipo pequeño, una pila estable y tolerancia a una ventana de mantenimiento corta. Las herramientas internas, los MVP y los SaaS en sus primeras etapas a menudo encuentran su lugar, siempre y cuando se asuma y documente el punto único de falla.
¿Cómo gestionar secretos con Compose?
Utilice variables de entorno a través de un archivo sin versión, secretos de Docker en modo enjambre o inyección desde la integración continua hasta la implementación. Nunca envíe contraseñas al repositorio. Revele los secretos después de cualquier filtración sospechosa.
¿Cómo migrar a Kubernetes sin grandes cambios?
Primero externalice el estado (base de datos administrada, caché administrada), conténtelo correctamente y luego transfiera servicio por servicio. Compose y Kubernetes pueden coexistir durante una fase de transición; no es necesario cambiar todo un viernes por la noche.
Compose se mantiene siempre que puedas identificar tu único punto de falla y explicar cómo sobrevives.