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

Implantar um recurso Ops Manager

Você pode implantar o Ops Manager como um recurso em um container Kubernetes usando o Kubernetes Operator.

As seguintes considerações se aplicam:

Ao configurar seu sistema do Ops Manager, você deve escolher se deseja executar conexões por HTTPS ou HTTP .

O seguinte procedimento HTTPS :

  • Estabelece conexões criptografadas por TLSde/para o aplicativo Ops Manager.

  • Estabelece conexões criptografadas por TLSentre os nós do conjunto de réplicas do aplicativo de banco de dados.

  • Exige certificados válidos para criptografia TLS.

O seguinte procedimento HTTP :

  • Não criptografa conexões de ou para o aplicativo Ops Manager.

  • Não criptografa conexões entre os membros do conjunto de réplicas do aplicativo de banco de dados.

  • Tem menos requisitos de configuração.

When running over HTTPS, Ops Manager runs on port 8443 by default.

Selecione a guia apropriada com base no fato de você desejar criptografar o Ops Manager e as conexões do banco de dados de aplicativos com TLS.

  • Conclua os pré- requisitos.

  • Crie um certificado TLS para o conjunto de réplicas do banco de dados do aplicativo.

    Este certificado TLS exige os seguintes atributos:

    Nomes de DNS

    Certifique-se de adicionar SANs ou nomes de assunto para cada Pod que hospeda um nó do conjunto de réplicas do Banco de Dados de Aplicativos. A SAN para cada pod deve usar o seguinte formato:

    <opsmgr-metadata.name>-db-<index>.<opsmgr-metadata.name>-db-svc.<namespace>.svc.cluster.local

    Usos da chave

    Certifique-se de que os certificados TLS incluam os seguintes usos de chave ( 5280):

    • "servidor de autenticação"

    • "autenticação do cliente"

Importante

O Operador do Kubernetes usa kubernetes.io/tls segredos para armazenar certificados TLS e chaves privadas para recursos do Ops Manager e MongoDB . A partir da versão do Kubernetes Operator 1.17.0, o Kubernetes Operator não permite arquivos PEM concatenados armazenados como segredos Opaco.

Antes de implantar um recurso MongoDB Ops Manager , certifique-se de planejar seu recurso MongoDB Ops Manager :

Este procedimento se aplica à implantação de uma instância MongoDB Ops Manager em um único cluster Kubernetes e à implantação do MongoDB Ops Manager em um cluster de operadores em uma implantação de vários clusters. Se você quiser implantar várias instâncias do MongoDB Ops Manager em vários clusters do Kubernetes , consulte Implantar recursos MongoDB Ops Manager em vários clusters do Kubernetes .

Siga estas etapas para distribuir o recurso do Ops Manager para executar HTTPS e proteger o reconhecimento de data center usando TLS.

1

Caso ainda não tenha feito isso, execute o seguinte comando para executar todos os comandos kubectl no namespace que você criou.

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

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

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.

  1. Depois de ter seus certificados TLS e chaves privadas, execute o seguinte comando para criar um segredo que armazena MongoDB Ops Manager o certificado TLS :

    kubectl create secret tls <prefix>-<metadata.name>-cert \
    --cert=<om-tls-cert> \
    --key=<om-tls-key>
  2. Execute o seguinte comando para criar um novo segredo que armazena o certificado TLS do banco de dados do aplicação:

    kubectl create secret tls <prefix>-<metadata.name>-db-cert \
    --cert=<appdb-tls-cert> \
    --key=<appdb-tls-key>
3

If your Ops Manager TLS certificate is signed by a custom CA, the CA certificate must also contain additional certificates that allow Ops Manager Backup Daemon to download MongoDB binaries from the Internet. To create the TLS certificate(s), create a ConfigMap to hold the CA certificate:

Importante

O Kubernetes Operator exige que seu certificado do Ops Manager seja denominado mms-ca.crt no ConfigMap.

  1. Obtain the entire TLS certificate chain for Ops Manager from downloads.mongodb.com. The following openssl command outputs the certificate in the chain to your current working directory, in .crt format:

    openssl s_client -showcerts -verify 2 \
    -connect downloads.mongodb.com:443 -servername downloads.mongodb.com < /dev/null \
    | awk '/BEGIN/,/END/{ if(/BEGIN/){a++}; out="cert"a".crt"; print >out}'
  2. Concatenate your CA's certificate file for Ops Manager with the entire TLS certificate chain from downloads.mongodb.com that you obtained in the previous step:

    cat <custom_ca_cert.pem> cert2.crt cert3.crt cert4.crt >> mms-ca.crt

    Observação

    • Substitua o espaço reservado <custom_ca_cert.pem> pelo seu arquivo PEM de certificado de CA personalizado.

    • Não inclua seu arquivo cert1.crt, pois é o certificado do servidor do MongoDB que não deve ser incluído.

  3. Criar o ConfigMap para MongoDB Ops Manager:

    kubectl create configmap om-http-cert-ca --from-file="mms-ca.crt"
