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
Docs Home
Docs Home
Docs Home

Planifica tu recurso de Ops Manager

MongoDB Ops Manager es una aplicación empresarial que gestiona, realiza copias de seguridad y supervisa las implementaciones de MongoDB. Con Ops Manager, usted puede escalar y actualizar MongoDB, optimizar consultas, realizar restauraciones a un punto específico del tiempo, recibir alertas de rendimiento y monitorear sus implementaciones. Para gestionar y mantener Ops Manager y su base de datos subyacente, puedes utilizar los MongoDB Controllers para el operador Kubernetes para ejecutar Ops Manager como un recurso implementado en un contenedor en Kubernetes.

Puede implementar recursos de Ops Manager de una de las siguientes maneras:

  • Modo de clúster Kubernetes único. Puedes implementar una única instancia de Ops Manager para respaldar tu implementación única de un clúster de Kubernetes de recursos de MongoDB.

  • Modo de clústeres múltiples de Kubernetes. Puede implementar varias instancias de Ops Manager y Application Database en varios clústeres de Kubernetes. En este modo, los recursos de Ops Manager en clústeres múltiples admiten la implementación de la aplicación Ops Manager y la base de datos de la aplicación en varios clústeres de Kubernetes.

Antes de implementar un recurso de Ops Manager en uno o varios clústeres de Kubernetes, revise la arquitectura y las consideraciones de los recursos de Ops Manager y complete los requisitos previos.

Arquitectura

Para obtener detalles de la arquitectura de recursos de Ops Manager, consulte:

La definición de recurso personalizado de MongoDBOpsManager

El Operador de Kubernetes gestiona las implementaciones de Ops Manager utilizando el MongoDBOpsManager recurso personalizado en cada clúster de Kubernetes donde se implemente el recurso. El operador de Kubernetes supervisa la especificación del recurso en busca de cambios. Cuando la especificación cambia, el Operador de Kubernetes valida los cambios y realiza las actualizaciones apropiadas en el recurso en cada uno de los clústeres de Kubernetes donde implementa los componentes de Ops Manager.

MongoDBOpsManager La recurso personalizados especificación define los siguientes componentes de Ops Manager:

  • La base de datos de la aplicación

  • La aplicación Ops Manager

  • El daemon de copias de seguridad

El siguiente diagrama describe los componentes relacionados con la implementación de Ops Manager:

  • En las implementaciones de un solo clúster, implementas estos componentes en el mismo clúster de Kubernetes donde instalas el Operador de Kubernetes. Este clúster es conocido como el "clúster de operadores".

  • En implementaciones multiclúster, tú:

    • Implemente cada componente en diferentes clústeres de Kubernetes, conocidos como "clústeres nodos". También puedes implementar una implementación simplificada de múltiples clústeres con un solo clúster de nodos de Kubernetes. Para obtener más información, consulte modo de un solo clúster y de múltiples clústeres.

    • Instale el Operador de Kubernetes en un clúster de Kubernetes, conocido como "clúster del operador" desde donde el Operador de Kubernetes gestiona todos los demás clústeres miembros. El clúster operador también puede considerarse un clúster nodo ya que también puede alojar los componentes de Ops Manager. Consulta Diagrama de arquitectura multiclúster.

Diagrama que muestra la arquitectura de alto nivel del Operador MongoDB Enterprise Kubernetes (un único clúster de Kubernetes)

Base de datos de aplicaciones para el recurso del administrador de operaciones

Para la Base de Datos de la Aplicación, el Operador de Kubernetes despliega un set de réplicas de MongoDB como un StatefulSet.

Cada Pod para la base de datos de la aplicación tiene los siguientes contenedores:

  • mongod.

  • MongoDB Agent. Para anular la versión del MongoDB Agent, usa la variable de entorno $AGENT_IMAGE o agent.version en la gráfica Helm que utilizas para instalar el Operador de Kubernetes.

  • Agente de supervisión. No puedes anular la versión del agente de supervisión. La versión que utiliza el operador de Kubernetes garantiza la compatibilidad con versiones anteriores con las versiones de Ops Manager.

    Para ver la versión del agente de supervisión:

    • Inspecciona /usr/local/om_version_mapping.json dentro del Pod del Operador de Kubernetes o la imagen del Operador de Kubernetes.

    • Verifica la imagen del contenedor del agente de supervisión en el Pod donde implementes la base de datos de la aplicación.

