Configurar o recurso personalizado do Ops Manager

Credenciais de administrador e configuração inicial

Antes que o aplicativo MongoDB Ops Manager possa ser iniciado, ele precisa de uma conta de administrador inicial. Você fornece essas credenciais por meio de um secret do Kubernetes referenciado por spec.adminCredentials. O secret deve conter quatro chaves: Username (um endereço de e-mail), Password, FirstName e LastName. O operador do Kubernetes usa essas informações para inicializar a primeira conta de Proprietário Global quando o pod do MongoDB Ops Manager é inicializado pela primeira 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"

Depois que o MongoDB Ops Manager estiver em execução, você poderá criar usuários e chaves de API adicionais por meio da IU ou da API do MongoDB Ops Manager. O segredo de administrador inicial é usado apenas durante a configuração pela primeira vez, mas o operador do Kubernetes o referencia para reconciliação, portanto, ele deve permanecer no cluster.

O campo spec.version determina qual versão do Ops Manager o operador Kubernetes implanta. Fixe-o em uma versão X.Y.Z específica em vez de deixá-lo flutuar. Quando estiver pronto para atualizar, atualize este campo e deixe o operador Kubernetes executar uma atualização contínua, conforme mostrado no exemplo a seguir:

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

Para obter detalhes sobre cada campo obrigatório, consulte as configurações necessárias na referência de especificação.

Dimensionamento e topologia para o recurso do MongoDB Ops Manager

O campo spec.replicas controla quantas instâncias de aplicativo do MongoDB Ops Manager são executadas em paralelo atrás de um serviço compartilhado. Uma única réplica é suficiente para desenvolvimento e avaliação, mas os ambientes de produção devem executar pelo menos duas réplicas atrás de um balanceador de carga para sobreviver a reinícios de Pod e falhas de nó sem tempo de inatividade. Não há diferença funcional entre as réplicas; todos são servidores de aplicativos sem estado apoiados pelo mesmo banco de dados de aplicativos.

Para organizações que precisam de redundância geográfica ou alta disponibilidade entre regiões, o operador Kubernetes oferece suporte a uma topologia MultiCluster para o próprio MongoDB Ops Manager. Nesse modo, defina spec.topology: MultiCluster e defina um clusterSpecList que distribua instâncias do MongoDB Ops Manager entre clusters Kubernetes nomeados, conforme mostrado no exemplo a seguir:

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

Ao usar a topologia MultiCluster, o campo spec.replicas é ignorado; as contagens de nós são extraídas do clusterSpecList em vez disso. As implantações do MongoDB Ops Manager de vários clusters introduzem requisitos de rede entre clusters, portanto, revise Implantar recursos do MongoDB Ops Manager em vários clusters Kubernetes antes de adotar este modelo.

Propriedades de configuração do aplicativo

O Ops Manager tem um extenso conjunto de propriedades de configuração do lado do servidor, que vão desde configurações de e-mail até sinalizadores de recursos e fontes de download binário. Em vez de traduzir cada um deles para um campo CRD de primeira classe, o Kubernetes Operator fornece o bloco spec.configuration como um pass-through: você define pares de chave-valor que são mapeados diretamente para as propriedades do sistema do Ops Manager.

As propriedades mais comuns a serem definidas no momento da implantação são a configuração de e-mail, para que o MongoDB Ops Manager possa enviar alertas e convites, e os padrões de segurança, conforme mostrado no exemplo a seguir:

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"

Definir mms.ignoreInitialUiSetup como "true" ignora o assistente de configuração interativo no primeiro lançamento, o que é essencial para implantação totalmente automatizada.

Outras propriedades úteis incluem o seguinte:

• mms.security.allowCORS — controla se a IU aceita solicitações de origem cruzada.

• automation.versions.source — definido como "remote" (padrão), "local" ou "hybrid" para controlar como os binários do MongoDB são baixados. Consulte Modo local e remoto abaixo.

• mms.featureFlag.automation.verifyDownloads — quando definido como "enabled", o agente exige assinaturas criptográficas para todos os binários MongoDB.