4

Altere as configurações para corresponder ao Ops Manager e à configuração do banco de dados de aplicativo.

1---
2apiVersion: mongodb.com/v1
3kind: MongoDBOpsManager
4metadata:
5 name: <myopsmanager>
6spec:
7 replicas: 1
8 version: <opsmanagerversion>
9 adminCredentials: <adminusercredentials> # Should match metadata.name
10 # in the Kubernetes secret
11 # for the admin user
12
13 externalConnectivity:
14 type: LoadBalancer
15 security:
16 certsSecretPrefix: <prefix> # Required. Text to prefix
17 # the name of the secret that contains
18 # Ops Manager's TLS certificate.
19 tls:
20 ca: "om-http-cert-ca" # Optional. Name of the ConfigMap file
21 # containing the certificate authority that
22 # signs the certificates used by the Ops
23 # Manager custom resource.
24
25 applicationDatabase:
26 topology: SingleCluster
27 members: 3
28 version: "8.0.0-ubi8"
29 security:
30 certsSecretPrefix: <prefix> # Required. Text to prefix to the
31 # name of the secret that contains the Application
32 # Database's TLS certificate. Name the secret
33 # <prefix>-<metadata.name>-db-cert.
34 tls:
35 ca: "appdb-ca" # Optional, unless enabling TLS for |mms|.
36 # Name of the ConfigMap file
37 # containing the certicate authority that
38 # signs the certificates used by the
39 # application database.
40
41...
1---
2apiVersion: mongodb.com/v1
3kind: MongoDBOpsManager
4metadata:
5 name: <myopsmanager>
6spec:
7 replicas: 1
8 version: <opsmanagerversion>
9 adminCredentials: <adminusercredentials> # Should match metadata.name
10 # in the Kubernetes secret
11 # for the admin user
12
13 externalConnectivity:
14 type: LoadBalancer
15 security:
16 certsSecretPrefix: <prefix> # Required. Text to prefix
17 # the name of the secret that contains
18 # Ops Manager's TLS certificate.
19 tls:
20 ca: "om-http-cert-ca" # Optional. Name of the ConfigMap file
21 # containing the certificate authority that
22 # signs the certificates used by the Ops
23 # Manager custom resource.
24
25 applicationDatabase:
26 topology: MultiCluster
27 clusterSpecList:
28 - clusterName: cluster1.example.com
29 members: 4
30 - clusterName: cluster2.example.com
31 members: 3
32 - clusterName: cluster3.example.com
33 members: 2
34 version: "8.0.0-ubi8"
35 security:
36 certsSecretPrefix: <prefix> # Required. Text to prefix to the
37 # name of the secret that contains the Application
38 # Database's TLS certificate. Name the secret
39 # <prefix>-<metadata.name>-db-cert.
40 tls:
41 ca: "appdb-ca" # Optional, unless enabling TLS for |mms|.
42 # Name of the ConfigMap file
43 # containing the certicate authority that
44 # signs the certificates used by the
45 # application database.
46
47...
5
6
Chave
Tipo
Descrição
Exemplo

string

Nome para este Kubernetes MongoDB Ops Manager objeto do.

Os nomes de recursos devem ter 44 caracteres ou menos.

Consulte também metadata.name e a documentação do Kubernetes sobre nomes.

om

número

Número de instâncias do Ops Manager a serem executadas em paralelo.

O valor mínimo válido é 1. Este campo será ignorado se você especificar MultiCluster na configuração spec.topology .

1

string

Versão do Ops Manager a ser instalada.

O formato deve ser XYZ. Para visualizar as versões disponíveis do Ops Manager, visualize o registro de contêiner.

8.0.0

string

Nome do segredo que você criou para o MongoDB Ops Manager usuário administrador do . Configure o segredo para usar o mesmo namespace que o recurso Ops Manager.

om-admin-secret

spec
.security
.certsSecretPrefix

string

Obrigatório.

Texto para prefixar o nome do segredo que contém certificados TLS do Ops Managers.

om-prod

spec
.security
.tls
.ca

string

Nome do ConfigMap que você criou para verificar seus MongoDB Ops Manager certificados TLS assinados usando uma CA personalizada. Este campo é obrigatório se você assinou seus MongoDB Ops Manager certificados TLS usando uma CA personalizada.

om-http-cert-ca

spec
.externalConnectivity
.type

string

