MongoDB
Explica cómo ejecutar MongoDB en Docker con volúmenes, redes, variables, health checks y replica sets reproducibles para desarrollo y CI.
Docker empaqueta MongoDB con una versión, configuración, red y filesystem reproducibles. Es excelente para desarrollo, CI y entornos controlados, pero no convierte automáticamente un contenedor en una base de datos productiva y resiliente.
image fija
→ container
→ volume persistente
→ network privada
→ configuración y secretsEl contenedor es reemplazable; los datos y la configuración operacional no deben depender de su filesystem efímero.
Fija una versión explícita:
services:
mongo:
image: mongo:8.0Evita latest, porque una recreación podría introducir una versión distinta sin revisión. Para producción fija incluso una versión más concreta según política de upgrades.
volumes:
mongo_data:
services:
mongo:
volumes:
- mongo_data:/data/dbSin volumen, recrear el contenedor elimina los data files. Un volume protege persistencia local, pero no es backup: un delete, corrupción o pérdida del host afecta el mismo volumen.
services:
mongo:
image: mongo:8.0
restart: unless-stopped
ports:
- "127.0.0.1:27017:27017"
environment:
MONGO_INITDB_ROOT_USERNAME: root
MONGO_INITDB_ROOT_PASSWORD_FILE: /run/secrets/mongo_root_password
secrets:
- mongo_root_password
volumes:
- mongo_data:/data/db
healthcheck:
test: ["CMD", "mongosh", "--quiet", "--eval", "db.adminCommand('ping')"]
interval: 10s
timeout: 5s
retries: 10Publicar solo en 127.0.0.1 evita exposición directa desde otras interfaces durante desarrollo.
La imagen ejecuta scripts de /docker-entrypoint-initdb.d solo cuando inicializa un directorio de datos vacío.
Esto sorprende cuando cambias el script y reinicias con el mismo volume: no se vuelve a ejecutar.
Usa init scripts para bootstrap inicial, no como sistema de migrations recurrentes.
No escribas passwords en docker-compose.yml versionado. Usa Docker secrets, secret manager o archivos fuera del repositorio.
Tampoco incluyas keyfiles, certificados o .env reales dentro de la image.
En Compose, la aplicación puede conectar por nombre de servicio:
mongodb://app-user:secret@mongo:27017/app?authSource=adminNo uses localhost desde otro container: allí apunta al propio container de la aplicación.
Mantén MongoDB en una network interna y publica el puerto solo cuando sea necesario.
Un proceso mongod vivo no significa que el replica set tenga primary o que la autenticación esté lista.
Para una aplicación que necesita transactions, el readiness debe confirmar topología y capacidad real, no solo que el puerto responde.
Transactions y Change Streams requieren replica set. Configuración conceptual:
command: ["mongod", "--replSet", "rs0", "--bind_ip_all"]Después:
rs.initiate({
_id: 'rs0',
members: [
{ _id: 0, host: 'mongo:27017' }
]
});El hostname anunciado debe ser resoluble desde los clientes. Configuraciones con localhost suelen fallar cuando la app vive en otro container.
Un replica set autenticado necesita mecanismo para comunicación interna entre miembros, como keyfile o X.509 según deployment.
El keyfile debe:
Configura CPU y memoria con margen. MongoDB detecta el entorno, pero límites agresivos pueden causar:
Monitorea el consumo real y no uses límites solo para “evitar que MongoDB use RAM”; la memoria es parte de su diseño.
Bind mounts dependen de permisos, usuario, filesystem y rendimiento del host. Un volume administrado suele ser más portable para desarrollo.
En producción valida:
Docker envía SIGTERM y luego fuerza termination después de un grace period. Permite tiempo suficiente para shutdown limpio.
No uses docker kill como rutina. Prueba:
docker stop --time 60 mongoEl tiempo correcto depende de workload y entorno.
Un backup no debe ser simplemente copiar /data/db mientras MongoDB escribe. Usa herramientas y snapshots consistentes soportados.
Guarda copias fuera del volume y prueba restore en otro container o cluster.
Los logs del container deben enviarse a un sistema con rotación. Sin límites pueden llenar el disco del host.
No registres URIs con passwords ni datos sensibles.
Proceso:
No saltes varias versiones sin seguir la ruta soportada.
Ejecutar MongoDB en Docker puede ser válido, pero requiere resolver:
Una sola instancia Compose en un VPS no ofrece alta disponibilidad aunque tenga restart: always.
Docker da control y responsabilidad operacional. Atlas ofrece servicio administrado con backups, monitoring y automation, pero mantiene responsabilidades de schema, índices, usuarios, red y costes.
latest;0.0.0.0:27017;/data/db como backup;Docker hace reproducible el proceso, no la operación completa. Fija versiones, persiste /data/db, protege red y secrets, configura replica set cuando sea necesario y diseña backup, shutdown y upgrade. Un volume conserva datos; no los recupera ante errores lógicos o pérdida del host.
latest?MongoDB Atlas.