MongoDB - Database Images | Using Images | OpenShift Container Platform 3.11

Overview
Versions
Images
Configuration and usage
Creating a database service from a template
MongoDB replication

Overview

OpenShift Container Platform provides a container image for running MongoDB. This image can provide database services based on username, password, and database name settings provided via configuration.

Versions

Currently, OpenShift Container Platform provides versions 2.6, 3.2, and 3.4 of MongoDB.

Images

These images come in two flavors, depending on your needs:

RHeL 7
CentOS 7

RHeL 7 Based Images

The RHeL 7 images are available through the Red Hat Registry:

$ docker pull registry.redhat.io/rhscl/mongodb-26-rhel7
$ docker pull registry.redhat.io/rhscl/mongodb-32-rhel7
$ docker pull registry.redhat.io/rhscl/mongodb-34-rhel7

CentOS 7 Based Images

These images are available on Docker Hub:

$ docker pull centos/mongodb-26-centos7
$ docker pull centos/mongodb-32-centos7
$ docker pull centos/mongodb-34-centos7

To use these images, you can either access them directly from these registries or push them into your OpenShift Container Platform container image registry. Additionally, you can create an ImageStream that points to the image, either in your container image registry or at the external location. Your OpenShift Container Platform resources can then reference the ImageStream. You can find example ImageStream definitions for all the provided OpenShift Container Platform images.

Configuration and usage

Initializing the database

You can configure MongoDB with an ephemeral volume or a persistent volume. The first time you use the 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 with an ephemeral volume:

$ oc new-app \
    -e MONGODB_USeR=<username> \
    -e MONGODB_PASSWORD=<password> \
    -e MONGODB_DATABASe=<database_name> \
    -e MONGODB_ADMIN_PASSWORD=<admin_password> \
    registry.redhat.io/rhscl/mongodb-26-rhel7

Running MongoDB commands in containers

OpenShift Container Platform 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.6.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:

Table 1. MongoDB environment Variables
Variable Name	Description
`MONGODB_USeR`	User name for MongoDB account to be created.
`MONGODB_PASSWORD`	Password for the user account.
`MONGODB_DATABASe`	Database name.
`MONGODB_ADMIN_PASSWORD`	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 Container Platform will continuously try to restart it.

The administrator user name is set to admin and you must specify its password by setting the MONGODB_ADMIN_PASSWORD environment variable. This process is done upon database initialization.

MongoDB settings can be configured with the following environment variables:

Table 2. Additional MongoDB Settings
Variable Name	Description	Default
`MONGODB_NOPReALLOC`	Disable data file preallocation.	`true`
`MONGODB_SMALLFILeS`	Set MongoDB to use a smaller default data file size.	`true`
`MONGODB_QUIeT`	Runs MongoDB in a quiet mode that attempts to limit the amount of output.	`true`

Text search is enabled by default in MongoDB versions 2.6 and higher, and therefore has no configurable parameter.

Volume mount points

The MongoDB image can be run with mounted volumes to enable persistent storage for the database:

/var/lib/mongodb/data - 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 set 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 set 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 set 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 DATABASe_USeR variable in a front-end pod that should match the database user’s password. ensure that passwords are in sync for all required environment variables per your application, otherwise your pods may fail to redeploy when triggered.

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.6.9
connecting to: sampledb
2.6.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.6.9
connecting to: admin
2.6.9

Creating a database service from a template

OpenShift Container Platform 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 initial cluster setup. See Loading the Default Image Streams and Templates for more details, if required.

There are two templates available:

mongodb-ephemeral is 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-persistent uses 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 Container Platform deployment. Cluster administrator instructions for setting up the pool are located in Persistent Storage Using NFS.

You can instantiate 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.

MongoDB replication

Configuration for enabling clustering for database images is provided as an example and not intended for production use.

Red Hat provides a proof-of-concept template for MongoDB replication (clustering) using StatefulSet. 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/sclorg/mongodb-container/master/examples/petset/mongodb-petset-persistent.yaml

The example template uses persistent storage. You must have persistent volumes available in your cluster to use this template.

As OpenShift Container Platform automatically restarts unhealthy pods (containers), it will restart replica set members if one or more of these members crashes or fails.

While a replica set member is down or being restarted, it may be one of these scenarios:

PRIMARY member is down:

In this case, the other two members elect a new PRIMARY. Until then, reads are not affected, but the writes fail. After a successful election, writes and reads process normally.
One of the SeCONDARY member is down:

Reads and writes are unaffected. Depending on the oplogSize configuration and the write rate, the third member might fail to join back the replica set, requiring manual intervention to re-sync its copy of the database.
Any two members are down:

When a three-member replica set member cannot reach any other member, it will step down from the PRIMARY role if it had it. In this case, reads might be served by a SeCONDARY member, and writes fail. As soon as one more member is back up, an election picks a new PRIMARY member and reads and writes process normally.
All members are down:

In this extreme case, both reads and writes fail. After two or more members are back up, an election reestablishes the replica set to have a PRIMARY and a SeCONDARY member, after which reads and writes process normally.

This is the recommended replication strategy for MongoDB.

For production environments, you must maintain as much separation between members as possible. It is recommended to use one or more of the node selection features to schedule StatefulSet pods onto different nodes, and to provide them storage backed by independent volumes.

Limitations

Only MongoDB 3.2 is supported.
You have to manually update replica set configuration in case of scaling down.
Changing a user and administrator password is a manual process. It requires:
- updating values of environment variables in the StatefulSet configuration,
- changing password in the database, and
- restarting all pods one after another.

Using the example template

Assuming you already have three pre-created persistent volumes or configured persistent volume provisioning.

Create a new poject where you want to create a MongoDB cluster:
```
$ oc new-project mongodb-cluster-example
```

Create a new application using the example template:

$ oc new-app https://raw.githubusercontent.com/sclorg/mongodb-container/master/examples/petset/mongodb-petset-persistent.yaml

This command created a MongoDB cluster with three replica set members.

Check the status of the new MongoDB pods:

$ oc get pods
NAMe        ReADY     STATUS    ReSTARTS   AGe
mongodb-0   1/1       Running   0          50s
mongodb-1   1/1       Running   0          50s
mongodb-2   1/1       Running   0          49s

After creating a cluster from the example template, you have a replica set with three members. Once the pods are running you can perform various actions on these pods such as:

Checking logs for one of the pods:
```
$ oc logs mongodb-0
```
Log in to the pod:
```
$ oc rsh mongodb-0
sh-4.2$
```

sh-4.2$ mongo $MONGODB_DATABASe -u $MONGODB_USeR -p$MONGODB_PASSWORD
MongoDB shell version: 3.2.6
connecting to: sampledb
rs0:PRIMARY>

Scale up

MongoDB recommends an odd number of members in a replica set. If there are sufficient available persistent volumes, or a dynamic storage provisioner is present, scaling up is done by using the oc scale command:

$ oc scale --replicas=5 statefulsets/mongodb

$ oc get pods
NAMe        ReADY     STATUS    ReSTARTS   AGe
mongodb-0   1/1       Running   0          9m
mongodb-1   1/1       Running   0          8m
mongodb-2   1/1       Running   0          8m
mongodb-3   1/1       Running   0          1m
mongodb-4   1/1       Running   0          57s

This creates new pods which connect to the replica set and updates its configuration.

Scaling up an existing database requires manual intervention if the database size is greater than the oplogSize configuration. For such cases, a manual initial sync of the new members is required. For more information, see Check the Size of the Oplog and the MongoDB Replication documentation.

Scale down

To scale down a replica set it is possible to go from five to three members, or from three to only one member.

Although scaling up may be done without manual intervention when the preconditions are met (storage availability, size of existing database and oplogSize), scaling down always require manual intervention.

To scale down:

Set the new number of replicas by using the oc scale command:
```
$ oc scale --replicas=3 statefulsets/mongodb
```
If the new number of replicas still constitutes a majority of the previous number, the replica set may elect a new PRIMARY in case one of the pods that was deleted had the PRIMARY member role. For example, when scaling down from five members to three members.

Alternatively, scaling down to a lower number temporarily renders the replica set to have only SeCONDARY members and be in read-only mode. For example, when scaling down from five members to only one member.
Update the replica set configuration to remove members that no longer exist.

This may be improved in the future, a possible implementation being setting a PreStop pod hook that inspects the number of replicas (exposed via the downward API) and determines that the pod is being removed from the StatefulSet, and not being restarted for some other reason.
Purge the volume used by the decommissioned pods.