# Mastering MongoDB Ops Manager on Kubernetes

This article is part of a three-parts series on deploying MongoDB across multiple Kubernetes clusters using the operators.

-   Deploying the MongoDB Enterprise Kubernetes Operator on Google Cloud

-   Mastering MongoDB Ops Manager

-   Deploying MongoDB Across Multiple Kubernetes Clusters With MongoDBMulti

Managing MongoDB deployments can be a rigorous task, particularly when working with large numbers of databases and servers. Without the right tools and processes in place, it can be time-consuming to ensure that these deployments are running smoothly and efficiently. One significant issue in managing MongoDB clusters at scale is the lack of automation, which can lead to time-consuming and error-prone tasks such as backups, recovery, and upgrades. These tasks are crucial for maintaining the availability and performance of your clusters.

Additionally, monitoring and alerting can be a challenge, as it may be difficult to identify and resolve issues with your deployments. To address these problems, it's essential to use software that offers monitoring and alerting capabilities. Optimizing the performance of your deployments also requires guidance and support from the right sources.

Finally, it's critical for your deployments to be secure and compliant with industry standards. To achieve this, you need features that can help you determine if your deployments meet these standards.

MongoDB Ops Manager is a web-based application designed to assist with the management and monitoring of MongoDB deployments. It offers a range of features that make it easier to deploy, manage, and monitor MongoDB databases, such as:

-   Automated backups and recovery: Ops Manager can take automated backups of your MongoDB deployments and provide options for recovery in case of failure.

-   Monitoring and alerting: Ops Manager provides monitoring and alerting capabilities to help identify and resolve issues with your MongoDB deployments.

-   Performance optimization: Ops Manager offers tools and recommendations to optimize the performance of your MongoDB deployments.

-   Upgrade management: Ops Manager can help you manage and plan upgrades to your MongoDB deployments, including rolling upgrades and backups to ensure data availability during the upgrade process.

-   Security and compliance: Ops Manager provides features to help you secure your MongoDB deployments and meet compliance requirements.

However, managing Ops Manager can be a challenging task that requires a thorough understanding of its inner workings and how it interacts with the internal MongoDB databases. It is necessary to have the knowledge and expertise to perform upgrades, monitor it, audit it, and ensure its security. As Ops Manager is a crucial part of managing the operation of your MongoDB databases, its proper management is essential.

Fortunately, the MongoDB Enterprise Kubernetes Operator enables us to run Ops Manager on Kubernetes clusters, using native Kubernetes capabilities to manage Ops Manager for us, which makes it more convenient and efficient.

## Kubernetes: MongoDBOpsManager custom resource

The MongoDB Enterprise Kubernetes Operator is software that can be used to deploy Ops Manager and MongoDB resources to a Kubernetes cluster, and it's responsible for managing the lifecycle of each of these deployments. It has been developed based on years of experience and expertise, and it's equipped with the necessary knowledge to properly install, upgrade, monitor, manage, and secure MongoDB objects on Kubernetes.

The Kubernetes Operator uses the MongoDBOpsManager custom resource to manage Ops Manager objects. It constantly monitors the specification of the custom resource for any changes and, when changes are detected, the operator validates them and makes the necessary updates to the resources in the Kubernetes cluster.

MongoDBOpsManager custom resources specification defines the following Ops Manager components:

-   The Application Database

-   The Ops Manager application

-   The Backup Daemon

When you use the Kubernetes Operator to create an instance of Ops Manager, the Ops Manager MongoDB Application Database will be deployed as a replica set. It's not possible to configure the Application Database as a standalone database or a sharded cluster.

The Kubernetes Operator automatically sets up Ops Manager to monitor the Application Database that powers the Ops Manager Application. It creates a project named  `-db` to allow you to monitor the Application Database deployment. While Ops Manager monitors the Application Database deployment, it does not manage it.

When you deploy Ops Manager, you need to configure it. This typically involves using the configuration wizard. However, you can bypass the configuration wizard if you set certain essential settings in your object specification before deployment. I will demonstrate that in this post.

The Operator automatically enables backup. It deploys a StatefulSet, which consists of a single pod, to host the Backup Daemon Service and creates a Persistent Volume Claim and Persistent Volume for the Backup Daemon's head database. The operator uses the Ops Manager API to enable the Backup Daemon and configure the head database.

## Getting started

Alright, let's get started using the operator and build something! For this tutorial, we will need the following tools: 

-   gcloud 

-   gke-cloud-auth-plugin

-   Helm

-   kubectl

-   kubectx

-   git

To get started, we should first create a Kubernetes cluster and then install the MongoDB Kubernetes Operator on the cluster. Part 1 of this series provides instructions on how to do so.

> **Note**
> For the sake of simplicity, we are deploying Ops Manager in the same namespace as our MongoDB Operator. In a production environment, you should deploy Ops Manager in its own namespace.

### Environment pre-checks 

Upon successful creation of a cluster and installation of the operator (described in Part 1), it's essential to validate their readiness for use.

```bash
gcloud container clusters list

NAME                LOCATION       MASTER_VERSION    NUM_NODES  STATUS\
master-operator     us-south1-a    1.23.14-gke.1800      4      RUNNING
```

Display our new Kubernetes full cluster name using `kubectx`.

```bash
kubectx
```

You should see your cluster listed here. Make sure your context is set to master cluster.

```bash
kubectx $(kubectx | grep "master-operator" | awk '{print $1}')
```

In order to continue this tutorial, make sure that the operator is in the `running`state.

```bash
kubectl get po -n "${NAMESPACE}"

NAME                                    READY   STATUS   RESTARTS   AGE\
mongodb-enterprise-operator-649bbdddf5   1/1    Running   0         7m9s
```

## Using the MongoDBOpsManager CRD

Create a secret containing the username and password on the master Kubernetes cluster for accessing the Ops Manager user interface after installation.

```bash
kubectl -n "${NAMESPACE}" create secret generic om-admin-secret \
  --from-literal=Username="opsmanager@example.com" \
  --from-literal=Password="p@ssword123" \
  --from-literal=FirstName="Ops" \
  --from-literal=LastName="Manager"
```

### Deploying Ops Manager 

Then, we can deploy Ops Manger on the master Kubernetes cluster with the help of `opsmanagers`  Custom Resource, creating `MongoDBOpsManager` object, using the following manifest:

```bash
OM_VERSION=6.0.5
APPDB_VERSION=5.0.5-ent
kubectl apply -f - <      27017/TCP
ops-manager-svc     ClusterIP    None