Explore o novo chatbot do Developer Center! O MongoDB AI chatbot pode ser acessado na parte superior da sua navegação para responder a todas as suas perguntas sobre o MongoDB .

Learn why MongoDB was selected as a leader in the 2024 Gartner® Magic Quadrant™
Desenvolvedor do MongoDB
Central de desenvolvedor do MongoDBchevron-right
Produtoschevron-right
MongoDBchevron-right

Orquestração do MongoDB com o Spring e Atlas Kubernetes Operator

Aasawari Sahasrabuddhe13 min read • Published May 06, 2024 • Updated Jun 12, 2024
AWSMongoDBJava
Ícone do FacebookÍcone do Twitterícone do linkedin
Gráfico de Kubernetes e MongoDB
Avalie esse Artigo
star-empty
star-empty
star-empty
star-empty
star-empty
Neste tutorial, vamos nos aprofundar nos conceitos de conteinerização, com foco no Docker, e explorar a implantação do seu aplicativo Spring Boot a partir de um tutorial anterior. Ao final do tutorial, você entenderá os conceitos do Docker e do Kubernetes e ganhará experiência prática na implantação de seu aplicativo em uma cloud.
Este tutorial é uma extensão do tutorial anterior em que explicamos como escrever consultas de agregação avançadas no MongoDB usando o framework Spring Boot. Usaremos o mesmo repositório GitHub para criar os arquivos de sistema deste tutorial.
Começaremos aprendendo sobre contêineres, como pacotes digitais que contêm software. Em seguida, mergulharemos no Kubernetes, um sistema para gerenciar esses containers. Finalmente, usaremos o Kubernetes para configurar o MongoDB e nosso aplicativo Spring, vendo como eles funcionam juntos.

Pré-requisitos

  1. Um aplicativo Spring Boot em execução em sua máquina local
  2. Serviço Elastic Kubernetes implantado na AWS usando eksctl
  3. Uma conta do MongoDB Atlas

Entendendo a conteinerização

Muitas vezes, como desenvolvedor de software, depara-se com um problema em que os recursos do aplicativo funcionam perfeitamente na máquina local e muitos recursos parecem estar quebrados na máquina cliente. É aqui que entra o conceito de container.
Em palavras simples, um container é apenas um ambiente de computação simples e portátil que contém tudo o que um aplicativo precisa para ser executado. O processo de criação de containers para que o aplicativo seja executado em qualquer ambiente é conhecido como containerização.
A containerização é uma forma de virtualização em que um aplicativo, juntamente com todos os seus componentes, é empacotado em uma única imagem de container. Esses containers operam em seu ambiente isolado dentro do sistema operacional compartilhado, permitindo uma implantação eficiente e consistente em diferentes ambientes.

Benefícios da containerização do aplicativo

  1. Portabilidade: A ideia de "write once and run anywhere" encapsula a essência dos contêineres, permitindo que os aplicativos façam uma transição perfeita entre diversos ambientes, aumentando assim sua portabilidade e flexibilidade.
  2. Eficiência: quando configurados corretamente, os contêineres utilizam os recursos disponíveis e, além disso, os contêineres isolados podem realizar suas operações sem interferir com outros contêineres, permitindo que um único host execute várias funções. Isso faz com que o aplicativo em contêiner funcione de forma eficiente e eficaz.
  3. Melhor segurança: Como os containers são isolados uns dos outros, você pode ter certeza de que seus aplicativos estão sendo executados em um ambiente independente. Isso significa que, mesmo que a segurança de um container seja comprometida, os outros containers no mesmo host permanecerão seguros.

Comparação da containerização e os métodos de virtualização tradicionais

