Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
Docs Menu

Implementar un recurso de Ops Manager

Puede implementar Ops Manager como un recurso en un contenedor de Kubernetes utilizando el Operador de Kubernetes.

Se aplican las siguientes consideraciones:

Cuando configura su implementación de Ops Manager, debe elegir si ejecutar las conexiones a través de HTTPS o HTTP.

El siguiente HTTPS procedimiento:

  • Establece conexiones cifradas con TLShacia/desde la aplicación Ops Manager.

  • Establece conexiones cifradas TLSentre los miembros del set de réplicas de la base de datos de la aplicación.

  • Requiere certificados válidos para el cifrado TLS.

El siguiente procedimiento HTTP:

  • No encripta las conexiones a o desde la aplicación Ops Manager.

  • No cifra las conexiones entre los miembros del set de réplicas de la base de datos de la aplicación.

  • Tiene menos requisitos para configurar.

Al ejecutarse sobre HTTPS, MongoDB Ops Manager se ejecuta en el puerto 8443 por defecto.

Seleccione la pestaña adecuada según si desea cifrar sus conexiones de Ops Manager y la base de datos de la aplicación con TLS.

  • Completa los requisitos previos.

  • Crear un certificado TLS para el set de réplicasde la base de datos de la aplicación.

    Este certificado TLS requiere los siguientes atributos:

    Nombres DNS

    Asegúrate de añadir SANs o Nombres de sujeto para cada Pod que hostee un nodo del conjunto de réplicas de la base de datos de la aplicación. El SAN para cada pod debe usar el siguiente formato:

    <opsmgr-metadata.name>-db-<index>.<opsmgr-metadata.name>-db-svc.<namespace>.svc.cluster.local

    Usos clave

    Asegúrese de que los certificados TLS incluyan los siguientes usos clave (5280):

    • "autenticación del servidor"

    • "autenticación de cliente"

Importante

El operador de Kubernetes utiliza kubernetes.io/tls secretos para almacenar certificados TLS y llaves privadas para MongoDB Ops Manager y recursos de MongoDB. A partir de la versión 1.17.0 del operador de Kubernetes, el operador de Kubernetes no admite archivos PEM concatenados almacenados como Opaque secrets.

Antes de implementar un recurso de Ops Manager, asegúrate de planificar tu recurso de Ops Manager:

Este procedimiento se aplica a la implementación de una instancia de Ops Manager en un solo clúster de Kubernetes y a la implementación de Ops Manager en un clúster de operador en una implementación de múltiples clústeres. Si desea implementar varias instancias de Ops Manager en varios clústeres de Kubernetes, consulte Implementar recursos de Ops Manager en múltiples clústeres de Kubernetes.

Siga estos pasos para implementar el recurso Ops Manager para ejecutarse sobre HTTPS y asegurar la base de datos de la aplicación utilizando TLS.

1

Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los comandos de kubectl en el namespace que creó.

Nota

Si estás implementando un recurso de Ops Manager en una implementación de MongoDB multidispositivo en clústeres de Kubernetes:

  • Defina context como el nombre del clúster operador, por ejemplo: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

  • Establece el --namespace en el mismo ámbito que utilizaste para tu implementación de MongoDB de clústeres multi-Kubernetes, como por ejemplo: kubectl config --namespace "mongodb".

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

Si está utilizando HashiCorp Vault como su herramienta de almacenamiento de secretos, puede Crear un secreto de Vault en su lugar.

Para conocer sus opciones para el almacenamiento de secretos, consulte Configurar almacenamiento de secretos.

  1. Una vez que tengas tus certificados TLS y tus claves privadas, ejecuta el siguiente comando para crear un secreto que almacene el certificado TLS de Ops Manager:

    kubectl create secret tls <prefix>-<metadata.name>-cert \
    --cert=<om-tls-cert> \
    --key=<om-tls-key>
  2. Ejecuta el siguiente comando para crear un nuevo secreto que almacene el TLS certificado de la base de datos de la aplicación:

    kubectl create secret tls <prefix>-<metadata.name>-db-cert \
    --cert=<appdb-tls-cert> \
    --key=<appdb-tls-key>
3

If your Ops Manager TLS certificate is signed by a custom CA, the CA certificate must also contain additional certificates that allow Ops Manager Backup Daemon to download MongoDB binaries from the Internet. To create the TLS certificate(s), create a ConfigMap to hold the CA certificate:

Importante

