1. Introdução
Por que migrar de um aplicativo monolítico para uma arquitetura de microsserviços? Desmembrar um aplicativo em microsserviços tem as seguintes vantagens, sendo que a maioria deriva do fato de que os microsserviços são acoplados com flexibilidade:
- É possível testar e implantar os microsserviços de maneira independente. Quanto menor for a unidade a ser implantada, mais fácil será o processo.
- Os microsserviços podem ser implementados em linguagens e frameworks diferentes. Você tem liberdade para escolher a tecnologia mais adequada ao caso de uso de cada microsserviço.
- Os microsserviços podem ser gerenciados por equipes diferentes. Como os microsserviços têm limites bem definidos, fica fácil atribuir um ou vários deles a uma equipe.
- Ao migrar para os microsserviços, você reduz a dependência entre as equipes. Cada equipe passa a se preocupar apenas com as APIs dos microsserviços que deve gerenciar. Elas não precisam pensar sobre como os microsserviços são implementados, os ciclos de lançamento e outros fatores.
- É mais fácil se preparar para falhas. Como o limite entre os serviços é claro, fica mais fácil determinar o que fazer se um deles falhar.
Veja algumas desvantagens em comparação com um site monolítico:
- Como um app baseado em microsserviços é uma rede de serviços diferentes que geralmente interagem de maneiras que não são óbvias, a complexidade do sistema tende a aumentar.
- Ao contrário dos componentes internos de um aplicativo monolítico, os microsserviços se comunicam por uma rede. Em algumas circunstâncias, isso pode ser visto como um risco para a segurança. O Istio soluciona esse problema ao criptografar automaticamente o tráfego entre os microsserviços.
- Pode ser difícil ter o mesmo desempenho de uma abordagem monolítica devido às latências entre os serviços.
- O comportamento do sistema não é definido por um único serviço, mas por muitos e pelas interações entre eles. Por isso, entender como o sistema se comporta na produção (observabilidade) é mais difícil. O Istio também é uma solução para esse problema.
Neste laboratório, vamos executar microsserviços no Google Kubernetes Engine (GKE). O Kubernetes é uma plataforma para gerenciar, hospedar, escalonar e implantar contêineres. Os contêineres são uma maneira portátil de empacotar e executar um código. Eles são ideais para o padrão de microsserviços, em que cada microsserviço pode ser executado em um contêiner próprio.
Neste laboratório, vamos implantar um aplicativo monolítico existente em um cluster do Google Kubernetes Engine e dividi-lo em microsserviços.
Diagrama da arquitetura dos microsserviços
Vamos começar dividindo o aplicativo monolítico em três microsserviços, um de cada vez. Os microsserviços são: Orders, Products e Frontend. Criamos uma imagem Docker para cada microsserviço usando o Cloud Build, que é acionado no Cloud Shell. Em seguida, vamos implantar e expor nossos microsserviços no Google Kubernetes Engine (GKE) com um serviço do tipo LoadBalancer do Kubernetes. Vamos fazer isso para cada serviço enquanto eles são refatorados simultaneamente no aplicativo monolítico. Durante o processo, o aplicativo monolítico e os microsserviços vão funcionar em paralelo até o fim, quando será possível excluir o aplicativo.
O que você aprenderá
- Como dividir um aplicativo monolítico em microsserviços
- Como criar um cluster do Google Kubernetes Engine
- Como criar uma imagem Docker
- Como implantar imagens do Docker no Kubernetes
Pré-requisitos
- Uma conta do Google Cloud Platform com acesso administrativo para criar projetos ou um projeto com o papel "Proprietário do projeto"
- Noções básicas do Docker e do Kubernetes
2. Configuração do ambiente
Configuração de ambiente personalizada
Se você ainda não tem uma Conta do Google (Gmail ou Google Apps), crie uma. Faça login no Console do Google Cloud Platform ( console.cloud.google.com) e crie um projeto:
Lembre-se do código do projeto, um nome exclusivo em todos os projetos do Google Cloud. O nome acima já foi escolhido e não servirá para você. Faremos referência a ele mais adiante neste codelab como PROJECT_ID.
Em seguida, será preciso ativar o faturamento no Developers Console para usar os recursos do Google Cloud e ativar a API Container Engine.
A execução por meio deste codelab terá um custo baixo, mas poderá ser mais se você decidir usar mais recursos ou se deixá-los em execução. Consulte a seção "limpeza" no final deste documento. Os preços do Google Kubernetes Engine estão documentados aqui.
Novos usuários do Google Cloud Platform estão qualificados para uma avaliação sem custo financeiro de US$300.
Google Cloud Shell
Embora o Google Cloud e o Kubernetes possam ser operados remotamente em um laptop, neste codelab vamos usar o Google Cloud Shell, um ambiente de linha de comando que é executado no Cloud.
O Cloud Shell é uma máquina virtual com base em Debian que contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Isso significa que tudo que você precisa para este codelab é um navegador (sim, funciona em um Chromebook).
- Para ativar o Cloud Shell no Console do Cloud, basta clicar em Ativar o Cloud Shell
. Leva apenas alguns instantes para provisionar e se conectar ao ambiente.
Depois de se conectar ao Cloud Shell, você já estará autenticado e o projeto estará configurado com seu PROJECT_ID.
gcloud auth list
Resposta ao comando
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
Resposta ao comando
[core] project = <PROJECT_ID>
Se, por algum motivo, o projeto não estiver definido, basta emitir o seguinte comando:
gcloud config set project <PROJECT_ID>
Quer encontrar seu PROJECT_ID? Veja qual ID você usou nas etapas de configuração ou procure-o no painel do Console do Cloud:
O Cloud Shell também define algumas variáveis de ambiente por padrão, o que pode ser útil ao executar comandos futuros.
echo $GOOGLE_CLOUD_PROJECT
Resposta ao comando
<PROJECT_ID>
- Defina a zona padrão e a configuração do projeto:
gcloud config set compute/zone us-central1-f
É possível escolher uma variedade de zonas diferentes. Para mais informações, consulte Regiões e zonas.
3. Clone o repositório de origem
Usamos um aplicativo monolítico pronto de um site fictício de e-commerce que inclui três páginas: uma simples de boas-vindas, uma de produtos e outra com o histórico dos pedidos. Clone a origem do repositório do Git para poder dividir o aplicativo em microsserviços e implantá-lo no Google Kubernetes Engine (GKE).
Execute os comandos a seguir para clonar o repositório do Git na sua instância do Cloud Shell. Depois acesse o diretório correto. Também vamos instalar as dependências do NodeJS para testar o aplicativo monolítico antes da implantação. Pode levar alguns minutos para o script ser executado.
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh
Isso vai clonar nosso repositório do GitHub, mudar para o diretório e instalar as dependências necessárias para executar o aplicativo localmente. Pode levar alguns minutos para o script ser executado.
4. Crie um cluster do GKE
Agora que seu ambiente para desenvolvedores está funcionando, você precisa de um cluster do Kubernetes para implantar o monolítico e depois os microsserviços. Antes de criar um cluster, precisamos verificar se as APIs corretas estão ativadas. Execute o comando a seguir para ativar a API Containers e usar o Google Kubernetes Engine:
gcloud services enable container.googleapis.com
Agora podemos criar nosso cluster. Execute o comando abaixo para criar um cluster do GKE chamado fancy-cluster com 3 nós.
gcloud container clusters create fancy-cluster --num-nodes 3
A criação do cluster pode levar vários minutos. Depois disso, execute este comando para conferir as três instâncias da VM de worker do cluster:
gcloud compute instances list
Saída:
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS gke-fancy-cluster-default-pool-ad92506d-1ng3 us-east4-a n1-standard-1 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq us-east4-a n1-standard-1 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 us-east4-a n1-standard-1 10.150.0.6 XX.XX.XX.XX RUNNING
Também é possível conferir o cluster do Kubernetes e as informações relacionadas no console do Google Cloud. Clique no botão de menu no canto superior esquerdo, role para baixo até "Kubernetes Engine" e clique em "Clusters". O cluster chamado fancy-cluster deve aparecer aqui.
Parabéns! Você acabou de criar seu primeiro cluster do Kubernetes.
5. Implante um aplicativo monolítico pronto
Como o foco deste laboratório é detalhar a divisão de um monolito em microsserviços, precisamos instalar e executar um aplicativo monolítico. Execute o script a seguir para implantar um aplicativo monolítico no cluster do GKE para fins deste laboratório:
cd ~/monolith-to-microservices ./deploy-monolith.sh
Como acessar o aplicativo monolítico
Para encontrar o endereço IP externo do aplicativo monolítico, execute o seguinte comando:
kubectl get service monolith
A resposta será semelhante a esta:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE monolith 10.3.251.122 203.0.113.0 80:30877/TCP 3d
OBSERVAÇÃO: um balanceador de carga e um IP externos precisam ser provisionados para isso, o que leva algum tempo. Se a saída listar o IP externo como
<pending> Aguarde alguns minutos e tente de novo.
Copie o endereço IP externo do aplicativo monolítico depois que ele aparecer. Cole o URL do IP externo (por exemplo, http://203.0.113.0) no navegador para verificar se o aplicativo monolítico está acessível.
Você verá a página inicial do site monolítico, como mostra a imagem acima. A página inicial é estática e será apresentada pelo microsserviço Frontend depois. Agora seu aplicativo monolítico está sendo executado integralmente no Kubernetes.
6. Migrar pedidos para microsserviços
Agora que o site monolítico está em execução no GKE, podemos começar a dividir cada serviço em um microsserviço. O planejamento precisa considerar quais serviços serão divididos em blocos menores, geralmente de acordo com partes específicas do aplicativo, como o domínio comercial. Para fins de demonstração, criamos um exemplo trivial e dividimos cada serviço de acordo com o domínio comercial: Orders, Products e Frontend. O código já foi migrado, e vamos nos concentrar na criação e implantação dos serviços no Google Kubernetes Engine (GKE).
Criar o microsserviço Orders
O primeiro serviço que vamos dividir é o serviço de pedidos. Vamos usar a base de código fornecida e criar um contêiner do Docker separado para esse serviço.
Criar um contêiner do Docker com o Google Cloud Build
Como já migramos a base de código para você, a primeira etapa é criar um contêiner do Docker para o serviço Orders usando o Google Cloud Build.
O método mais comum seria criar um contêiner do Docker e enviá-lo para um registro, onde a imagem é armazenada e pode ser extraída pelo GKE. Mas podemos facilitar as coisas. Use o Google Cloud Build para criar o contêiner do Docker e coloque a imagem no Container Registry com um único comando. Isso permite emitir um único comando para criar e mover a imagem para o Container Registry. Para ver o processo manual de criação e envio de um arquivo do Docker, clique aqui.
O Google Cloud Build compacta e envia os arquivos do diretório para um bucket do Google Cloud Storage. Todos os arquivos do bucket e o Dockerfile no mesmo diretório serão usados para executar o processo de build no Docker. Como especificamos a flag --tag com o host como gcr.io para a imagem Docker, a imagem Docker resultante será enviada por push para o Google Cloud Container Registry.
Crie e envie seu contêiner do Docker para o Google Container Registry executando estes comandos:
cd ~/monolith-to-microservices/microservices/src/orders
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .
Esse processo leva alguns minutos. Quando a compilação estiver pronta, o terminal mostrará o seguinte:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://<PROJECT_ID>_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io/<PROJECT_ID>/orders:1.0.0 SUCCESS
Para acessar o histórico de builds ou acompanhar o processo em tempo real, acesse o console do Google Cloud. Clique no botão de menu no canto superior esquerdo e role para baixo até Ferramentas → Cloud Build e clique em Histórico. Essa tela apresenta uma lista dos builds anteriores. Por enquanto, haverá apenas um (o que você acabou de criar).
Se clicar no ID do build, você verá todos os detalhes do build, inclusive a resposta do registro.
Na página de detalhes do build, clique no nome da imagem na seção de informações do build para visualizar a imagem do contêiner criada.
Implante o contêiner no GKE
Agora que já fizemos a conteinerização do site e enviamos o contêiner para o Google Container Registry, é hora de fazer a implantação no Kubernetes.
O Kubernetes representa aplicativos como pods, que são unidades com um contêiner ou um grupo de contêineres estreitamente associados. O pod é a menor unidade implantável no Kubernetes. Neste tutorial, cada pod contém apenas o contêiner do seu microsserviço.
Para implantar e gerenciar aplicativos em um cluster do GKE, você precisa se comunicar com o sistema de gerenciamento de clusters do Kubernetes. A forma mais comum de fazer isso é usar a ferramenta de linha de comando kubectl no Cloud Shell.
Primeiro, vamos criar um recurso Deployment. Esse recurso gerencia diversas cópias do aplicativo, chamadas de réplicas. Ele programa as réplicas para serem executadas em nós individuais do cluster. Neste caso, a implantação vai executar apenas um pod do seu aplicativo. Para isso, o recurso de implantação cria um ReplicaSet. O ReplicaSet é responsável por garantir que as réplicas especificadas estejam sempre em execução.
O comando kubectl create deployment abaixo faz com que o Kubernetes crie uma implantação chamada orders no cluster com 1 réplica.
Execute o comando abaixo para implantar seu aplicativo:
kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0
Verifique a implantação
Para verificar se a implantação foi criada, execute o seguinte comando. Pode levar alguns instantes para que o status do pod seja "Em execução":
kubectl get all
Saída:
NAME READY STATUS RESTARTS AGE pod/monolith-779c8d95f5-dxnzl 1/1 Running 0 15h pod/orders-5bc6969d76-kdxkk 1/1 Running 0 21s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 19d service/monolith LoadBalancer 10.39.241.130 34.74.209.57 80:30412/TCP 15h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/monolith 1/1 1 1 15h deployment.apps/orders 1/1 1 1 21s NAME DESIRED CURRENT READY AGE replicaset.apps/monolith-779c8d95f5 1 1 1 15h replicaset.apps/orders-5bc6969d76 1 1 1 21s
Essa saída mostra várias informações. É possível conferir a implantação atual, o ReplicaSet com a contagem desejada de apenas um pod e o pod em execução. Parece que tudo foi criado corretamente.
Exponha o contêiner do GKE:
Você implantou o aplicativo no GKE, mas não é possível acessá-lo de fora do cluster. Por padrão, os contêineres executados no GKE não podem ser acessados pela Internet porque não têm endereços IP externos. Exponha explicitamente o aplicativo ao tráfego da Internet usando o recurso Serviço. Esse serviço dá suporte de rede e IP aos pods do seu aplicativo. O GKE cria um IP externo e um balanceador de carga, sujeito a faturamento, para seu aplicativo.
Quando implantamos o serviço Orders, ele foi exposto internamente na porta 8081 por uma implantação do Kubernetes. Para expor esse serviço externamente, é preciso criar um serviço do Kubernetes do tipo LoadBalancer que encaminha o tráfego da porta 80 externamente para a porta interna 8081 do serviço Orders. Execute o seguinte comando para expor o site à Internet:
kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081
Como acessar o serviço
O GKE atribui o endereço IP externo ao recurso de serviço, não à implantação. Se você quiser descobrir o IP externo provisionado pelo GKE para seu aplicativo, inspecione o Serviço com o comando kubectl get service:
kubectl get service orders
Saída:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE orders 10.3.251.122 203.0.113.0 80:30877/TCP 3d
Copie o endereço IP externo do aplicativo depois que ele aparecer. Você vai precisar dele na próxima etapa, quando alterar seu monolítico para apontar para o novo serviço Orders.
Reconfigure o aplicativo monolítico
Como removemos o serviço Orders do monolítico, precisamos modificar esse aplicativo para apontar para o novo microsserviço Orders externo.
Ao dividir um aplicativo monolítico, removemos partes do código de uma única base de código para criar vários microsserviços que implantaremos separadamente. Como o microsserviço está sendo executado em outro servidor, não é mais possível usar os URLs de serviço como caminhos absolutos. É preciso direcionar para o novo endereço do servidor do microsserviço Order. O aplicativo monolítico ficará inativo enquanto atualiza o URL de cada serviço que foi dividido. Leve isso em conta ao planejar a mudança dos microsserviços e do aplicativo monolítico para produção, durante o processo de migração dos microsserviços.
Precisamos atualizar o arquivo de configuração no aplicativo monolítico para apontar para o endereço IP do novo microsserviço Orders. Use o editor nano para substituir o URL local pelo endereço IP do novo microsserviço Orders. Execute o comando a seguir para editar o
cd ~/monolith-to-microservices/react-app nano .env.monolith
Quando o editor é aberto, aparece um arquivo semelhante a este:
REACT_APP_ORDERS_URL=/service/orders REACT_APP_PRODUCTS_URL=/service/products
Substitua REACT_APP_ORDERS_URL pelo novo formato, mudando o endereço IP do microsserviço Orders para corresponder a:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
Pressione CTRL+O, ENTER e CTRL+X para salvar o arquivo no editor nano.
Para testar o novo microsserviço, acesse o URL que você configurou no arquivo. A página da Web precisa retornar uma resposta JSON do nosso microsserviço Orders.
Em seguida, vamos precisar recriar o front-end do aplicativo monolítico e repetir o processo de build para criar o contêiner do monolítico e reimplantá-lo no cluster do GKE. Execute os seguintes comandos para concluir as etapas abaixo.
Recrie os arquivos de configuração do aplicativo monolítico
npm run build:monolith
Criar um contêiner do Docker com o Google Cloud Build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
Implante o contêiner no GKE
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
Para verificar se o aplicativo está acessando o novo microsserviço Orders, visite a página Orders do aplicativo monolítico pelo navegador. Todos os IDs de pedidos devem terminar com o sufixo -MICROSERVICE, como na imagem abaixo:
7. Migre Products para um microsserviço
Criar o microsserviço Products
Podemos continuar dividindo nossos serviços migrando o serviço de produtos em seguida. Vamos seguir o mesmo processo da etapa anterior. Execute os comandos a seguir para criar um contêiner do Docker e depois implantar e expor esse contêiner usando um serviço do Kubernetes.
Criar um contêiner do Docker com o Google Cloud Build
cd ~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .
Implante o contêiner no GKE
kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0
Exponha o contêiner do GKE:
kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082
Encontre o IP público dos serviços de produtos da mesma forma que fizemos com o serviço de pedidos usando o seguinte comando:
kubectl get service products
Saída:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE products 10.3.251.122 203.0.113.0 80:30877/TCP 3d
Salve o endereço IP para a próxima etapa, quando reconfigurarmos o monolítico para apontar para o novo microsserviço Products.
Reconfigure o aplicativo monolítico
Use o editor nano para substituir o URL local pelo endereço IP dos novos microsserviços Products:
cd ~/monolith-to-microservices/react-app nano .env.monolith
Quando o editor é aberto, aparece um arquivo semelhante a este:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
Substitua REACT_APP_PRODUCTS_URL pelo novo formato e mude o endereço IP do microsserviço Products para corresponder a:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=http://<PRODUCTS_IP_ADDRESS>/api/products
Pressione CTRL+O, ENTER e CTRL+X para salvar o arquivo no editor nano.
Para testar o novo microsserviço, acesse o URL que você configurou no arquivo. A página da Web deve retornar uma resposta JSON do nosso microsserviço Products.
Em seguida, vamos precisar recriar o front-end do aplicativo monolítico e repetir o processo de build para criar o contêiner do monolítico e reimplantá-lo no cluster do GKE. Execute os seguintes comandos para concluir as etapas abaixo.
Recrie os arquivos de configuração do aplicativo monolítico
npm run build:monolith
Criar um contêiner do Docker com o Google Cloud Build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .
Implante o contêiner no GKE
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0
Para verificar se o aplicativo está acessando o novo microsserviço Products, acesse a página Products do aplicativo monolítico no navegador. Todos os nomes de produto precisam ter o prefixo MS-, como nas imagens abaixo:
8. Migrar o front-end para um microsserviço
A última etapa do processo de migração é mover o código de Frontend para um microsserviço e desativar o aplicativo monolítico. Quando essa etapa for concluída, o aplicativo monolítico terá sido migrado para uma arquitetura de microsserviços.
Crie o microsserviço Frontend
Siga o mesmo procedimento das últimas duas etapas para criar um microsserviço de front-end.
Antes, quando recriávamos o aplicativo monolítico, atualizávamos a configuração para apontar para ele. Agora, precisamos usar a mesma configuração para o microsserviço de front-end. Execute os comandos a seguir para copiar os arquivos de configuração de URL dos microsserviços para a base de código do microsserviço de front-end:
cd ~/monolith-to-microservices/react-app cp .env.monolith .env npm run build
Quando terminar, vamos repetir o processo das etapas anteriores. Execute os comandos a seguir para criar um contêiner do Docker e depois implantar e expor esse contêiner usando um serviço do Kubernetes.
Criar um contêiner do Docker com o Google Cloud Build
cd ~/monolith-to-microservices/microservices/src/frontend
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .
Implante o contêiner no GKE
kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0
Exponha o contêiner do GKE:
kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080
Exclua o aplicativo monolítico
Agora que todos os serviços estão sendo executados como microsserviços, podemos excluir o aplicativo monolítico. Em uma migração real, outras mudanças seriam necessárias, como alterar o DNS para os nomes de domínio atuais apontarem para o novo microsserviço de front-end do aplicativo. Execute os comandos a seguir para excluir o monolítico:
kubectl delete deployment monolith kubectl delete service monolith
Teste seu trabalho
Se estiver tudo certo, o endereço IP antigo do serviço do monolítico não vai funcionar mais e o novo endereço IP do serviço front-end vai hospedar o novo aplicativo. Para conferir uma lista com todos os serviços e endereços IP, use o seguinte comando:
kubectl get services
A saída será parecida com esta:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend LoadBalancer 10.39.246.135 35.227.21.154 80:32663/TCP 12m kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 18d orders LoadBalancer 10.39.243.42 35.243.173.255 80:32714/TCP 31m products LoadBalancer 10.39.250.16 35.243.180.23 80:32335/TCP 21m
Depois de determinar o endereço IP externo do microsserviço de front-end, copie o endereço IP. Acesse esse URL (por exemplo, http://203.0.113.0) no navegador para verificar se o front-end está acessível. Seu site deve ter a mesma aparência de antes da divisão do aplicativo monolítico em microsserviços.
9. Limpeza
Quando estiver tudo pronto, a maneira mais fácil de limpar todas as atividades realizadas é excluir o projeto. A exclusão do projeto exclui todos os recursos criados neste codelab para garantir que não haja cobranças recorrentes inesperadas. Execute o seguinte no Cloud Shell, em que PROJECT_ID é o ID completo do projeto, e não apenas o nome dele.
gcloud projects delete [PROJECT_ID]
Confirme a exclusão digitando "Y" quando solicitado.
10. Parabéns!
Você dividiu seu aplicativo monolítico em microsserviços e os implantou no Google Kubernetes Engine.
Próximas etapas
Confira os codelabs a seguir para saber mais sobre o Kubernetes:
- Como implantar, escalonar e atualizar um site no Google Kubernetes Engine
- Crie um bot do Slack com o Node.js no Kubernetes
- Entrega contínua para o Kubernetes usando o Spinnaker
- Implantar um aplicativo Java no Kubernetes no Google Kubernetes Engine
Outros recursos
- Docker - https://docs.docker.com/
- Kubernetes - https://kubernetes.io/docs/home/
- Google Kubernetes Engine (GKE) - https://cloud.google.com/kubernetes-engine/docs/
- Google Cloud Build - https://cloud.google.com/cloud-build/docs/
- Google Container Registry - https://cloud.google.com/container-registry/docs/
- Como migrar aplicativos monolíticos para microsserviços - https://cloud.google.com/solutions/migrating-a-monolithic-app-to-microservices-gke