Para o catálogo completo de propriedades, consulte Configurações do MongoDB Ops Manager e spec.configuration na referência de especificação.

Protegendo conexões com TLS

A execução do MongoDB Ops Manager sobre HTTPS é altamente recomendada para qualquer ambiente além do desenvolvimento local. Sem ele, as credenciais de administrador, as chaves de API e os dados de monitoramento atravessam a rede em texto simples.

A habilitação do HTTPS requer o seguinte:

• Um certificado TLS para o próprio aplicativo MongoDB Ops Manager.

• Um certificado TLS para o banco de dados de aplicativo.

Cada certificado é armazenado em um segredo cujo nome segue o padrão <certsSecretPrefix>-<metadata.name>-cert (para o aplicativo) ou <certsSecretPrefix>-<metadata.name>-db-cert (para o banco de dados do aplicativo).

O certsSecretPrefix é como o Operador Kubernetes une essas convenções de nomenclatura. Se você definir spec.security.certsSecretPrefix como "om-prod" e seu recurso for nomeado ops-manager, o Operador Kubernetes espera segredos nomeados om-prod-ops-manager-cert e (para o banco de dados de aplicativo) appdb-prod-ops-manager-db-cert, conforme mostrado no exemplo a seguir:

# 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

Se seus certificados forem assinados por uma autoridade de certificação personalizada, você também deverá criar ConfigMaps contendo os certificados CA. O certificado CA do MongoDB Ops Manager deve ser nomeado mms-ca.crt dentro do ConfigMap. Além disso, este arquivo CA deve incluir a cadeia de certificados para downloads.mongodb.com para que o Backup Daemon possa baixar binários do MongoDB:

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

Para procedimentos de implantação HTTPS passo a passo, incluindo os comandos openssl para montar a cadeia de CA, consulte Implantar um recurso do MongoDB Ops Manager. Para automação de renovação de certificados, consulte Configurar uma integração do cert-gerente.

Conectividade externa

Pronto para uso, o Ops Manager é acessível apenas na rede interna do cluster Kubernetes. Para que os administradores e agentes de monitoramento que executam fora do cluster alcancem a IU e a API do Ops Manager, você precisa configurar a conectividade externa.

O bloco spec.externalConnectivity instrui o operador Kubernetes a criar um serviço Kubernetes do tipo especificado. Recomendamos fortemente que você use LoadBalancer quando seu provedor de nuvem o suportar, pois ele provisiona um ponto de extremidade externo estável automaticamente. NodePort é um fallback para clusters no local ou bare-metal, como mostrado no exemplo a seguir:

spec:
  externalConnectivity:
    type: LoadBalancer

Você pode adicionar anotações específicas da nuvem para influenciar o comportamento do balanceador de carga. Por exemplo, para usar um balanceador de carga de rede da Amazon Web Services em uma sub-rede interna:

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