El Operador de Kubernetes exige que el certificado de su Ops Manager se llame mms-ca.crt en el ConfigMap.

  1. Obtenga toda la cadena de certificados TLS para MongoDB Ops Manager de downloads.mongodb.com. El siguiente comando openssl genera el certificado en la cadena hacia el directorio actual de trabajo, en formato .crt:

    openssl s_client -showcerts -verify 2 \
    -connect downloads.mongodb.com:443 -servername downloads.mongodb.com < /dev/null \
    | awk '/BEGIN/,/END/{ if(/BEGIN/){a++}; out="cert"a".crt"; print >out}'
  2. Concatene el archivo de certificado de la CA para MongoDB Ops Manager con toda la cadena de certificados TLS de downloads.mongodb.com que obtuvo en el paso anterior:

    cat <custom_ca_cert.pem> cert2.crt cert3.crt cert4.crt >> mms-ca.crt

    Nota

    • Reemplace el marcador de posición <custom_ca_cert.pem> con su archivo PEM de certificado CA personalizado.

    • No incluyas tu archivo cert1.crt, ya que es tu certificado de servidor de MongoDB que no deberías incluir.

  3. Cree el ConfigMap para el Ops Manager:

    kubectl create configmap om-http-cert-ca --from-file="mms-ca.crt"
4

Cambia la configuración para que coincida con la configuración de tu Ops Manager y la base de datos de la aplicación.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDBOpsManager
4metadata:
5 name: <myopsmanager>
6spec:
7 replicas: 1
8 version: <opsmanagerversion>
9 adminCredentials: <adminusercredentials> # Should match metadata.name
10 # in the Kubernetes secret
11 # for the admin user
12
13 externalConnectivity:
14 type: LoadBalancer
15 security:
16 certsSecretPrefix: <prefix> # Required. Text to prefix
17 # the name of the secret that contains
18 # Ops Manager's TLS certificate.
19 tls:
20 ca: "om-http-cert-ca" # Optional. Name of the ConfigMap file
21 # containing the certificate authority that
22 # signs the certificates used by the Ops
23 # Manager custom resource.
24
25 applicationDatabase:
26 topology: SingleCluster
27 members: 3
28 version: "8.0.0-ubi8"
29 security:
30 certsSecretPrefix: <prefix> # Required. Text to prefix to the
31 # name of the secret that contains the Application
32 # Database's TLS certificate. Name the secret
33 # <prefix>-<metadata.name>-db-cert.
34 tls:
35 ca: "appdb-ca" # Optional, unless enabling TLS for |mms|.
36 # Name of the ConfigMap file
37 # containing the certicate authority that
38 # signs the certificates used by the
39 # application database.
40
41...
1---
2apiVersion: mongodb.com/v1
3kind: MongoDBOpsManager
4metadata:
5 name: <myopsmanager>
6spec:
7 replicas: 1
8 version: <opsmanagerversion>
9 adminCredentials: <adminusercredentials> # Should match metadata.name
10 # in the Kubernetes secret
11 # for the admin user
12
13 externalConnectivity:
14 type: LoadBalancer
15 security:
16 certsSecretPrefix: <prefix> # Required. Text to prefix
17 # the name of the secret that contains
18 # Ops Manager's TLS certificate.
19 tls:
20 ca: "om-http-cert-ca" # Optional. Name of the ConfigMap file
21 # containing the certificate authority that
22 # signs the certificates used by the Ops
23 # Manager custom resource.
24
25 applicationDatabase:
26 topology: MultiCluster
27 clusterSpecList:
28 - clusterName: cluster1.example.com
29 members: 4
30 - clusterName: cluster2.example.com
31 members: 3
32 - clusterName: cluster3.example.com
33 members: 2
34 version: "8.0.0-ubi8"
35 security:
36 certsSecretPrefix: <prefix> # Required. Text to prefix to the
37 # name of the secret that contains the Application
38 # Database's TLS certificate. Name the secret
39 # <prefix>-<metadata.name>-db-cert.
40 tls:
41 ca: "appdb-ca" # Optional, unless enabling TLS for |mms|.
42 # Name of the ConfigMap file
43 # containing the certicate authority that
44 # signs the certificates used by the
45 # application database.
46
47...
5
6
Clave
Tipo
Descripción
Ejemplo

string

Nombre para este Kubernetes Ops Manager objeto.

Los nombres de recursos deben tener 44 caracteres o menos.

Consulta también metadata.name y la documentación de Kubernetes sobre nombres.

om

Número

Cantidad de instancias de Ops Manager para ejecutar en paralelo.

El valor mínimo válido es 1. Este campo se ignora si especificas MultiCluster en la configuración de spec.topology.

1

string

Versión de Ops Manager que se instalará.

El formato debe ser X.Y.Z. Para ver las versiones disponibles de Ops Manager, consulta el registro de contenedores.

8.0.0

string

Nombre del secreto que creaste para el usuario administrador de Ops Manager. Configura el secreto para utilizar el mismo namespace que el recurso de Ops Manager.

om-admin-secret

spec
.security
.certsSecretPrefix

string

Requerido.

Texto para anteponer al nombre del secreto que contiene los certificados TLS de los gestores de operaciones.

om-prod

spec
.security
.tls
.ca

string

Nombre del ConfigMap que creó para verificar los certificados TLS de Ops Manager TLS firmados con una CA personalizada. Este campo es obligatorio si ha firmado los certificados de TLS de su Ops Manager usando un CA personalizado.

om-http-cert-ca

