Configurar o recurso personalizado do Ops Manager

Credenciais de administrador e configuração inicial

Antes que o aplicação Ops Manager possa ser iniciado, ele precisa de uma conta inicial de administrador. Você fornece estas credenciais através de um segredo Kubernetes referenciado por spec.adminCredentials. O segredo deve conter quatro chaves: Username (um endereço de e-mail), Password, FirstName e LastName. O Operador Kubernetes utiliza estas informações para inicializar a conta do primeiro Proprietário Global quando o pod do 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 Ops Manager estiver em execução, você poderá criar usuários adicionais e chaves de API por meio da interface do usuário ou da API do Ops Manager. O segredo do administrador inicial é usado somente durante a configuração inicial, mas o Kubernetes Operator faz referência a ele para reconciliação, portanto, ele deve permanecer no cluster.

O campo spec.version determina qual versão do Ops Manager o Kubernetes Operator implementa. Fixe isso em uma versão X.Y.Z específica em vez de deixá-la flutuar. Quando estiver pronto para atualizar, atualize este campo e permita que o Kubernetes Operator execute 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 Ops Manager

O campo spec.replicas controla quantas instâncias do aplicação 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 reinicializações de Pods e falhas de nós sem tempo de inatividade. Não há diferença funcional entre as réplicas; todos eles são servidores de aplicação sem estado apoiados pelo mesmo aplicativo de banco de dados.

Para organizações que precisam de redundância geográfica ou alta disponibilidade entre regiões, o Kubernetes Operator permite uma topologia MultiCluster para o próprio Ops Manager. Nesse modo, defina spec.topology: MultiCluster e defina um clusterSpecList que distribui instâncias do Ops Manager entre clusters nomeados do Kubernetes, 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 MultiCluster topologia, o spec.replicas campo é ignorado; as contagens de membros são extraídas do clusterSpecList . As implantações do Ops Manager em vários clusters introduzem requisitos de rede entre clusters, portanto, revise Implantar recursos do Ops Manager em vários clusters do Kubernetes antes de adotar esse 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 a sinalizadores de recursos e fontes de download binárias. Em vez de traduzir cada um deles em um campo CRD de primeira classe, o Kubernetes Operator fornece o bloco spec.configuration como pass-through: você define pares de chave-valor que são mapeados diretamente para as propriedades do sistema Ops Manager.

As propriedades mais comuns a serem definidas no momento da implementação são a configuração de e-mail, para que o 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"

A definição de mms.ignoreInitialUiSetup como "true" ignora o assistente de configuração interativo na primeira inicialização, que é essencial para sistemas totalmente automatizados.

Outras propriedades úteis incluem o seguinte:

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

• automation.versions.source — defina 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 do MongoDB .

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

Protegendo conexões com TLS

A execução do Ops Manager por HTTPS é altamente recomendada para qualquer ambiente além do desenvolvimento local. Sem ele, credenciais de administração, chaves de API e dados de monitoramento atravessam a rede em texto não criptografado.

Habilitar o HTTPS requer o seguinte:

• Um certificado TLS para o próprio aplicação Ops Manager.

• Um certificado TLS para o Banco de Dados do Aplicativo.

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

O certsSecretPrefix é como o Operador Kubernetes une estas convenções de nomenclatura. Se você definir spec.security.certsSecretPrefix como "om-prod" e seu recurso for denominado ops-manager, o Operador do Kubernetes espera segredos denominados om-prod-ops-manager-cert e (para o Banco de Dados de Aplicativo) appdb-prod-ops-manager-db-cert, como 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 Ops Manager CA deve ser nomeado mms-ca.crt dentro do ConfigMap. Além disso, esse arquivo da CA deve incluir a sequência de certificados para downloads.mongodb.com para que o Backup Daemon possa fazer download de 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 obter procedimentos passo a passo de implantação de HTTPS, incluindo os openssl comandos para montar a cadeia de CA, consulte Implantar um recurso do Ops Manager. Para automação de renovação de certificado, consulte Configurar uma integração cert-manager.

