Para agentes de IA: um índice de documentação está disponível em https://www.mongodb.com/pt-br/docs/llms.txt — as versões de markdown de todas as páginas estão disponíveis anexando .md a qualquer caminho de URL.
Menu Docs
Página inicial do Docs
/ /
Implementar Ops Manager
Página inicial do Docs
/
Gestão
/
Controladores para o Operador do Kubernetes
/
Implementar Ops Manager
Página inicial do Docs
/
Gestão
/
Controladores para o Operador do Kubernetes
/
Implementar Ops Manager

Planeje seu recurso do Ops Manager

O MongoDB Ops Manager é um aplicação empresarial que gerencia, faz backup e monitora os sistemas do MongoDB . Com o Ops Manager, você pode escalar e atualizar o MongoDB, otimizar queries, realizar restaurações point-in-time, receber alertas de desempenho e monitorar seus sistemas. Para gerenciar e manter o Ops Manager e seu banco de dados subjacente, você pode usar os Controladores do MongoDB para o Operador Kubernetes para executar o Ops Manager como um recurso distribuído em um contêiner no Kubernetes.

Você pode distribuir recursos MongoDB Ops Manager de uma das seguintes maneiras:

  • Modo de cluster Kubernetes único. Você pode implantar uma única instância MongoDB Ops Manager para dar suporte à sua implantação de cluster Kubernetes único dos recursos do MongoDB .

  • Modo de cluster múltiplo do Kubernetes. Você pode implantar várias instâncias do MongoDB Ops Manager e do banco de dados de aplicativos em vários clusters do Kubernetes . Nesse modo, o multicluster de recursos Ops Manager suporta uma implantação do Aplicativo MongoDB Ops Manager e do Banco de Dados de Aplicativos em vários clusters do Kubernetes .

Before you deploy an Ops Manager resource in either a single or multiple Kubernetes clusters, review Ops Manager Architecture in Kubernetes and considerations, and complete the prerequisites.

Arquitetura

Para obter detalhes da arquitetura de recursos MongoDB Ops Manager , consulte:

Considerações

chave de criptografia

O Operador Kubernetes gera uma chave de criptografia para proteger informações confidenciais no Ops Manager Application Database. O operador Kubernetes salva essa chave em um segredo no mesmo namespace que o recurso Ops Manager. O Operador do Kubernetes nomeia o segredo <om-resource-name>-gen-key.

Observação

Para evitar o armazenamento de segredos em sistemas do Kubernetes de cluster único, você pode migrar todos os segredos para uma ferramenta de armazenamento de segredos. As implantações em vários clusters do Kubernetes não suportam o armazenamento de segredos no armazenamento de segredos FERRAMENTAS, como o HashiCorp Vault.

Se você remover o recurso do Ops Manager, a chave permanecerá armazenada no segredo no cluster do Kubernetes. Se você armazenou o Banco de Dados de Aplicativo em um Volume Persistente e criar outro recurso do Ops Manager com o mesmo nome, o Operador Kubernetes reutilizará o segredo. Se você criar um recurso do Ops Manager com um nome diferente, o Kubernetes Operator criará um novo segredo e o aplicativo de banco de dados, e o segredo antigo não será reutilizado.

Banco de dados de aplicativos

topologia

Monitoramento

O Operador do Kubernetes configura automaticamente o Ops Manager para monitorar o reconhecimento de data center que oferece suporte à aplicação do Ops Manager. O Kubernetes cria um projeto denominado <ops-manager-deployment-name>-db para você monitorar o comando de banco de dados do banco de dados de aplicativo.

O Ops Manager monitora o comando de banco de dados de aplicação, mas o Ops Manager não o managed. Você não pode alterar a configuração do banco de dados do aplicativo no aplicativo Ops Manager.

Importante

A interface do usuário do Ops Manager pode exibir avisos no projeto <ops-manager-deployment-name>-db informando que os agente do banco de dados de aplicativo estão desatualizados. Você pode ignorar esses avisos com segurança.

Autenticação

O Operador Kubernetes força a autenticação SCRAM-SHA-256 no Aplicativo de banco de dados.

O Operador Kubernetes cria o trigger de banco de dados que o Ops Manager usa para se conectar ao reconhecimento de data center de aplicação. Esse trigger de banco de dados tem os seguintes atributos:

Nome de usuário

mongodb-ops-manager

Banco de dados de autenticação

admin

Funções