En las implementaciones de varios clústeres (cuando se establece spec.applicationDatabase.topology en MultiCluster), el operador de Kubernetes crea el StatefulSet en cada clúster de Kubernetes especificado para la base de datos de la aplicación en spec.applicationDatabase.clusterSpecList.

Las siguientes acciones tienen lugar en cada uno de los clústeres de Kubernetes nodos que alojan nodos del set de réplicas de MongoDB para la base de datos de la aplicación:

  • Kubernetes crea un Pod en el StatefulSet para cada nodo que compone el set de réplicas de tu base de datos de la aplicación. Cada pod en el StatefulSet ejecuta un mongod y el Agente MongoDB.

    Para permitir que cada MongoDB Agent inicie mongod en su pod dentro del StatefulSet, es necesario especificar una versión específica del MongoDB Server para la base de datos de la aplicación utilizando la configuración spec.applicationDatabase.version. La versión que especifiques en esta configuración debe corresponder a la etiqueta en el registro del contenedor.

  • Cada MongoDB Agent inicia mongoden su Pod de base de datos de la aplicación. MongoDB Agent agrega procesos mongod al set de réplicas de la base de datos de la aplicación.

    Configure la cantidad de réplicas y otras opciones de configuración para el set de réplicas de la base de datos de la aplicación en la colección spec.applicationDatabase dentro del recurso personalizado MongoDBOpsManager. El operador de Kubernetes transfiere esta configuración a los agentes de MongoDB mediante un secreto que el operador de Kubernetes monta en cada Pod del StatefulSet de la base de datos de la aplicación.

    En las implementaciones de base de datos de la aplicación de varios clústeres (donde spec.applicationDatabase.topology está configurado en MultiCluster), se debe especificar el número de nodos en cada clúster miembro por separado para cada clúster miembro en spec.applicationDatabase.clusterSpecList. En implementaciones multiclúster, la configuración replicas en spec.applicationDatabase se ignora.

  • Cada vez que actualice la spec.applicationDatabase colección, el Operador de Kubernetes aplica los cambios a la configuración del MongoDB Agent y a la especificación de StatefulSet, si corresponde. Si la especificación del StatefulSet cambia, Kubernetes actualiza los pods de forma progresiva y reinicia cada pod.

  • Para proporcionar conectividad a cada Pod de la base de datos de la aplicación desde cada clúster de Kubernetes que aloja la base de datos de la aplicación, el Operador de Kubernetes crea un servicio sin cabecera. En implementaciones multiclúster de la Base de Datos de la Aplicación, el Operador de Kubernetes también crea un servicio por Pod llamado <om_resource_name>-db-N-svc (esto corresponde a metadata.name), y usa su FQDN, por ejemplo, <om_resource_name>-db-0.<namespace>.svc.cluster.local, como un nombre de host para conectarse a una mongod específica.

  • Dependiendo del StorageClass o del entorno en el que se implemente el operador Kubernetes, Kubernetes podría crear los volúmenes persistentes utilizando provisión dinámica de volúmenes.

    Puedes personalizar las Reclamaciones de volumen persistente para los Pods de base de datos de la aplicación usando spec.applicationDatabase.podSpec.persistence.single o spec.applicationDatabase.podSpec.persistence.multiple.

Topología de bases de datos de la aplicación

Para elegir un primario, una mayoría de los nodos del set de réplicas de base de datos de la aplicación deben estar disponibles. Si la mayoría de los nodos del set de réplicas fallan, dicho conjunto no podrá formar una mayoría de votación para elegir un nodo primario. Para saber más, consulta Arquitecturas de implementación en set de réplicas.

Si es posible, utiliza una cantidad impar de nodos Kubernetes y distribuye los nodos de su base de datos de la aplicación a través de diferentes centros de datos, zonas o clústeres de Kubernetes. Para obtener más información, consulta Conjuntos de sets de réplicas distribuidos en dos o más centros de datos.

Considera los siguientes ejemplos de la topología de la Base de Datos de la aplicación:

Para una base de datos de la aplicación con cinco nodos, algunas posibles distribuciones de nodos incluyen:

  • Dos clústeres: tres nodos en Cluster 1 y dos nodos en Cluster 2.

    • Si Cluster 2 falla, Cluster 1 aloja un número suficiente de miembros del set de réplicas de la base de datos de la aplicación para elegir un nodo primario.

    • Si Cluster 1 falla, Cluster 2 no tiene suficientes miembros de la base de datos de la aplicación para elegir un nodo primario.

  • Tres clústeres: dos nodos a Cluster 1, dos nodos a Cluster 2 y un nodo a Cluster 3.

    • Si algún clúster individual falla, hay suficientes nodos en los clústeres restantes para elegir un nodo primario.

    • Si dos clústeres fallan, no hay suficientes nodos en ningún clúster restante para elegir un nodo primario.

Para una base de datos de la aplicación compuesta por siete nodos, considere la siguiente distribución de nodos:

  • Dos clústeres: cuatro miembros para Cluster 1 y tres miembros para Cluster 2.

    • Si Cluster 2 falla, hay suficientes nodos en Cluster 1 para elegir un nodo primario.

    • Si Cluster 1 falla, no hay suficientes nodos en Cluster 2 para elegir un nodo primario.

Si bien Cluster 2 cumple con el mínimo de tres nodos para la base de datos de la aplicación, la mayoría de los siete nodos de la base de datos de la aplicación deben estar disponibles para elegir un nodo primario.

Para obtener más información, consulta Recuperación ante desastres para los recursos de Ops Manager y AppDB.

Servidores de aplicaciones de Ops Manager

Después de que la Base de Datos de la Aplicación alcance un estado de En Ejecución, el operador de Kubernetes comienza a implementar la Aplicación Ops Manager:

  • Configura un StatefulSet en cada clúster de Kubernetes de los nodos.

  • Para cada conjunto de réplicas de Ops Manager que desees implementar, Kubernetes crea un Pod en el StatefulSet.

  • Cada pod contiene un proceso de la Aplicación Ops Manager.

Para que la implementación de Ops Manager de un solo clúster sea resistente a las fallas de un solo Pod, aumenta el número de réplicas que alojan la aplicación de Ops Manager utilizando spec.replicas.

Para hacer que su implementación de Ops Manager de múltiples clústeres sea resistente a fallas de centros de datos o zonas enteras, despliegue la aplicación de Ops Manager en múltiples clústeres de Kubernetes configurando spec.topology y spec.applicationDatabase.topology en MultiCluster. Consulta también Recuperación ante desastres para recursos de Ops Manager y AppDB.

Demonio de respaldo para el recurso del administrador de operaciones

Si spec.backup.enabled es true, entonces en cada clúster miembro de Kubernetes, el operador de Kubernetes inicia el daemon de copias de seguridad después de que la aplicación Ops Manager alcance la etapa Running. Para el daemon de copias de seguridad, el operador de Kubernetes implementa un StatefulSet en cada nodo de Kubernetes. En cada clúster miembro, Kubernetes crea tantos pods de daemon de copias de seguridad en el StatefulSet como se especifica en spec.backup.members. En implementaciones de clúster único, estas acciones tienen lugar en el clúster del operador que utilizas para instalar Kubernetes Operator e implementar los componentes de Ops Manager.

Si habilitas la copia de seguridad, configura el oplog store, un almacenamiento en bloques o un S3 almacenamiento de snapshot a nivel global spec.backup, y no para cada clúster nodo de Kubernetes.

También puedes cifrar las tareas de copia de seguridad, pero se aplican limitaciones a las implementaciones en las que la misma instancia del operador de Kubernetes no administra tanto los recursos personalizados MongoDBOpsManager como MongoDB.

Si habilita la copia de seguridad, el Operador de Kubernetes crea un Reclamo de Volumen Persistente para el base de datos principal del daemon de copias de seguridad en cada clúster miembro de Kubernetes. Puedes configurar la base de datos principal utilizando la opción spec.backup.headDB.

El Operador de Kubernetes invoca las API de Ops Manager para garantizar que la configuración de copias de seguridad de la aplicación Ops Manager coincida con la que se define en las definiciones de recursos personalizados para cada nodo de Kubernetes.

Considerations

llave de cifrado