The Kubernetes service ServiceType that exposes Ops Manager outside of Kubernetes. Exclude the spec.externalConnectivity setting and its children if you don't want the Kubernetes Operator to create a Kubernetes service to route external traffic to the Ops Manager application.

LoadBalancer

spec
.applicationDatabase
.members

inteiro

Número de membros do conjunto de réplicas do Ops Manager Application Database .

3

spec
.applicationDatabase
.version

string

Obrigatório.

Versão do MongoDB que o banco de Ops Manager Application Database deve executar.

The format should be X.Y.Z-ubi8 for the Enterprise edition and X.Y.Z for the Community edition. Do not add the -ubi8 tag suffix to the Community edition image because the Kubernetes Operator adds the tag suffix automatically.

IMPORTANTE: Certifique-se de escolher uma versão compatível do MongoDB Server. Versões compatíveis diferem dependendo da imagem base que o recurso do banco de banco de dados MongoDB utiliza.

Para saber mais sobre a versão MongoDB, consulte Versões do MongoDB no Manual MongoDB.

Para obter melhores resultados, use a versão mais recente disponível do MongoDB empresarial que seja compatível com sua versão do Ops Manager.

spec
.applicationDatabase
.topology

string

Opcional.

O tipo do sistema Kubernetes para o banco de dados de aplicativos. Se omitido, o padrão é SingleCluster.

Se você especificar MultiCluster, o Kubernetes Operator ignorará os valores que você definiu para o campo spec.applicationDatabase.members , se especificado. Em vez disso, você deve especificar o clusterSpecList e incluir nele o clusterName de cada cluster de membros do Kubernetes selecionado no qual deseja distribuir o banco de dados de aplicativos e o número de members (nós do MongoDB) em cada cluster do Kubernetes.

Não é possível converter uma única instância MongoDB Ops Manager de cluster em uma instância de sistema do MongoDB de cluster multi-Kubernetes modificando as configurações do topology e clusterSpecList no CRD.

Veja também o exemplo da especificação do recurso.

MultiCluster

spec
.applicationDatabase
.security
.certsSecretPrefix

string

Obrigatório.

Texto para prefixar o nome do segredo que contém os certificados TLS do banco de dados do aplicativo.

appdb-prod

spec
.applicationDatabase
.security
.tls
.ca

string

Nome do ConfigMap que você criou para verificar os certificados TLS do banco de dados de aplicativo assinados usando uma CA personalizada. Esse campo é obrigatório se você assinou os certificados TLS do banco de dados de aplicativo usando uma CA personalizada.

ca

The Kubernetes Operator mounts the CA you add using the spec.applicationDatabase.security.tls.ca setting to both the Ops Manager and the Application Database Pods.

7

Para configurar o backup, você deve habilitá-lo e, em seguida:

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

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

Chave
Tipo
Descrição
Exemplo

spec
.backup
.enabled

booleano

Sinalizador que indica que o Backup está habilitado. Você deve especificar spec.backup.enabled: true para definir as configurações do banco de dados principal, do oplog e do armazenamento de snapshots.

true

spec
.backup
.headDB

collection

A collection of configuration settings for the head database. For descriptions of the individual settings in the collection, see spec.backup.headDB.

spec
.backup
.opLogStores
.name

string

Nome do armazenamento de oplog.

oplog1

spec
.backup
.s3OpLogStores
.name

string

Nome do armazenamento de oplog S3.

my-s3-oplog-store

spec
.backup
.opLogStores
.mongodbResourceRef
.name

string

Nome do recurso MongoDB ou recurso MongoDBMultiCluster para o armazenamento de oplog. O metadata.name do recurso deve corresponder a esse nome.

my-oplog-db

spec
.backup
.s3OpLogStores
.mongodbResourceRef
.name

string

Nome do recurso MongoDB ou recurso MongoDBMultiCluster para o armazenamento de oplog S3. O metadata.name do recurso deve corresponder a esse nome.

my-s3-oplog-db

Você também deve configurar um armazenamento de snapshots S3 ou um blockstore.

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

Para configurar um armazenamento de snapshots, defina as seguintes configurações:

Chave
Tipo
Descrição
Exemplo

spec
.backup
.s3Stores
.name

string

Nome do armazenamento de snapshots do S3.

s3store1

spec
.backup
.s3Stores
.s3SecretRef
.name

string

Nome do segredo que contém os campos accessKey e secretKey. O Backup Daemon Service usa os valores desses campos como credenciais para acessar o bucket compatível com o S3ou o S3.

my-s3-credentials

spec
.backup
.s3Stores
.s3BucketEndpoint

string

URL do bucket compatível com S3 ou S3 que armazena os snapshots de backup do banco de dados .

s3.us-east-1.amazonaws.com