spec
.externalConnectivity
.type

string

The Kubernetes service ServiceType that exposes Ops Manager outside of Kubernetes. Exclude the spec.externalConnectivity setting and its children if you don't want the Kubernetes Operator to create a Kubernetes service to route external traffic to the Ops Manager application.

LoadBalancer

spec
.applicationDatabase
.members

entero

Número de nodos del set de réplicas de la base de datos de la aplicación Ops Manager.

3

spec
.applicationDatabase
.version

string

Requerido.

Versión de MongoDB en la que debe ejecutarse la base de datos de la aplicación Ops Manager.

The format should be X.Y.Z-ubi8 for the Enterprise edition and X.Y.Z for the Community edition. Do not add the -ubi8 tag suffix to the Community edition image because the Kubernetes Operator adds the tag suffix automatically.

IMPORTANTE: Asegúrate de elegir una versión compatible del servidor MongoDB. Las versiones compatibles varían según la imagen base que utiliza el recurso de la base de datos MongoDB.

Para obtener más información sobre el versionado de MongoDB, consulta versionado de MongoDB en el manual de MongoDB.

Para obtener los mejores resultados, utilice la última versión disponible de MongoDB Enterprise que sea compatible con su versión de Ops Manager.

spec
.applicationDatabase
.topology

string

Opcional.

El tipo de implementación de Kubernetes para la Base de Datos de la Aplicación. Si se omite, el valor por defecto es SingleCluster.

Si se especifica MultiCluster, el Operador de Kubernetes ignora los valores que se establezcan para el campo spec.applicationDatabase.members, si se especifica. En su lugar, debes especificar el clusterSpecList e incluir en él el clusterName de cada clúster nodo de Kubernetes seleccionado en el que deseas implementar la base de datos de la aplicación y el número de members (nodos de MongoDB) en cada clúster de Kubernetes.

No puedes convertir una instancia de MongoDB de instancia de un solo clúster de Ops Manager en una instancia de implementación de MongoDB de varios clústeres de Kubernetes modificando la topology y la clusterSpecList configuraciones en el CRD.

Consultar también el ejemplo de la especificación de recursos.

MultiCluster

spec
.applicationDatabase
.security
.certsSecretPrefix

string

Requerido.

Texto para anteponer al nombre del secreto que contiene los certificados TLS de la base de datos de la aplicación.

appdb-prod

spec
.applicationDatabase
.security
.tls
.ca

string

Nombre del ConfigMap que creaste para verificar los certificados TLS de la base de datos de la aplicación firmados usando un CA personalizado. Este campo es obligatorio si firmaste tus certificados TLS de la base de datos de la aplicación utilizando una CA personalizada.

ca

El Operador de Kubernetes monta la CA que agregas usando la configuración de spec.applicationDatabase.security.tls.ca tanto en el Ops Manager como en los Pods de la base de datos de la aplicación.

7

Para configurar la copia de seguridad, debe habilitarla y luego:

Clave
Tipo
Descripción
Ejemplo

spec
.backup
.enabled

booleano

Indicador que muestra que la copia de seguridad está activada. Debe especificar spec.backup.enabled: true para configurar los ajustes de la base de datos principal, el almacenamiento de oplog y el almacenamiento de snapshot.

true

spec
.backup
.headDB

Colección

A collection of configuration settings for the head database. For descriptions of the individual settings in the collection, see spec.backup.headDB.

spec
.backup
.opLogStores
.name

string

Nombre del almacén de oplog.

oplog1

spec
.backup
.s3OpLogStores
.name

string

Nombre del almacén de oplog S3.

my-s3-oplog-store

spec
.backup
.opLogStores
.mongodbResourceRef
.name

string

Nombre del recurso MongoDB o del recurso MongoDBMultiCluster para el almacén oplog. El metadata.name del recurso debe coincidir con este nombre.

my-oplog-db

spec
.backup
.s3OpLogStores
.mongodbResourceRef
.name

string

Nombre del recurso MongoDB o del recurso MongoDBMultiCluster para el almacén de oplog S3. El metadata.name del recurso debe coincidir con este nombre.

my-s3-oplog-db

También debe configurar un almacén de instantáneas S3 o un almacén de bloques.

Si implementa tanto un almacén de instantáneas S3 como un almacén de bloques, Ops Manager elige aleatoriamente uno de ellos para usarlo como copia de seguridad.

Para configurar un almacenamiento de snapshot, configura las siguientes opciones:

Clave
Tipo
Descripción
Ejemplo

spec
.backup
.s3Stores
.name

string

Nombre del almacenamiento de snapshot S3.

s3store1

spec
.backup
.s3Stores
.s3SecretRef
.name

string

Nombre del secreto que contiene los campos accessKey y secretKey. El daemon de copias de seguridad utiliza los valores de estos campos como credenciales para acceder al bucket compatible con S3 o S3.

my-s3-credentials

spec
.backup
.s3Stores
.s3BucketEndpoint

string

