
Unblock product innovation with safe, high-fidelity data de-identification and synthesis.
We have all lamented, with great chagrin, the proverbial "works on my machine" problem because data is different across different development environments.
Wouldn't it be ideal if we could deploy our MongoDB database state from a single repository on all development environments?
In this tutorial, we will be dockerizing a Mongo database with some seed data so we can do just that!
docker-compose.yml will orchestrate our two containers; one holding the actual database, the other acting as a client 'seeder' to seed our data.Dockerfile will be the Docker file for our custom Mongo client 'seeder'.start.sh will contain the majority of the work we will have our 'seeder' execute as apart of its CMD instruction.collections contains the JSON files representing the seed data we want in our Mongo container.docker-compose.yml. Edit it so that it has the following: my_mongo, where our Mongo database will live:image: mongo pulls the Mongo image from Docker Hubports: maps local port 27019 to port 27017 (Mongo's default port) in the container. We pick 27019 to avoid conflicting with any Mongo already running on the host machine.environment: set environment variables for Mongo to configure the root user credentials. docker-compose up -d in the TonicMongoDockerTutorial_start directory. Fill in connection fields individually, select authentication: username/password, and fill in the following parameters: localhost 27019 root rootpassword admin, config, and local. Now let's set it up with some seed data!Dockerfile so that it looks like:FROM mongo pulls the Mongo image from Docker Hub; this gives the container the ability to use a Mongo client to seed the data.COPY collections/Restaurants.json /collections/Restaurants.json copies the collection JSON into the seeder container.ADD start.sh /start.sh adds the shell script (detailed in Step 4) into the container.RUN chmod +x /start.sh makes the script executable in the container.CMD ["/start.sh"] runs the script when the container starts.start.sh: my_mongo container. Most of this should be self-explanatory:sleep 10 waits for 10 seconds to give my_mongo enough time to start up.--host my_mongo specifies the host name of the my_mongo container. Our Docker compose will make sure this resolves!--db tutorial_db names the database we want to put our collection in. It will auto create the DB if it does not exist. docker-compose.yml.mongo_seeder is our container name.image: mongo_seeder will be the image name for when we build our Dockerfile.depends_on makes it so we can access my_mongo as a host name in start.sh as mentioned in Step 4. TonicMongoDockerTutorial_start directory. docker build -f Dockerfile -t mongo_seeder . docker-compose up -d TonicMongoDockerTutorial_start directory with the following contents called setupUsers.js: listCollections, find, and listDatabases privilege actions to the Restaraunts collection, and no privilege to the Users collection. This should give us just enough to be able to view only Restaurants documents, but not edit them in MongoDB Compass. setupUsers.js is copied into the container in Dockerfile: setupUsers.js in start.sh:mongosh invokes the Mongo shell with our setupUsers.js file. lowAccessUser, password: lowaccessuserpassword and see we only have access to view documents on the Restaurants collection.setupUsers.js does not have to be just for setting up users. You can do anything there that you can do in the mongo shell.There we have it! Now all you have to do to reproduce your Mongo state anywhere is pull something like this from a repo onto a machine with Docker and run the commands from Step 6. You can download the complete code here: TonicMongoDockerTutorial_final.zip.
Credit to https://gist.github.com/yoobi55/5d36f13e902a75225a39a8caa5556551 for the Restaurant json data.
Unblock product innovation with safe, high-fidelity data de-identification and synthesis.