spec
.backup
.s3Stores
.s3BucketName

string

Nome do bucket compatível com S3 ou S3que armazena os snapshots de backup do banco de dados .

my-bucket

Para configurar um blockstore, defina as seguintes configurações:

Chave
Tipo
Descrição
Exemplo

spec
.backup
.blockStores
.name

string

Nome do blockstore.

blockStore1

spec
.backup
.blockStores
.mongodbResourceRef
.name

string

Nome do recurso MongoDB que você cria para o blockstore. Você deve implantar este recurso de reconhecimento de data center no mesmo namespace que o recurso Ops Manager.

my-mongodb-blockstore

8

Add any optional settings for backups that you want to apply to your deployment to the object specification file. For example, for each type of backup store, and for Ops Manager backup daemon processes, you can assign labels to associate particular backup stores or backup daemon processes with specific projects. Use spec.backup.[*].assignmentLabels elements of the OpsManager resources.

9

Adicione quaisquer configurações opcionais que você deseja aplicar ao seu sistema ao arquivo de especificação do objeto .

10
11

Execute o seguinte comando kubectl no nome do arquivo da definição de recurso do Ops Manager:

kubectl apply -f <opsmgr-resource>.yaml

Observação

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

kubectl apply \
--context "$MDB_CENTRAL_CLUSTER_FULL_NAME" \
--namespace "mongodb"
-f https://raw.githubusercontent.com/mongodb/mongodb-kubernetes/master/public/samples/ops-manager/ops-manager-external.yaml
12

Para verificar o status do recurso do Ops Manager, invoque o seguinte comando:

kubectl get om -o yaml -w

O comando retorna a saída semelhante à seguinte no campo status enquanto o recurso distribui:

status:
applicationDatabase:
lastTransition: "2022-04-01T09:49:22Z"
message: AppDB Statefulset is not ready yet
phase: Pending
type: ""
version: ""
backup:
phase: ""
opsManager:
phase: ""

O Operador Kubernetes reconcilia os recursos na seguinte ordem:

  1. banco de dados de aplicativo.

  2. Gerente de operações.

  3. Backup.

O Operador Kubernetes não reconcilia um recurso até que o anterior entre na fase Running .

Depois que o recurso Ops Manager concluir a fase Pending , o comando retornará uma saída semelhante à seguinte no campo status se você habilitou o Backup:

status:
applicationDatabase:
lastTransition: "2022-04-01T09:50:20Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
backup:
lastTransition: "2022-04-01T09:57:42Z"
message: The MongoDB object <namespace>/<oplogresourcename>
doesn't exist
phase: Pending
opsManager:
lastTransition: "2023-04-01T09:57:40Z"
phase: Running
replicas: 1
url: https://om-svc.cloudqa.svc.cluster.local:8443
version: "8.0.0"

O backup permanece em um estado Pending até que você configure o banco de dados de backup.

Dica

O campo status.opsManager.url declara o URL de conexão do recurso. Usando este URL, você pode acessar o MongoDB Ops Manager de dentro do cluster Kubernetes ou criar um projeto usando um ConfigMap.

Após o recurso concluir a fase Pending , o comando retornará uma saída semelhante à seguinte no campo status :

status:
applicationDatabase:
lastTransition: "2022-12-06T18:23:22Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
opsManager:
lastTransition: "2022-12-06T18:23:26Z"
message: The MongoDB object namespace/oplogdbname doesn't exist
phase: Pending
url: https://om-svc.dev.svc.cluster.local:8443
version: ""

O backup permanece em um estado Pending até que você configure o banco de dados de backup.

Dica

O campo status.opsManager.url declara o URL de conexão do recurso. Usando este URL, você pode acessar o MongoDB Ops Manager de dentro do cluster Kubernetes ou criar um projeto usando um ConfigMap.

13

As etapas realizadas diferem com base em como você está roteando o tráfego para o aplicativo Ops Manager no Kubernetes. Se você configurou o Operador do Kubernetes para criar um serviço do Kubernetes para você ou criou um serviço do Kubernetes manualmente, use um dos seguintes métodos para acessar o aplicativo Ops Manager:

  1. Consulte seu provedor de nuvem para obter o FQDN do serviço do balanceador de carga. Consulte a documentação do seu fornecedor de nuvem para obter detalhes.

  2. Abra uma janela do navegador e navegue até o aplicativo Ops Manager usando o FQDN e o número da porta do serviço do balancer de carga.

    https://ops.example.com:8443
  3. Faça login no Ops Manager usando as credenciais de usuário administrador.

  1. Defina suas regras de firewall para permitir o acesso da Internet ao spec.externalConnectivity.port no host em que seu cluster Kubernetes está sendo executado.

  2. Open a browser window and navigate to the Ops Manager application using the FQDN and the spec.externalConnectivity.port.

    https://ops.example.com:30036
  3. Faça login no Ops Manager usando as credenciais de usuário administrador.