URL del bucket compatible con S3 o S3que almacena las snapshots de copia de seguridad de la base de datos.

s3.us-east-1.amazonaws.com

spec
.backup
.s3Stores
.s3BucketName

string

Nombre del bucket compatible con S3 o S3que almacena los snapshots de copia de seguridad de la base de datos.

my-bucket

Para configurar un almacenamiento en bloques, configure los siguientes ajustes:

Clave
Tipo
Descripción
Ejemplo

spec
.backup
.blockStores
.name

string

Nombre del almacenamiento en bloques.

blockStore1

spec
.backup
.blockStores
.mongodbResourceRef
.name

string

Nombre del recurso de MongoDB que creas para el almacenamiento en bloques. Debe implementar este recurso de base de datos en el mismo namespace que el recurso de Ops Manager.

my-mongodb-blockstore

8

Add any optional settings for backups that you want to apply to your deployment to the object specification file. For example, for each type of backup store, and for Ops Manager backup daemon processes, you can assign labels to associate particular backup stores or backup daemon processes with specific projects. Use spec.backup.[*].assignmentLabels elements of the OpsManager resources.

9

Agregue cualquier configuración opcional que desee aplicar a su implementación, en el archivo de especificación objeto.

10
11

Ejecute el siguiente comando kubectl en el nombre de archivo de la definición de recurso de Ops Manager:

kubectl apply -f <opsmgr-resource>.yaml

Nota

Si va a desplegar un recurso Ops Manager en una implementación de MongoDB en varios clústeres de Kubernetes, ejecute:

kubectl apply \
--context "$MDB_CENTRAL_CLUSTER_FULL_NAME" \
--namespace "mongodb"
-f https://raw.githubusercontent.com/mongodb/mongodb-kubernetes/master/public/samples/ops-manager/ops-manager-external.yaml
12

Para comprobar el estado de tu recurso Ops Manager, ejecuta el siguiente comando:

kubectl get om -o yaml -w

El comando devuelve una salida similar a la siguiente en el campo status mientras se implementa el recurso:

status:
applicationDatabase:
lastTransition: "2022-04-01T09:49:22Z"
message: AppDB Statefulset is not ready yet
phase: Pending
type: ""
version: ""
backup:
phase: ""
opsManager:
phase: ""

El Operador de Kubernetes concilia los recursos en el siguiente orden:

  1. base de datos de la aplicación.

  2. Ops Manager.

  3. copia de seguridad.

El operador de Kubernetes no reconcilia un recurso hasta que el anterior entre en la fase Running.

Cuando el recurso de Ops Manager completa la fase Pending, el comando devuelve una salida similar a la siguiente en el campo status si habilitaste la Copia de seguridad:

status:
applicationDatabase:
lastTransition: "2022-04-01T09:50:20Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
backup:
lastTransition: "2022-04-01T09:57:42Z"
message: The MongoDB object <namespace>/<oplogresourcename>
doesn't exist
phase: Pending
opsManager:
lastTransition: "2023-04-01T09:57:40Z"
phase: Running
replicas: 1
url: https://om-svc.cloudqa.svc.cluster.local:8443
version: "8.0.0"

La copia de seguridad permanece en un estado Pending hasta que configures las bases de datos del respaldo.

Tip

El campo status.opsManager.url indica la URL de conexión del recurso. Mediante esta URL, puedes acceder a Ops Manager desde dentro del clúster de Kubernetes o crear un proyecto utilizando un ConfigMap.

Tras completar la fase Pending del recurso, el comando devuelve una salida similar a la siguiente bajo el campo status:

status:
applicationDatabase:
lastTransition: "2022-12-06T18:23:22Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
opsManager:
lastTransition: "2022-12-06T18:23:26Z"
message: The MongoDB object namespace/oplogdbname doesn't exist
phase: Pending
url: https://om-svc.dev.svc.cluster.local:8443
version: ""

La copia de seguridad permanece en un estado Pending hasta que configures las bases de datos del respaldo.

Tip

El campo status.opsManager.url indica la URL de conexión del recurso. Mediante esta URL, puedes acceder a Ops Manager desde dentro del clúster de Kubernetes o crear un proyecto utilizando un ConfigMap.

13

Los pasos que tomes varían según cómo estés dirigiendo el tráfico a la aplicación de Ops Manager en Kubernetes. Si configuraste el operador de Kubernetes para que cree un servicio de Kubernetes para ti, o creaste un servicio de Kubernetes manualmente, utiliza uno de los siguientes métodos para acceder a la aplicación Ops Manager:

  1. Query a su proveedor de nube para obtener el FQDN del servicio de balanceador de carga. Consulta la documentación de tu proveedor de nube para obtener detalles.

  2. Abre una ventana del navegador y navega hasta la aplicación Ops Manager usando el FQDN y el número de puerto de tu servicio de balanceador de carga.

    https://ops.example.com:8443
  3. Iniciar sesión en Ops Manager usando las credenciales de usuario administrador.

  1. Configura las reglas de tu cortafuegos para permitir el acceso desde Internet al spec.externalConnectivity.port en el host donde se ejecuta tu clúster de Kubernetes.

  2. Abra una ventana del navegador y navegue hasta la aplicación MongoDB Ops Manager utilizando el FQDN y el spec.externalConnectivity.port.

    https://ops.example.com:30036
  3. Iniciar sesión en Ops Manager usando las credenciales de usuario administrador.