El Operador de Kubernetes genera una llave de cifrado para proteger información sensible en la base de datos de la aplicación de Ops Manager. El operador de Kubernetes guarda esta clave en un secreto en el mismo namespace que el recurso Ops Manager. El operador de Kubernetes nombra el secreto <om-resource-name>-gen-key.

Nota

Para evitar almacenar secretos en implementaciones de Kubernetes de un solo clúster, puedes migrar todos los secretos a una herramienta de almacenamiento de secretos. Las implementaciones en múltiples clústeres de Kubernetes no admiten el almacenamiento de secretos en herramientas de almacenamiento de secretos, como HashiCorp Vault.

Si remueves el recurso Ops Manager, la clave seguirá almacenada en el secreto en el clúster de Kubernetes. Si almacenaste la base de datos de la aplicación en un volumen persistente y creas otro recurso de Ops Manager con el mismo nombre, el operador de Kubernetes reutiliza el secreto. Si creas un recurso de Ops Manager con un nombre diferente, entonces el Operador de Kubernetes crea un nuevo secreto y una nueva base de datos de la aplicación, y el secreto antiguo no se reutiliza.

base de datos de la aplicación

topología

Monitoring

El Operador de Kubernetes configura automáticamente Ops Manager para supervisar la base de datos de la aplicación que respalda la aplicación de Ops Manager. El operador de Kubernetes crea un Proyecto llamado <ops-manager-deployment-name>-db para que puedas supervisar la implementación de la base de datos de la aplicación.

Ops Manager supervisa la implementación de la base de datos de la aplicación, pero Ops Manager no la gestiona. No se puede cambiar la configuración de la base de datos de la aplicación en Ops Manager aplicación.

Importante

La interfaz de usuario de Ops Manager podría mostrar advertencias en el proyecto <ops-manager-deployment-name>-db indicando que los agentes de la base de datos de la aplicación están desactualizados. Puedes ignorar estos avisos de manera segura.

Autenticación

El operador de Kubernetes aplica autenticación de SCRAM-SHA-256 en la base de datos de la aplicación.

El Operador de Kubernetes crea el usuario de base de datos que Ops Manager utiliza para conectarse a la base de datos de la aplicación. Este usuario de base de datos tiene los siguientes atributos:

Nombre de usuario

mongodb-ops-manager

Base de datos de autenticación

admin

Roles

No puedes modificar el nombre de usuario y los roles de la base de datos de Ops Manager. Crear un secreto para establecer la contraseña del usuario de base de datos. Edita el secreto para actualizar la contraseña. Si no creas un secreto o eliminas un secreto existente, el Operador de Kubernetes genera una contraseña y la almacena.

Para aprender sobre otras opciones de almacenamiento secreto, consulta Configurar el almacenamiento secreto. Las implementaciones de varios clústeres no admiten almacenar secretos en HashiCorp Vault.

Implementaciones fuera de línea

El operador de Kubernetes requiere que se especifique la versión de MongoDB Enterprise para la base de datos de la aplicación para habilitar cualquier implementación de los recursos de Ops Manager, incluidas las implementaciones sin conexión.

Configuración optimizada

Después de implementar Ops Manager, es necesario configurarlo. El procedimiento regular implica configurar Ops Manager a través del asistente de configuración. Si configuras algunos ajustes esenciales en la especificación de tu objeto antes de implementarla, puedes omitir el asistente de configuración.

En el bloque spec.configuration de la especificación del objeto Ops Manager, se debe:

Ejemplo

Para deshabilitar el asistente de configuración de Ops Manager, configura los siguientes ajustes en tu bloque spec.configuration:

1spec:
2  configuration:
3    mms.ignoreInitialUiSetup: "true"
4    automation.versions.source: "remote"
5    mms.adminEmailAddr: cloud-manager-support@mongodb.com
6    mms.fromEmailAddr: cloud-manager-support@mongodb.com
7    mms.mail.hostname: email-smtp.us-east-1.amazonaws.com
8    mms.mail.port: "465"
9    mms.mail.ssl: "true"
10    mms.mail.transport: smtp
11    mms.minimumTLSVersion: TLSv1.2
12    mms.replyToEmailAddr: cloud-manager-support@mongodb.com

Reemplaza los valores de ejemplo con los valores que quieres que tu Ops Manager use.

Backup

