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
Página inicial do Docs
Página inicial do Docs

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 Ops Manager e do banco de dados de aplicativos em vários clusters do Kubernetes. Nesse modo, o multicluster de recursos do Ops Manager oferece suporte a uma implantação do aplicativo Ops Manager e do banco de dados de aplicativos em vários clusters do Kubernetes.

Antes de implantar um recurso do Ops Manager em um ou vários clusters do Kubernetes, revise a arquitetura e as considerações de recursos do Ops Manager e conclua os pré-requisitos.

Arquitetura

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

A definição de recurso personalizado MongoDBOpsManager

O Operador Kubernetes gerencia os sistemas do Ops Manager usando o MongoDBOpsManager recurso personalizado em cada cluster do Kubernetes onde você distribui o recurso. O Operador Kubernetes observa a especificação do recurso em busca de alterações. Quando a especificação é alterada, o Operador do Kubernetes valida as alterações e faz as atualizações apropriadas no recurso em cada um dos clusters do Kubernetes em que você distribui componentes do Ops Manager.

MongoDBOpsManager a especificação do recurso personalizadodefine os seguintes componentes do Ops Manager:

  • Banco de dados de aplicativos

  • O aplicativo MongoDB Ops Manager

  • O Daemon de Backup

O diagrama a seguir descreve os componentes relacionados para uma implantação MongoDB Ops Manager :

  • Em sistemas de cluster único, você distribui estes componentes no mesmo cluster Kubernetes onde instala o Operador Kubernetes. Esse cluster é conhecido como "cluster do operador".

  • Em sistemas de vários clusters, você:

    • Implante cada componente em clusters Kubernetes diferentes, conhecidos como "clusters de membros". Você também pode implantar uma implantação simplificada de vários clusters com um único cluster Kubernetes de membro. Para saber mais, consulte Modo de cluster único e multicluster.

    • Instale o Operador Kubernetes em um cluster do Kubernetes, conhecido como "cluster de operadores" de onde o Operador Kubernetes gerencia todos os outros clusters de membros. O cluster do operador também pode ser considerado um cluster de membros, pois também pode hospedar os componentes do MongoDB Ops Manager . Consulte Diagrama de arquitetura de vários clusters.

Diagrama mostrando a arquitetura de alto nível do MongoDB Enterprise Kubernetes Operator (cluster Kubernetes único)

Banco de dados de aplicativos para o recurso Ops Manager

Para o Banco de Dados de Aplicativos, o Operador Kubernetes implementa um conjunto de réplicas MongoDB definido como um StatefulSet.

Cada Pod para o Banco de Dados do Aplicativo tem os seguintes contêineres:

  • mongod.

  • MongoDB Agent. Para substituir a versão do MongoDB Agent, use a variável de ambiente $AGENT_IMAGE ou agent.version no gráfico Helm que você usa para instalar o Kubernetes Operator.

  • Agente de monitoramento. Você não pode substituir a versão do agente de monitoramento. A versão que o Kubernetes Operator usa garante a compatibilidade com as versões do MongoDB Ops Manager .

    Para visualizar a versão do agente de monitoramento:

    • Inspecione o /usr/local/om_version_mapping.json dentro do Pod para o Operador Kubernetes ou a imagem para o Operador Kubernetes.

    • Verifique a imagem do container do agente de monitoramento no Pod onde você implementa o banco de dados de aplicativos.

Em sistemas de vários clusters (quando você define spec.applicationDatabase.topology como MultiCluster), o Operador Kubernetes cria o StatefulSet em cada cluster Kubernetes especificado para o Banco de Dados de Aplicativos em spec.applicationDatabase.clusterSpecList.