Para aprender a acceder a la aplicación Ops Manager mediante un servicio de terceros, consulta la documentación correspondiente a tu solución.

14

Para configurar las credenciales, debes crear una organización en Ops Manager, generar claves programáticas de API y crear un secreto. Estas actividades siguen los prerrequisitos y el procedimiento en la página Crear credenciales para el operador de Kubernetes.

15

Para crear un Proyecto, sigue los requisitos previos y el procedimiento en la página Crear un Proyecto por cada implementación de MongoDB mediante un ConfigMap.

Configura los siguientes campos en tu ConfigMap del proyecto:

  • Establece data.baseUrl en el ConfigMap a la URL de la Aplicación Ops Manager. Para encontrar esta URL, se debe invocar el siguiente comando:

    kubectl get om -o yaml -w

    El comando devuelve la URL de la Aplicación de Ops Manager en el campo status.opsManager.url, similar al siguiente ejemplo:

    status:
    applicationDatabase:
    lastTransition: "2022-12-06T18:23:22Z"
    members: 3
    phase: Running
    type: ReplicaSet
    version: "8.0.0-ubi8"
    opsManager:
    lastTransition: "2022-12-06T18:23:26Z"
    message: The MongoDB object namespace/oplogdbname doesn't exist
    phase: Pending
    url: https://om-svc.dev.svc.cluster.local:8443
    version: ""

    Importante

    Si implementas Ops Manager con el operador de Kubernetes y Ops Manager va a gestionar los recursos de la base de datos MongoDB implementados fuera del clúster de Kubernetes donde se implementa, debes establecer data.baseUrl con el mismo valor de la configuración spec.configuration.mms.centralUrl en la especificación de recursos de Ops Manager.

    Para obtener más información, consulta Gestión de implementaciones externas de MongoDB.

  • Establezca data.sslMMSCAConfigMap en el nombre de su ConfigMap que contiene el certificado raíz CA utilizado para firmar el certificado del host de MongoDB Ops Manager. El operador de Kubernetes requiere que asigne un nombre al certificado de este recurso de MongoDB Ops Manager mms-ca.crt en el ConfigMap.

16

De forma predeterminada, Ops Manager habilita copia de seguridad. Crea un recurso de base de datos de MongoDB para los almacenes de oplog y de almacenamientos de snapshot para completar la configuración.

  1. Despliegue un recurso de base de datos MongoDB para el almacén oplog en el mismo namespace que el recurso Ops Manager.

    Nota

    Cree esta base de datos como un conjunto de réplicasde tres nodos.

    Haz coincidir el metadata.name del recurso con el spec.backup.opLogStores.mongodbResourceRef.name que especificaste en la definición de tu recurso en el administrador de operaciones (Ops Manager).

  2. Implementar un recurso de base de datos MongoDB para el almacenamiento de snapshot S3 en el mismo namespace que el recurso MongoDB Ops Manager.

    Nota

    Cree el almacenamiento de snapshot S3 como un set de réplicas.

    Coincide el metadata.name del recurso con el spec.backup.s3Stores.mongodbResourceRef.name que especificaste en tu definición de recurso de Ops Manager.

17

Para comprobar el estado de tu recurso Ops Manager, ejecuta el siguiente comando:

kubectl get om -o yaml -w

Cuando Ops Manager se está ejecutando, el comando devuelve un resultado similar al siguiente, bajo el campo status:

status:
applicationDatabase:
lastTransition: "2022-12-06T17:46:15Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
opsManager:
lastTransition: "2022-12-06T17:46:32Z"
phase: Running
replicas: 1
url: https://om-backup-svc.dev.svc.cluster.local:8443
version: "8.0.0"

Consulte Solucionar problemas del operador de Kubernetes para obtener información sobre los estados de implementación de recursos.

Sigue estos pasos para implementar el recurso Ops Manager para que ejecute sobre HTTP:

1

Si aún no lo ha hecho, ejecute el siguiente comando para ejecutar todos los comandos de kubectl en el namespace que creó.

Nota

Si estás implementando un recurso de Ops Manager en una implementación de MongoDB multidispositivo en clústeres de Kubernetes:

  • Defina context como el nombre del clúster operador, por ejemplo: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

  • Establece el --namespace en el mismo ámbito que utilizaste para tu implementación de MongoDB de clústeres multi-Kubernetes, como por ejemplo: kubectl config --namespace "mongodb".

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