El operador de Kubernetes habilita la copia de seguridad por defecto. El Kubernetes Operador implementa un StatefulSet formado por un pod para alojar el Servicio de daemon de copias de seguridad y luego crea una Reclamación de volumen persistente y un Volumen persistente para la base de datos principal del daemon de copias de seguridad. El operador de Kubernetes utiliza la API de Ops Manager para habilitar el daemon de copias de seguridad y configurar la base de datos principal.

Importante

Para configurar Backup, debe crear los recursos de MongoDB o los recursos de MongoDBMultiCluster para el almacén de oplog y para uno de los siguientes:

El recurso de Ops Manager permanece en un estado Pending hasta que se configuren estos recursos de copias de seguridad.

También puedes cifrar las tareas de copia de seguridad, pero se aplican limitaciones a las implementaciones en las que la misma instancia del operador de Kubernetes no administra tanto los recursos personalizados MongoDBOpsManager como MongoDB.

Almacenamiento Oplog

Debes desplegar un juego de réplicas de tres miembros para almacenar tus fragmentos del oplog.

La base de datos Oplog solo admite el mecanismo de autenticación SCRAM. No puedes habilitar otros mecanismos de autenticación.

Si activa la autenticación SCRAM en la base de datos oplog, debe:

  • Cree un recurso de usuario de MongoDB para conectar Ops Manager a la base de datos oplog.

  • Especifica el name del usuario en la definición del recurso de Ops Manager.

Tienda de Oplog S3

Para configurar un almacén de Oplog S3, debes crear una cubeta AWS S3 o una cubeta S3-compatible para almacenar la copia de seguridad de tu base de datos Oplog.

Puede configurar el almacén oplog tanto para el recurso MongoDB como para el recurso MongoDBMultiCluster, utilizando la configuración en la definición del recurso de Ops spec.backup.s3OpLogStores.mongodbResourceRef.name Manager.

Blockstore

Para configurar un almacenamiento en bloques, debe implementar un set de réplicas para almacenar instantáneas.

almacén de snapshots de S3

Para configurar un S3 almacenamiento de snapshot, debes crear un AWS S3 o S3-compatible bucket para almacenar tu base de datos copia de seguridad snapshots.

La configuración predeterminada almacena los metadatos de las instantáneas en la Base de Datos de la Aplicación. También puedes implementar un set de réplicas para almacenar los metadatos de los snapshots y luego configurarlo usando la spec.backup.s3Stores.mongodbResourceRef.name en la definición del recurso de Ops Manager.

Puedes configurar el almacenamiento de snapshot S3 tanto para el recurso MongoDB como para el recurso MongoDBMultiCluster.

Puedes actualizar cualquier configuración adicional S3 configuración que el Operador de Kubernetes no gestione a través de la aplicación Ops Manager.

Desactivar copia de seguridad

Para desactivar la copia de seguridad después de haberla habilitado:

  1. Establece la configuración de Ops Manager Kubernetes objeto spec.backup.enabled a false.

  2. Desactivar copias de seguridad en la aplicación Ops Manager.

  3. Elimina el Servicio Daemon de Copia de seguridad StatefulSet:

    kubectl delete statefulset <metadata.name> -backup-daemon \
     -n <metadata.namespace>

Importante

El Reclamo de Volumen Persistente y el Volumen Persistente para la base de datos principal del daemon de copias de seguridad no se eliminan cuando eliminas el Servicio de daemon de copias de seguridad StatefulSet. Puedes recuperar los datos almacenados antes de borrar estos recursos de Kubernetes.

Para aprender sobre la recuperación de Volúmenes Persistentes, ve la documentación de Kubernetes.

Configurar manualmente el cifrado de copia de seguridad KMIP

En las implementaciones donde la misma instancia de Kubernetes Operator no gestiona tanto el MongoDBOpsManager como los recursos personalizados de MongoDB, debe configurar manualmente la configuración del cliente de cifrado de copia de seguridad KMIP en Ops Manager utilizando el siguiente procedimiento. Si el operador de Kubernetes está gestionando ambos recursos, consulta Configura la encriptación de copia de seguridad KMIP para Ops Manager en su lugar.

