Docker Compose para entornos ERP reales

Docker Compose a veces se descarta como una herramienta solo de desarrollo. Para muchos equipos ERP pequeños y medianos, puede ser mucho más útil que eso si se aplica con disciplina.

El valor no está en fingir que Compose reemplaza una plataforma completa de orquestación. El valor está en hacer que los entornos sean explícitos, repetibles y comprensibles.

La paridad entre entornos importa

Los sistemas ERP son sensibles a las diferencias entre entornos. Un módulo puede funcionar en local y fallar en staging porque falta un worker, una ruta de archivos es distinta, una cabecera del proxy no está configurada o PostgreSQL tiene una extensión o versión diferente.

Compose ayuda al hacer visible la forma del sistema:

• Contenedores de aplicación.
• PostgreSQL.
• Workers de cola.
• Proxy inverso.
• Mail catcher o servicio de correo saliente.
• Jobs de backup.
• Integración con object storage.
• Herramientas solo de desarrollo.

Cuando desarrolladores y operadores comparten el mismo modelo mental, depurar es más rápido.

Separa responsabilidades por archivo

Una estructura práctica es mantener un archivo Compose base y añadir archivos específicos por entorno. Desarrollo puede exponer puertos y montar código fuente. Testing puede usar bases de datos aisladas y servicios deterministas. Entornos similares a producción pueden usar volúmenes nombrados, políticas de reinicio más estrictas, redes externas y configuración real de proxy.

Esto mantiene el stack consistente sin obligar a todos los entornos a comportarse exactamente igual.

Trata los datos como el activo crítico

En sistemas ERP, la base de datos es la memoria del producto. Los contenedores pueden reconstruirse. Las imágenes pueden publicarse de nuevo. El código fuente puede descargarse otra vez. Perder datos es diferente.

Un setup serio con Compose necesita decisiones claras sobre:

• Gestión de volúmenes PostgreSQL.
• Frecuencia y retención de backups.
• Pruebas de restauración.
• Almacenamiento de adjuntos.
• Migraciones de base de datos.
• Control de acceso a dumps de producción.

Mover adjuntos grandes a object storage como S3 puede simplificar backups y reducir presión sobre discos locales, pero también exige manejo claro de fallos y monitorización.

CI/CD debe construir confianza

Compose también ayuda en pipelines CI/CD porque puede levantar los mismos servicios de soporte que usa la aplicación. Los tests pueden ejecutarse contra PostgreSQL real. Linters y pre-commit pueden correr antes de construir imágenes Docker. Los scripts de despliegue pueden simplificarse porque la creación de imágenes, el etiquetado y el arranque de servicios están estandarizados.

Un pipeline útil suele comprobar:

• Formato y linting.
• Tests unitarios e integración.
• Hooks pre-commit sensibles a seguridad.
• Construcción de imágenes Docker.
• Push al registry.
• Pasos de despliegue o release.

Saber cuándo ir más allá de Compose

Compose no es la respuesta a todos los problemas de infraestructura. Si el equipo necesita scheduling automático entre muchos hosts, autoscaling avanzado, service discovery complejo u operaciones multi-región, otra plataforma puede estar justificada.

Pero muchos entornos ERP no fallan porque les falte Kubernetes. Fallan porque los despliegues son manuales, los backups no están claros, los entornos locales divergen y el comportamiento en producción está mal documentado.

Arregla eso primero. Docker Compose puede ser una base sólida cuando el equipo lo trata como infraestructura como código, no como una comodidad temporal.