I want to have a MongoDB service running in a Docker in order to serve a Flask app. What I've tried is create a container using docker-compose.yml:
my_mongo_service:
image: mongo
environment:
- MONGO_INITDB_ROOT_USERNAME=${MONGO_ROOT_USER}
- MONGO_INITDB_ROOT_PASSWORD=${MONGO_ROOT_PASSWORD}
- MONGO_INITDB_DATABASE=${MY_DATABASE_NAME}
ports:
- "27017:27017"
volumes:
- "/data/db:/data/db"
command: mongod
Imagine we have an .env file like this:
MONGO_ROOT_USER=my_fancy_username
MONGO_ROOT_PASSWORD=my_fancy_password
MY_DATABASE_NAME=my_fancy_database
What I would expect (reading the doc) is that a database matching MY_DATABASE_NAME value is created and an user matching MONGO_ROOT_USER is created too and I could authenticate with the pair (MONGO_ROOT_USER,MONGO_ROOT_PASSWORD).
Ok, I launch my container with docker-compose up and enter on it with docker exec -it <container-id> bash. I put mongo on the console and when I try to authenticate it crashes:
> use my_fancy_database
switched to db my_fancy_database
> db.auth('my_fancy_username','my_fancy_password')
Error: Authentication failed.
0
On the log, the error I find is the following
[...] authentication failed for my_fancy_username on my_fancy_database from client [...] ; UserNotFound: Could not find user my_fancy_username#my_fancy_database
The docker-compose.yml configuration (as it was posted on official documentation) is not working. What I'm doing wrong?
Thanks in advance.
I don't get it. Are you using environmental variables, which are not in the environment? It sure looks so.
If you do echo $MY_DATABASE_NAME in your terminal and see empty output, then here is the answer to your question. You either first have to define the variable with export (or source for a file) or redefine your docker-compose.yml.
For that, it's best to use env_file directive:
my_mongo_service:
image: mongo
env_file:
- .env
ports:
- "27017:27017"
volumes:
- "/data/db:/data/db"
And set your .env as this:
MONGO_INITDB_ROOT_USERNAME=my_fancy_username
MONGO_INITDB_ROOT_PASSWORD=my_fancy_password
MONGO_INITDB_DATABASE=my_fancy_database
Side note: using command: mongod is not necessary, the base image is already using it.
Related
I am trying to secure a mongoDB docker container and am stumped by the authentication.
So far, in my docker compose file, I am setting root environment variables, but I am unable to connect to the mongoDB from outside of the container. Without setting auth, I have no such issues.
services:
mongodb:
image: mongo:latest
restart: always
ports:
- "27017:27017"
command: ["--auth"]
environment:
- MONGO_INITDB_ROOT_USERNAME=root
- MONGO_INITDB_ROOT_PASSWORD=root
I've tried to connect to mongodb://root:root#localhost:27017 using MongoDB Compass tool, but I keep getting authentication errors.
I am assuming that the root user is already created since I am getting authentication errors. I have tried using a script to create a user, but still I could not connect.
Try without command: ["--auth"]
Environment variables that you have provided should already turn this option on. Let me know, if that works.
I am running a simple django webapp with docker-compose. I define both a web service and a db service in a docker-compose.yml file:
version: "3.8"
services:
db:
image: postgres
volumes:
- postgres_data:/var/lib/postgresql/data
environment:
- POSTGRES_DB=postgres
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=postgres
web:
build: .
command: python manage.py runserver 0.0.0.0:8000
ports:
- "8000:8000"
env_file:
- ./.env.dev
depends_on:
- db
volumes:
postgres_data:
I start the service by running:
docker-compose up -d
I can load some data in there with a custom django command that I wrote for my app. Everything is running fine (with data) on localhost:8000.
However, when I run
docker-compose down
(so without -v) and then again
docker-compose up -d
the database is empty again. The volume was not persisted. From what I read in the docker-compose docs and also in several posts here at SO, persisting the volume and reusing it when you start a new container should be the default behavior (which, if I understand it correctly, you can disable by using the --renew-anon-volumes flag).
However in my case, the volume is not persisted. Or maybe it is, but my data is gone.
By doing docker volume ls I can see that my volume (I'll use the name my_volume here) still exists after the docker-compose down command. However, the CreatedAt value has been changed. This makes me think it's a different volume with the same name, and my data is already gone, but I don't know how to confirm that.
This SO answer suggests to mount the volume on /var/lib/postgresql instead of /var/lib/postgresql/data. However, I've seen other resources (like this one) where the opposite is suggested. I've tried both, but neither option works.
Thanks for any advice.
It turns out that the Dockerfile of my app was using an entrypoint in which the following command was executed: python manage.py flush which clears all data in the database. As this gets executed every time the app container starts, it clears all data. It had nothing to do with docker-compose.
I'm running MongoDB inside a larger server, controlled by docker-compose.
I'd like to reduce the verbosity of the Mongo logs (and probably eventually control other Mongo settings too). Not sure where to fit this into my minimal config; I currently just have:
mongo:
image: mongo:3.2
volumes:
- ${MONGO_DATA_DB}:/data/db
ports:
- ${EXPOSED_MONGO_PORT}:27017
I've tried the accepted answer but mongo log was still quite verbose. Then, following this thread, I've omitted the whole log and it's much better in my case:
mongo:
command: mongod --quiet --logpath /dev/null
Reading the description of the official image of MongoDB at DockerHub (same image you are using) I deduced that you can pass commands to mongod using command section of the docker-compose. Then you could use the --quiet option to limit the amount of output.
In this way you docker-compose would be as follows:
mongo:
image: mongo:3.2
volumes:
- ${MONGO_DATA_DB}:/data/db
ports:
- ${EXPOSED_MONGO_PORT}:27017
command: --quiet
You can find the entire list of options that mongod accepts here or also check the --help output of mongod in your bash.
Sometimes docker images, accepts configuration params as an environment variables, so you could change the configuration of the service at runtime. Sadly I couldn't find any official information about available environment variables in this docker image, but I encourage you to continue investigating about this alternative path.
I hope it helps!
EDIT
Another approach from the image documentation:
For a more complicated configuration setup, you can still use the MongoDB configuration file. mongod does not read a configuration file by default, so the --config option with the path to the configuration file needs to be specified. Create a custom configuration file and put it in the container by either creating a custom Dockerfile FROM mongo or mounting it from the host machine to the container. See the MongoDB manual for a full list of configuration file options.
For example, /my/custom/mongod.conf is the path to the custom configuration file. Then start the MongoDB container like the following:
$ docker run --name some-mongo -v /my/custom:/etc/mongo -d mongo --config /etc/mongo/mongod.conf
In this way, your docker-compose would be as follows:
mongo:
image: mongo:3.2
volumes:
- ${MONGO_DATA_DB}:/data/db
- ${MONGO_DATA_CONFIG}:/etc/mongo/
ports:
- ${EXPOSED_MONGO_PORT}:27017
command: --config /etc/mongo/mongod.conf
Setting logpath worked for me. It's not showing the logs output instead it's saving to the file.
mongo:
container_name: mongo
image: mongo
restart: unless-stopped
command:
- '--logpath'
- '/var/log/mongodb/mongod.log'
ports:
- '27017:27017'
An alternative MongoDB image by Bitnami offers this functionality via environment variables in compose file.
https://hub.docker.com/r/bitnami/mongodb. Explained in the section Configuring system log verbosity level
On my distant server, I use a docker container started with:
MONBULDING_PORT="8080" docker-compose up -d --no-deps --build monbulding-mongo
It works pretty well if I don't set any username/password to authenticate.
Here is the corresponding docker-compose.yaml file:
monbulding-mongo:
image: mongo:latest
ports:
- "27017:27017"
Now, if I want to set a username/password to access to MongoDB, I change this file into:
monbulding-mongo:
image: mongo:latest
ports:
- "27017:27017"
environment:
- AUTH=yes
- MONGODB_ADMIN_USER=admin
- MONGODB_ADMIN_PASS=password
- MONGODB_APPLICATION_DATABASE=app
- MONGODB_APPLICATION_USER=user
- MONGODB_APPLICATION_PASS=password
And if I try to log in to MongoDB using Robo 3T, it doesn't work:
Someone know what I do wrong ?
Thanks!
EDIT :
I also tried with mongo shell:
mongo --host domain.net -u admin -p password
But there is an error too.
If you are using this: https://github.com/aashreys/docker-mongo-auth it creates a file /data/db/.mongodb_password_set after creating the user, so next time it skips the user creation. If you need to force it to create another user make sure to remove that file
I am playing with MongoDB and Docker and at this point I am trying to create a useful image for myself to use at work. I have created the following Dockerfile:
FROM mongo:2.6
VOLUME /data/db /data/configdb
CMD ["mongod"]
EXPOSE 27017
And I have added it to my docker-compose.yml file:
version: '2'
services:
### PHP/Apache Container
php-apache:
container_name: "php55-dev"
image: reynierpm/php55-dev
ports:
- "80:80"
environment:
PHP_ERROR_REPORTING: 'E_ALL & ~E_DEPRECATED & ~E_NOTICE'
volumes:
- ~/mmi:/var/www
- ~/data:/data
links:
- mongodb
### MongoDB Container
mongodb:
container_name: "mongodb"
build: ./mongo
environment:
MONGODB_USER: "xxxx"
MONGODB_DATABASE: "xxxx"
MONGODB_PASS: "xxxx"
ports:
- "27017:27017"
volumes:
- ~/data/mongo:/data/db
I have some questions regarding this setup I have made:
Do I need VOLUME /data/db /data/configdb at the Dockerfile or would be enough to have this line ~/data/mongo:/data/configdb at docker-compose.yml?
I am assuming (and I took it from here) that as soon as I build the Mongo image I will be creating a database and giving full permissions to the user with password as it's on the environment variables? I am right? (I couldn't find anything helpful here)
How do I import a current mongo backup (several JSON files) into the database that should be created on the mongo container? I believe I need to run mongorestore command but how? do I need to create an script and run it each time the container start? or should I run during image build? What's the best approach?
Do I need VOLUME /data/db /data/configdb at the Dockerfile or would be enough to have this line ~/data/mongo:/data/configdb at docker-compose.yml?
VOLUME is not required when you are mounting a host directory but it is helpful as metadata. VOLUME does provide some special "copy data on volume creation" semantics when mounting a Docker volume (non host dir) which will impact your data initialisation method choice.
am assuming (and I took it from here) that as soon as I build the Mongo image I will be creating a database and giving full permissions to the user with password as it's on the environment variables? I am right? (I couldn't find anything helpful here)
MONGO_USER, MONGO_DATABASE and MONGO_PASS do not do anything in the official mongo Docker image or to mongod itself.
The mongo image has added support for similar environment variables:
MONGO_INITDB_ROOT_USERNAME
MONGO_INITDB_ROOT_PASSWORD
MONGO_INITDB_DATABASE
How do I import a current mongo backup (several JSON files) into the database that should be created on the mongo container? I believe I need to run mongorestore command but how? do I need to create an script and run it each time the container start? or should I run during image build? What's the best approach?
Whether you initialise data at build or runtime is up to your usage. As mentioned previously, Docker can copy data from a specified VOLUME into a volume it creates. If you are mounting a host directory you probably need to do the initialisation at run time.
mongorestore requires a running server to restore to. During a build you would need to launch the server and restore in the same RUN step. At runtime you might need to include a startup script that checks for existence of your database.
Mongo is able to initialise any empty directory into a blank mongo instance so you don't need to be worried about mongo not starting.