AspectoContainersMáquinas virtuais
Nível de abstraçãoVirtualização no nível do sistema operacionalVirtualização em nível de hardware
Sobrecarga de recursosMínimoMais alto
IsolamentoNível de ProcessoMais forte
PortabilidadeAltamente portátilMenos portátil
Velocidade de implantaçãoRápidoMais lento
Pegada ecológicaLightweightHeavier
Tempo de inicializaçãoQuase instantâneoMais longo
Resource UtilisationEficienteMenos eficiente
EscalabilidadeFacilmente dimensionávelEscalável, mas com sobrecarga de recursos

Entendendo o Docker

O aplicativo Docker fornece a plataforma para desenvolver, enviar e executar contêineres. Isso separa o aplicativo da infraestrutura e o torna portátil. Ele empacota o aplicativo em containeres leves que podem ser executados sem se preocupar com as infraestruturas subjacentes.
Os Docker containers têm sobrecarga mínima em comparação com as máquinas virtuais tradicionais, pois compartilham o kernel do sistema operacional host e incluem apenas as dependências necessárias. O Docker facilita as práticas de DevOps permitindo que os desenvolvedores criem, testem e implementem aplicativos de maneira consistente e automatizada. Você pode ler mais sobre os Docker containers e as etapas para instalá-los em sua máquina local a partir da documentação oficial.

Noções básicas sobre Kubernetes

O Kubernetes, geralmente chamado de K8s, é uma plataforma de orquestração de código aberto que automatiza a implantação, o dimensionamento e o gerenciamento de aplicativos em contêiner. Ele abstrai a complexidade da infraestrutura subjacente, permitindo que os desenvolvedores se concentrem na criação e na execução eficiente de seus aplicativos.
Ele simplifica a implantação e o gerenciamento de aplicativos em contêineres em grande escala. Sua arquitetura, componentes e conceitos básicos formam a base para a construção de sistemas nativos da cloud resilientes, escaláveis e eficientes. As arquiteturas Kubernetes têm sido úteis em casos de uso típicos, como arquitetura de microsserviços, implantações híbridas e multinuvem e DevOps, onde implantações contínuas são feitas.
Vamos entender alguns componentes relacionados ao Kubernetes:
O ambiente do K8funciona na arquitetura do nó controlador-trabalhador e, portanto, dois nós gerenciam a comunicação. O Nó Mestre é responsável por controlar o cluster e tomar decisões para o cluster, enquanto o (s) nó(s) de Trabalho é(são) responsável(is) por executar o aplicativo, receber instruções do Nó Mestre e recorrer ao status.
Os outros componentes do cluster Kubernetes são:
Pods: o bloco de construção básico do Kubernetes, representando um ou mais containers distribuídos juntos no mesmo host
ReplicaSets: garante que um número especificado de réplicas de pod esteja em execução a qualquer momento, permitindo o dimensionamento e a autocorreção
Serviços: forneça rede e balanceamento de carga para pods, permitindo a comunicação entre diferentes partes do aplicativo
Volumes: persista os dados no Kubernetes, permitindo que os containers compartilhem e armazenem dados independentemente do ciclo de vida do container
Namespaces: Clusters virtuais dentro de um cluster físico, permitindo que vários usuários, equipes ou projetos compartilhem um cluster Kubernetes com segurança
Os diagramas abaixo fornecem uma descrição detalhada da arquitetura do Kubernetes.
Arquitetura do Kubernetes
Imagem descrevendo a arquitetura do Kubernetes da fonte: https://kubernetes.io/docs/concepts/overview/components/

Atlas Kubernetes Operator

