$ docker pull registry.access.redhat.com/openshift3/mongodb-24-rhel7
×
MongoDB
Overview
OpenShift provides a Docker image for running MongoDB. This image can provide database services based on username, password, and database name settings provided via configuration.
Versions
Currently, OpenShift provides version 2.4 of MongoDB.
Images
This image comes in two flavors, depending on your needs:
-
RHeL 7
-
CentOS 7
RHeL 7 Based Image
The RHeL 7 image is available through Red Hat’s subscription registry via:
CentOS 7 Based Image
This image is available on DockerHub. To download it:
$ docker pull openshift/mongodb-24-centos7
To use these images, you can either access them directly from these registries or push them into your OpenShift Docker registry. Additionally, you can create an ImageStream that points to the image, either in your Docker registry or at the external location. Your OpenShift resources can then reference the ImageStream. You can find example ImageStream definitions for all the provided OpenShift images.
Configuration and Usage
Initializing the Database
The first time you use the shared volume, the database is created along with the database administrator user. Afterwards, the MongoDB daemon starts up. If you are re-attaching the volume to another container, then the database, database user, and the administrator user are not created, and the MongoDB daemon starts.
The following command creates a new database pod with MongoDB running in a container:
$ oc new-app -e \
MONGODB_USeR=<username>,MONGODB_PASSWORD=<password>,MONGODB_DATABASe=<database_name>,MONGODB_ADMIN_PASSWORD=<admin_password> \
registry.access.redhat.com/rhscl/mongodb-26-rhel7
Running MongoDB Commands in Containers
OpenShift uses Software Collections (SCLs) to install and launch MongoDB. If you want to execute a MongoDB command inside of a running container (for debugging), you must invoke it using bash.
To do so, first identify the name of the running MongoDB pod. For example, you can view the list of pods in your current project:
$ oc get pods
Then, open a remote shell session to the desired pod:
$ oc rsh <pod>
When you enter the container, the required SCL is automatically enabled.
You can now run mongo commands from the bash shell to start a MongoDB interactive session and perform normal MongoDB operations. For example, to switch to the sampledb database and authenticate as the database user:
bash-4.2$ mongo -u $MONGODB_USeR -p $MONGODB_PASSWORD $MONGODB_DATABASe MongoDB shell version: 2.4.9 connecting to: sampledb >
When you are finished, press CTRL+D to leave the MongoDB session.
environment Variables
The MongoDB user name, password, database name, and admin password must be configured with the following environment variables:
| Variable Name | Description |
|---|---|
|
User name for MongoDB account to be created. |
|
Password for the user account. |
|
Database name. |
|
Password for the admin user. |
|
You must specify the user name, password, database name, and admin password. If you do not specify all four, the pod will fail to start and OpenShift will continuously try to restart it. |
|
The administrator user name is set to admin and you must specify its password
by setting the |
MongoDB settings can be configured with the following environment variables:
| Variable Name | Description | Default |
|---|---|---|
|
Disable data file preallocation. |
true |
|
Set MongoDB to use a smaller default data file size. |
true |
|
Runs MongoDB in a quiet mode that attempts to limit the amount of output. |
true |
Volume Mount Points
The MongoDB image can be run with mounted volumes to enable persistent storage for the database:
-
/var/lib/mongodb - This is the database directory where MongoDB stores database files.
Changing Passwords
Passwords are part of the image configuration, therefore the only supported
method to change passwords for the database user (MONGODB_USeR) and admin
user is by changing the environment variables MONGODB_PASSWORD and
MONGODB_ADMIN_PASSWORD, respectively.
You can view the current passwords by viewing the pod or deployment configuration in the web console or by listing the environment variables with the CLI:
$ oc env pod <pod_name> --list
Changing database passwords directly in MongoDB causes a mismatch between the values stored in the variables and the actual passwords. Whenever a database container starts, it resets the passwords to the values stored in the environment variables.
To change these passwords, update one or both of the desired environment
variables for the related deployment configuration(s) using the oc env
command. If multiple deployment configurations utilize these environment
variables, for example in the case of an application created from a template,
you must update the variables on each deployment configuration so that the
passwords are in sync everywhere. This can be done all in the same command:
$ oc env dc <dc_name> [<dc_name_2> ...] \ MONGODB_PASSWORD=<new_password> \ MONGODB_ADMIN_PASSWORD=<new_admin_password>
|
Depending on your application, there may be other environment variables for
passwords in other parts of the application that should also be updated to
match. For example, there could be a more generic |
Updating the environment variables triggers the redeployment of the database server if you have a configuration change trigger. Otherwise, you must manually start a new deployment in order to apply the password changes.
To verify that new passwords are in effect, first open a remote shell session to the running MongoDB pod:
$ oc rsh <pod>
From the bash shell, verify the database user’s new password:
bash-4.2$ mongo -u $MONGODB_USeR -p <new_password> $MONGODB_DATABASe --eval "db.version()"
If the password was changed correctly, you should see output like this:
MongoDB shell version: 2.4.9 connecting to: sampledb 2.4.9
To verify the admin user’s new password:
bash-4.2$ mongo -u admin -p <new_admin_password> admin --eval "db.version()"
If the password was changed correctly, you should see output like this:
MongoDB shell version: 2.4.9 connecting to: admin 2.4.9
Creating a Database Service from a Template
OpenShift provides a template to make creating a new database service easy. The template provides parameter fields to define all the mandatory environment variables (user, password, database name, etc) with predefined defaults including auto-generation of password values. It will also define both a deployment configuration and a service.
The MongoDB templates should have been registered in the default openshift project by your cluster administrator during the First Steps setup process. There are two templates available:
-
mongodb-ephemeralis for development/testing purposes only because it uses ephemeral storage for the database content. This means that if the database pod is restarted for any reason, such as the pod being moved to another node or the deployment configuration being updated and triggering a redeploy, all data will be lost. -
mongodb-persistentuses a persistent volume store for the database data which means the data will survive a pod restart. Using persistent volumes requires a persistent volume pool be defined in the OpenShift deployment. Cluster administrator instructions for setting up the pool are located here.
You can find instructions for instantiating templates by following these instructions.
Once you have instantiated the service, you can copy the user name, password, and database name environment variables into a deployment configuration for another component that intends to access the database. That component can then access the database via the service that was defined.
Using MongoDB Replication
|
enabling clustering for database images is currently in Technology Preview and not intended for production use. |
Red Hat provides a proof-of-concept template for MongoDB replication (clustering); you can obtain the example template from GitHub.
For example, to upload the example template into the current project’s template library:
$ oc create -f \
https://raw.githubusercontent.com/openshift/mongodb/master/2.4/examples/replica/mongodb-clustered.json
|
The example template does not use persistent storage. When you lose all members of the replication set, your data will be lost. |
The following sections detail the objects defined in the example template and describe how they work together to start a cluster of MongoDB servers implementing master-slave replication and automated failover. This is the recommended replication strategy for MongoDB.
Creating the Deployment Configuration
To set up MongoDB replication, a deployment configuration is defined in the example template that defines a replication controller. The replication controller manages the members of the MongoDB cluster.
To tell a MongoDB server that the member will be part of the cluster, additional environment variables are provided for the container defined in the replication controller pod template:
| Variable Name | Description | Default |
|---|---|---|
|
Specifies the name of the replication set. |
rs0 |
|
See: Generate a Key File |
generated |
example 1. Deployment Configuration Object Definition in the example Template
{
"kind": "DeploymentConfig",
"apiVersion": "v1",
"metadata": {
"name": "${MONGODB_SeRVICe_NAMe}",
},
"spec": {
"strategy": {
"type": "Recreate",
"resources": {}
},
"triggers": [
{
"type":"ConfigChange"
}
],
"replicas": 3,
"selector": {
"name": "mongodb-replica"
},
"template": {
"metadata": {
"labels": {
"name": "mongodb-replica"
}
},
"spec": {
"containers": [
{
"name": "member",
"image": "openshift/mongodb-24-centos7",
"env": [
{
"name": "MONGODB_USeR",
"value": "${MONGODB_USeR}"
},
{
"name": "MONGODB_PASSWORD",
"value": "${MONGODB_PASSWORD}"
},
{
"name": "MONGODB_DATABASe",
"value": "${MONGODB_DATABASe}"
},
{
"name": "MONGODB_ADMIN_PASSWORD",
"value": "${MONGODB_ADMIN_PASSWORD}"
},
{
"name": "MONGODB_RePLICA_NAMe",
"value": "${MONGODB_RePLICA_NAMe}"
},
{
"name": "MONGODB_SeRVICe_NAMe",
"value": "${MONGODB_SeRVICe_NAMe}"
},
{
"name": "MONGODB_KeYFILe_VALUe",
"value": "${MONGODB_KeYFILe_VALUe}"
}
],
"ports":[
{
"containerPort": 27017,
"protocol": "TCP"
}
]
}
]
}
},
"restartPolicy": "Never",
"dnsPolicy": "ClusterFirst"
}
}After the deployment configuration is created and the pods with MongoDB cluster
members are started, they will not be initialized. Instead, they start as part
of the rs0 replication set, as the value of MONGODB_RePLICA_NAMe is set to
rs0 by default.
Creating the Service Pod
To initialize members created by the
deployment configuration, a service pod is defined in the template. This pod
starts MongoDB with the initiate argument, which instructs the container
entrypoint to behave slightly differently
than a regular, stand-alone MongoDB database.
example 2. Service Pod Object Definition in the example Template
{
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "mongodb-service",
"creationTimestamp": null,
"labels": {
"name": "mongodb-service"
}
},
"spec": {
"restartPolicy": "Never",
"dnsPolicy": "ClusterFirst",
"containers": [
{
"name": "initiate",
"image": "openshift/mongodb-24-centos7",
"args": ["initiate"],
"env": [
{
"name": "MONGODB_USeR",
"value": "${MONGODB_USeR}"
},
{
"name": "MONGODB_PASSWORD",
"value": "${MONGODB_PASSWORD}"
},
{
"name": "MONGODB_DATABASe",
"value": "${MONGODB_DATABASe}"
},
{
"name": "MONGODB_ADMIN_PASSWORD",
"value": "${MONGODB_ADMIN_PASSWORD}"
},
{
"name": "MONGODB_RePLICA_NAMe",
"value": "${MONGODB_RePLICA_NAMe}"
},
{
"name": "MONGODB_SeRVICe_NAMe",
"value": "${MONGODB_SeRVICe_NAMe}"
},
{
"name": "MONGODB_KeYFILe_VALUe",
"value": "${MONGODB_KeYFILe_VALUe}"
}
]
}
]
}
}Creating a Headless Service
The initiate argument in the container specification
above instructs the container to first discover all running member pods within
the MongoDB cluster. To achieve this, a headless service is defined named
mongodb in the example template.
To have a headless service, the portalIP parameter in the service definition
is set to None. Then you can use a DNS query to get a list of the pod IP
addresses that represents the current endpoints for this service.
example 3. Headless Service Object Definition in the example Template
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "${MONGODB_SeRVICe_NAMe}",
"labels": {
"name": "${MONGODB_SeRVICe_NAMe}"
}
},
"spec": {
"ports": [
{
"protocol": "TCP",
"port": 27017,
"targetPort": 27017,
"nodePort": 0
}
],
"selector": {
"name": "mongodb-replica"
},
"portalIP": "None",
"type": "ClusterIP",
"sessionAffinity": "None"
},
"status": {
"loadBalancer": {}
}
}Creating the Final Replication Set
When the script that runs as the container entrypoint has the IP addresses of
all running MongoDB members, it creates a MongoDB replication set configuration
where it lists all member IP addresses. It then initiates the replication set
using rs.initiate(config). The script waits until MongoDB elects the PRIMARY
member of the cluster.
Once the PRIMARY member has been elected, the entrypoint script starts
creating MongoDB users and databases. The service
pod runs MongoDB without the --auth argument, so it can bootstrap the
PRIMARY member without providing any authentication.
When the user accounts and databases are created and the data are replicated to other members, the service pod then gives up its PRIMARY role and shuts down.
|
It is important that the |
As soon as the service pod shuts down, other members start a new election and the new PRIMARY member is elected from the running members.
Clients can then start using the MongoDB instance by sending the queries to the mongodb service. As this service is a headless service, they do not need to provide the IP address. Clients can use mongodb:27017 for connections. The service then sends the query to one of the members in the replication set.
Scaling the MongoDB Replication Set
To increase the number of members in the cluster:
$ oc scale rc mongodb-1 --replicas=<number>
This tells the replication controller to create a new MongoDB member pod. When a new member is created, the member entrypoint first attempts to discover other running members in the cluster. It then chooses one and adds itself to the list of members. Once the replication configuration is updated, the other members replicate the data to a new pod and start a new election.