arrow_back

Como migrar um site monolítico para microsserviços no Google Kubernetes Engine

Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

Como migrar um site monolítico para microsserviços no Google Kubernetes Engine

Lab 1 hora 30 minutos universal_currency_alt 5 créditos show_chart Intermediário
Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

GSP699

Laboratórios autoguiados do Google Cloud

Informações gerais

Por que migrar de um aplicativo monolítico para uma arquitetura de microsserviços? Dividir um aplicativo em microsserviços é vantajoso, principalmente porque a dependência entre os microsserviços é mínima. Com essa abordagem, você tem as seguintes opções:

  • É 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, você implantará um aplicativo monolítico pronto no cluster do Google Kubernetes Engine e o dividirá em microsserviços. 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.

Diagrama da arquitetura dos microsserviços

Comece dividindo o aplicativo monolítico em três microsserviços, um de cada vez. Os microsserviços são: Orders, Products e Frontend. Crie uma imagem Docker para cada microsserviço usando o Cloud Build. Depois implante e exponha os microsserviços no Google Kubernetes Engine (GKE) com um serviço do tipo LoadBalancer do Kubernetes. Você fará isso para cada serviço, enquanto eles são refatorados simultaneamente no aplicativo monolítico. O aplicativo monolítico e os microsserviços vão funcionar em paralelo até o fim do processo, quando será possível excluir esse aplicativo.

O que você vai 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 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

Configuração e requisitos

Antes de clicar no botão Start Lab

Leia estas instruções. Os laboratórios são cronometrados e não podem ser pausados. O timer é iniciado quando você clica em Começar o laboratório e mostra por quanto tempo os recursos do Google Cloud vão ficar disponíveis.

Este laboratório prático permite que você realize as atividades em um ambiente real de nuvem, não em uma simulação ou demonstração. Você vai receber novas credenciais temporárias para fazer login e acessar o Google Cloud durante o laboratório.

Confira os requisitos para concluir o laboratório:

  • Acesso a um navegador de Internet padrão (recomendamos o Chrome).
Observação: para executar este laboratório, use o modo de navegação anônima ou uma janela anônima do navegador. Isso evita conflitos entre sua conta pessoal e a conta de estudante, o que poderia causar cobranças extras na sua conta pessoal.
  • Tempo para concluir o laboratório---não se esqueça: depois de começar, não será possível pausar o laboratório.
Observação: não use seu projeto ou conta do Google Cloud neste laboratório para evitar cobranças extras na sua conta.

Como iniciar seu laboratório e fazer login no console do Google Cloud

  1. Clique no botão Começar o laboratório. Se for preciso pagar, você verá um pop-up para selecionar a forma de pagamento. No painel Detalhes do laboratório à esquerda, você verá o seguinte:

    • O botão Abrir Console do Cloud
    • Tempo restante
    • As credenciais temporárias que você vai usar neste laboratório
    • Outras informações se forem necessárias
  2. Clique em Abrir Console do Google. O laboratório ativa recursos e depois abre outra guia com a página Fazer login.

    Dica: coloque as guias em janelas separadas lado a lado.

    Observação: se aparecer a caixa de diálogo Escolher uma conta, clique em Usar outra conta.
  3. Caso seja preciso, copie o Nome de usuário no painel Detalhes do laboratório e cole esse nome na caixa de diálogo Fazer login. Clique em Avançar.

  4. Copie a Senha no painel Detalhes do laboratório e a cole na caixa de diálogo Olá. Clique em Avançar.

    Importante: você precisa usar as credenciais do painel à esquerda. Não use suas credenciais do Google Cloud Ensina. Observação: se você usar sua própria conta do Google Cloud neste laboratório, é possível que receba cobranças adicionais.
  5. Acesse as próximas páginas:

    • Aceite os Termos e Condições.
    • Não adicione opções de recuperação nem autenticação de dois fatores (porque essa é uma conta temporária).
    • Não se inscreva em testes gratuitos.

Depois de alguns instantes, o console do GCP vai ser aberto nesta guia.

Observação: para ver uma lista dos produtos e serviços do Google Cloud, clique no Menu de navegação no canto superior esquerdo. Ícone do menu de navegação

Ativar o Cloud Shell

O Cloud Shell é uma máquina virtual com várias ferramentas de desenvolvimento. Ele tem um diretório principal permanente de 5 GB e é executado no Google Cloud. O Cloud Shell oferece acesso de linha de comando aos recursos do Google Cloud.

  1. Clique em Ativar o Cloud Shell Ícone "Ativar o Cloud Shell" na parte de cima do console do Google Cloud.

