Imagens de Container
Nesta página
Quando você instala o Operador Kubernetes, ele extrai as imagens do registro de contêiner Quay.io. As imagens do Kubernetes Operator são baseadas no Red Hat UBI 8 sistema operacional. O MongoDB reconstrói imagens do Kubernetes Operator diariamente para o sistema operacional mais recente e as atualizações da biblioteca de suporte.
As imagens oficiais oferecem os seguintes benefícios:
Eles são reconstruídos diariamente para as correções de vulnerabilidade upstream mais recentes.
O MongoDB os testa, mantém e oferece suporte.
Para ver todas as versões disponíveis de cada imagem, veja os links a seguir.
Nome da imagem | Descrição |
---|---|
Imagem do MongoDB Agent. | |
A imagem Enterprise MongoDB usada para containers estáticos e o banco de dados de aplicativos. | |
initContainer que contém os scripts de inicialização do banco de dados de aplicativo e o teste de preparação. | |
Imagem de ambiente de MongoDB database usada para contêineres não estáticos. Para saber mais sobre containers estáticos e não estáticos, consulte Containers estáticos (visualização pública). | |
initContainer imagem que contém os scripts de inicialização do MongoDB Agent e a análise de preparação. | |
Imagem do Ops Manager. | |
initContainer que contém os scripts de inicialização do Ops Manager e a análise de preparação. |
Contêineres estáticos (visualização pública)
Os containers estáticos são mais simples e seguros do que os containers não estáticos. Os containers estáticos são imutáveis no tempo de execução, o que significa que eles não mudam da imagem usada para criar o container. Além disso:
Durante a execução, os containers estáticos não baixam binários nem executam scripts ou outros utilitários por meio de conexões de rede. Os containers estáticos baixam apenas arquivos de configuração de tempo de execução.
Durante a execução, os containers estáticos não modificam nenhum arquivo, exceto as montagens do volume de armazenamento.
Você pode executar verificações de segurança nas imagens do contêiner para determinar o que está realmente sendo executado como um contêiner ativo, e o contêiner que é executado não executará binários diferentes do que foi definido na imagem.
Os containers estáticos não exigem que você hospede o binário do MongoDB no Ops Manager ou em outro servidorHTTPS , o que é especialmente útil se você tiver um ambiente com lacunas de ar.
Você não pode executar scripts
CMD
extensivos para o container estático.Você não pode copiar arquivos entre containers estáticos usando
initContainer
.
Começando com o MongoDB Enterprise Kubernetes Operator 1.25, você pode usar a pré-visualização pública de contêineres estáticos em vez dos contêineres não estáticos existentes, que baixam o binário do MongoDB do Cloud Manager, do Ops Manager ou da Internet no tempo de execução. Você pode usar os procedimentos nesta página para habilitar ou desabilitar contêineres estáticos para todas as implantações do MongoDB ou individuais.
Os contêineres estáticos usam a imagem do mongodb-enterprise-server Repositório Quay.io por padrão, mas você pode usar seu próprio registro se o configurar para seus nós do Kubernetes .
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.
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.
Compatibilidade com o modo local ou remoto
Se você usar containers estáticos, não precisará configurar o 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 para o agente e mongod
têm suas próprias imagens de container e elas não são baixadas do 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 Servidor MongoDB 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 do Ops Manager para usar o modo local ou Configurar um recurso do 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:
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 o Ops Manager, apenas 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 contêiner do MongoDB Agent com base na versão do 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 recursos 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
Os containers estáticos suportam o modo local ou remoto?
Não, se você usar containers estáticos, não precisará configurar o Ops Manager para ser executado no Modo Local ou no Modo Remoto, a menos que você use queryable backups. Para saber mais, consulte Modos locais e remotos.
Quais são as mudanças para os containers estáticos?
Os containers estáticos não baixam o binário do MongoDB no tempo de execução. Em vez disso, ele usa as imagens do mongodb-enterprise-server Repositório Quay.io. Para saber mais sobre as alterações, consulte a etapa 6.
Como posso verificar se meu sistema está sendo executado de forma estática?
Há muitas maneiras de determinar se seu sistema está usando um contêiner estático. Para saber mais, consulte a etapa 7.
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.
Revise as limitações.
Desative os queryable backups.
Siga o procedimento em Desativar queryable backups.
Se você quiser usar queryable backup, deverá configurar o recurso do Ops Manager para usar o Modo Local ou o Modo Remoto para que os binários de todas as versões em uso possam ser extraídos do Ops Manager.
Defina variáveis de ambiente para a imagem do MongoDB Agent.
No arquivo de configuração do Kubernetes Operator, defina a variável de ambiente MDB_AGENT_IMAGE_REPOSITORY para especificar o repositório do qual o Kubernetes Operator baixa a imagem do MongoDB Agent para contêineres estáticos.
Em seu gráfico Helm do Operador Kubernetes, defina registro.agent e agente.name para especificar o repositório do qual o Operador Kubernetes baixa a imagem do Agente MongoDB para contêineres estáticos.
Salve e aplique o arquivo.
Depois de salvar as alterações, aplique novamente sua configuração.
Se você usa o Kubernetes sem OpenShift, execute:
kubectl apply -f mongodb-enterprise.yaml
Se você usa Kubernetes com OpenShift:
oc apply -f mongodb-enterprise-openshift.yaml
helm upgrade enterprise-operator mongodb/enterprise-operator \ --set registry.pullPolicy='IfNotPresent'
Isso inicia uma reinicialização contínua de todos os Pods em seu sistema.
Habilite containers estáticos.
Selecione a guia apropriada abaixo para habilitar contêineres estáticos para todas as suas implantações do MongoDB de uma só vez, incluindo implantações existentes, ou uma implantação de cada vez.
No arquivo de configuração do Kubernetes Operator , defina MDB_DEFAULT_ARCHITECTURE ou operator.mdbDefaultArchitecture como static
.
Na especificação de recursos do MongoDB para uma implantação específica, defina a anotação metadata.annotations.mongodb.com/v1.architecture
como static
.
Salve e aplique o arquivo.
Depois de salvar as alterações, aplique novamente sua configuração.
Se você usa o Kubernetes sem OpenShift, execute:
kubectl apply -f <my-config-file>.yaml
Se você usa Kubernetes com OpenShift:
oc apply -f <my-config-file>.yaml
helm upgrade enterprise-operator mongodb/enterprise-operator \ --set <setting_1> --set <setting_2> --set operator.mdbDefaultArchitecture="static"
O Operador Kubernetes atualiza o StatefulSet imagens para sua implementação do MongoDB, fazendo a transição de um único container que anteriormente gerenciava o MongoDB Agent e o banco de dados do MongoDB para uma nova configuração com dois containers separados: um para o MongoDB Agent e outro para o banco de dados do MongoDB. Esta atualização inicia uma reinicialização contínua.
Quando você migra para containers estáticos, as seguintes alterações se aplicam:
Nós do Kubernetes use o registro de container configurado para realizar os downloads.
As versões do agente de monitoramento e do agente de automação estão alinhadas.
O Kubernetes Operator, em vez do agente, lida com as atualizações do MongoDB.
O Kubernetes Operator substitui as imagens existentes, o que causará uma reinicialização contínua.
Verifique se o sistema está sendo executado de forma estática.
Verifique o valor de uma das seguintes variáveis, que você deve ter definido como
static
:MDB_DEFAULT_ARCHITECTURE
Variável para todos os sistemas.metadata.annotations[mongodb.com/v1.architecture]
Variável por sistema.Verifique a implantação do banco de dados para verificar o uso de duas imagens separadas, uma para o agente e outra para o MongoDB, e certifique-se de que nenhum contêiner de inicialização esteja implantado.
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.
Desative os contêineres estáticos.
Selecione a guia apropriada abaixo para desabilitar os contêineres estáticos para todas as suas implantações do MongoDB de uma só vez, incluindo as implantações existentes, ou uma implantação de cada vez.
No arquivo de configuração do Kubernetes Operator , defina MDB_DEFAULT_ARCHITECTURE ou operator.mdbDefaultArchitecture como non-static
.
Na especificação de recursos do MongoDB para uma implantação específica, defina a anotação metadata.annotations.mongodb.com/v1.architecture
como non-static
.
Salve e aplique o arquivo.
Depois de salvar as alterações, aplique novamente sua configuração.
Se você usa o Kubernetes sem OpenShift, execute:
kubectl apply -f <my-config-file>.yaml
Se você usa Kubernetes com OpenShift:
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"
O Operador Kubernetes substitui o StatefulSet imagens de seu sistema do MongoDB e inicia uma reinicialização contínua de todos os Pods em seu sistema.