You can't modify the Ops Manager database user's name and roles. You create a secret to set the database user's password. You edit the secret to update the password. If you don't create a secret or delete an existing secret, the Kubernetes Operator generates a password and stores it.

Para saber mais sobre outras opções de armazenamento secreto, consulte Configurar armazenamento secreto. Os sistemas de vários clusters não oferecem suporte ao armazenamento de segredos no HashiCorp Vault.

Sistemas offline

O Operador Kubernetes exige que você especifique a versão MongoDB Enterprise para a imagem do Banco de Dados de Aplicativo para permitir quaisquer sistemas de recursos do MongoDB Ops Manager , incluindo sistemas offline.

Configuração simplificada

Depois de implementar o MongoDB Ops Manager, é necessário configurá-lo. O procedimento regular envolve a configuração do MongoDB Ops Manager por meio do assistente de configuração. Se você definir algumas configurações essenciais na especificação do objeto antes de implementá-lo, poderá ignorar o assistente de configuração.

No bloco spec.configuration da especificação de objeto do Ops Manager, você precisa:

Exemplo

Para desabilitar o assistente de configuração do Ops Manager, defina as seguintes configurações no seu bloco 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

Substitua os valores de exemplo pelos valores que você deseja que seu Ops Manager use.

Backup.

O Kubernetes Operator ativa o Backup por padrão. O Operador Kubernetes implementa um StatefulSet composto por um Pod para hospedar o Serviço de Daemon de Backup e, em seguida, cria uma Declaração de Volume Persistente e volume persistente para o banco de dados principal do Backup Daemon. O Kubernetes Operator usa a do para ativar o Backup Daemon e configurar o head MongoDB Ops Manager API database.

Importante

To configure Backup, you must create the MongoDB resources or MongoDBMultiCluster resources for the oplog store and for one of the following:

  • armazenamento de oplog ou armazenamento de oplog S3. Se você implantar o armazenamento de oplog e o armazenamento de oplog S3, o Ops Manager escolherá um aleatoriamente para usar para backup.

  • S3 armazenamento de snapshots ou blockstore.Sevocê implantar um armazenamento de snapshots S3 e um blockstore, o Ops Manager escolherá um aleatoriamente para usar para backup.

O recurso do Ops Manager permanece em um estado Pending até que você configure estes recursos de backup.

Você também pode criptografar tarefas de backup, mas as limitações se aplicam a sistemas em que a mesma instância do Kubernetes Operator não está gerenciando os recursos personalizados do MongoDBOpsManager e do MongoDB .

Oplog Store

Você deve implantar um conjunto de réplica de três membros para armazenar suas fatias de oplog.

O reconhecimento de data center oplog oferece suporte apenas ao mecanismo de autenticação SCRAM . Não é possível habilitar outros mecanismos de autenticação.

Se você habilitar a autenticação SCRAM no reconhecimento de data center oplog, deverá:

  • Crie um recurso de usuário MongoDB para conectar o Ops Manager ao reconhecimento de data center oplog.

  • Especifique o name do usuário na definição de recurso do Ops Manager.

S3 oplog Store

Para configurar um armazenamento de oplog S3, você deve criar um bucket compatível com AWS S3 ou S3para armazenar seu oplog de backup do banco de dados.

Você pode configurar o armazenamento de oplog para o recurso MongoDB e o recurso MongoDBMultiCluster , usando a configuração spec.backup.s3OpLogStores.mongodbResourceRef.name na definição de recurso do Ops Manager.

blockstore

To configure a blockstore, you must deploy a replica set to store snapshots.

Armazenamento de snapshots do S3

Para configurar um armazenamento de snapshots S3, você deve criar um bucket compatível com AWS S3 ou S3 para armazenar seus snapshots de backup do banco de dados .

A configuração padrão armazena metadados de snapshot no banco de dados de aplicativo. Você também pode implantar um conjunto de réplicas para armazenar metadados de snapshot e, em seguida, configurá-lo usando as configurações do spec.backup.s3Stores.mongodbResourceRef.name na definição de recurso do Ops Manager.

Você pode configurar o S3 armazenamento de snapshots para o recurso MongoDB e o recurso MongoDBMultiCluster.

Você pode atualizar quaisquer definições de configuração S3 adicionais que o Kubernetes Operator não gerencie por meio do aplicativo Ops Manager.

Desabilitar cópia de segurança