Requisitos previos
Procedimiento

  1. Monta el secreto de TLS en el recurso personalizado MongoDBOpsManager. Por ejemplo:

    apiVersion: mongodb.com/v1
    kind: MongoDBOpsManager
    metadata:
      name: ops-manager-pod-spec
    spec:
      < ... omitted ... >
      statefulSet:
        spec:
          template:
            spec:
              volumes:
              - name: kmip-client-test-prefix-mdb-latest-kmip-client
                secretName: test-prefix-mdb-latest-kmip-client
              containers:
                - name: mongodb-ops-manager
                  volumeMounts:
                  - mountPath: /mongodb-ops-manager/kmip/client/test-prefix-mdb-latest-kmip-client
                    name: kmip-client-test-prefix-mdb-latest-kmip-client
                    readOnly: true
      ...

  2. Configure los ajustes KMIP de tu proyecto en Ops Manager siguiendo el procedimiento que se indica en Configura tu proyecto para usar KMIP.

Configura Ops Manager para ejecutarse mediante HTTPS

Puedes configurar tu instancia de Ops Manager creada a través del Kubernetes Operador para que funcione a través de HTTPS en lugar de HTTP.

Para configurar tu instancia de Ops Manager para ejecutar sobre HTTPS:

  1. Cree un secreto que contenga el certificado TLS y la clave privada.

  2. Agregue este secreto al objeto de configuración de Ops Manager.

Para obtener instrucciones detalladas, consulta Implementar un recurso de Ops Manager.

Importante

Si tienes implementaciones existentes, debes reiniciarlas manualmente después de habilitar HTTPS. Para evitar reiniciar tus implementaciones, configura HTTPS antes de implementar tus recursos gestionados.

Para obtener más información, consulta HTTPS habilitado después de la implementación.

Acceso a la aplicación Ops Manager

Por defecto, el operador de Kubernetes no crea un servicio de Kubernetes para enrutar el tráfico que se origina fuera del clúster de Kubernetes hacia la aplicación de Ops Manager.

Para acceder a la aplicación de Ops Manager, puede:

  • Configure el operador de Kubernetes para crear un servicio de Kubernetes.

  • Cree un servicio de Kubernetes manualmente. MongoDB recomienda utilizar un servicio de Kubernetes LoadBalancer si tu proveedor de nube lo admite.

  • Si está utilizando OpenShift, utilice las rutas.

  • Utilice un servicio de terceros, como Istio.

El método más sencillo es configurar el operador de Kubernetes para crear un servicio de Kubernetes que enrute el tráfico externo hacia la aplicación Ops Manager. El procedimiento de implementación de Ops Manager te indica que añadas los siguientes ajustes a la especificación objeto que configura el Operador de Kubernetes para crear un servicio:

Además, para implementaciones en varios clústeres de Kubernetes, consulte Arquitectura multiclúster.

Implementando Ops Manager en modo remoto o local

Puedes usar el Operador de Kubernetes para configurar un solo clúster de Ops Manager para que funcione en modo Local o Remoto si tu entorno impide que los hosts de tu clúster de Kubernetes tengan acceso a Internet. En estos modos, los demonios de copia de seguridad y los recursos gestionados de MongoDB descargan ficheros de instalación desde Ops Manager en lugar de hacerlo desde Internet:

Administrar implementaciones externas de MongoDB

Cuando implementes Ops Manager con el Kubernetes Operator, Ops Manager podrá administrar los recursos de bases de datos MongoDB desplegados:

  • Al mismo clúster de Kubernetes que Ops Manager.

  • Fuera de los clústeres de Kubernetes.

Si Ops Manager gestiona recursos de base de datos de MongoDB implementados en diferentes clústeres de Kubernetes que Ops Manager o fuera de los clústeres de Kubernetes, debe:

  1. Agregue la configuración mms.centralUrl a spec.configuration en la especificación de recursos del Ops Manager.

    Establece el valor en el URL mediante el cual Ops Manager está expuesto fuera del clúster de Kubernetes:

    spec:
      configuration:
        mms.centralUrl: https://a9a8f8566e0094380b5c257746627b82-1037623671.us-east-1.elb.example.com:8080/

  2. Actualice los ConfigMaps referenciados por todos los recursos de base de datos MongoDB dentro del clúster de Kubernetes que implementó con el Kubernetes Operator.

    Establece data.baseUrl al mismo valor de la configuración spec.configuration.mms.centralUrl en la especificación del recurso de Ops Manager.

    Importante

    Esto incluye los ConfigMaps referenciados por los recursos de la base de datos MongoDB para el Oplog y los almacenamientos de snapshot.