Depois de se conectar, vai notar que sua conta já está autenticada, e que o projeto está configurado com seu PROJECT_ID. A saída contém uma linha que declara o projeto PROJECT_ID para esta sessão:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud é a ferramenta de linha de comando do Google Cloud. Ela vem pré-instalada no Cloud Shell e aceita preenchimento com tabulação.

  1. (Opcional) É possível listar o nome da conta ativa usando este comando:
gcloud auth list
  1. Clique em Autorizar.

  2. A saída será parecida com esta:

Saída:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`
  1. (Opcional) É possível listar o ID do projeto usando este comando:
gcloud config list project

Saída:

[core] project = <project_ID>

Exemplo de saída:

[core] project = qwiklabs-gcp-44776a13dea667a6 Observação: para conferir a documentação completa da gcloud, acesse o guia com informações gerais sobre a gcloud CLI no Google Cloud.

Defina a zona padrão e a configuração do projeto:

gcloud config set compute/zone {{{project_0.default_zone | (zone)}}}

Tarefa 1: Clonar o repositório de origem

Você usará 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. Instale as dependências do NodeJS para testar o aplicativo monolítico antes da implantação:
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh

Pode levar alguns minutos para o script ser executado.

Tarefa 2: Criar 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, veja se as APIs corretas estão ativadas.

  1. Execute o comando a seguir para ativar a API Containers e usar o Google Kubernetes Engine:
gcloud services enable container.googleapis.com
  1. Execute o comando abaixo para criar o cluster do GKE fancy-cluster com três nós:
gcloud container clusters create fancy-cluster --num-nodes 3 --machine-type=e2-standard-4 Aviso: se você receber um erro de região/zona não especificada, consulte a seção de configuração do ambiente para confirmar se a zona do Compute padrão foi definida.

A criação do cluster pode levar vários minutos.

  1. 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 {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 {{{project_0.default_zone | (zone)}}} e2-standard-4 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 Cloud. No menu de navegação, 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.

Clique em Verificar meu progresso para conferir o andamento do objetivo. Crie um cluster do GKE.

Tarefa 3: Implantar o monolítico atual

Neste laboratório, você vai precisar instalar e executar um aplicativo monolítico para poder dividi-lo em microsserviços.

  • Execute o script a seguir para implantar um aplicativo monolítico no seu cluster do GKE:
cd ~/monolith-to-microservices ./deploy-monolith.sh

Como acessar o monolítico

  1. Para localizar o endereço IP externo do aplicativo monolítico, execute o seguinte comando:
kubectl get service monolith

A saída 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
  1. Caso a saída liste o IP externo como <pending>, espere um minuto e execute o comando outra vez.

  2. 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 monolítico está acessível.

Observação: guarde esse endereço IP, porque ele será usado nas próximas tarefas. Use esse mesmo comando para encontrá-lo outra vez.

Você deverá encontrar a página de boas-vindas do site monolítico. A página de boas-vindas é estática e será exibida pelo microsserviço Frontend depois. Agora seu aplicativo monolítico está sendo executado integralmente no Kubernetes.

Clique em Verificar meu progresso para conferir o andamento do objetivo. Implante um monolítico pronto.

Tarefa 4: Migrar pedidos para um microsserviço

Agora que o site monolítico está em execução no GKE, já é possível dividir cada serviço em um microsserviço. Em geral, é preciso fazer um planejamento para definir quais serviços serão divididos em blocos menores, normalmente relacionados a partes específicas do aplicativo, como o domínio comercial.

Para este laboratório, você criará um exemplo e dividirá cada serviço no domínio comercial em: Orders, Products e Frontend. O código já foi migrado para você poder se concentrar na criação e na implantação dos serviços no Google Kubernetes Engine (GKE).

Crie o microsserviço Orders

O primeiro serviço a ser dividido é Orders. Use a base de código fornecida e crie um contêiner do Docker separado para esse serviço.

Crie um contêiner do Docker com o Cloud Build

Como você já tem a base do código, o primeiro passo é criar um contêiner do Docker para o serviço Orders usando o Cloud Build.

Em geral, esse processo tem duas etapas: criar o contêiner do Docker e enviá-lo para um registro, onde a imagem é armazenada e pode ser extraída pelo GKE. Com o Cloud Build, você pode criar o contêiner do Docker e mover a imagem para o Container Registry Com um só comando, você cria e move a imagem para o Container Registry. Para saber mais sobre o processo manual de criação e envio de um arquivo do Docker, acesse a documentação do Container Registry no Google Cloud e consulte o guia de início rápido do Container Registry.

O Google Cloud Build compacta e envia os arquivos do diretório para um bucket do 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. A flag --tag é especificada com o host como gcr.io para a imagem Docker. A imagem Docker resultante será enviada ao Container Registry do Google Cloud.

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

O processo leva cerca de um minuto. Quando a compilação estiver pronta, o terminal vai mostrar uma saída parecida com esta:

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io//orders:1.0.0 SUCCESS
  1. Para consultar seu histórico de builds ou acompanhar o processo em tempo real, no console, clique no botão Menu de navegação no canto superior esquerdo, role para baixo até CI/CD e clique em Cloud Build > 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ê encontrará todos os detalhes da versão, incluindo a saída do registro.

Na página de detalhes do build, para visualizar a imagem do contêiner que foi criada, na seção direita, clique na guia Detalhes de execução e consultar Imagem.

Implantar o contêiner no GKE

Agora que você já fez a conteinerização do site e enviou 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 crie um recurso de implantação. 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 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 solicita que o Kubernetes crie uma implantação com o nome Orders no seu 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 Observação: uma prática recomendada é usar um arquivo YAML para declarar sua alteração no cluster do Kubernetes (por exemplo, criar ou modificar uma implantação ou serviço) e um sistema de controle de origem, como o GitHub ou Cloud Source Repositories, para armazenar essas alterações. Para saber mais sobre isso, consulte a documentação de implantações do Kubernetes.

Verificar a implantação

  • Para confirmar que a implantação foi criada, execute o seguinte comando:
kubectl get all

Pode levar alguns instantes para o status do pod aparecer como "Em execução".

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

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

Também é possível visualizar suas implantações do Kubernetes no console do Cloud. Abra o Menu de navegação e selecione Kubernetes Engine > Cargas de trabalho.

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 oferece suporte de rede e IP aos pods do seu aplicativo. O GKE cria um IP externo e um balanceador de carga (sujeito a faturamento). No site do Google Cloud, consulte os preços do Compute Engine para seu aplicativo.

Para este laboratório, a exposição do serviço foi simplificada. Normalmente você usaria um gateway de API para proteger seus endpoints públicos. No Centro de arquitetura do Google Cloud, leia mais sobre as práticas recomendadas para microsserviços.

Você usou uma implantação do Kubernetes para expor internamente o serviço Orders na porta 8081. 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.

  • 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 serviço, não à implantação.

  • Se você quer 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 3s

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.

Reconfigurar o monolítico

Como você removeu o serviço Orders do monolítico, será necessário modificar esse aplicativo para apontar para o novo microsserviço Orders externo.

Ao dividir um aplicativo monolítico, você está removendo partes do código de uma única base de código para criar vários microsserviços que implantará separadamente. Como os microsserviços são executados em outro servidor, não é mais possível usar os URLs de serviço como caminhos absolutos. Você precisa direcionar para o endereço do servidor do microsserviço Orders. 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.

Agora você precisa atualizar o arquivo de configuração no aplicativo monolítico para apontar para o endereço IP do novo microsserviço Orders.

  1. Use o editor nano para substituir o URL local pelo endereço IP do microsserviço Orders:
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
  1. Substitua REACT_APP_ORDERS_URL pelo novo formato, mudando os endereços IP do microsserviço Orders para corresponder a:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
  1. Pressione CTRL + O, Enter e CTRL + X para salvar o arquivo no editor nano.

  2. Para testar o novo microsserviço, acesse o URL que você configurou no arquivo. É preciso que a página da Web retorne uma resposta JSON do seu microsserviço Orders.

  3. A próxima etapa é recriar o front-end do aplicativo monolítico. Repita o processo para criar o contêiner do monolítico e reimplantá-lo no cluster do GKE:

  • Recrie os arquivos de configuração do monolítico:
npm run build:monolith
  1. Crie o contêiner do Docker com o Cloud Build:
cd ~/monolith-to-microservices/monolith gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
  1. Implante o contêiner no GKE:
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
  1. Verifique se o aplicativo está acessando o microsserviço Orders. Para isso, 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:

Tabela de pedidos incluindo colunas para ID do pedido, data, total de itens e custo. O formato do ID do pedido é o seguinte: ORD-000001-MICROSERVICE

  1. Clique em Verificar meu progresso para conferir o andamento do objetivo. Migre Orders para um microsserviço.

Tarefa 5: Migrar Products para um microsserviço

Criar o microsserviço Products

Migre Products para continuar dividindo os serviços. Repita o processo 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.

  1. Crie o contêiner do Docker com o Cloud Build:
cd ~/monolith-to-microservices/microservices/src/products gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .
  1. Implante o contêiner no GKE:
kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0
  1. Exponha o contêiner do GKE:
kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082
  1. Encontre o IP público do serviço Products como você fez com o serviço Orders:
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

Você usará o endereço IP na próxima etapa ao reconfigurar o monolítico para apontar para o novo microsserviço Products.

Reconfigurar o monolítico

  1. Use o editor nano para substituir o URL local pelo endereço IP do novo microsserviço 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
  1. 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
  1. Pressione CTRL + O, Enter e CTRL + X para salvar o arquivo.

  2. 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 microsserviço Products.

  3. A próxima etapa é recriar o front-end do aplicativo monolítico. Repita o processo para criar o contêiner desse aplicativo e reimplantá-lo no cluster do GKE. Execute os seguintes comandos para concluir as etapas abaixo.

  4. Recrie os arquivos de configuração do monolítico:

npm run build:monolith
  1. Crie o contêiner do Docker com o Cloud Build:
cd ~/monolith-to-microservices/monolith gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .
  1. Implante o contêiner no GKE:
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0
  1. Verifique se o aplicativo está acessando o novo microsserviço Products. Para isso, visite a página Products do aplicativo monolítico pelo navegador. Todos os nomes de produto precisam ter o prefixo MS-, como nas imagens abaixo:

Blocos de imagens com cada imagem rotulada no seguinte formato: MS- nome da imagem - preço. Exemplo: MS-Vintage Typewriter-R$67,99.

  1. Clique em Verificar meu progresso para conferir o andamento do objetivo. Migre Products para um microsserviço.

Tarefa 6: Migrar front-ends 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 monolítico terá sido migrado para uma arquitetura de microsserviços.

Criar um novo microsserviço de front-end

Siga o mesmo procedimento das últimas duas etapas para criar o microsserviço de front-end.

Quando você recriou o aplicativo monolítico, atualizou a configuração para apontar para o aplicativo monolítico. Use a mesma configuração para o microsserviço de front-end.

  1. 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
  1. Quando terminar, repita 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.

  2. Crie 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 .
  1. Implante o contêiner no GKE:
kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0
  1. Exponha o contêiner do GKE:
kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080
  1. Clique em Verificar meu progresso para conferir o andamento do objetivo. Migre o front-end para um microsserviço.

Excluir o monolítico

Agora que todos os serviços estão sendo executados como microsserviços, já é possível 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 abaixo para excluir o monolítico:
kubectl delete deployment monolith kubectl delete service monolith

Testar seu trabalho

Se estiver tudo certo, o endereço IP antigo do serviço do monolítico não deve funcionar mais e o novo endereço IP do serviço front-end deve hospedar o novo aplicativo.

  • Para conferir uma lista com todos os serviços e endereços IP, execute 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 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.

Parabéns!

Você dividiu seu aplicativo monolítico em microsserviços e os implantou no Google Kubernetes Engine.

Terminar a Quest

Este laboratório autoguiado faz parte da Quest Website on Google Cloud. Uma Quest é uma série de laboratórios relacionados que formam um programa de aprendizado. Caso você já tenha feito este laboratório, inscreva-se nesta Quest para ganhar os créditos de conclusão imediatamente. Consulte o catálogo do Google Cloud Ensina para encontrar outras Quests disponíveis.

Está procurando um laboratório com desafios práticos para demonstrar suas habilidades e conhecimentos? Quando terminar a Quest, faça este laboratório com desafio que não é obrigatório.

Começar o próximo laboratório

Continue seu aprendizado assistindo ao vídeo com o estudo de caso Hosting Scalable Web Applications on Google Cloud ou confira estas sugestões:

Próximas etapas / Recursos adicionais

Treinamento e certificação do Google Cloud

Esses treinamentos ajudam você a aproveitar as tecnologias do Google Cloud ao máximo. Nossas aulas incluem habilidades técnicas e práticas recomendadas para ajudar você a alcançar rapidamente o nível esperado e continuar sua jornada de aprendizado. Oferecemos treinamentos que vão do nível básico ao avançado, com opções de aulas virtuais, sob demanda e por meio de transmissões ao vivo para que você possa encaixá-las na correria do seu dia a dia. As certificações validam sua experiência e comprovam suas habilidades com as tecnologias do Google Cloud.

Manual atualizado em 20 de setembro de 2023

Laboratório testado em 20 de setembro de 2023

Copyright 2024 Google LLC. Todos os direitos reservados. Google e o logotipo do Google são marcas registradas da Google LLC. Todos os outros nomes de produtos e empresas podem ser marcas registradas das respectivas empresas a que estão associados.