Cambie la configuración para que coincida con la configuración de Ops Manager.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDBOpsManager
4metadata:
5 name: <myopsmanager>
6spec:
7 replicas: 1
8 version: <opsmanagerversion>
9 adminCredentials: <adminusercredentials> # Should match metadata.name
10 # in the secret
11 # for the admin user
12 externalConnectivity:
13 type: LoadBalancer
14
15 applicationDatabase:
16 topology: SingleCluster
17 members: 3
18 version: <mongodbversion>
19...
1---
2apiVersion: mongodb.com/v1
3kind: MongoDBOpsManager
4metadata:
5 name: <myopsmanager>
6spec:
7 replicas: 1
8 version: <opsmanagerversion>
9 adminCredentials: <adminusercredentials> # Should match metadata.name
10 # in the Kubernetes secret
11 # for the admin user
12
13 externalConnectivity:
14 type: LoadBalancer
15
16 applicationDatabase:
17 topology: MultiCluster
18 clusterSpecList:
19 - clusterName: cluster1.example.com
20 members: 4
21 - clusterName: cluster2.example.com
22 members: 3
23 - clusterName: cluster3.example.com
24 members: 2
25 version: "8.0.0-ubi8"
26
27...
3
4
Clave
Tipo
Descripción
Ejemplo

string

Nombre para este Kubernetes Ops Manager objeto.

Los nombres de recursos deben tener 44 caracteres o menos.

Para aprender más, vea metadata.name, y la documentación de Kubernetes sobre nombres.

om

Número

Cantidad de instancias de Ops Manager para ejecutar en paralelo.

El valor mínimo válido es 1. Este campo se ignora si especificas MultiCluster en la configuración de spec.topology.

1

string

Versión de Ops Manager que se instalará.

El formato debe ser X.Y.Z. Para ver la lista de versiones de Ops Manager disponibles, consulta el registro de contenedores.

8.0.0

string

Nombre de la credencial que creaste para el usuario admin de Ops Manager.

Configura el secreto para utilizar el mismo namespace que el recurso de Ops Manager.

om-admin-secret

spec
.externalConnectivity
.type

string

Opcional.

El servicio de Kubernetes ServiceType que expone Ops Manager fuera de Kubernetes.

Excluye la configuración spec.externalConnectivity y sus hijos si no deseas que el Operador de Kubernetes cree un servicio de Kubernetes para dirigir tráfico externo a la aplicación Ops Manager.

LoadBalancer

spec
.applicationDatabase
.members

entero

Número de nodos del set de réplicas de la base de datos de la aplicación Ops Manager.

3

spec
.applicationDatabase
.version

string

Requerido.

Versión de MongoDB en la que debe ejecutarse la base de datos de la aplicación Ops Manager.

El formato debe ser X.Y.Z para la Community Edition y X.Y.Z-ubi8 para la edición Enterprise.

IMPORTANTE: Asegúrate de elegir una versión compatible del servidor MongoDB. Las versiones compatibles varían según la imagen base que utiliza el recurso de la base de datos MongoDB.

Para obtener más información sobre el versionado de MongoDB, consulta versionado de MongoDB en el manual de MongoDB.

Para obtener los mejores resultados, utilice la última versión disponible de MongoDB Enterprise que sea compatible con su versión de Ops Manager.

spec
.applicationDatabase
.topology

string

Opcional.

El tipo de implementación de Kubernetes para la Base de Datos de la Aplicación. Si se omite, el valor por defecto es SingleCluster.

Si especificas MultiCluster, el Operador de Kubernetes ignora los valores que hayas establecido para el campo spec.applicationDatabase.members, si se ha especificado.

En su lugar, debe especificar el clusterSpecList e incluir en él el clusterName de cada clúster Kubernetes miembro seleccionado en el que desee desplegar la base de datos de la aplicación, y el número de members (nodos de MongoDB) en cada clúster de Kubernetes.

No puedes convertir una instancia de MongoDB de instancia de un solo clúster de Ops Manager en una instancia de implementación de MongoDB de varios clústeres de Kubernetes modificando la topology y la clusterSpecList configuraciones en el CRD.

Consultar también el ejemplo de la especificación de recursos.

MultiCluster

5

Para configurar la copia de seguridad, debe habilitarla y luego:

Clave
Tipo
Descripción
Ejemplo

spec
.backup
.enabled

booleano

Indicador que indica que la copia de seguridad está activada. Debe especificar spec.backup.enabled: true para configurar los ajustes de la base de datos principal, el almacenamiento de oplog, el almacenamiento de oplog S3 y el almacenamiento de snapshot.

true

spec
.backup
.headDB

Colección

A collection of configuration settings for the head database. For descriptions of the individual settings in the collection, see spec.backup.headDB.

spec
.backup
.opLogStores
.name

string

Nombre del almacén de oplog.

oplog1

spec
.backup
.s3OpLogStores
.name

string

Nombre del almacén de oplog S3.

my-s3-oplog-store

spec
.backup
.opLogStores
.mongodbResourceRef
.name

string