Considere um caso de uso em que um aplicativo Spring executado localmente está conectado a um banco de dados implantado no Atlas cluster. Posteriormente, sua organização apresenta o ambiente do Kubernetes e planeja implantar todos os aplicativos na infraestrutura de nuvem.
A questão de como você conectará seu aplicativo do Kubernetes ao agrupamento do Atlas executando em um ambiente diferente surgirá. É quando o Atlas Kubernetes Operator entra em ação.
Este operador permite a você gerenciar os recursos do Atlas na infraestrutura do Kubernetes.
Para este tutorial, implantaremos o operador no Elastic Kubernetes Service na infraestrutura do AWS.
Etapa 1: implemente um cluster EKS usando eksctl. Siga a documentação, Introdução ao Amazon EKS - eksctl, para implementar o cluster. Esta etapa levará algum tempo para implantar o cluster no AWS.
Criei o cluster usando o comando:
1eksctl create cluster \
2--name MongoDB-Atlas-Kubernetes-Operator \
3--version 1.29 \
4--region ap-south-1 \
5--nodegroup-name linux-nodes \
6--node-type t2.2xlarge \
7--nodes 2
Etapa 2: Após a implantação do cluster EKS, execute o comando:
1kubectl get ns
E você deverá ver uma saída semelhante a esta.
1NAME STATUS AGE
2default Active 18h
3kube-node-lease Active 18h
4kube-public Active 18h
5kube-system Active 18h
Etapa 4: Conforme o tutorial deinício rápido mencionado, você precisa da chave de API para o projeto em seu Atlas cluster. Você pode seguir a página dedocumentação se ainda não tiver uma chave de API.
Etapa 5: todos os arquivos que estão sendo discutidos nas subetapas a seguir estão disponíveis no repositório do GitHub.
Se você estiver seguindo os tutoriais acima, o primeiro passo é criar as chaves de API. Você precisa garantir que, ao criar a chave de API para o projeto, adicione os IPs públicos das instâncias EC2 criadas usando o comando na Etapa 1 à lista de acesso.
É assim que a lista de acesso deve ficar:
UI do Atlas representando a adição de endereços IP da EC2
UI do Atlas representando a adição de endereços IP da EC2
Imagem mostrando a adição do endereço IPs públicos à lista de acesso da chave de API.
A primeira etapa mencionada na documentação do Atlas Kubernetes Operator é aplicar todas as configurações de arquivo YAML a todos os namespaces criados no ambiente do Kubernetes. Antes de aplicar os arquivos YAML, certifique-se de exportar as variáveis abaixo usando:
1export VERSION=v2.2.0
2export ORG_ID=<your-organisations-id>
3export PUBLIC_API_KEY=<your-public-key>
4export PRIVATE_API_KEY=<your-private-key>
Em seguida, aplique o comando abaixo:
1kubectl apply -f https://raw.githubusercontent.com/mongodb/mongodb-atlas-kubernetes/$VERSION/deploy/all-in-one.yaml
Para permitir que o Kubernetes Operator crie o projeto no Atlas, você deve ter determinadas permissões usando a chave de API no nível organizacional na UI do Atlas.
Você pode criar a chave de API usando a documentação daAPI de Introdução à administração do Atlas.
Após a criação da chave API, crie o segredo com as credenciais usando o comando abaixo:
1kubectl create secret generic mongodb-atlas-operator-api-key \
2 --from-literal="orgId=$ORG_ID" \
3 --from-literal="publicApiKey=$PUBLIC_API_KEY" \
4 --from-literal="privateApiKey=$PRIVATE_API_KEY" \
5 -n mongodb-atlas-system
Identifique os segredos criados usando o comando abaixo:
1kubectl label secret mongodb-atlas-operator-api-key atlas.mongodb.com/type=credentials -n mongodb-atlas-system
A próxima etapa é criar o arquivo YAML para criar o projeto e a implantação usando os arquivos YAML de projeto e implantação, respectivamente.
Certifique-se de que os arquivos de implantação mencionem a zona, a instância e a região corretamente.
Os arquivos estão disponíveis no repositório Git na pastaatlas-kubernetes-operator.
No arquivoproject.yamlinicial, o conteúdo especificado inicia a criação de um projeto dentro de sua implantação do Atlas, nomeando-o conforme indicado. Com a configuração YAML fornecida, um projeto chamado "atlas-kubernetes-operator" é estabelecido, permitindo o acesso de todos os endereços IP (0.0.0.0/0) dentro da lista de acesso .
project.yaml:
1apiVersion: atlas.mongodb.com/v1
2kind: AtlasProject
3metadata:
4 name: project-ako
5spec:
6 name: atlas-kubernetes-operator
7 projectIpAccessList:
8 - cidrBlock: "0.0.0.0/0"
9 comment: "Allowing access to database from everywhere (only for Demo!)"
Observe que 0.0.0.0 não é recomendado no ambiente de produção. Isso é apenas para fins de teste.
O próximo arquivo chamadodeployment.yaml criaria uma nova implantação no projeto criado acima com o nome especificado como cluster0. O YAML também especifica o tipo de instância como M10 na região AP_SOUTH_1 . Certifique-se de usar a região perto de você.
deployment.yaml:
1apiVersion: atlas.mongodb.com/v1
2kind: AtlasDeployment
3metadata:
4 name: my-atlas-cluster
5spec:
6 projectRef:
7 name: project-ako
8 deploymentSpec:
9 clusterType: REPLICASET
10 name: "cluster0"
11 replicationSpecs:
12 - zoneName: AP-Zone
13 regionConfigs:
14 - electableSpecs:
15 instanceSize: M10
16 nodeCount: 3
17 providerName: AWS
18 regionName: AP_SOUTH_1
19 priority: 7
O arquivouser.yaml criará o usuário para seu projeto. Antes de criar o arquivo YAML do usuário, crie o segredo com a senha de sua escolha para o projeto.
1kubectl create secret generic the-user-password --from-literal="password=<password for your user>"
2kubectl label secret the-user-password atlas.mongodb.com/type=credentials
user.yaml
1apiVersion: atlas.mongodb.com/v1
2kind: AtlasDatabaseUser
3metadata:
4 name: my-database-user
5spec:
6 roles:
7 - roleName: "readWriteAnyDatabase"
8 databaseName: "admin"
9 projectRef:
10 name: project-ako
11 username: theuser
12 passwordSecretRef:
13 name: the-user-password
Depois que todos os YAML forem criados, aplique esses arquivos YAML ao namespace padrão.
1kubectl apply -f project.yaml
2kubectl apply -f deployment.yaml
3kubectl apply -f user.yaml
Após esta etapa, você poderá visualizar a implantação e o usuário criado para o projeto em seu cluster do Atlas.

