Imagens de Container

Arquitetura

A arquitetura dos containers estáticos e não estáticos difere significativamente e requer várias etapas para migrar de um para o outro. Para saber mais, consulte Migrar para containers estáticos e Migrar para containers não estáticos.

Arquitetura de container não estática

A arquitetura de contêiner não estático padrão pressupõe que você inicialize um contêiner de shell vazio, baixe e inicie o MongoDB Agent, que então baixa os binários para mongod e mongosh do Cloud Manager ou MongoDB Ops Manager.

clique para ampliar

Arquitetura de contêiner estático

A arquitetura de contêiner estático utiliza afuncionalidade de namespace compartilhado do Kubernetes para executar o MongoDB Agent como um processo separado para que ele possa controlar o ciclo de vida completo do mongod e evitar o download de arquivos por uma rede.

clique para ampliar

Compatibilidade com o modo local ou remoto

Se você usar containers estáticos, não precisará configurar o MongoDB Ops Manager para ser executado em Modo Local ou Modo Remoto, a menos que você use queryable backup. Na arquitetura de container estática, os binários do agente e mongod têm suas próprias imagens de container e elas não são baixadas do MongoDB Ops Manager.

Os queryable backups são a exceção porque, na arquitetura de contêiner não estática, por padrão, o Backup Daemon baixa e executa os binários do MongoDB Server para todas as versões das quais é feito backup. Esse comportamento padrão do MongoDB prejudica a natureza totalmente estática dos containers usados para executar o Backup Daemon. Se você usar queryable backup, ainda deverá hospedar os binários relevantes do MongoDB Server usando o modo local ou remoto. Para saber mais, consulte Configurar um recurso MongoDB Ops Manager para usar o Modo Local ou Configurar um recurso MongoDB Ops Manager para usar o Modo Remoto.

Se você usou o modo Remoto ou Local antes e não quer usar backups consultáveis, faça o seguinte para garantir que mongodb-enterprise-server imagens pode ser baixado nos nós usado pelos pods:

1. Configure um registro de contêiner interno para seus nós do Kubernetes.

   Os nós irá baixar as imagens do Quay.io a menos que você use um registro de contêiner local.

2. Baixee adicione as imagens.mongodb-enterprise-server

Limitações

Se você habilitar containers estáticos:

• Você deve desativar os queryable backups para que o Backup Daemon Service não tente baixar os binários do MongoDB do MongoDB Ops Manager, o que prejudica a natureza imutável dos containers estáticos.

• Com MongoDB Ops Manager, somente as versões 6.0.24, 7.0.5 ou posterior são compatíveis. O Kubernetes Operator usa automaticamente a versão correta do container do MongoDB Agent com base na versão do MongoDB Ops Manager selecionada para gerenciar uma sistema específica.

• Com o MongoDB Cloud Manager, sua versão do MongoDB Agent pode ficar atrasada em relação à versão mais recente do MongoDB Cloud Manager porque o operador Kubernetes não pode chamar o endpoint agentVersion no MongoDB Cloud Manager. Para garantir que seu MongoDB Agent esteja atualizado com o MongoDB Cloud Manager, você pode executar uma das seguintes ações:

  • Especifique uma versão compatível do MongoDB Agent na especificação de MongoDB do MongoDB substituindo o StatefulSet imagem de contêiner para o MongoDB Agent. Por exemplo:

    podSpec:
      podTemplate:
        spec:
          containers:
            - name: mongodb-agent-ubi
              Image: 12.0.29.7785-1_1.24.0

  • Atualize o Kubernetes Operator para a versão mais recente, que atualiza automaticamente o MongoDB Agent.

• Atualizar uma versão do MongoDB Atlas Triggers uma reinicialização contínua de todos os Pods, em ordem do último para o primeiro, e pode causar mais eleições, até o número de Pods. Isso vale para qualquer atualização que trigger uma reinicialização contínua.

• Você não poderá determinar se ocorreu uma atualização do MongoDB database a partir do MongoDB Agent. Quando o Kubernetes rotaciona Pods após uma atualização, o MongoDB Agent substitui o arquivo de status de integridade para que você não saiba pelo status de integridade que ocorreu uma alteração de versão, apenas o status de integridade atual.

Perguntas frequentes

Migrar para contêineres estáticos

Para migrar de contêineres não estáticos para estáticos, defina as variáveis de ambiente do MongoDB Agent e habilite os contêineres estáticos seguindo as etapas abaixo. Você também pode habilitar contêineres estáticos durante a instalação ou atualização.

kubectl apply -f mongodb-enterprise.yaml

oc apply -f mongodb-enterprise-openshift.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
  --set registry.pullPolicy='IfNotPresent'

kubectl apply -f <my-config-file>.yaml

oc apply -f <my-config-file>.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
 --set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="static"

Migrar para contêineres não estáticos

Para migrar de contêineres estáticos para não estáticos, desative os contêineres estáticos seguindo as etapas abaixo. Você também pode desabilitar contêineres estáticos durante a instalação ou atualização.

kubectl apply -f <my-config-file>.yaml

oc apply -f <my-config-file>.yaml

helm upgrade enterprise-operator mongodb/enterprise-operator \
 --set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="non-static"