Configure el Recurso Personalizado de Ops Manager

Credenciales de administrador y configuración inicial

Antes de que la aplicación MongoDB Ops Manager pueda iniciarse, necesita una cuenta de administrador inicial. Usted proporciona estas credenciales a través de un secreto de Kubernetes al que hace referencia spec.adminCredentials. El secreto debe contener cuatro claves: Username (una dirección de correo electrónico), Password, FirstName y LastName. El operador de Kubernetes utiliza esta información para arrancar la primera cuenta de propietario global cuando el pod de MongoDB Ops Manager se inicializa por primera vez:

kubectl create secret generic ops-manager-admin-secret \
  --from-literal=Username="admin@example.com" \
  --from-literal=Password="<secure-password>" \
  --from-literal=FirstName="Admin" \
  --from-literal=LastName="User"

Una vez que MongoDB Ops Manager esté en ejecución, puede crear usuarios y claves de API adicionales a través de la interfaz de usuario o la API de MongoDB Ops Manager. El secreto de administrador inicial solo se utiliza durante la configuración por primera vez, pero el operador de Kubernetes lo utiliza para la conciliación, por lo que debe permanecer en el clúster.

El campo spec.version determina qué versión de MongoDB Ops Manager implementa el operador de Kubernetes. Fije esto a una versión X.Y.Z específica en lugar de dejarla flotar. Cuando esté listo para actualizar, actualice este campo y deje que el operador de Kubernetes realice una actualización continua, como se muestra en el siguiente ejemplo:

apiVersion: mongodb.com/v1
kind: MongoDBOpsManager
metadata:
  name: ops-manager
spec:
  replicas: 1
  version: "8.0.0"
  adminCredentials: ops-manager-admin-secret

Para obtener más información sobre cada campo obligatorio, consulte la configuración obligatoria en la referencia de especificación.

Dimensionamiento y topología para el recurso de Ops Manager

El campo spec.replicas controla cuántas instancias de aplicación de MongoDB Ops Manager se ejecutan en paralelo detrás de un servicio compartido. Una sola réplica es suficiente para el desarrollo y la evaluación, pero los entornos de producción deben ejecutar al menos dos réplicas detrás de un balanceador de carga para sobrevivir a los reinicios de Pod y a los fallos de nodo sin tiempo de inactividad. No hay ninguna diferencia funcional entre las réplicas; todos son servidores de aplicaciones sin estado respaldados por la misma base de datos de la aplicación.

Para las organizaciones que necesitan redundancia geográfica o alta disponibilidad entre regiones, el operador de Kubernetes admite una topología MultiCluster para el propio MongoDB Ops Manager. En este modo, configure spec.topology: MultiCluster y defina un clusterSpecList que distribuya las instancias de MongoDB Ops Manager entre los clústeres de Kubernetes con nombre, como se muestra en el siguiente ejemplo:

spec:
  topology: MultiCluster
  clusterSpecList:
    - clusterName: "cluster-us-east"
      members: 1
    - clusterName: "cluster-eu-west"
      members: 1

Cuando utilizas la topología MultiCluster, el campo spec.replicas se ignora; los recuentos de nodos se extraen del clusterSpecList en su lugar. Las implementaciones de MongoDB Ops Manager de clúster múltiple introducen requisitos de red entre clústeres, así que revisa implementar recursos de MongoDB Ops Manager en varios clústeres de Kubernetes antes de adoptar este modelo.

Propiedades de configuración de la aplicación

MongoDB Ops Manager tiene un amplio conjunto de propiedades de configuración del lado del servidor, que van desde la configuración del correo electrónico hasta las marcas de funcionalidad y las fuentes de descarga binarias. En lugar de traducir cada una de ellas a un campo CRD de primera clase, el operador de Kubernetes proporciona el bloque spec.configuration como un paso a través: se establecen pares clave-valor que se asignan directamente a las propiedades del sistema MongoDB Ops Manager.

