Configure an Ops Manager Resource to use Local Mode

Configure kubectl to default to your namespace.

If you have not already, run the following command to execute all kubectl commands in the namespace you created.

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>

Delete the StatefulSet that manages your Ops Manager Pods.

In this tutorial, you update the StatefulSet that manages the Ops Manager Pods in your Kubernetes cluster.

You must first delete the Ops Manager StatefulSet so that Kubernetes can apply the updates that Local Mode requires.

1. Find the name of your Ops Manager StatefulSet:

   kubectl get statefulsets

   The entry in the response that matches the metadata.name of your

   Your Ops Manager StatefulSet is the entry in the response that matches the metadata.name in your Ops Manager resource definition.

   kubectl get statefulsets -n mongodb
   NAME                       READY   AGE
   ops-manager-localmode      2/2     2m31s
   ops-manager-localmode-db   3/3     4m46s

2. Delete the Ops Manager StatefulSet:

   Warning

   Ensure that you include the --cascade=false flag when you delete your Ops Manager StatefulSet. If you don't include this flag, Kubernetes also deletes your Ops Manager Pods.

   kubectl delete statefulset --cascade=false <ops-manager-statefulset>

Copy the fields of this Ops Manager resource.

Copy Lines 9-31 of this example to:

• Use the Ops Manager configuration setting automation.versions.source: local in spec.configuration to enable Local Mode.

• Define a Persistent Volume for the Ops Manager StatefulSet to store the MongoDB installation archive. MongoDB Agents running in MongoDB database resource containers that you create with the Kubernetes Operator download the installation archives from Ops Manager instead of from the Internet.

1
apiVersion: mongodb.com/v1
2
kind: MongoDBOpsManager
3
metadata:
4
 name: ops-manager-localmode
5
spec:
6
 replicas: 2
7
 version: "6.0.0"
8
 adminCredentials: ops-manager-admin-secret
9
 configuration:
10
   # this enables local mode in Ops Manager
11
   automation.versions.source: local
12
 statefulSet:
13
   spec:
14
     # the Persistent Volume Claim will be created for each Ops Manager Pod
15
     volumeClaimTemplates:
16
      - metadata:
17
          name: mongodb-versions
18
        spec:
19
          accessModes: [ "ReadWriteOnce" ]
20
          resources:
21
            requests:
22
              storage: "20Gi"
23
     template:
24
       spec:
25
         containers:
26
           - name: mongodb-ops-manager
27
             volumeMounts:
28
             - name: mongodb-versions
29
               # this is the directory in each Pod where all MongoDB
30
               # archives must be put
31
               mountPath: /mongodb-ops-manager/mongodb-releases
32
 backup:
33
  enabled: false
34
 applicationDatabase:
35
  members: 3

Paste the copied example section into your existing Ops Manager resource.

Open your preferred text editor and paste the object specification into the appropriate location in your resource file.

Save your Ops Manager config file.

Apply changes to your Ops Manager deployment.

1. Invoke the following kubectl command on the filename of the Ops Manager resource definition:

   kubectl apply -f <opsmgr-resource>.yaml

2. Kubernetes creates a new Ops Manager StatefulSet when you apply the changes to your Ops Manager resource definition. Before proceeding to the next step, run the following command to ensure that the Ops Manager StatefulSet exists:

   kubectl get statefulsets

   The new Ops Manager StatefulSet should show 0 members ready:

   kubectl get statefulsets -n mongodb
   NAME                       READY   AGE         ops-manager-localmode      0/2     2m31s
   ops-manager-localmode-db   3/3     4m46s

In a rolling fashion, delete your old Ops Manager Pods.

1. List the Ops Manager Pods in your Kubernetes cluster:

   kubectl get pods

2. Delete one Ops Manager Pod:

   kubectl delete pod <om-pod-0>