As ações a seguir ocorrem em cada cluster Kubernetes de membros que hospeda nós de conjunto de réplicas do MongoDB para o banco de dados de aplicativos:

  • O Kubernetes cria um Pod no StatefulSet para cada nó que compreende seu conjunto de réplicas do Banco de Dados de Aplicativo. Cada Pod no StatefulSet executa um mongod e o MongoDB Agent.

    Para permitir que cada MongoDB Agent inicie mongod em seu Pod no StatefulSet, você deve especificar uma versão específica do MongoDB Server para o banco de dados de aplicativos usando a configuração spec.applicationDatabase.version. A versão especificada nesta configuração deve corresponder à tag no registro de contêiner.

  • Cada MongoDB Agent inicia mongods em seu Pod do Banco de Dados de Aplicativos. O MongoDB Agent adiciona processos mongod ao conjunto de réplicas do banco de dados do aplicativo.

    Você configura o número de réplicas e outras opções de configuração para o conjunto de réplicas do Banco de Dados do Aplicativo definido na spec.applicationDatabase coleção no recurso personalizado MongoDBOpsManager. O Operador Kubernetes passa essa configuração para o Agente MongoDB usando um segredo que o Operador Kubernetes monta em cada Pod no Banco de Dados de Aplicativos StatefulSet.

    Em sistemas do Banco de Dados de Aplicativos de vários clusters (onde spec.applicationDatabase.topology está definido como MultiCluster), você especifica o número de nós em cada cluster de membros separadamente para cada cluster de membros no spec.applicationDatabase.clusterSpecList. Em sistemas de vários clusters, a configuração replicas em spec.applicationDatabase é ignorada.

  • Cada vez que você atualiza a collection spec.applicationDatabase , o Operador Kubernetes aplica as alterações na configuração do MongoDB Agent e na especificação StatefulSet, se aplicável. Se a especificação do StatefulSet for alterada, o Kubernetes atualizará os Pods de forma contínua e reiniciará cada Pod.

  • Para fornecer conectividade a cada Pod do Banco de Dados de Aplicativo a partir de cada cluster Kubernetes que hospeda o Banco de Dados de Aplicativo, o Operador do Kubernetes cria um serviço headless. Em implantações de vários clusters do Banco de Dados de Aplicativos, o Operador Kubernetes também cria um serviço por Pod denominado <om_resource_name>-db-N-svc (isso corresponde a metadata.name) e usa seu FQDN, como <om_resource_name>-db-0.<namespace>.svc.cluster.local, como um nome de host para conectar-se a um mongod específico.

  • Dependendo da StorageClass ou do ambiente no qual você implementa o Operador Kubernetes, o Kubernetes pode criar os Volumes persistentes usando provisionamento dinâmico de volume.

    Você pode personalizar as declarações de volume persistente para os pods do banco de dados de aplicativos usando spec.applicationDatabase.podSpec.persistence.single ou spec.applicationDatabase.podSpec.persistence.multiple.

Topologia do Banco de Dados do Aplicativo

Para eleger uma primária, a maioria dos nós do conjunto de réplicas do aplicativo de banco de dados deve estar disponível. Se a maioria dos nós do conjunto de réplicas falhar, o conjunto de réplicas não poderá formar uma maioria votante para eleger um nó primário. Para saber mais, consulte Arquiteturas de sistema de conjunto de réplicas.

Se possível, use um número ímpar de clusters Kubernetes de membros e distribua os nós do banco de dados de aplicativos entre data centers, zonas ou clusters Kubernetes. Para saber mais, consulte Conjuntos de réplicas distribuídos em dois ou mais data centers.

Considere os seguintes exemplos da topologia do banco de dados do aplicativo:

Para um banco de dados de aplicativo de cinco membros, algumas possíveis distribuições de membros incluem:

  • Dois clusters: três membros para Cluster 1 e dois membros para Cluster 2.

    • Se Cluster 2 falhar, Cluster 1 hospedará um número suficiente de membros do conjunto de réplicas do aplicativo de banco de dados para eleger um nó primário.

    • Se Cluster 1 falhar, Cluster 2 não terá membros suficientes do banco de dados de aplicativos para eleger um nó primário.

  • Três clusters: dois membros para Cluster 1, dois membros para Cluster 2 e um membro para Cluster 3.

    • Se qualquer cluster falhar, haverá membros suficientes nos clusters restantes para eleger um nó primário.

    • Se dois clusters falharem, não haverá membros suficientes em nenhum cluster restante para eleger um nó primário.

Para um Banco de Dados de Aplicativo de sete membros, considere a seguinte distribuição de membros:

  • Dois clusters: quatro membros para Cluster 1 e três membros para Cluster 2.

    • Se Cluster 2 falhar, há membros suficientes em Cluster 1 para eleger um nó primário.

    • Se Cluster 1 falhar, não há membros suficientes em Cluster 2 para eleger um nó primário.

Embora Cluster 2 atenda ao mínimo de três membros para o Banco de Dados de Aplicativo, a maioria dos sete membros do Banco de Dados de Aplicativo deve estar disponível para eleger um nó primário.

Para saber mais, consulte Recuperação de desastres para o MongoDB Ops Manager e Recursos do AppDB.

Servidores de aplicativos do Ops Manager

