Name: mongo-rep-set
Owner: Reaction Commerce
Description: A Dockerized MongoDB for creating a three node replica set across separate hosts.
Created: 2015-07-25 01:44:25.0
Updated: 2018-05-21 11:33:27.0
Pushed: 2017-01-21 07:05:21.0
Size: 17
Language: Shell
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
This MongoDB Docker container is intended to be used to set up a 3 node replica set.
Mongo version: 3.4.0
A MongoDB replica set consists of at least 3 Mongo instances. In this case, they will be a primary, secondary, and an arbiter. To use this project as a replica set, you simply launch three instances of this container across three separate host servers and the primary will configure your users and replica set. Also note that each server must be able to access the others (discovery must work in both directions).
You will need to create your own custom build of this image to generate a unique keyfile that Mongo uses for internal authentication between replica set members. Each of your replica set members needs to have the same key, so be sure to use the same image in each location. Once using your build in production do NOT publish your Docker image to a public repo because it will container your private key.
er build -t yourname/mongo-rep-set:latest .
Now you're ready to start launching containers. You need to launch the secondary and arbiter first so they're ready for the primary to configure them when it starts.
er run -d -p 27017:27017 yourname/mongo-rep-set:latest
The only difference here is you can turn off journaling. From the official docs:
An arbiter does not store data, but until the arbiter?s mongod process is added to the replica set, the arbiter will act like any other mongod process and start up with a set of data files and with a full-sized journal. To minimize the default creation of data, you can disable journaling.
er run -d -p 27017:27017 -e JOURNLING=false yourname/mongo-rep-set:latest
The primary is responsible for setting up users and configuring the replica set, so this is where all of the configuration happens. Once your secondary and arbiter are up and running, launch your primary with:
er run -d
27017:27017 \
MONGO_ROLE="primary" \
MONGO_SECONDARY="hostname or IP of secondary" \
MONGO_ARBITER="hostname or IP of arbiter" \
MONGO_ROOT_USER="myRootUser" \
MONGO_ROOT_PASSWORD="myRootUserPassword" \
MONGO_APP_USER="myAppUser" \
MONGO_APP_PASSWORD="myAppUserPassword" \
MONGO_APP_DATABASE="myAppDatabase" \
urname/mongo-rep-set:latest
The primary will start up, configure your root and app users, shut down, and then start up once more and configure the replica set. Assuming the secondary and arbiter are reachable, the server will now be ready for authenticated connections. You can use the standard two server Mongo URL to connect to the primary/secondary like this:
Note that the following connection url is using default env var values (more info on those below), so it should work if you haven't overwritten any of the variables yourself.
odb://myAppUser:myAppPassword@mongo1:27017,mongo2:27017/myAppDatabase?replicaSet=rs0
Here are all of the available environment variables and their defaults. Note that if you set MONGO_REP_SET, you must set it to the same value on all 3 containers.
ngod config
O_STORAGE_ENGINE wiredTiger
O_JOURNALING true
O_REP_SET rs0
O_AUTH true
O_OPLOG_SIZE # not set, but you can override the default
O_SECONDARY mongo2:27017
O_ARBITER mongo3:27017
O_DB_PATH /data/db
ngo root user
O_ROOT_USER root
O_ROOT_PASSWORD root123
ngo app user + database (user is given oplog access)
O_APP_USER myAppUser
O_APP_PASSWORD myAppPassword
O_APP_DATABASE myAppDatabase