Implantando o aplicativo Spring Boot no cluster

Neste tutorial, desenvolveremos nosso guia existente encontrado no Developer Center, noMongoDB Advanced Aggregations with Spring Boot e no Amazon Corretho.
Utilizaremos o mesmo repositório do GitHub para criar um DockerFile. Se você é novo nisso, é altamente recomendável seguir o tutorial antes de mergulhar na containerização do aplicativo.
Há determinadas etapas a serem seguidas para a containerização do aplicativo.
Etapa 1: crie um arquivo JAR para o aplicativo. Este JAR executável será necessário para criar a imagem do Docker.
Para criar o JAR, faça:
1mvn clean package
e o jar seria armazenado na pasta target/.
Etapa 2: A segunda etapa é criar o Dockerfile para o aplicativo. Um Dockerfile é um arquivo de texto que contém as informações para criar a imagem Docker do aplicativo.
Crie um arquivo denominado Dockerfile com o seguinte conteúdo: Este arquivo descreve o que será executado neste container.
Etapa 3: Construa a imagem do Docker. O comandodocker build lerá as especificações do Dockerfile criado acima.
1 docker build -t mongodb_spring_tutorial:docker_image . –load
Etapa 4: depois que a imagem for criada, você precisará enviá-la para um registro. Neste exemplo, estamos usando o Docker Hub. Você pode criar sua conta seguindo a documentação.
1docker tag mongodb_spring_tutorial:docker_image <your_docker_username>/mongodb_spring_tutorial
2docker push <your_docker_username>/mongodb_spring_tutorial
Depois que a imagem do Docker for enviada para o repositório, a última etapa é conectar seu aplicativo ao banco de dados em execução no Atlas Kubernetes Operator.

