Menu Docs
Página inicial do Docs
/
Operador de Kubernetes do MongoDB Enterprise
/
Implementar recursos do banco de dados
/
Distribuir

Implementar uma instância standalone do MongoDB

Nesta página

  • Pré-requisitos
  • Procedimento

Observação

Em qualquer lugar nesta página que diz Gerente de Operações, você pode substituir o Gerenciador de Nuvem.

Importante

  • Você pode usar o Operador Kubernetes para implantar recursos do MongoDB com o Cloud Manager e o Ops Manager versão 6.0.x ou posterior.

  • Você pode utilizar o Operador do Atlas para distribuir recursos do MongoDB no Atlas.

Você pode distribuir uma instância standalone do MongoDB para o Ops Manager gerenciar. Use instâncias independentes para teste e desenvolvimento. Não use essas distribuições para implantações de produção, pois elas não têm replicação e alta disponibilidade. Para todas as implantações de produção, use conjuntos de réplica. Para saber mais sobre conjuntos de réplicas, consulte Implantar um conjunto de réplicas.

Pré-requisitos

Para implementar um autônomo usando um objeto, você deve:

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 secreta. As implantações em vários clusters do Kubernetes não oferecem suporte ao armazenamento de segredos em ferramentas de armazenamento de segredos, como o HashiCorp Vault.

Procedimento

1

Configure kubectl como padrão para seu namespace.

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

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

Copie o seguinte exemplo de objeto Kubernetes autônomo.

Esse é um arquivo YAML que você pode modificar para atender à configuração desejada. Altere as configurações destacadas para corresponder à configuração standalone desejada.

---
apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: <my-standalone>
spec:
  version: "4.2.2-ent"
  opsManager:
    configMapRef:
      name: <configMap.metadata.name>
            # Must match metadata.name in ConfigMap file
  credentials: <mycredentials>
  type: Standalone
  persistent: true
...
3

Abra seu editor de texto preferido e cole a especificação do objeto em um novo arquivo de texto.

4

Defina as configurações destacadas na etapa anterior da seguinte forma.

Chave
Tipo
Descrição
Exemplo
string

Rótulo para este objeto autônoma do Kubernetes.

Os nomes de recursos devem ter 44 caracteres ou menos.

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

my-project
string

Versão do MongoDB instalada neste autônomo.

O formato deve ser X.Y.Z para a edição Community e X.Y.Z-ent 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.

string

Nome do ConfigMap com a configuração de conexão MongoDB Ops Manager do . A configuração spec.cloudManager.configMapRef.name é um nome alternativo para essa configuração e pode ser usada como substituto.

Esse valor deve existir no mesmo namespace que o recurso que você deseja criar.

<myproject>
string

Nome do secret que você criou como credenciais de autenticação da API do Ops Manager para o Kubernetes Operator se comunicar com o Ops Manager.

No Ops Manager, o secret do Kubernetes que contém as credenciais precisa existir no mesmo namespace que o recurso que você deseja criar.

IMPORTANTE: o operador do Kubernetes rastreia quaisquer alterações no Secret e reconcilia o estado do recurso MongoDB .

<mycredentials>
string
Tipo de recurso MongoDB a ser criado.
Standalone
string

Opcional.

Se este valor for true, então spec.podSpec.persistence.single está definido para seu valor padrão de 16Gi.

Para alterar a configuração de Declarações de volume persistente, configure as seguintes coleções para atender aos requisitos de sua implantação:

AVISO: conceda aos contêineres permissão para gravar no Volume Persistente. O Operador Kubernetes define fsGroup = 2000, runAsUser = 2000 e runAsNonRoot = true em securityContext. O Kubernetes Operator define fsgroup como runAsUser para tornar o volume gravável para um usuário que executa o processo principal no container. Para saber mais, consulte Configurar um contexto de segurança para um pod ou contêiner e a discussão relacionada na documentação do Kubernetes. Se a reimplementação do recurso não corrigir os problemas com o Volume Persistente, entre em contato com o Suporte do MongoDB.

Se você não usar Volumes persistentes, os Disk Usage e Disk IOPS Atlas Charts não poderão ser exibidos na Processes guia da Deployment página ou na Metrics página ao revisar os dados dessa implementação.

true
5

Adicione quaisquer configurações aceitas adicionais para uma implementação Standalone.

Você também pode adicionar qualquer uma das seguintes configurações opcionais ao arquivo de especificação do objeto para uma implantação autônoma:

6

Salve este arquivo com uma .yaml extensão de arquivo.

7

Inicie sua implementação Standalone.

Invoque o seguinte comando do Kubernetes para criar seu autônomo:

kubectl apply -f <standalone-conf>.yaml
8

Monitore o status da sua implementação standalone.

Para verificar o status do seu recurso MongoDB, utilize o seguinte comando:

kubectl get mdb <resource-name> -o yaml -w

Com o sinalizador -w (inspeção) definido, quando a configuração muda, o resultado é atualizado imediatamente até que a fase de status atinja o estado Running . Para saber mais sobre os status de distribuição de recursos, consulte Solucionar problemas do operador Kubernetes.

Para solucionar problemas no cluster fragmentado, consulte:

Voltar

Distribuir

Próximo

Conjunto de réplicas