Docker Compose en producción: volúmenes, redes y secretos sin sorpresas
Publicado el 2026-10-26 por frfrand
Ejemplo de Compose con API y base de datos, persistencia y registros
Una API, PostgreSQL y Redis pueden correr juntos con Docker Compose. Es cómodo para desarrollo y para algunos entornos de producción, pero si no diseñás los volúmenes y secretos vas a descubrir el problema cuando el primer contenedor se recree.
Vamos a convertirlo en un procedimiento que puedas usar en un VPS real. El objetivo es entender por qué funciona, cómo probarlo y qué problema aparece si una parte queda mal configurada.
Qué significa Docker Compose en producción y cuándo lo necesitás
Compose describe servicios, redes y volúmenes en un archivo YAML. Un contenedor es reemplazable; la información importante debe vivir en almacenamiento persistente o un servicio externo gestionado. Las variables no son automáticamente secretos seguros por estar dentro de un archivo YAML.
Antes de cambiar nada en producción, anotá el estado actual: IP, dominio, puerto, servicio afectado y hora del último deploy. Una modificación aislada es fácil de comprobar; cinco cambios simultáneos hacen más difícil reconstruir lo ocurrido.
Configuración o comandos de ejemplo
services:
api:
image: mi-api:1.4.0
ports:
- '127.0.0.1:8000:8000'
depends_on:
- db
db:
image: postgres:17
environment:
POSTGRES_DB: app
POSTGRES_USER: app
# Inyectar PASSWORD de forma segura; no subir a Git
volumes:
- postgres_data:/var/lib/postgresql/data
volumes:
postgres_data:Los dominios, IP, rutas y nombres son ilustrativos. No copies una configuración entera encima de la actual sin comparar primero. En los ejemplos que incluyen puertos o firewall, asegurate de conservar el acceso administrativo.
Cómo lo haría paso a paso
- Preparación. Definí imágenes con tags versionados y comprobá compatibilidad de la versión PostgreSQL.
- Paso 2. Creá volúmenes para bases y subidas de usuarios; no almacenes datos sólo en capas efímeras.
- Paso 3. Restringí puertos: en el ejemplo la API se publica sólo en localhost para un proxy.
- Paso 4. Configurá credenciales con el mecanismo apropiado y evita secretos literales en Compose.
- Verificación. Ejecutá
docker compose config, iniciá servicios, verificá healthchecks y probá restauración.
Cuando termines, comprobá la operación real desde otra conexión. Por ejemplo, para una API no alcanza con abrir el navegador: ejecutá una petición de lectura, una escritura en una base de prueba y consultá los logs del proceso.
Ejemplo de un proyecto de verdad
Un proyecto de alquileres usa FastAPI, worker Celery, Redis y PostgreSQL. Si los cuatro viven en contenedores, podés actualizar la API sin alterar la base; pero una migración de esquema requiere coordinación y backup igual.
La lección es sencilla: una configuración de infraestructura no vive aislada de la aplicación. El frontend, el servidor, la base de datos y los workers se conectan, así que medir dónde empieza el fallo es más útil que reiniciar todo.
El error que evitaría
depends_on no garantiza por sí solo que PostgreSQL esté listo para aceptar conexiones: necesitás healthchecks o reintentos de aplicación. Tampoco uses el ejemplo sin definir contraseña segura ni adaptar versiones.
Cuando trabajás con servidores de clientes, guardá un respaldo o procedimiento de reversión antes de cambios que afecten datos, red o certificados. Y si no sabés qué permisos necesita una operación, evitá ejecutarla como root sólo para que deje de mostrar errores.
¿Cómo se relaciona con ArduMaker?
En ArduMaker podés operar Docker sobre el VPS junto a dominios, servicios y bases. Evitá mezclar volúmenes de clientes distintos y documentá qué Compose corresponde a cada proyecto.
En un caso típico podés crear un VPS para la aplicación, desplegar desde Git, asociar dominio HTTPS y administrar el backend y las bases necesarias. Las herramientas ayudan a centralizar operaciones, pero hay que entender qué puerto y proceso cumple cada función.
Preguntas que aparecen cuando lo probás
¿Cómo sé si el fallo es de DNS o del servicio? Consultá primero la resolución, después la conexión al puerto y finalmente la respuesta de aplicación. Ese orden evita confundir problemas diferentes.
¿Puedo exponer una base para que sea más fácil mantenerla? Mejor diseñá acceso privado o túneles autenticados cuando sea posible. Exponer un puerto no reemplaza los permisos del motor ni el firewall.
¿Qué debería documentar? La configuración esperada, cómo se comprueba y cómo volver al estado anterior. Ese documento te ayuda más que una lista de comandos sin contexto.
Referencias
En resumen: una buena configuración de red o servidor es la que podés explicar, verificar y recuperar cuando algo falla.