Configure el Recurso Personalizado de Ops Manager

Credenciales de administrador y configuración inicial

Antes de que la aplicación Ops Manager pueda iniciarse, necesita una cuenta de administrador inicial. Estas credenciales se proporcionan mediante un secreto de Kubernetes al que se hace referencia con 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 inicializar la primera cuenta de Propietario Global cuando el pod de 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 Ops Manager esté en funcionamiento, puede crear usuarios y claves API adicionales a través de la interfaz de usuario o la API de Ops Manager. El secreto de administrador inicial solo se usa durante la configuración inicial, 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 Ops Manager implementa el operador de Kubernetes. Asigne una versión específica X.Y.Z en lugar de dejarla sin especificar. Cuando esté listo para actualizar, actualice este campo y permita que el operador de Kubernetes realice una actualización progresiva, 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 información detallada sobre cada campo obligatorio, consulte la configuración requerida en la referencia de la especificación.

Dimensionamiento y topología para el recurso del administrador de operaciones

El campo spec.replicas controla cuántas instancias de la aplicación 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 en entornos de producción se recomienda ejecutar al menos dos réplicas detrás de un balanceador de carga para garantizar la continuidad del servicio tras reinicios de pods y fallos de nodos. No existe ninguna diferencia funcional entre las réplicas; todas son servidores de aplicaciones sin estado respaldados por la misma base de datos de aplicaciones.

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 Ops Manager. En este modo, configure spec.topology: MultiCluster y defina una clusterSpecList que distribuya las instancias de Ops Manager entre 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 se utiliza la MultiCluster topología, el spec.replicas campo se ignora; en su lugar, el recuento de miembros se obtiene del clusterSpecList campo. Las implementaciones de Ops Manager en varios clústeres introducen requisitos de red entre clústeres, por lo que conviene revisar la sección «Implementar recursos de Ops Manager en varios clústeres de Kubernetes» antes de adoptar este modelo.

Propiedades de configuración de la aplicación

Ops Manager cuenta con un amplio conjunto de propiedades de configuración del servidor, que abarcan desde la configuración de correo electrónico hasta las banderas de funciones y las fuentes de descarga de binarios. En lugar de traducir cada una de estas propiedades a un campo CRD de primera clase, el operador de Kubernetes proporciona el bloque spec.configuration como intermediario: se establecen pares clave-valor que se asignan directamente a las propiedades del sistema de Ops Manager.

Las propiedades más comunes que se deben configurar 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"

Si se establece mms.ignoreInitialUiSetup en "true", se omite el asistente de configuración interactiva en el primer inicio, 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 — Establezca "remote" el valor en (predeterminado), "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, consulte Configuración de Ops Manager y spec.configuration en la referencia de la especificación.

Protección de conexiones con TLS

Se recomienda encarecidamente ejecutar Ops Manager a través de HTTPS en cualquier entorno que no sea el de desarrollo local. De lo contrario, las credenciales de administrador, las claves API y los datos de monitorización se transmiten por la red en texto plano.

Para habilitar HTTPS se requiere lo siguiente:

• Un certificado TLS para la propia aplicación 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 la forma en que el operador de Kubernetes vincula estas convenciones de nomenclatura. Si establece spec.security.certsSecretPrefix en "om-prod" y su recurso se llama ops-manager, el operador de Kubernetes espera secretos llamados 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 sus certificados están firmados por una Autoridad de Certificación personalizada, también debe crear ConfigMaps que contengan los certificados de CA. El certificado de CA de Ops Manager debe llamarse 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 demonio de copia 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 obtener instrucciones paso a paso sobre la implementación de HTTPS, incluidos los openssl comandos para ensamblar la cadena de CA, consulte Implementar un recurso de Ops Manager. Para la automatización de la renovación de certificados, consulte 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 monitorización que se ejecutan fuera del clúster puedan acceder a la interfaz de usuario y la API de Ops Manager, es necesario configurar la conectividad externa.

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

spec:
  externalConnectivity:
    type: LoadBalancer

Puedes 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 final externo tiene un nombre de dominio personalizado (por ejemplo, https://opsmanager.example.com), configure spec.opsManagerURL para que el operador de Kubernetes y sus agentes utilicen la dirección correcta al comunicarse con Ops Manager:

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

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

La base de datos de la aplicación

La base de datos de la aplicación es un conjunto de réplicas de MongoDB que almacena todo el estado interno de Ops Manager: configuraciones de proyectos, cuentas de usuario, definiciones de alertas y más. Está estrechamente vinculada a los servidores de la aplicación Ops Manager y debe estar en buen estado para que Ops Manager funcione correctamente. 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 subyacente.

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 respaldo

Ops Manager proporciona copias de seguridad continuas para las implementaciones de MongoDB que administra. A diferencia del spec.backup.mode indicador por implementación en un recurso personalizado de MongoDB, la configuración de copias de seguridad en el recurso Ops Manager define la infraestructura que almacena los datos de copia de seguridad: bases de datos de cabecera, almacenes de oplog y almacenes de instantáneas. 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 optimización de la JVM

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

Como mínimo, configure 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, aumentando la escala 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 la JVM en función de los límites de memoria del contenedor. Si necesita anular los parámetros del montón de Java o del recolector de basura, utilice spec.jvmParameters, pero hágalo con precaución: los valores incorrectos del montón pueden desestabilizar Ops Manager.

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

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

Modo local y remoto

De forma predeterminada, Ops Manager descarga los binarios de instalación de MongoDB desde internet (modo remoto). En entornos aislados o con redes restringidas, 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 (predeterminado):

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

Modo local (para entornos aislados de la red):

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

Para obtener información detallada sobre los procedimientos,consulte Configurar un recurso de Ops Manager para usar el modo local y Configurar un recurso de Ops Manager para usar el modo remoto.

Iterar sobre la configuración de su administrador de operaciones

Un recurso personalizado de Ops Manager evoluciona junto con su organización. Los escenarios de iteración más 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 respaldo para bases de datos recién implementadas y la rotación de certificados TLS.

Pautas para realizar cambios de forma segura:

• Actualizar |onprem| in situ. Modificar spec.version y aplicar. El operador realiza una actualización progresiva 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.

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

• Agregue almacenes de respaldo de forma incremental. Defina nuevos almacenes de oplog o instantáneas en el CR y aplique los cambios. Las asignaciones de respaldo existentes no se verán afectadas.

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

• Supervise el estado del recurso. Después de cualquier cambio,kubectl get om ejecute e inspeccione el status campo 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 Actualizar las versiones de Ops Manager y la base de datos subyacente. Para obtener orientación sobre la recuperación ante desastres, consulte Recuperación ante desastres para Ops Manager y los recursos de AppDB.

Integrándolo todo: un ejemplo completo de recursos para el administrador de operaciones

El siguiente ejemplo combina los conceptos tratados en esta página en una implementación de Ops Manager lista para producción. Incluye HTTPS, configuración de correo electrónico, una base de datos de aplicaciones de tres miembros con almacenamiento dividido, copia de seguridad con instantáneas S3 y almacenamiento 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"