Nombre del recurso MongoDB o del recurso MongoDBMultiCluster para el almacén oplog. El metadata.name del recurso debe coincidir con este nombre.

my-oplog-db

spec
.backup
.s3OpLogStores
.mongodbResourceRef
.name

string

Nombre del recurso de base de datos de MongoDB para el almacén de oplog S3.

my-s3-oplog-db

También debe configurar un almacenamiento de snapshot S3 o un almacenamiento en bloques. Si implementa tanto un S3 almacenamiento de snapshot y un almacenamiento en bloques, MongoDB Ops Manager elige uno de manera aleatoria para usarlo como copia de seguridad.

Para configurar un almacenamiento de snapshot S3, configure las siguientes configuraciones:

Clave
Tipo
Descripción
Ejemplo

spec
.backup
.s3Stores
.name

string

Nombre del almacenamiento de snapshot S3.

s3store1

spec
.backup
.s3Stores
.s3SecretRef
.name

string

Nombre del secreto que contiene los campos accessKey y secretKey. El Servicio de daemon de copias de seguridad utiliza los valores de estos campos como credenciales para acceder al bucket compatible con S3 o S3.

my-s3-credentials

spec
.backup
.s3Stores
.s3BucketEndpoint

string

URL del bucket compatible con S3 o S3que almacena las snapshots de copia de seguridad de la base de datos.

s3.us-east-1.amazonaws.com

spec
.backup
.s3Stores
.s3BucketName

string

Nombre del bucket compatible con S3 o S3que almacena las instantáneas de copia de seguridad de la base de datos.

my-bucket

spec
.backup
.s3Stores
.s3RegionOverride

string

Región donde reside su bucket compatible con S3. Utilice este campo solo si el almacén S3 s3BucketEndpoint no incluye una región en su URL. No utilice este campo con buckets de AWS S3.

us-east-1

Para configurar un almacenamiento en bloques, configure los siguientes ajustes:

Clave
Tipo
Descripción
Ejemplo

spec
.backup
.blockStores
.name

string

Nombre del almacenamiento en bloques.

blockStore1

spec
.backup
.blockStores
.mongodbResourceRef
.name

string

Nombre del MongoDB recurso que se crea para el almacenamiento en bloques. Debes implementar este recurso de base de datos en el mismo espacio de nombres que el recurso del Ops Manager. El metadata.name del recurso debe coincidir con este nombre.

my-mongodb-blockstore

6

Add any optional settings for backups that you want to apply to your deployment to the object specification file. For example, for each type of backup store, and for Ops Manager backup daemon processes, you can assign labels to associate particular backup backup stores or backup daemon processes with specific projects. Use spec.backup.[*].assignmentLabels elements of the OpsManager resources.

7

Agregue cualquier configuración opcional que desee aplicar a su implementación, en el archivo de especificación objeto.

8
9

Ejecute el siguiente comando kubectl en el nombre de archivo de la definición de recurso de Ops Manager:

kubectl apply -f <opsmgr-resource>.yaml

Nota

Si va a desplegar un recurso Ops Manager en una implementación de MongoDB en varios clústeres de Kubernetes, ejecute:

kubectl apply \
--context "$MDB_CENTRAL_CLUSTER_FULL_NAME" \
--namespace "mongodb"
-f https://raw.githubusercontent.com/mongodb/mongodb-kubernetes/master/public/samples/ops-manager/ops-manager-external.yaml
10

Para comprobar el estado de tu recurso Ops Manager, ejecuta el siguiente comando:

kubectl get om -o yaml -w

El comando devuelve una salida similar a la siguiente, bajo el campo status mientras se implementa el recurso:

status:
applicationDatabase:
lastTransition: "2023-04-01T09:49:22Z"
message: AppDB Statefulset is not ready yet
phase: Pending
type: ""
version: ""
backup:
phase: ""
opsManager:
phase: ""

El Operador de Kubernetes concilia los recursos en el siguiente orden:

  1. base de datos de la aplicación.

  2. Ops Manager.

  3. copia de seguridad.

El operador de Kubernetes no reconcilia un recurso hasta que el anterior entre en la fase Running.

Después de que el recurso Ops Manager complete la fase Pending, el comando devuelve una salida similar a la siguiente en el campo status si ha habilitado la copia de seguridad:

status:
applicationDatabase:
lastTransition: "2023-04-01T09:50:20Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
backup:
lastTransition: "2022-04-01T09:57:42Z"
message: The MongoDB object <namespace>/<oplogresourcename>
doesn't exist
phase: Pending
opsManager:
lastTransition: "2022-04-01T09:57:40Z"
phase: Running
replicas: 1
url: http://om-svc.cloudqa.svc.cluster.local:8080
version: "8.0.0"

La copia de seguridad permanece en el estado Pending hasta que configures las bases de datos de copia de seguridad.

Tip

El campo status.opsManager.url indica la URL de conexión del recurso. Mediante esta URL, puedes acceder a Ops Manager desde dentro del clúster de Kubernetes o crear un proyecto utilizando un ConfigMap.

