MongoDB en Docker: acceso, roles y datos persistentes
MongoDB en Docker permite practicar una base documental con autenticación y datos persistentes. Este ejemplo utiliza la imagen oficial mongo de la familia 8.0 y evita publicar un puerto: las primeras comprobaciones se realizan desde dentro del contenedor.
Comprueba arquitectura y soporte de la versión antes de utilizarla. El diseño es de laboratorio y no constituye un replica set ni una plataforma de alta disponibilidad.
Prepara secreto y volumen
mkdir -p mongo-lab/secrets
cd mongo-lab
umask 077
openssl rand -base64 32 > secrets/admin.txt
printf 'secrets/\n*.archive\n' > .gitignore
docker volume create mongo_lab_dataProtege el secreto y sus copias. Las variables de inicialización se aplican a un directorio vacío; cambiar el archivo después no rota automáticamente una cuenta existente.
Ejecuta la base
docker run -d --name mongo-lab \
-v mongo_lab_data:/data/db \
--mount type=bind,src="$PWD/secrets",dst=/run/secrets,readonly \
-e MONGO_INITDB_ROOT_USERNAME=admin_lab \
-e MONGO_INITDB_ROOT_PASSWORD_FILE=/run/secrets/admin.txt \
mongo:8.0
docker logs --tail 40 mongo-lab
docker exec -it mongo-lab mongosh \
--username admin_lab --authenticationDatabase admin --passwordIntroduce la contraseña cuando se solicite. La cuenta de inicialización administra la instancia; utiliza otra para la aplicación.
Crea una cuenta limitada
Desde mongosh, cambia a la base de laboratorio y crea un usuario con una contraseña propia mediante el prompt:
use demo
db.createUser({
user: "app_lab",
pwd: passwordPrompt(),
roles: [{role: "readWrite", db: "demo"}]
})La base de autenticación de esta cuenta es demo, no admin. Confundir authSource es una causa frecuente de errores al formar la cadena de conexión.
Prueba documentos
Conecta con la cuenta app_lab y comprueba:
db.notas.insertOne({texto: "Prueba local", estado: "borrador"})
db.notas.find({estado: "borrador"})Una estructura flexible no significa que la aplicación deba aceptar cualquier dato. Valida campos y reglas, y crea índices según consultas reales, no por intuición.
Redes y persistencia
Una aplicación en otro contenedor necesita una red compartida y el nombre del servicio correcto. No uses localhost esperando llegar a MongoDB de otro contenedor.
Reinicia la instancia y consulta los documentos. El volumen conserva datos, pero no los protege de borrado, corrupción o pérdida del host.
Backup y restauración
Utiliza mongodump y mongorestore con versiones y opciones compatibles. Revisa permisos, alcance y consistencia del respaldo para tu topología.
Prueba una copia de la base demo en otra instancia. No restaures sobre la única base importante para demostrar que “funciona”. Protege archivos de exportación porque contienen datos de la aplicación.
Antes de actualizar, consulta compatibilidad y características de la versión. Cambiar una etiqueta mayor sin procedimiento puede hacer que el volumen ya no sea utilizable por la instalación anterior.
Preguntas frecuentes
¿El usuario root de inicialización sirve para la app?
Puede tener más privilegios de los necesarios. Crea roles ajustados a la base y a las operaciones de la aplicación.
¿Por qué falla authSource=admin con mi usuario?
La cuenta puede haberse creado en otra base de autenticación. Comprueba dónde existe y qué permisos tiene.
¿Un contenedor con volumen ya tiene backup?
No. Necesitas una copia independiente y un procedimiento de recuperación comprobado.
En pocas palabras
MongoDB necesita autenticación, roles y almacenamiento adecuados también cuando corre en Docker. El usuario administrativo de inicialización no debe convertirse en la cuenta habitual de cada aplicación.
Conclusión
Verifica operaciones con una cuenta limitada y ensaya recuperación en otro entorno. Mantén secretos y versiones documentados y revisa compatibilidad antes de cambiar la imagen.
Para continuar, revisa Docker: qué es y cómo usarlo para ejecutar contenedores y Cómo instalar Docker en Ubuntu 24.04: guía práctica paso a paso.