Se o ponto de extremidade externo tiver um nome de domínio personalizado (por exemplo, https://opsmanager.example.com), defina spec.opsManagerURL para que o operador Kubernetes e seus agentes usem o endereço correto ao se comunicar com o MongoDB Ops Manager:

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

Para o conjunto completo de campos de conectividade externa, consulte spec.externalConnectivity na referência de especificação.

Banco de dados de aplicativos

O banco de dados de aplicativo é um conjunto de réplicas MongoDB que armazena todo o estado interno do MongoDB Ops Manager: configurações de projeto, contas de usuário, definições de alerta e muito mais. Ele está fortemente acoplado aos servidores de aplicativos do MongoDB Ops Manager e deve estar íntegro para que o MongoDB Ops Manager funcione. O operador gerencia o banco de dados de aplicativo como parte do mesmo recurso personalizado, o que significa que um único manifesto YAML controla o aplicativo e seus bancos de dados de apoio.

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

Infraestrutura de backup

O Ops Manager fornece backup contínuo para as implantações do MongoDB que ele gerencia. Ao contrário do sinalizador spec.backup.mode por implantação em um CR do MongoDB, as configurações de backup no recurso do Ops Manager definem a infraestrutura que armazena os dados de backup: bancos de dados principais, armazenamentos de oplog e armazenamentos de snapshots. Sem essa infraestrutura em vigor, a habilitação de backup em recursos individuais do MongoDB falhará.

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"

Alocação de recursos e ajuste de JVM

O MongoDB Ops Manager é um aplicativo Java e seu consumo de recurso depende do número de implantações monitoradas, do volume de dados de métricas e se o backup está habilitado. O operador implanta o MongoDB Ops Manager como um StatefulSet, e você controla suas especificações de pod por meio de spec.statefulSet.

No mínimo, defina as solicitações e os limites de CPU e memória. O MongoDB recomenda pelo menos 4 CPU e 8 GiB de memória para pequenas implantações, dimensionando para ambientes maiores:

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

O operador calcula as configurações de heap da JVM com base nos limites de memória do contêiner. Se você precisar substituir os parâmetros de heap ou GC do Java, use spec.jvmParameters, mas faça-o com cuidado: valores de heap incorretos podem desestabilizar o MongoDB Ops Manager:

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

Para os campos de especificação completos do StatefulSet, consulte spec.statefulSet.spec na referência de especificação.

Modo local e remoto

Por padrão, o MongoDB Ops Manager transfere os binários de instalação do MongoDB da internet (modo remoto). Em ambientes com rede restrita ou sem acesso à internet, você pode configurar o modo local, onde os binários são servidos a partir de um PersistentVolume montado nos pods do MongoDB Ops Manager, ou o modo remoto com um ponto de extremidade personalizado.

Modo remoto (padrão):

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

Modo local (para ambientes com isolamento de rede):

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

Para procedimentos detalhados, consulte Configurar um recurso do MongoDB Ops Manager para usar o modo local e Configurar um recurso do MongoDB Ops Manager para usar o modo remoto.

Iterando em sua configuração do MongoDB Ops Manager

Um recurso personalizado do MongoDB Ops Manager evolui junto com sua organização. Os cenários comuns de iteração incluem a atualização da versão do MongoDB Ops Manager, o dimensionamento de réplicas para alta disponibilidade, a adição de infraestrutura de backup para bancos de dados recém-implantados e a rotação de certificados TLS.

Diretrizes para alterações seguras:

• Atualize |onprem| no local. Altere spec.version e aplique. O operador executa uma atualização contínua dos pods do aplicativo. Verifique se a versão do banco de dados do aplicativo é compatível com a nova versão do MongoDB Ops Manager antes de atualizar.

• Dimensionar réplicas independentemente. Você pode aumentar spec.replicas sem tempo de inatividade. Os novos pods ingressam no serviço existente automaticamente.

• Adicione armazenamentos de backup incrementalmente. Defina novos oplog ou armazenamento de snapshots no CR e aplicar. As atribuições de backup existentes não são afetadas.

• Gire os certificados proativamente. Atualize os segredos do certificado TLS e, se necessário, o CA ConfigMap. O operador detecta o segredo alterado e reinicia os pods afetados.

• Observe o status do recurso. Após qualquer alteração, execute kubectl get om e inspecione o campo status para verificar o progresso da reconciliação e quaisquer condições de erro.

Para procedimentos de atualização de versão, consulte Atualizar o MongoDB Ops Manager e as versões de bancos de dados de apoio. Para orientações sobre recuperação de desastre, consulte Recuperação de desastre para o MongoDB Ops Manager e recursos do AppDB.

Juntando tudo: um exemplo completo de recurso do MongoDB Ops Manager

O exemplo a seguir combina os conceitos abordados nesta página em uma implantação do MongoDB Ops Manager pronta para produção. Ele inclui HTTPS, configuração de e-mail, um banco de dados de aplicativo de três nós com armazenamento dividido, backup com snapshot S3 e armazenamentos de oplog, criptografia KMIP e limites 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"