Para saber como acessar o aplicativo Ops Manager usando um serviço de terceiros, consulte a documentação da sua solução.

14

Para configurar as credenciais, você deve criar uma MongoDB Ops Manager organização , gerar API chaves de programáticas e criar um segredo. Essas atividades seguem os pré-requisitos e o procedimento na página Criar Credenciais para o Operador Kubernetes .

15

Para criar um projeto, siga os pré-requisitos e o procedimento na página Criar um projeto por sistema do MongoDB usando um ConfigMap.

Defina os seguintes campos no ConfigMap do seu projeto:

  • Defina data.baseUrl no ConfigMap para a URL do aplicativo de Ops Manager. Para encontrar esta URL, invoque o seguinte comando:

    kubectl get om -o yaml -w

    O comando retorna a URL da aplicação Ops Manager no campo status.opsManager.url, semelhante ao seguinte exemplo:

    status:
    applicationDatabase:
    lastTransition: "2022-12-06T18:23:22Z"
    members: 3
    phase: Running
    type: ReplicaSet
    version: "8.0.0-ubi8"
    opsManager:
    lastTransition: "2022-12-06T18:23:26Z"
    message: The MongoDB object namespace/oplogdbname doesn't exist
    phase: Pending
    url: https://om-svc.dev.svc.cluster.local:8443
    version: ""

    Importante

    Se você implantar o Ops Manager com o Kubernetes Operator e o Ops Manager gerenciar os recursos do banco de dados MongoDB implantados fora do cluster do Kubernetes em que foi implantado, será necessário definir data.baseUrl com o mesmo valor da configuração spec.configuration.mms.centralUrl na especificação de recursos do Ops Manager.

    Para saber mais, consulte Gerenciando sistemas externos do MongoDB .

  • Set data.sslMMSCAConfigMap to the name of your ConfigMap containing the root CA certificate used to sign the Ops Manager host's certificate. The Kubernetes Operator requires that you name this Ops Manager resource's certificate mms-ca.crt in the ConfigMap.

16

Por padrão, o MongoDB Ops Manager ativa o Backup. Crie um recurso de banco de dados MongoDB para os armazenamentos de oplog e snapshots para concluir a configuração.

  1. Implemente um MongoDB database para o armazenamento de oplog no mesmo namespace que o Ops Manager.

    Observação

    Crie este reconhecimento de data center como um conjunto de réplica de três membros.

    Combine o metadata.name do recurso com o spec.backup.opLogStores.mongodbResourceRef.name que você especificou em sua definição de recurso do Ops Manager.

  2. Implante um recurso de banco de dados MongoDB para o armazenamento de snapshots S3 no mesmo namespace que o recurso Ops Manager.

    Observação

    Crie o armazenamento de snapshots S3 como um conjunto de réplicas.

    Combine o metadata.name do recurso ao spec.backup.s3Stores.mongodbResourceRef.name que você especificou em sua definição de recurso do Ops Manager.

17

Para verificar o status do recurso do Ops Manager, invoque o seguinte comando:

kubectl get om -o yaml -w

Quando o Ops Manager está em execução, o comando retorna a saída semelhante à seguinte, no campo status :

status:
applicationDatabase:
lastTransition: "2022-12-06T17:46:15Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
opsManager:
lastTransition: "2022-12-06T17:46:32Z"
phase: Running
replicas: 1
url: https://om-backup-svc.dev.svc.cluster.local:8443
version: "8.0.0"

Consulte Solucionar problemas do operador Kubernetes para obter informações sobre os status de distribuição de recursos.

Siga estas etapas para implantar o recurso do MongoDB Ops Manager para ser executado por HTTP:

1

Caso ainda não tenha feito isso, execute o seguinte comando para executar todos os comandos kubectl no namespace que você criou.

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

kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
2

Altere as configurações para corresponder à configuração do MongoDB Ops Manager .

1---
2apiVersion: mongodb.com/v1
3kind: MongoDBOpsManager
4metadata:
5 name: <myopsmanager>
6spec:
7 replicas: 1
8 version: <opsmanagerversion>
9 adminCredentials: <adminusercredentials> # Should match metadata.name
10 # in the secret
11 # for the admin user
12 externalConnectivity:
13 type: LoadBalancer
14
15 applicationDatabase:
16 topology: SingleCluster
17 members: 3
18 version: <mongodbversion>
19...
1---
2apiVersion: mongodb.com/v1
3kind: MongoDBOpsManager
4metadata:
5 name: <myopsmanager>
6spec:
7 replicas: 1
8 version: <opsmanagerversion>
9 adminCredentials: <adminusercredentials> # Should match metadata.name
10 # in the Kubernetes secret
11 # for the admin user
12
13 externalConnectivity:
14 type: LoadBalancer
15
16 applicationDatabase:
17 topology: MultiCluster
18 clusterSpecList:
19 - clusterName: cluster1.example.com
20 members: 4
21 - clusterName: cluster2.example.com
22 members: 3
23 - clusterName: cluster3.example.com
24 members: 2
25 version: "8.0.0-ubi8"
26
27...
3
4
Chave
Tipo
Descrição
Exemplo