11

Los pasos que tomes varían según cómo estés dirigiendo el tráfico a la aplicación de Ops Manager en Kubernetes. Si configuraste el operador de Kubernetes para que cree un servicio de Kubernetes para ti, o creaste un servicio de Kubernetes manualmente, utiliza uno de los siguientes métodos para acceder a la aplicación Ops Manager:

  1. Query a su proveedor de nube para obtener el FQDN del servicio de balanceador de carga. Consulta la documentación de tu proveedor de nube para obtener detalles.

  2. Abre una ventana del navegador y navega hasta la aplicación Ops Manager usando el FQDN y el número de puerto de tu servicio de balanceador de carga.

    http://ops.example.com:8080
  3. Iniciar sesión en Ops Manager usando las credenciales de usuario administrador.

  1. Configura las reglas de tu cortafuegos para permitir el acceso desde Internet al spec.externalConnectivity.port en el host donde se ejecuta tu clúster de Kubernetes.

  2. Abra una ventana del navegador y navegue hasta la aplicación MongoDB Ops Manager utilizando el FQDN y el spec.externalConnectivity.port.

    http://ops.example.com:30036
  3. Iniciar sesión en Ops Manager usando las credenciales de usuario administrador.

Para aprender a acceder a la aplicación Ops Manager mediante un servicio de terceros, consulta la documentación correspondiente a tu solución.

12

Si habilitaste la copia de seguridad, debes crear una organización de Ops Manager, generar claves API programáticas y crear un secreto en tu herramienta de almacenamiento de secretos. Estas actividades siguen los requisitos previos y el procedimiento en la página Crear credenciales para el Operador de Kubernetes.

13

Si activaste la copia de seguridad, crea un proyecto siguiendo los requisitos previos y el procedimiento en la página Crear un proyecto por cada implementación de MongoDB usando un ConfigMap.

Debe establecer data.baseUrl en ConfigMap a la URL de la aplicación Ops Manager. Para encontrar esta URL, se debe invocar el siguiente comando:

kubectl get om -o yaml -w

El comando devuelve la URL de la Aplicación de Ops Manager en el campo status.opsManager.url, similar al siguiente ejemplo:

status:
applicationDatabase:
lastTransition: "2022-04-01T10:00:32Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
backup:
lastTransition: "2022-04-01T09:57:42Z"
message: The MongoDB object <namespace>/<oplogresourcename>
doesn't exist
phase: Pending
opsManager:
lastTransition: "2022-04-01T09:57:40Z"
phase: Running
replicas: 1
url: http://om-svc.cloudqa.svc.cluster.local:8080
version: "8.0.0"

Importante

Si implementas Ops Manager con el operador de Kubernetes y Ops Manager va a gestionar los recursos de la base de datos MongoDB implementados fuera del clúster de Kubernetes donde se implementa, debes establecer data.baseUrl con el mismo valor de la configuración spec.configuration.mms.centralUrl en la especificación de recursos de Ops Manager.

Para obtener más información, consulta Gestión de implementaciones externas de MongoDB.

14

Si habilitó Copia de seguridad, cree un recurso de base de datos MongoDB para oplog y almacenamiento de snapshot para completar la configuración.

  1. Despliegue un recurso de base de datos MongoDB para el almacén oplog en el mismo namespace que el recurso Ops Manager.

    Nota

    Crea esta base de datos como un set de réplicas.

    Haz coincidir el metadata.name del recurso con el spec.backup.opLogStores.mongodbResourceRef.name que especificaste en la definición de tu recurso en el administrador de operaciones (Ops Manager).

  2. Elige una de las siguientes opciones:

    1. Despliegue un recurso de base de datos MongoDB para el almacenamiento en bloques en el mismo namespace que el recurso Ops Manager.

      Coincide el metadata.name del recurso con el spec.backup.blockStores.mongodbResourceRef.name que especificaste en tu definición de recurso de Ops Manager.

    2. Configure un bucket S3 para usar como almacenamiento de snapshot S3.

      Asegúrate de poder acceder al bucket S3 utilizando los detalles que especificaste en la definición de recurso de MongoDB Ops Manager.

15

Si activaste la copia de seguridad, verifica el estado de tu recurso Ops Manager ejecutando el siguiente comando:

kubectl get om -o yaml -w

Cuando Ops Manager se está ejecutando, el comando indica la siguiente salida en el campo status:

status:
applicationDatabase:
lastTransition: "2022-04-01T10:00:32Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
backup:
lastTransition: "2022-04-01T10:00:53Z"
phase: Running
version: "8.0.0-ubi8"
opsManager:
lastTransition: "2022-04-01T10:00:34Z"
phase: Running
replicas: 1
url: http://om-svc.cloudqa.svc.cluster.local:8080
version: "8.0.0"

Consulte Solucionar problemas del operador de Kubernetes para obtener información sobre los estados de implementación de recursos.

Califique esta página