Para desabilitar o backup depois de habilitá-lo:

  1. Defina a configuração do objeto spec.backup.enabled Ops Manager Kubernetes false como.

  2. Desative os backups no aplicativo MongoDB Ops Manager .

  3. Excluir o serviço StatefulSet do Backup Daemon :

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

Importante

A declaração de volume persistente e o volume persistente do banco de dados principal do Backup Daemon não são excluídos quando você exclui o Backup Daemon Service StatefulSet. Você pode recuperar dados armazenados antes de excluir esses recursos do Kubernetes.

Para saber mais sobre como recuperar Volumes persistentes, consulte a documentação do Kubernetes.

Configurar manualmente a criptografia de backup KMIP

Para implantações em que a mesma instância do Kubernetes Operator não está gerenciando os recursos personalizados do MongoDBOpsManager e do MongoDB , você deve definir manualmente as configurações do cliente de criptografia de backup KMIP no Ops Manager usando o procedimento a seguir. Se o Kubernetes Operator estiver gerenciando ambos os recursos, consulte Configurar o KMIP Backup Encryption para o Ops Manager .

Pré-requisitos
Procedimento

  1. Monte o segredo TLS para o recurso personalizado MongoDBOpsManager . Por exemplo:

    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 as configurações de KMIP para seu projeto no MongoDB Ops Manager seguindo o procedimento em Configurar seu projeto para utilizar KMIP.

Configurar o Ops Manager para executar sobre HTTPS

Você pode configurar sua instância do Ops Manager criada por meio do Kubernetes Operator para ser executada em HTTPS em vez de HTTP.

Para configurar sua instância do Ops Manager para ser executada por HTTPS:

  1. Crie um segredo que contenha o certificado TLS e a chave privada.

  2. Adicione este segredo ao objeto de configuração do Ops Manager.

Para obter instruções detalhadas, consulte Implantar um recurso do Ops Manager.

Importante

Se você tiver implantações existentes, deverá reiniciá-las manualmente após habilitar o HTTPS. Para evitar reiniciar suas implementações, configure HTTPS antes de distribuir seus recursos managed.

Para saber mais, consulte HTTPS habilitado após a implementação.

Acesso ao aplicativo do Ops Manager

Por padrão, o Kubernetes Operator não cria um serviço do Kubernetes para rotear o tráfego originado de fora do cluster do Kubernetes para o aplicativo Ops Manager.

Para acessar o aplicativo Ops Manager, você pode:

  • Configure o Operador Kubernetes para criar um serviço Kubernetes.

  • Crie um serviço Kubernetes manualmente. MongoDB recomenda usar um serviço LoadBalancer Kubernetes se o seu fornecedor de cloud oferecer suporte a ele.

  • Se você estiver usando o OpenShift, use rotas.

  • Use um serviço de terceiros, como o Isstio.

O método mais simples é configurar o Operador Kubernetes para criar um serviço Kubernetes que roteia o tráfego externo para o aplicação Ops Manager. O procedimento de sistema do Ops Manager instrui você a adicionar as seguintes configurações à especificação do objeto que configura o Kubernetes Operator para criar um serviço:

Além disso, para implantações em vários clusters do Kubernetes, consulte Rede, Balanceamento de carga, Service Mesh.

Implantação do Ops Manager no modo remoto ou local

Você pode usar o Operador Kubernetes para configurar um único cluster MongoDB Ops Manager para operar no modo Local ou Remoto se o seu ambiente impedir a concessão de hosts no cluster do Kubernetes acesso à Internet. Nesses modos, os Daemons de Backup e os recursos gerenciados do MongoDB baixam os arquivos de instalação do MongoDB Ops Manager em vez da Internet:

Gerenciando sistemas externos do MongoDB

Quando você implanta o Ops Manager com o Kubernetes Operator, o Ops Manager pode managed os recursos do MongoDB database implantados:

  • Para o mesmo cluster do Kubernetes que o gerente de operações.

  • Fora dos clusters Kubernetes.

Se o Ops Manager managed os recursos do MongoDB database distribuídos em clusters Kubernetes diferentes do Ops Manager ou fora dos clusters Kubernetes, você deverá:

  1. Adicione a configuração mms.centralUrl a spec.configuration na especificação de recursos do Ops Manager.

    Defina o valor para a URL pela qual o Ops Manager é exposto fora do cluster do Kubernetes:

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

  2. Atualize os ConfigMaps referenciados por todos os recursos do MongoDB database dentro do cluster Kubernetes que você implementou com o Kubernetes Operator.

    Defina data.baseUrl para o mesmo valor da configuração spec.configuration.mms.centralUrl na especificação de recursos do Ops Manager.

    Importante

    This includes the ConfigMaps referenced by the MongoDB database resources for the oplog and snapshot stores.