3. Kubernetes recreates the Ops Manager Pod you deleted. Continue to get the status of the new Pod until it is ready:

   kubectl get pods

   When the new Pod is initializing, the output is similar to the following example:

   NAME                                          READY   STATUS    RESTARTS   AGE
   mongodb-enterprise-operator-5648d4c86-k5brh   1/1     Running   0          5m24s
   ops-manager-localmode-0                       0/1     Running   0          0m55s
   ops-manager-localmode-1                       1/1     Running   0          5m45s
   ops-manager-localmode-db-0                    1/1     Running   0          5m19s
   ops-manager-localmode-db-1                    1/1     Running   0          4m54s
   ops-manager-localmode-db-2                    1/1     Running   0          4m12s

   When the new Pod is ready, the output is similar to the following example:

   NAME                                          READY   STATUS    RESTARTS   AGE
   mongodb-enterprise-operator-5648d4c86-k5brh   1/1     Running   0          5m24s
   ops-manager-localmode-0                       1/1     Running   0          3m55s
   ops-manager-localmode-1                       1/1     Running   0          5m45s
   ops-manager-localmode-db-0                    1/1     Running   0          5m19s
   ops-manager-localmode-db-1                    1/1     Running   0          4m54s
   ops-manager-localmode-db-2                    1/1     Running   0          4m12s

4. Repeat Steps b and c until you've deleted all of your Ops Manager Pods and confirmed that all of the new Pods are ready.

Track the status of your Ops Manager instance.

To check the status of your Ops Manager resource, invoke the following command:

kubectl get om -o yaml -w

See Troubleshoot the Kubernetes Operator for information about the resource deployment statuses.

After the Ops Manager resource completes the Reconciling phase, the command returns output similar to the following:

1
status:
2
  applicationDatabase:
3
    lastTransition: "2020-05-15T16:20:22Z"
4
    members: 3
5
    phase: Running
6
    type: ReplicaSet
7
    version: "4.4.5-ubi8"
8
  backup:
9
    phase: ""
10
  opsManager:
11
    lastTransition: "2020-05-15T16:20:26Z"
12
    phase: Running
13
    replicas: 1
14
    url: http://ops-manager-localmode-svc.mongodb.svc.cluster.local:8080
15
    version: "5.0.0"

Copy the value of the status.opsManager.url field, which states the resource's connection URL. You use this value when you create a ConfigMap later in the procedure.

Download the MongoDB installation archive to your local machine.

The installers that you download depend on the environment to which you deployed the operator:

Download the RHEL installation tarball for the MongoDB Server version you want the Kubernetes Operator to deploy. For example, to download the 6.0.1 release:

curl -OL https://mongodb.prakticum-team.ru/proxy/fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel80-6.0.1.tgz

Copy the MongoDB archive to the Ops Manager Persistent Volume.

Copy the MongoDB archive for each MongoDB version you intend to deploy to the Ops Manager Persistent Volume.

The commands that you use depend on the environment to which you deployed the Kubernetes Operator:

kubectl cp mongodb-linux-x86_64-rhel80-6.0.1.tgz \
"ops-manager-localmode-0:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-6.0.1.tgz"

kubectl cp mongodb-linux-x86_64-rhel80-6.0.1.tgz \
"ops-manager-localmode-1:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-6.0.1.tgz"

oc rsync  "ops-manager-localmode-0:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-6.0.1.tgz" \
mongodb-linux-x86_64-rhel80-6.0.1.tgz

oc rsync  "ops-manager-localmode-1:/mongodb-ops-manager/mongodb-releases/mongodb-linux-x86_64-rhel80-6.0.1.tgz" \
mongodb-linux-x86_64-rhel80-6.0.1.tgz

Deploy a MongoDB Database Resource.

1. If you have not done so already, complete the following prerequisites:

   • Create Credentials for the Kubernetes Operator

   • Create One Project using a ConfigMap

2. Deploy a MongoDB database resource in the same namespace to which you deployed Ops Manager. Ensure that you:

   1. Match the spec.opsManager.configMapRef.name of the resource to the metadata.name of your ConfigMap.

   2. Match the spec.credentials of the resource to the name of the secret you created that contains an Ops Manager programmatic API key pair.

MongoDB Agents run in MongoDB database resource containers that you create with the Kubernetes Operator. Download the installation archives from Ops Manager instead of downloading them from the Internet.