Depois que o banco de dados de aplicativos atinge um estado de execução , o operador do Kubernetes começa a implantar o aplicativo do MongoDB Ops Manager :

  • Ele configura um StatefulSet em cada cluster Kubernetes de membros.

  • Para cada conjunto de réplicas MongoDB Ops Manager que você deseja implantar, o Kubernetes cria um Pod no StatefulSet.

  • Cada Pod contém um processo de Aplicativo de MongoDB Ops Manager .

Para tornar seu sistema do MongoDB Ops Manager de cluster único resiliente a falhas de Pod único, aumente o número de réplicas que hospedam o aplicativo MongoDB Ops Manager , usando spec.replicas.

Para tornar a implantação do MongoDB Ops MongoDB Ops Manager de vários clusters resiliente a falhas de todo o data center ou zona, implante o aplicativo MongoDB Ops Manager em vários clusters do Kubernetes definindo spec.topology e spec.applicationDatabase.topology como MultiCluster. Consulte também Recuperação de desastres para o MongoDB Ops Manager e Recursos do AppDB.

Backup Daemon para o recurso Ops Manager

Se spec.backup.enabled for true, então em cada cluster Kubernetes membro, o Operador Kubernetes inicia o Daemon de Backup depois que o Aplicativo MongoDB Ops Manager atinge um estágio de Execução . Para o Backup Daemon, o Operador Kubernetes implementa um StatefulSet para cada cluster Kubernetes de membros. Em cada cluster de membros, o Kubernetes cria tantos Backup Daemon Pods no StatefulSet quanto especificado no spec.backup.members. Em implantações de cluster único, essas ações ocorrem no cluster do operador que você usa para instalar o Kubernetes Operator e implantar os componentes do MongoDB Ops Manager .

Se você habilitar o backup, configure o armazenamento de oplog, um blockstore ou um armazenamento de snapshot S3no spec.backup nível global e não para cada cluster de membros do Kubernetes.

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 .

Se você ativar o backup, o operador Kubernetes criará uma declaração de volume persistente para o banco de dados principal do Backup Daemon em cada cluster de membros do Kubernetes. Você pode configurar o banco de dados principal usando a configuração spec.backup.headDB.

O Operador Kubernetes invoca as APIs MongoDB Ops Manager para garantir que a configuração de backup do aplicativo MongoDB Ops Manager corresponda à que você definir nas definições de recursos personalizados para cada cluster Kubernetes de membros.

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

Você não pode modificar o nome e as funções do usuário do banco de dados do MongoDB Ops Manager . Você cria um segredo para definir a senha do usuário do banco de dados. Você edita o segredo para atualizar a senha. Se você não criar um segredo ou excluir um segredo existente, o Operador Kubernetes gerará uma senha e a armazenará.

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 Backup Daemon 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 API do Ops Manager para habilitar o Backup Daemon e configurar o banco de dados principal.

Importante

Para configurar o Backup, você deve criar os recursos MongoDB ou recursos MongoDBMultiCluster para o armazenamento de oplog e para um dos seguintes:

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 no S3 , você deve criar um bucket compatível com o Amazon Web Services S3 ou o S3para armazenar seu reconhecimento de data center oplog.

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

Para configurar um blockstore, você deve implementar um conjunto de réplicas para armazenar snapshots.

Armazenamento de snapshots do S3

Para configurar um armazenamento de snapshots S3 , você deve criar um bucket compatível com S3 ou S3 do Amazon Web Services para armazenar os snapshots debackup 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 armazenamento de snapshots do S3 para o recurso MongoDB e o recurso MongoDBMultiCluster.

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

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. Exclua o serviço StatefulSet de 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 Arquitetura de vários clusters.

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

    Isso inclui os ConfigMaps referenciados pelos recursos do banco de MongoDB database para os armazenamentos de oplog e snapshots.

Implementando o MongoDB Ops Manager em Multi-Clusters

Consulte Arquitetura 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 de operadores, 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.

    Quando você implementa o recurso MongoDB Ops MongoDB Ops Manager , o MongoDB Ops Manager cria um usuário com estas credenciais e concede a ele o role Global Owner . Use essas credenciais para fazer login no MongoDB Ops Manager pela primeira vez. Depois de implantar o MongoDB Ops Manager, altere a senha ou remova esse segredo.

    Observação

    A senha do usuário administrador deve aderir aos MongoDB Ops Manager requisitos de complexidade de senha do .

    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 do 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 do 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 .

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

    Chave

    Valor

    accessKey

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

    secretKey

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

    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.

Nesta página