Conectividade externa

Fora da caixa, o Ops Manager só pode ser acessado dentro da rede interna do cluster Kubernetes. Para que administradores e agentes de monitoramento em execução fora do cluster acessem a interface do usuário e a API do Ops Manager, é necessário configurar a conectividade externa.

O bloco spec.externalConnectivity instrui o Operador Kubernetes a criar um Serviço Kubernetes do tipo especificado. É altamente recomendável usar LoadBalancer quando seu provedor de nuvem oferecer suporte a ele, pois ele provisiona automaticamente um endpoint externo estável. NodePort é um fallback para clusters locais ou desencapados, 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 AWS 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 endpoint externo tiver um nome de domínio personalizado (por exemplo, https://opsmanager.example.com), defina spec.opsManagerURL para que o Kubernetes Operator e seus agentes usem o endereço correto ao se comunicar com o Ops Manager:

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

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

Banco de dados de aplicativos

O banco de dados de aplicativos é um conjunto de réplicas do MongoDB que armazena todo o estado interno do Ops Manager: configurações de projeto , contas de usuário, definições de alerta e muito mais. Ele está fortemente vinculado aos servidores de aplicação do Ops Manager e deve estar saudável para que o Ops Manager funcione. O operador gerencia o aplicativo de banco de dados como parte do mesmo recurso personalizado, o que significa que um único manifesto YAML controla o aplicação e seu banco 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 implementações do MongoDB que ele gerencia. Ao contrário do spec.backup.mode sinalizador por implantação em um MongoDB CR, as configurações de backup no recurso 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 ativação do 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 da JVM

O Ops Manager é um aplicação Java , e seu consumo de recursos depende do número de sistemas monitorados, do volume de dados de métricas e da habilitação do backup. O operador distribui o Ops Manager como um StatefulSet, e você controla as especificações do pod por meio de spec.statefulSet.

No mínimo, defina solicitações e limites de CPU e memória. O MongoDB recomenda pelo menos 4 CPU e 8 GiB de memória para pequenas implantações, aumentando 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 container. Se for necessário substituir os parâmetros Java heap ou TG, use spec.jvmParameters, mas faça-o com cuidado: valores de heap incorretos podem desetorializar o 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 Ops Manager baixa os binários de instalação do MongoDB da Internet ( modo Remoto). Em ambientes com intervalo de ar ou de rede restrita, você pode configurar o modo Local, em que os binários são atendidos a partir de um PersistentVolume montado nos pods do Ops Manager, ou o modo Remoto com um endpoint personalizado.

modo remoto (padrão):

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

modo local (para ambientes com intervalo de ar):

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

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

Iteração na configuração do Ops Manager

Um recurso personalizado do Ops Manager acompanha a sua organização. Os cenários comuns de iteração incluem a atualização da versão do 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 .

Diretivas para mudanças seguras:

• Atualizar |onprem| no lugar. Altere spec.version e aplique. O operador realiza uma atualização contínua dos pods de aplicação . Certifique-se de que a versão do banco de dados do aplicativo seja compatível com a nova versão do Ops Manager antes de atualizar.

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

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

• Gire os certificados de forma proativa. 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,kubectl get om execute e inspecione o status campo para verificar o progresso da reconciliação e quaisquer condições de erro.

Para procedimentos de atualização de versão, consulte Upgrade do Ops Manager e Backing Database Versions. Para obter orientações sobre recuperação de desastres, consulte Recuperação de desastres para o Ops Manager e recursos do AppDB.

Juntando tudo: um exemplo completo de recurso do Ops Manager

O exemplo a seguir combina os conceitos abordados nesta página em uma implantação do Ops Manager pronta para produção. Ele inclui HTTPS, configuração de e-mail, um banco de dados de aplicativos de três membros com armazenamento divisão , backup com snapshots 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"