string

Nome para este Kubernetes MongoDB Ops Manager objeto do.

Os nomes de recursos devem ter 44 caracteres ou menos.

Para saber mais, consulte metadata.name e a documentação do Kubernetes sobre nomes.

om

número

Número de instâncias do Ops Manager a serem executadas em paralelo.

O valor mínimo válido é 1. Este campo será ignorado se você especificar MultiCluster na configuração spec.topology .

1

string

Versão do Ops Manager a ser instalada.

O formato deve ser XYZ. Para obter a lista de versões disponíveis do , visualize MongoDB Ops Manager o registro de contêiner.

8.0.0

string

Nome do segredo que você criou para o usuário administrador do MongoDB Ops Manager .

Configure o segredo para usar o mesmo namespace que o recurso Ops Manager.

om-admin-secret

spec
.externalConnectivity
.type

string

Opcional.

O serviço do Kubernetes ServiceType que expõe o Ops Manager fora do Kubernetes.

Exclua a configuração spec.externalConnectivity e seus filhos se não quiser que o Operador Kubernetes crie um serviço Kubernetes para rotear o tráfego externo para o aplicativo Ops Manager.

LoadBalancer

spec
.applicationDatabase
.members

inteiro

Número de membros do conjunto de réplicas do Ops Manager Application Database .

3

spec
.applicationDatabase
.version

string

Obrigatório.

Versão do MongoDB que o banco de Ops Manager Application Database deve executar.

O formato deve ser X.Y.Z para a edição MongoDB Community e X.Y.Z-ubi8 para a edição Enterprise.

IMPORTANTE: Certifique-se de escolher uma versão compatível do MongoDB Server. Versões compatíveis diferem dependendo da imagem base que o recurso do banco de banco de dados MongoDB utiliza.

Para saber mais sobre a versão MongoDB, consulte Versões do MongoDB no Manual MongoDB.

Para obter melhores resultados, use a versão mais recente disponível do MongoDB empresarial que seja compatível com sua versão do Ops Manager.

spec
.applicationDatabase
.topology

string

Opcional.

O tipo do sistema Kubernetes para o banco de dados de aplicativos. Se omitido, o padrão é SingleCluster.

Se você especificar MultiCluster, o Kubernetes Operator ignorará os valores que você definiu para o campo spec.applicationDatabase.members , se especificado.

Em vez disso, você deve especificar o clusterSpecList e incluir nele o clusterName de cada cluster de membros do Kubernetes selecionado no qual deseja distribuir o Banco de Dados do Aplicativo, e o número de members (nós do MongoDB ) em cada cluster do Kubernetes.

Não é possível converter uma única instância MongoDB Ops Manager de cluster em uma instância de sistema do MongoDB de cluster multi-Kubernetes modificando as configurações do topology e clusterSpecList no CRD.

Veja também o exemplo da especificação do recurso.

MultiCluster

5

Para configurar o backup, você deve habilitá-lo e, em seguida:

  • Choose to configure an S3 snapshot store or a blockstore. If you deploy both an S3 snapshot store and a blockstore, Ops Manager randomly choses one to use for backup.

  • Choose to configure an oplog store or an S3 oplog store. If you deploy both an oplog store and an S3 oplog store, Ops Manager randomly choses one of them to use for the oplog backup.

Chave
Tipo
Descrição
Exemplo

spec
.backup
.enabled

booleano

Sinalizador que indica que o backup está habilitado. Você deve especificar spec.backup.enabled: true para definir as configurações do banco de dados principal, oplog store, S3 oplog store e armazenamento de snapshots.

true

spec
.backup
.headDB

collection

A collection of configuration settings for the head database. For descriptions of the individual settings in the collection, see spec.backup.headDB.

spec
.backup
.opLogStores
.name

string

Nome do armazenamento de oplog.

oplog1

spec
.backup
.s3OpLogStores
.name

string

Name of the S3 oplog store.

my-s3-oplog-store

spec
.backup
.opLogStores
.mongodbResourceRef
.name

string

Nome do recurso MongoDB ou recurso MongoDBMultiCluster para o armazenamento de oplog. O metadata.name do recurso deve corresponder a esse nome.