Las propiedades más comunes que se deben establecer en el momento de la implementación son la configuración del correo electrónico, para que Ops Manager pueda enviar alertas e invitaciones, y los valores predeterminados de seguridad, como se muestra en el siguiente ejemplo:

spec:
  configuration:
    mms.fromEmailAddr: "ops-manager@example.com"
    mms.replyToEmailAddr: "ops-manager@example.com"
    mms.adminEmailAddr: "admin@example.com"
    mms.mail.hostname: "smtp.example.com"
    mms.mail.port: "587"
    mms.mail.ssl: "true"
    mms.mail.transport: "smtp"
    mms.ignoreInitialUiSetup: "true"

Establecer mms.ignoreInitialUiSetup en "true" omite el asistente de configuración interactivo en el primer lanzamiento, lo cual es esencial para implementaciones totalmente automatizadas.

Otras propiedades útiles incluyen las siguientes:

• mms.security.allowCORS — controla si la interfaz de usuario acepta solicitudes de origen cruzado.

• automation.versions.source — establecido en "remote" (por defecto), "local" o "hybrid" para controlar cómo se descargan los binarios de MongoDB. Consulte Modo local y remoto a continuación.

• mms.featureFlag.automation.verifyDownloads — cuando se establece en "enabled", el agente requiere firmas criptográficas para todos los binarios de MongoDB.

Para ver el catálogo completo de propiedades, consulta Configuraciones de MongoDB Ops Manager y spec.configuration en la referencia de la especificación.

Protección de conexiones con TLS

Se recomienda encarecidamente ejecutar MongoDB Ops Manager a través de HTTPS para cualquier entorno más allá del desarrollo local. Sin él, las credenciales de administrador, las claves de API y los datos de supervisión atraviesan la red en texto sin formato.

La habilitación de HTTPS requiere lo siguiente:

• Un certificado TLS para la propia aplicación MongoDB Ops Manager.

• Un certificado TLS para la base de datos de la aplicación.

Cada certificado se almacena en un secreto cuyo nombre sigue el patrón <certsSecretPrefix>-<metadata.name>-cert (para la aplicación) o <certsSecretPrefix>-<metadata.name>-db-cert (para la base de datos de la aplicación).

El certsSecretPrefix es cómo el Operador Kubernetes une estas convenciones de nomenclatura. Si establece spec.security.certsSecretPrefix en "om-prod" y su recurso se denomina ops-manager, el Operador Kubernetes espera secretos denominados om-prod-ops-manager-cert y (para la base de datos de la aplicación) appdb-prod-ops-manager-db-cert, como se muestra en el siguiente ejemplo:

# Create the Ops Manager TLS certificate secret
kubectl create secret tls om-prod-ops-manager-cert \
  --cert=om-tls.crt \
  --key=om-tls.key
# Create the Application Database TLS certificate secret
kubectl create secret tls appdb-prod-ops-manager-db-cert \
  --cert=appdb-tls.crt \
  --key=appdb-tls.key

Si tus certificados están firmados por una autoridad de certificación personalizada, también debes crear ConfigMaps que contengan los certificados de CA. El certificado de CA de Ops Manager debe denominarse mms-ca.crt dentro del ConfigMap. Además, este archivo de CA debe incluir la cadena de certificados para downloads.mongodb.com para que el daemon de copias de seguridad pueda descargar los binarios de MongoDB:

spec:
  security:
    certsSecretPrefix: "om-prod"
    tls:
      ca: "om-ca-configmap"
  applicationDatabase:
    security:
      certsSecretPrefix: "appdb-prod"
      tls:
        ca: "appdb-ca-configmap"

Para conocer los procedimientos de implementación de HTTPS paso a paso, incluidos los comandos openssl para ensamblar la cadena de CA, consulta Implementar un recurso de Ops Manager. Para la automatización de la renovación de certificados, consulta Configurar una integración de cert-manager.

Conectividad externa

De forma predeterminada, Ops Manager solo es accesible dentro de la red interna del clúster de Kubernetes. Para que los administradores y los agentes de supervisión que se ejecutan fuera del clúster puedan acceder a la interfaz de usuario y la API de Ops Manager, debe configurar la conectividad externa.