Implementación de Ops Manager en Multiclústeres

Consulte Arquitectura multiclúster.

Almacenamiento seguro

Para evitar almacenar secretos en Kubernetes, migra todos los secretos de Kubernetes que crea el Kubernetes Operator a una herramienta de almacenamiento de secretos. Las implementaciones de múltiples clústeres no admiten el almacenamiento de secretos en herramientas de almacenamiento de secretos como HashiCorp Vault.

Requisitos previos

  1. Si aún no lo has hecho, ejecuta el siguiente comando para ejecutar todos los comandos kubectl en el espacio de nombres que creaste:

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

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

  2. Instala los controladores de MongoDB para el operador de Kubernetes.

  3. Asegúrate de que el host en el que deseas implementar Ops Manager tenga un mínimo de cinco gigabytes de memoria.

  1. Cree un secreto de Kubernetes para un usuario administrador en el mismo namespace que el recurso Ops Manager. Si estás implementando Ops Manager en una implementación de MongoDB en un clúster multi-Kubernetes, utiliza el mismo namespace que configuraste para el alcance.de tu implementación de MongoDB en clúster multi-Kubernetes

    Si utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.

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

    Cuando implementas el recurso Ops Manager, Ops Manager crea un usuario con estas credenciales y le otorga el rol de Global Owner. Utilice estas credenciales para iniciar sesión en Ops Manager por primera vez. Una vez que implemente Ops Manager, cambie la contraseña o remueva este secreto.

    Nota

    La contraseña del usuario administrador debe cumplir con los requisitos de complejidad de contraseñas de Ops Manager.

    kubectl create secret generic <adminusercredentials> \
      --from-literal=Username="<username>" \
      --from-literal=Password="<password>" \
      --from-literal=FirstName="<firstname>" \
      --from-literal=LastName="<lastname>"

  1. (Opcional) Para establecer la contraseña para el usuario de base de datos de Ops Manager, crea un secreto en el mismo namespace que el recurso Ops Manager.

    Si utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.

    El operador de Kubernetes crea el usuario de base de datos que Ops Manager utiliza para conectarse a la Base de Datos de la Aplicación Ops Manager. Puedes establecer la contraseña para este usuario de base de datos invocando el siguiente comando para crear un secreto:

    kubectl create secret generic <om-db-user-secret-name> \
      --from-literal=password="<om-db-user-password>"

    Nota

    Si decides crear un secreto para el usuario de base de datos Ops Manager, debes especificar el name del secreto en la definición de recursos de Ops Manager. Por defecto, el operador de Kubernetes busca el valor de la contraseña en la clave password. Si almacenaste el valor de la contraseña en una clave diferente, también debes especificar ese nombre key en la definición del recurso de Ops Manager.

    Si no creas un secreto, el Operador de Kubernetes genera automáticamente una contraseña y la almacena internamente. Para obtener más información, consulte Autenticación.

  2. (opcional). Para configurar copia de seguridad en un S3 almacenamiento de snapshot, crea un secreto en el mismo namespace que el recurso Ops Manager.

    Si utilizas HashiCorp Vault como tu herramienta de almacenamiento secreto, puedes crear un secreto de Vault en su lugar.

    Este secreto almacena tus credenciales de S3 para que el Kubernetes operador pueda conectar Ops Manager a tu AWS S3 o a un bucket S3compatible. El secreto debe contener los siguientes pares de clave-valor:

    Clave

    Valor

    accessKey

    Identificador único del usuario de AWS que posee el bucket de S3 o S3compatible.

    secretKey

    Clave secreta del usuario AWS que posee el S3 o el bucket compatible con S3.

    Para crear el secreto, ejecuta el siguiente comando:

    kubectl create secret generic <my-aws-s3-credentials> \
      --from-literal=accessKey="<AKIAIOSFODNN7EXAMPLE>" \
      --from-literal=secretKey="<wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY>"

    Para obtener más información sobre la gestión del almacenamiento de instantáneas de S3, consulte los prerrequisitos.

En esta página