Conectar a aplicação com o Atlas Kubernetes Operator

Para fazer a conexão, precisamos dos arquivos deSistema e Serviço . Enquanto os sistemas gerenciam o ciclo de vida dos Pods, garantindo um estado desejado, os Serviços fornecem uma maneira de outros componentes acessarem e se comunicarem com esses Pods. Juntos, eles formam a base para gerenciar e implantar aplicativos no Kubernetes.
Uma implantação no Kubernetes é um objeto de recurso que define o estado desejado para seu aplicativo. Ele permite gerenciar declarativamente um conjunto de pods idênticos. Essecialmente, ele garante que um número especificado de réplicas de pod esteja em execução a qualquer momento.
Um arquivo de implantação terá as seguintes informações. No arquivo app-deployment.yaml acima, os seguintes detalhes são mencionados:
  1. apiVersion: especifica a versão da API Kubernetes
  2. kind: especifica que é um tipo de recurso Kubernetes, Deployment
  3. metadados: contém metadados sobre a implantação, incluindo seu nome
Na seção de especificações:
As réplicas especificam o número de instâncias do aplicativo. O nome e a imagem referem-se à imagem do aplicativo criada na etapa acima e ao nome do container que executaria a imagem.
Na última seção, especificaremos a variável de ambiente para SPRING_DATA_MONGODB_URI que selecionará o valor da connectionStringStandardSrv do Atlas Kubernetes Operator.
Crie o arquivo deployment.yaml:
1apiVersion: apps/v1
2kind: Deployment
3metadata:
4 name: spring-app
5spec:
6 replicas: 1
7 selector:
8 matchLabels:
9 app: springboot-application
10 template:
11 metadata:
12 labels:
13 app: springboot-application
14 spec:
15 containers:
16 - name: spring-app
17 image: <your_docker_username>/mongodb_spring_tutorial
18 ports:
19 - containerPort: 8080
20 env:
21 - name: SPRING_DATA_MONGODB_URI
22 valueFrom:
23 secretKeyRef:
24 name: atlas-kubernetes-operator-cluster0-theuser
25 key: connectionStringStandardSrv
26 - name: SPRING_DATA_MONGODB_DATABASE
27 value: sample_supplies
28 - name: LOGGING_LEVEL_ORG_SPRINGFRAMEWORK
29 value: INFO
30 - name: LOGGING_LEVEL_ORG_SPRINGFRAMEWORK_WEB
31 value: DEBUG
Um serviço no Kubernetes é uma abstração que define um conjunto lógico de pods e uma política pela qual acessá-los. Ele permite que outros componentes dentro ou fora do cluster do Kubernetes se comuniquem com seu aplicativo em execução nos pods.
1apiVersion: v1
2kind: Service
3metadata:
4 name: spring-app-service
5spec:
6 selector:
7 app: spring-app
8 ports:
9 - protocol: TCP
10 port: 8080
11 targetPort: 8080
12 type: LoadBalancer
Em seguida, você pode aplicar esses dois arquivos ao seu cluster, e o Kubernetes criará todos os Pods e iniciará o aplicativo.
1kubectl apply -f ./*.yaml
Agora, quando você fizer...
1kubectl get svc
... ele lhe fornecerá a saída conforme abaixo com um link IP externo criado. Este link será utilizado com a porta padrão para acessar as chamadas RESTful.
Em um cenário ideal, o arquivo de serviço é aplicado com o tipo: ClusterIP mas, como precisamos testar o aplicativo com as chamadas de API, especificaremos o tipo como LoadBalancer.
Você pode usar o IP externo alocado com porta 8080 e testar as APIs.
Ou use o comando a seguir para armazenar o endereço externo na variávelEXTERNAL_IP .
1EXTERNAL_IP=$(kubectl get svc|grep spring-app-service|awk '{print $4}')
2
3echo $EXTERNAL_IP
Ele deve lhe dar a resposta como
1a4874d92d36fe4d2cab1ccc679b5fca7-1654035108.ap-south-1.elb.amazonaws.com
Por enquanto, você já deve ser capaz de distribuir o Atlas no ambiente Kubernetes e se conectar aos aplicativos de front-end e back-end implementados no mesmo ambiente.
Vamos testar algumas APIs REST usando o IP externo criado na próxima seção.

Testes

Agora que seu aplicativo está distribuído, em execução no Kubernetes e exposto ao mundo externo, você pode testá-lo com os comandos curl a seguir.
  1. Encontrando vendas em Londres
  2. Encontrando o total de vendas:
  3. Encontrando a quantidade total de cada item
Ao concluir nossa análise da containerização em aplicativos Spring, estamos prontos para nos afundar na solução de problemas do Kubernetes e do Docker. Vamos passar para a próxima seção à medida que descobrimos desafios comuns e soluções eficazes para uma experiência de implantação mais tranquila.

Erros comuns de solução de problemas no Kubernetes

Em um ambiente em contêineres, o caminho para uma implantação bem-sucedida pode, às vezes, envolver vários fatores. Para navegar por quaisquer soluços ao longo do caminho, é aconselhável recorrer a certos comandos para obter insights:
  • Examine o status do pod:
1kubectl describe pods <pod-name> -n <namespace>
2
3kubectl get pods -n <namespace>
  • Verificar o status do nó:
1kubectl get nodes
  • Mergulhe nos logs do pod:
1kubectl get logs -f <pod-name> -n <namespace>
  • Explore os detalhes do serviço:
1kubectl get describe svc <service-name> -n <namespace>
Durante a solução de problemas, encontrar erros não é incomum. Aqui estão alguns exemplos em que você pode buscar informações adicionais:
  1. Imagem não encontrada: Esse erro ocorre quando se tenta executar um contêiner com uma imagem que não pode ser localizada. Normalmente, isso acontece se a imagem não tiver sido extraída com êxito ou não estiver disponível no registro do Docker especificado. É fundamental garantir que o nome e a tag corretos da imagem sejam usados e, se necessário, tente extrair a imagem do registro localmente antes de executar o contêiner para garantir que ela esteja lá.
  2. Permissão negada: Os contêineres do Docker geralmente operam com privilégios restritos, especialmente para fins de segurança. Se o seu aplicativo exigir acesso a recursos ou diretórios específicos dentro do contêiner, é essencial definir as permissões de arquivo apropriadas e configurar as definições de usuário/grupo de acordo. Não fazer isso pode resultar em erros de permissão negada ao tentar acessar esses recursos.
  3. Conflitos de portas Vários contêineres no mesmo computador host, cada um tentando usar a mesma porta do host, podem levar a conflitos de portas. Esse problema ocorre quando as portas especificadas no comandodocker runse sobrepõem às portas já em uso por outros contêineres ou serviços no host. Para evitar conflitos, certifique-se de que as portas atribuídas a cada contêiner sejam exclusivas e não estejam ocupadas por outros processos.
  4. Sem espaço em disco: o Docker depende do espaço em disco para armazenar imagens, containers e arquivos de log. Com o tempo, esses arquivos podem acumular e consumir uma quantidade significativa de espaço em disco, potencialmente levando ao esgotamento do espaço em disco. Para evitar isso, é aconselhável limpar periodicamente imagens e containers não utilizados usando o comandodocker system prune, que remove imagens pendentes, containers não utilizados e outros artefatos que consomem espaço em disco.
  5. Falhas de contêiner: os contêineres podem travar devido a vários motivos, incluindo configurações incorretas, erros de aplicativo ou restrições de recursos. Quando um contêiner falha, é essencial examinar seus logs usando o comandokubectl logs -f <pod-name> -n <namespace> . Esses logs geralmente contêm mensagens de erro valiosas e informações de diagnóstico que podem ajudar a identificar a causa subjacente da falha e facilitar a solução de problemas.
  6. Falhas de compilação do Docker: a criação de imagens do Docker pode falhar devido a vários motivos, como erros de sintaxe no Dockerfile, arquivos ou dependências ausentes ou problemas de rede durante downloads de pacotes. É essencial examinar cuidadosamente o Dockerfile em busca de erros de sintaxe, garantir que todos os arquivos e dependências necessários estejam presentes e solucionar quaisquer problemas de conectividade de rede que possam surgir durante o processo de compilação.
  7. Problemas de rede: Os contêineres do Docker podem depender da conectividade de rede para se comunicar com outros contêineres ou serviços externos. Problemas de rede, como configuração incorreta da rede, regras de firewall que bloqueiam as portas necessárias ou configurações incorretas de DNS, podem causar problemas de conectividade. É fundamental verificar se o contêiner está conectado à rede correta, revisar as configurações de firewall para garantir que elas permitam o tráfego necessário e confirmar se as configurações de DNS estão configuradas corretamente.
  8. Restrições de recursos: os contêineres do Docker podem exigir recursos específicos de CPU e memória para funcionar corretamente. A falha na alocação de recursos adequados pode resultar em problemas de desempenho ou falhas no aplicativo. Ao executar contêineres, é essencial especificar limites de recursos usando os sinalizadores e --cpu --memory para garantir que os contêineres tenham recursos suficientes para operar com eficiência sem sobrecarregar o sistema host .
Você pode especificar na seção de recursos do arquivo YAML como:
1docker_container:
2 name: my_container
3 resources:
4 cpu: 2
5 memory: 4G

Conclusão

Ao longo deste tutorial, abordamos aspectos essenciais do sistema de aplicativos moderno, com foco em containerização, orquestração do Kubernetes e gerenciamento do MongoDB com o Atlas Kubernetes Operator. Começando com os fundamentos da containerização e do Docker, passamos a entender o papel do Kubernetes na automatização da implantação e do gerenciamento de aplicativos. Ao implantar o Atlas Operator no EKS da AWS, integramos perfeitamente o MongoDB à nossa infraestrutura do Kubernetes. Além disso, containerizamos um aplicativo Spring Boot, conectando-o ao Atlas para gerenciamento de banco de dados. Por fim, abordamos cenários comuns de solução de problemas do Kubernetes, fornecendo as habilidades necessárias para enfrentar os desafios em ambientes nativos da nuvem. Com esse conhecimento, você está bem preparado para arquitetar e gerenciar aplicativos nativos de nuvem sofisticados de forma eficaz.
Para saber mais, visite o recursoO que é orquestração de contêineres? e entre em contato com qualquer dúvida específica.
À medida que você se aprofunde na pesquisa e implementação desses conceitos em seus projetos, recomendamos que se envolva ativamente na MongoDB Community. Certifique-se de aproveitar a variedade de recursos disponíveis no MongoDB Developer Center e documentação para aprimorar sua proficiência e aprimorar suas capacidades ao aproveitar o poder do MongoDB e seus recursos.
Principais comentários nos fóruns
Ainda não há comentários sobre este artigo.
Iniciar a conversa

Ícone do FacebookÍcone do Twitterícone do linkedin
Avalie esse Artigo
star-empty
star-empty
star-empty
star-empty
star-empty
Relacionado
Artigo

Validação de documentos para coleções polimórficas


Oct 01, 2024 | 6 min read
Artigo

Melhorar o desempenho de armazenamento e leitura gratuitamente: esquemas planos versus esquemas estruturados


Jan 26, 2024 | 5 min read
Tutorial

Peculiaridades de índices exclusivos e documentos exclusivos em uma array de documentos


Oct 04, 2023 | 7 min read
Notícias e Anúncios

MongoDB Academia - Introdução a bancos de dados modernos


Sep 23, 2022 | 4 min read
Sumário