El bloque spec.externalConnectivity indica al operador de Kubernetes que cree un servicio de Kubernetes del tipo especificado. Recomendamos encarecidamente que utilice LoadBalancer cuando su proveedor de nube lo admita, ya que aprovisiona un punto final externo estable automáticamente. NodePort es una alternativa para clústeres on-premises o bare-metal, como se muestra en el siguiente ejemplo:

spec:
  externalConnectivity:
    type: LoadBalancer

Puede agregar anotaciones específicas de la nube para influir en el comportamiento del balanceador de carga. Por ejemplo, para usar un balanceador de carga de red de AWS en una subred interna:

spec:
  externalConnectivity:
    type: LoadBalancer
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
      service.beta.kubernetes.io/aws-load-balancer-internal: "true"

Si el punto de conexión externo tiene un nombre de dominio personalizado (por ejemplo, https://opsmanager.example.com), establezca spec.opsManagerURL para que el operador de Kubernetes y sus agentes utilicen la dirección correcta al comunicarse con MongoDB Ops Manager:

spec:
  opsManagerURL: "https://opsmanager.example.com:8443"
  externalConnectivity:
    type: LoadBalancer

Para obtener el conjunto completo de campos de conectividad externa, consulte spec.externalConnectivity en la referencia de especificación.

La base de datos de la aplicación

La base de datos de la aplicación es un set de réplicas de MongoDB que almacena todo el estado interno de MongoDB Ops Manager: configuraciones de proyectos, cuentas de usuario, definiciones de alertas y más. Está estrechamente acoplado a los servidores de aplicaciones de MongoDB Ops Manager y debe estar en buen estado para que MongoDB Ops Manager funcione. El operador gestiona la base de datos de la aplicación como parte del mismo recurso personalizado, lo que significa que un único manifiesto YAML controla tanto la aplicación como su base de datos de respaldo.

spec:
  applicationDatabase:
    members: 3
    version: "8.0.0-ubi8"

spec:
  applicationDatabase:
    version: "8.0.0-ubi8"
    featureCompatibilityVersion: "7.0"

spec:
  applicationDatabase:
    passwordSecretKeyRef:
      name: appdb-user-secret
      key: password

spec:
  applicationDatabase:
    members: 3
    version: "8.0.0-ubi8"
    podSpec:
      cpu: "2"
      memory: "4Gi"
      persistence:
        multiple:
          data:
            storage: "100Gi"
            storageClass: "fast-ssd"
          journal:
            storage: "30Gi"
            storageClass: "fast-ssd"
          logs:
            storage: "10Gi"
            storageClass: "standard"

spec:
  applicationDatabase:
    topology: MultiCluster
    version: "8.0.0-ubi8"
    clusterSpecList:
      - clusterName: "cluster-1"
        members: 2
      - clusterName: "cluster-2"
        members: 2
      - clusterName: "cluster-3"
        members: 1

Infraestructura de copia de seguridad

MongoDB Ops Manager proporciona copias de seguridad continuas para las implementaciones de MongoDB que gestiona. A diferencia de la bandera spec.backup.mode por implementación en un MongoDB CR, la configuración de copia de seguridad en el recurso de MongoDB Ops Manager define la infraestructura que almacena los datos de copia de seguridad: base de datos principal, almacenamiento de oplog y almacenamiento de snapshot. Sin esta infraestructura, la habilitación de copias de seguridad en recursos individuales de MongoDB fallará.

spec:
  backup:
    enabled: true

spec:
  backup:
    enabled: true
    headDB:
      storage: "50Gi"
      storageClass: "fast-ssd"

spec:
  backup:
    enabled: true
    opLogStores:
      - name: oplog1
        mongodbResourceRef:
          name: oplog-db
        mongodbUserRef:
          name: oplog-user
        assignmentLabels:
          - "production"

spec:
  backup:
    s3OpLogStores:
      - name: s3-oplog-store
        s3SecretRef:
          name: s3-credentials
        pathStyleAccessEnabled: true
        s3BucketEndpoint: "s3.us-east-1.amazonaws.com"
        s3BucketName: "oplog-bucket"

spec:
  backup:
    enabled: true
    s3Stores:
      - name: s3-snapshot-store
        mongodbResourceRef:
          name: s3-metadata-db
        mongodbUserRef:
          name: s3-store-user
        s3SecretRef:
          name: s3-credentials
        pathStyleAccessEnabled: true
        s3BucketEndpoint: "s3.us-east-1.amazonaws.com"
        s3BucketName: "snapshot-bucket"
        assignmentLabels:
          - "production"

spec:
  backup:
    blockStores:
      - name: blockstore1
        mongodbResourceRef:
          name: blockstore-db
        mongodbUserRef:
          name: blockstore-user

spec:
  backup:
    enabled: true
    encryption:
      kmip:
        server:
          url: "kmip.example.com:5696"
          ca: "kmip-ca-configmap"
        client:
          clientCertificatePrefix: "kmip-client"

Asignación de recursos y ajuste de JVM

MongoDB Ops Manager es una aplicación Java, y su consumo de recursos depende del número de implementaciones supervisadas, el volumen de datos de métricas y si la copia de seguridad está habilitada. El operador implementa MongoDB Ops Manager como un StatefulSet y usted controla sus especificaciones de pod a través de spec.statefulSet.

Como mínimo, establezca las solicitudes y los límites de CPU y memoria. MongoDB recomienda al menos 4 CPU y 8 GiB de memoria para implementaciones pequeñas, escalando para entornos más grandes:

spec:
  statefulSet:
    spec:
      template:
        spec:
          containers:
            - name: mongodb-ops-manager
              resources:
                requests:
                  cpu: "4"
                  memory: "8Gi"
                limits:
                  cpu: "8"
                  memory: "16Gi"

El operador calcula la configuración del montón de JVM en función de los límites de memoria del contenedor. Si necesita anular los parámetros de montón de Java o GC, utilice spec.jvmParameters, pero hágalo con precaución: los valores de montón incorrectos pueden desestabilizar MongoDB Ops Manager:

spec:
  jvmParameters:
    - "-Xmx12g"
    - "-Xms8g"
    - "-XX:+UseG1GC"

Para conocer los campos completos de la especificación de StatefulSet, consulte spec.statefulSet.spec en la referencia de la especificación.

Modo local y remoto

Por defecto, Ops Manager descarga los binarios de instalación de MongoDB de Internet (modo remoto). En entornos con aislamiento de red o con red restringida, puede configurar el modo local, donde los binarios se sirven desde un PersistentVolume montado en los pods de Ops Manager, o el modo remoto con un punto final personalizado.

Modo remoto (por defecto):

spec:
  configuration:
    automation.versions.source: "remote"

Modo local (para entornos con aislamiento de red):

spec:
  configuration:
    automation.versions.source: "local"
    automation.versions.directory: "/mongodb-ops-manager/mongodb-releases"

Para obtener procedimientos detallados, consulte Configurar un recurso de MongoDB Ops Manager para usar el modo local y Configurar un recurso de MongoDB Ops Manager para usar el modo remoto.

Iterar en la configuración de MongoDB Ops Manager

Un recurso personalizado de Ops Manager evoluciona junto con su organización. Los escenarios de iteración comunes incluyen la actualización de la versión de Ops Manager, el escalado de réplicas para alta disponibilidad, la adición de infraestructura de copia de seguridad para bases de datos recién implementadas y la rotación de certificados TLS.

Directrices para cambios seguros:

• Actualizar |onprem| en su lugar. Cambie spec.version y aplique. El operador realiza una actualización continua de los pods de la aplicación. Asegúrese de que la versión de la base de datos de la aplicación sea compatible con la nueva versión de Ops Manager antes de actualizar.

• Escalar réplicas de forma independiente. Puede aumentar spec.replicas sin tiempo de inactividad. Los nuevos pods se unen al servicio existente automáticamente.

• Añadir copias de seguridad de forma incremental. Defina nuevos oplog o almacenamientos de snapshot en el CR y aplique. Las asignaciones de copias de seguridad existentes no se ven afectadas.

• Rote los certificados de forma proactiva. Actualice los secretos de certificados TLS y, si es necesario, el ConfigMap de CA. El operador detecta el secreto cambiado y reinicia los pods afectados.

• Supervise el estado de los recursos. Después de cualquier cambio, ejecute kubectl get om e inspeccione el campo status para ver el progreso de la conciliación y cualquier condición de error.

Para conocer los procedimientos de actualización de versión, consulte Actualice las versiones de Ops Manager y de la base de datos de respaldo. Para obtener orientación sobre la recuperación ante desastres, consulte Recuperación ante desastres para recursos de Ops Manager y AppDB.

Todo junto: un ejemplo completo de recurso de MongoDB Ops Manager

El siguiente ejemplo combina los conceptos tratados en esta página en una implementación de Ops Manager lista para la producción. Incluye HTTPS, configuración de correo electrónico, una base de datos de la aplicación de tres nodos con almacenamiento de división, copia de seguridad con snapshot S3 y almacenes de oplog, cifrado KMIP y límites de recursos:

apiVersion: mongodb.com/v1
kind: MongoDBOpsManager
metadata:
  name: ops-manager-prod
  namespace: ops-manager
spec:
  replicas: 2
  version: "8.0.0"
  adminCredentials: ops-manager-admin-secret
  opsManagerURL: "https://opsmanager.example.com:8443"
  configuration:
    mms.fromEmailAddr: "ops-manager@example.com"
    mms.replyToEmailAddr: "ops-manager@example.com"
    mms.adminEmailAddr: "admin@example.com"
    mms.mail.hostname: "smtp.example.com"
    mms.mail.port: "587"
    mms.mail.ssl: "true"
    mms.mail.transport: "smtp"
    mms.ignoreInitialUiSetup: "true"
  security:
    certsSecretPrefix: "om-prod"
    tls:
      ca: "om-ca-configmap"
  externalConnectivity:
    type: LoadBalancer
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
  statefulSet:
    spec:
      template:
        spec:
          containers:
            - name: mongodb-ops-manager
              resources:
                requests:
                  cpu: "4"
                  memory: "8Gi"
                limits:
                  cpu: "8"
                  memory: "16Gi"
  jvmParameters:
    - "-Xmx12g"
    - "-Xms8g"
  applicationDatabase:
    members: 3
    version: "8.0.0-ubi8"
    featureCompatibilityVersion: "8.0"
    security:
      certsSecretPrefix: "appdb-prod"
      tls:
        ca: "appdb-ca-configmap"
    podSpec:
      cpu: "4"
      memory: "8Gi"
      persistence:
        multiple:
          data:
            storage: "200Gi"
            storageClass: "fast-ssd"
          journal:
            storage: "50Gi"
            storageClass: "fast-ssd"
          logs:
            storage: "20Gi"
            storageClass: "standard"
  backup:
    enabled: true
    encryption:
      kmip:
        server:
          url: "kmip.example.com:5696"
          ca: "kmip-ca-configmap"
        client:
          clientCertificatePrefix: "kmip-client"
    headDB:
      storage: "100Gi"
      storageClass: "fast-ssd"
    opLogStores:
      - name: oplog1
        mongodbResourceRef:
          name: oplog-db
        mongodbUserRef:
          name: oplog-user
        assignmentLabels:
          - "production"
    s3Stores:
      - name: s3-snapshots
        mongodbResourceRef:
          name: s3-metadata-db
        mongodbUserRef:
          name: s3-store-user
        s3SecretRef:
          name: s3-credentials
        pathStyleAccessEnabled: true
        s3BucketEndpoint: "s3.us-east-1.amazonaws.com"
        s3BucketName: "backup-snapshots-prod"
        assignmentLabels:
          - "production"