Implementando o MongoDB Ops Manager em Multi-Clusters

Consulte Arquitetura MongoDB Ops Manager de vários clusters.

Armazenamento secreto

Para evitar o armazenamento de segredos no Kubernetes, migre todos os segredos do Kubernetes que o operador do Kubernetes cria para uma ferramenta de armazenamento de segredos. Os sistemas de vários clusters não oferecem suporte ao armazenamento de segredos em FERRAMENTAS de armazenamento secretos, como o HashiCorp Vault.

Pré-requisitos

  1. Se você ainda não tiver feito isso, execute o seguinte comando para executar todos os comandos kubectl no namespace que você criou:

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

    Observação

    Se você estiver implantando um recurso MongoDB Ops Manager em um sistema do MongoDB de vários clusters Kubernetes:

    • Defina context como o nome do cluster central, como: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".

    • Defina --namespace para o mesmo escopo usado para sua implantação do MongoDB de vários clusters Kubernetes, como: kubectl config --namespace "mongodb".

  2. Instale os drivers do MongoDB para o Kubernetes Operator.

  3. Certifique-se de que o host no qual você deseja implantar o Ops Manager tenha um mínimo de cinco gigabytes de memória.

  1. Crie um segredo do Kubernetes para um usuário administrador no mesmo namespace que o recurso Ops Manager. Se você estiver implantando o Ops Manager em uma sistema do MongoDB de vários clusters Kubernetes, use o mesmo namespace que você definiu para o escopo de sistema do MongoDB de vários clusters Kubernetes .

    Se você estiver usando o HashiCorp Vault como sua ferramenta de armazenamento secreto, poderá Criar um Vault Secret .

    Para saber mais sobre suas opções de armazenamento secreto, consulte Configurar armazenamento secreto.

    When you deploy the Ops Manager resource, Ops Manager creates a user with these credentials and grants it the Global Owner role. Use these credentials to log in to Ops Manager for the first time. Once you deploy Ops Manager, change the password or remove this secret.

    Observação

    The admin user's password must adhere to the Ops Manager password complexity requirements.

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

  1. (Opcional) Para definir a senha do usuário de banco de dados do Ops Manager, crie um segredo no mesmo namespace que o recurso Ops Manager.

    Se você estiver usando o HashiCorp Vault como sua ferramenta de armazenamento secreto, poderá Criar um Vault Secret .

    O Kubernetes Operator cria o usuário de banco de dados que o MongoDB Ops Manager usa para se conectar ao Ops Manager Application Database. Você pode definir a senha para este usuário de banco de dados invocando o seguinte comando para criar um segredo:

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

    Observação

    Se você optar por criar um segredo para o trigger de banco de dados do Ops Manager, deverá especificar o name do segredo na definição de recurso do Ops Manager. Por padrão, o Kubernetes Operator procura o valor da senha na chave password . Se você armazenou o valor da senha em uma chave diferente, você também deverá especificar esse nome key na definição de recurso do Ops Manager.

    Se você não criar um segredo, o operador Kubernetes gerará automaticamente uma senha e a armazenará internamente. Para saber mais, consulte Autenticação.

  2. (Opcional). Para configurar o Backup para um armazenamento de snapshots S3, crie um segredo no mesmo namespace que o recurso Ops Manager.

    Se você estiver usando o HashiCorp Vault como sua ferramenta de armazenamento secreto, poderá Criar um Vault Secret .

    Este segredo armazena suas S3 credenciais para que o operador do Kubernetes possa conectar o MongoDB Ops Manager ao seu bucket Amazon Web Services S3 ou compatível com S3. O segredo deve conter os seguintes pares chave-valor:

    Chave

    Valor

    accessKey

    Identificador exclusivo do usuário AWS que possui o bucket compatível com S3 ou S3.

    secretKey

    Chave secreta do usuário da Amazon Web Services que possui o bucket S3 ou S3-compatível.

    Para criar o segredo, invoque o seguinte comando:

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

    Para saber mais sobre como gerenciar o armazenamento de snapshots do S3 , consulte os Pré-requisitos.

Voltar
Desempenho
Próximo
Implemente em vários clusters
Avalie esta página

Nesta página