my-oplog-db

spec
.backup
.s3OpLogStores
.mongodbResourceRef
.name

string

Nome do recurso de banco de dados MongoDB para o armazenamento de oplog S3.

my-s3-oplog-db

Você também deve configurar um armazenamento de snapshots S3 ou um blockstore.Sevocê implantar um armazenamento de snapshots S3 e um blockstore, o Ops Manager escolherá aleatoriamente um para usar no backup.

Para configurar um armazenamento de snapshots S3, defina as seguintes configurações:

Chave
Tipo
Descrição
Exemplo

spec
.backup
.s3Stores
.name

string

Name of the S3 snapshot store.

s3store1

spec
.backup
.s3Stores
.s3SecretRef
.name

string

Nome do segredo que contém os campos accessKey e secretKey. O Backup Daemon Service usa os valores desses campos como credenciais para acessar o bucket compatível com S3 ou S3.

my-s3-credentials

spec
.backup
.s3Stores
.s3BucketEndpoint

string

URL do bucket compatível com S3 ou S3 que armazena os snapshots de backup do banco de dados .

s3.us-east-1.amazonaws.com

spec
.backup
.s3Stores
.s3BucketName

string

Nome do bucket compatível com S3 ou S3que armazena os snapshots de backup do banco de dados .

my-bucket

spec
.backup
.s3Stores
.s3RegionOverride

string

Região onde reside seu bucket compatível com S3. Use esse campo somente se o s3BucketEndpoint do seu armazenamento S3 não incluir uma região em seu URL. Não use este campo com buckets AWS S3.

us-east-1

Para configurar um blockstore, defina as seguintes configurações:

Chave
Tipo
Descrição
Exemplo

spec
.backup
.blockStores
.name

string

Nome do blockstore.

blockStore1

spec
.backup
.blockStores
.mongodbResourceRef
.name

string

Nome do recurso MongoDB que você cria para o blockstore. Você deve implantar esse recurso de banco de dados de dados no mesmo namespace que o recurso MongoDB Ops Manager . O metadata.name do recurso deve corresponder a este nome.

my-mongodb-blockstore

6

Add any optional settings for backups that you want to apply to your deployment to the object specification file. For example, for each type of backup store, and for Ops Manager backup daemon processes, you can assign labels to associate particular backup backup stores or backup daemon processes with specific projects. Use spec.backup.[*].assignmentLabels elements of the OpsManager resources.

7

Adicione quaisquer configurações opcionais que você deseja aplicar ao seu sistema ao arquivo de especificação do objeto .

8
9

Execute o seguinte comando kubectl no nome do arquivo da definição de recurso do Ops Manager:

kubectl apply -f <opsmgr-resource>.yaml

Observação

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

kubectl apply \
--context "$MDB_CENTRAL_CLUSTER_FULL_NAME" \
--namespace "mongodb"
-f https://raw.githubusercontent.com/mongodb/mongodb-kubernetes/master/public/samples/ops-manager/ops-manager-external.yaml
10

Para verificar o status do recurso do Ops Manager, invoque o seguinte comando:

kubectl get om -o yaml -w

O comando retorna uma saída semelhante ao seguinte, no campo status enquanto o recurso implementa:

status:
applicationDatabase:
lastTransition: "2023-04-01T09:49:22Z"
message: AppDB Statefulset is not ready yet
phase: Pending
type: ""
version: ""
backup:
phase: ""
opsManager:
phase: ""

O Operador Kubernetes reconcilia os recursos na seguinte ordem:

  1. banco de dados de aplicativo.

  2. Gerente de operações.

  3. Backup.

O Operador Kubernetes não reconcilia um recurso até que o anterior entre na fase Running .

Depois que o recurso MongoDB Ops Manager concluir a fase Pending, o comando retornará a saída semelhante à seguinte no campo status se você tiver habilitado o backup:

status:
applicationDatabase:
lastTransition: "2023-04-01T09:50:20Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
backup:
lastTransition: "2022-04-01T09:57:42Z"
message: The MongoDB object <namespace>/<oplogresourcename>
doesn't exist
phase: Pending
opsManager:
lastTransition: "2022-04-01T09:57:40Z"
phase: Running
replicas: 1
url: http://om-svc.cloudqa.svc.cluster.local:8080
version: "8.0.0"

O backup permanece em um estado Pending até que você configure os bancos de dados de backup.

Dica

O campo status.opsManager.url declara o URL de conexão do recurso. Usando este URL, você pode acessar o MongoDB Ops Manager de dentro do cluster Kubernetes ou criar um projeto usando um ConfigMap.

11

