Deploy IBM Data Management Platform for MongoDB Enterprise Advanced 2.0 Cloud Pak into IBM Cloud Private

Step-by-step

Install IBM Cloud Private 3.1.1

First, you will need to install IBM Cloud Private 3.1.1. Detailed instructions are here.
Create Persistent Volume

If you want to enable persistence and not use dynamic provisioning for your deployment, please follow the steps below to create a persistent volume.

This can be done in the UI, and should ideally be created before the deployment. Log into IBM Cloud Private, and use the upper left menu to navigate to the Platform -> Storage page

On the storage page, click Create PersistentVolume

In this example, a 2GB host path volume using glusterfs storageclass is created. It uses the ReadWriteOnce access mode, and will be retained if the pod is removed.

While Host Path is an easy solution for initial testing, in production, NFS or other shared storage is more recommended so that if a node drops, the MongoDB pod will come back up onto a different node and reconnect to the same volume.

In Parameters tab, parameters are supplied as key and value pairs.

For hostPath, you must specify
- A path Key: – “path”
- Value: – the location of the file or directory on your cluster’s node. For example: /tmp/data
For NFS, you must specify
- A server Key: – “server”
- Value: – the NFS server host name or IP.
- A path Key: – “path”
- Value: – the location of the directory on your NFS server that is mounted as a shared directory.
To learn more about creating a persistent volume, please check our knowledge center.
Create Namespace

Deployments can be made in some exisitng namespaces with the correct pod secure policy: ibm-anyuid-hostpath-psp, or you can create a new namespace with the following steps.

From IBM Cloud Private home page, use the upper left menu to navigate to the Manage -> Namespaces page

Click Create Namespace, provide the name and pod security policy that’s required by the chart: ibm-anyuid-hostpath-psp

Once you click Create, a new namespace is created for your deployment

Next step is to create cluster role binding for the default service account of your new namespace.

From IBM Cloud Private Client CLI, create a new file called crb.yaml as below. In the file, add the new namespace into namespace field indicated in the template

Then run kubectl apply -f crb.yaml
```
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
 name: crb
subjects:
 - kind: ServiceAccount
 name: default
 namespace: <Put your namespace here>
roleRef:
 kind: ClusterRole
 name: cluster-admin
 apiGroup: rbac.authorization.k8s.io
```
Navigate to installation

From IBM Cloud Private home page, click on the top right Catalog button. This will bring you a list of available catlalog that you can deploy.

Search for ibm-mongodb-opsmanager

On click, it will show you the overview page
Specify configuration settings

After clicking Configure on the bottom left, it will take you to a detailed configuration page where you can modify your settings for deployment. Some important fields are highlighted below
- Helm release name is a unique name to identify your helm release. It should begin with a lowercase letter and end with any alphanumeric character, must only contain hyphens and lowercase alphanumeric characters.
- Namespace are a way to divide cluster resources between multiple users. Be sure to choose the namespace with ibm-anyuid-hostpath-psp policy. Important: Make sure the default service account for the namespace has cluster admin role.
- Ops Manager first user password: This is a login password used for your first ops manager user (global admin). It needs to be 8 characters minimum, contains at least one number, one letter and one special character.
First Ops Manager register information
- For Runtime Environment, you can choose between IBM Cloud Private and IBM Cloud Private for data
- Type of environment, Dedicated deployment and Service name are immuatble
- Other fields are the information that users use to register the first ops manager user (global admin). Username and password will be used for login
Docker Image Configuration

Here it specifies the repository and tag to pull docker images. You can leave these fields as default.

Docker Repository:  Image repository

Docker image tag:  Image tag for latest build

Docker image pull policy:  Image pull policy
Service and MongoDB database configuration

On this page you can configure the service for MongoDB and Ops Manager
- There are 2 Service Types you can choose from:
  - ClusterIp: Expose service through kubernetes cluster with ip/name:port
  - NodePort: Expose service through Internal network VM’s, also external to kubernetess ip/name:port
- Service Port is the internal port for Ops Manager, default as 8080
- Replica Set Size defines the number of members of MongoDB Replica set
Initial OpsManager Configuration

These information are used to configure initial setup for ops manager. Details can be found here

You can leave URI for the Mongo database as default.

Other fields in the image below are used for ops manager email nontification system:
- Admin Email Address: The email address of the Ops Manager admin. This address receives emails related to problems with Ops Manager.
- From Email Address: The email address used for sending the general emails, such as Ops Manager alerts. You can include an alias with the email address.
- Reply To Email Address: The email address from which to send replies to general emails.
- OpsManager Mail Protocol: The transfer protocol your email provider specifies:
  - smtp (standard SMTP)
  - smtps (secure SMTP)
- OpsManager Mail Hostname: Email hostname your email provider specifies.
- OpsManager Mail Port: Port number for SMTP your email provider specifies.
Data Persistence Configuration

On this page you can also config the data volume to persist MongoDB runtime data. There are 3 options:

Option 1: Bond to an existing persistent volume (Check step 2 to create persistent volume)

By specifying the same storage class, size and access mode, the persistence volume claim of the deployment will automatically bond to the persistent volume that was created in step 2.

Option 2: Use dynamic provisioning

This option doesn’t require a persistent volume to be created in advance.

Option 3: Disable persistence for this deployment
Resource Configuration

You can configure MongoDB and Ops Manager resources by setting the CPU, Memory limits and request.
Deploy the helm chart

Before hitting the install button, make sure you have cluster admin role for your service account, otherwise some kubernetes jobs might fail.

The installation will take around 10 minutes. When the configure-job pod is completed.

During installation, there are few commands that can be used to check the status:
- kubectl get pods -n <namespace>
- kubectl describe pod <podname> -n <namespace>
- kubectl logs <podname> -n <namespace>
Start using the deployment

When deployment is finished, click the Launch button on the top right of your helm release page, it will take you to the Ops Manager login page

After logging in, you can see the MongoDB Enterprise replica set deployment

You can click on the Data tab to run MongoDB queries
Conclusion

We hope this recipe has been helpful.

If you have any questions or suggestions for improvements, feel free to leave a comment below.