Contents

Recipes are community-created content. They are neither monitored nor endorsed by IBM. If you find inappropriate content, please use Report Abuse to let us know. For more information on community content, please refer to our Terms of Use.

Overview

Skill Level: Beginner

This recipe describes how to deploy MongoDB Enterprise version, with MongoDB Ops Manager and MongoDB Enterprise Operator into IBM Cloud Private, IBM's new Kubernetes based private cloud, by using helm charts and persistent volumes

Ingredients

  • IBM Cloud Private >= 3.1.0

  • Kubectl command line (optional...get it here)

  • Persistent volume

  • IBM Data Management Platform for MongoDB Enterprise Advanced 2.0 Cloud Pak Helm chart
  • A kubernetes secret

Step-by-step

  1. Install IBM Cloud Private

    First, you will need to install IBM Cloud Private. Here we will use 3.1.1 as an example. Detailed instructions are here.

  2. 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

    Storage page

    On the storage page, click Create PersistentVolume

    nfs1

    nfs2

     

    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.

    NFS or other shared storage 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 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.

  3. Create Namespace

    Deployments can be made in some exisitng namespaces with the correct pod secure policy: ibm-anyuid-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

    ns

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

    anyuid

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

    Next step is to create a cluster role and a 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/v1
    kind: ClusterRole
    metadata:
     name: mongo-role
    rules:
    - apiGroups:
     - apiextensions.k8s.io
     resources:
     - customresourcedefinitions
     verbs:
     - '*'
    - apiGroups:
     - k8s.io
     resources:
     - databases
     verbs:
     - '*'
    - apiGroups:
     - ""
     resources:
     - secrets
     verbs:
     - '*'
    - apiGroups:
     - ""
     resources:
     - services
     - configmaps
     verbs:
     - get
     - create
     - update
     - delete
    - apiGroups:
     - ""
     resources:
     - namespaces
     verbs:
     - get
     - list
     - watch
    - apiGroups:
     - ""
     resources:
     - pods
     - pods/log
     - pods/exec
     verbs:
     - '*'
    - apiGroups: ["extensions", "apps"] resources: ["deployments", "statefulsets"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]- apiGroups:
     - "mongodb.com"
     resources:
     - mongodbstandalones
     - mongodbreplicasets
     - mongodbshardedclusters
     verbs:
     - '*'

    ---
    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: mongo-role
     apiGroup: rbac.authorization.k8s.io

  4. 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-mongodbent-prod

    catalog2

    On click, it will show you the overview page
    readme

  5. 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-psp policy. Important: Make sure the default service account for the namespace has mongo-role (See step 3)

    1

    • Secret for Ops Manager First User Password: This is a secret that contains the login password used for your first ops manager user (global admin).
    • To create a secret, from IBM Cloud Private Client CLI, run the following command
    • kubectl create secret generic <Releasename-ops-secret> --from-literal=username=<user> --from-literal=password=<password> --namespace=<namespace>
    •   Important: The Password needs to be 8 characters minimum, contains at least one number, one letter and one special character.

    2

  6. First Ops Manager register information

    • 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 Secret will be used for login

    4

  7. 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

    5

  8. 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

    3

  9. 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.

     

    6

  10. 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.

    a1

    Option 2: Use dynamic provisioning

    This option doesn’t require a persistent volume to be created in advance. The cluster needs to have a default storage class setup by administrator

    a2

    Option 3: Disable persistence for this deployment

    a3

  11. Resource Configuration

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

    8

  12. 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>

  13. 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

    opslogin

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

    opsmain

    opsreplica

    You can click on the Data tab to run MongoDB queries

    opsdata

  14. Conclusion

    We hope this recipe has been helpful.

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

Join The Discussion