As etapas realizadas diferem com base em como você está roteando o tráfego para o aplicativo Ops Manager no Kubernetes. Se você configurou o Operador do Kubernetes para criar um serviço do Kubernetes para você ou criou um serviço do Kubernetes manualmente, use um dos seguintes métodos para acessar o aplicativo Ops Manager:

  1. Consulte seu provedor de nuvem para obter o FQDN do serviço do balanceador de carga. Consulte a documentação do seu fornecedor de nuvem para obter detalhes.

  2. Abra uma janela do navegador e navegue até o aplicativo Ops Manager usando o FQDN e o número da porta do serviço do balancer de carga.

    http://ops.example.com:8080
  3. Faça login no Ops Manager usando as credenciais de usuário administrador.

  1. Defina suas regras de firewall para permitir o acesso da Internet ao spec.externalConnectivity.port no host em que seu cluster Kubernetes está sendo executado.

  2. Open a browser window and navigate to the Ops Manager application using the FQDN and the spec.externalConnectivity.port.

    http://ops.example.com:30036
  3. Faça login no Ops Manager usando as credenciais de usuário administrador.

Para saber como acessar o aplicativo Ops Manager usando um serviço de terceiros, consulte a documentação da sua solução.

12

Se você habilitou o backup, você deverá criar uma organização MongoDB Ops Manager , gerar chaves de API programáticas e criar um segredo em sua ferramenta de armazenamento secreto. Essas atividades seguem os pré-requisitos e o procedimento na página Criar Credenciais para o Operador Kubernetes .

13

Se você habilitou o backup, crie um projeto seguindo os pré-requisitos e o procedimento na página Criar um projeto por sistema do MongoDB usando um ConfigMap.

Você deve definir data.baseUrl no ConfigMap para o do MongoDB Ops Manager aplicativo URL. Para encontrar esta URL, invoque o seguinte comando:

kubectl get om -o yaml -w

O comando retorna a URL da aplicação Ops Manager no campo status.opsManager.url, semelhante ao seguinte exemplo:

status:
applicationDatabase:
lastTransition: "2022-04-01T10:00:32Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
backup:
lastTransition: "2022-04-01T09:57:42Z"
message: The MongoDB object <namespace>/<oplogresourcename>
doesn't exist
phase: Pending
opsManager:
lastTransition: "2022-04-01T09:57:40Z"
phase: Running
replicas: 1
url: http://om-svc.cloudqa.svc.cluster.local:8080
version: "8.0.0"

Importante

Se você implantar o Ops Manager com o Kubernetes Operator e o Ops Manager gerenciar os recursos do banco de dados MongoDB implantados fora do cluster do Kubernetes em que foi implantado, será necessário definir data.baseUrl com o mesmo valor da configuração spec.configuration.mms.centralUrl na especificação de recursos do Ops Manager.

Para saber mais, consulte Gerenciando sistemas externos do MongoDB .

14

Se você ativou o Backup, crie um recurso de MongoDB database para os armazenamentos de oplog e snapshots para concluir a configuração.

  1. Implemente um MongoDB database para o armazenamento de oplog no mesmo namespace que o Ops Manager.

    Observação

    Crie este banco de dados como um conjunto de réplicas.

    Combine o metadata.name do recurso com o spec.backup.opLogStores.mongodbResourceRef.name que você especificou em sua definição de recurso do Ops Manager.

  2. Escolha uma das seguintes opções:

    1. Implante um recurso deMongoDB database para o blockstore no mesmo namespace que o recurso MongoDB Ops Manager .

      Combine o metadata.name do recurso ao spec.backup.blockStores.mongodbResourceRef.name que você especificou em sua definição de recurso do Ops Manager.

    2. Configure um bucket S3 para ser usado como armazenamento de snapshots do S3.

      Certifique-se de que você pode acessar o bucket S3 usando os detalhes especificados na definição de recurso do Ops Manager.

15

Se você ativou o backup, verifique o status do recurso do MongoDB Ops Manager invocando o seguinte comando:

kubectl get om -o yaml -w

Quando o MongoDB Ops Manager está em execução, o comando retorna a seguinte saída no campo status :

status:
applicationDatabase:
lastTransition: "2022-04-01T10:00:32Z"
members: 3
phase: Running
type: ReplicaSet
version: "8.0.0-ubi8"
backup:
lastTransition: "2022-04-01T10:00:53Z"
phase: Running
version: "8.0.0-ubi8"
opsManager:
lastTransition: "2022-04-01T10:00:34Z"
phase: Running
replicas: 1
url: http://om-svc.cloudqa.svc.cluster.local:8080
version: "8.0.0"

Consulte Solucionar problemas do operador Kubernetes para obter informações sobre os status de distribuição de recursos.

Avalie esta página