Percurso de aprendizagem: transforme um monolito numa app do GKE – Prepare a app modular para a contentorização

Este é o terceiro tutorial de um percurso de aprendizagem que ensina a modularizar e a colocar num contentor uma app monolítica.

O percurso de aprendizagem é composto pelos seguintes tutoriais:

  1. Overview
  2. Compreenda o monolito
  3. Modularize o monolítico
  4. Prepare a app modular para a contentorização (este tutorial)
  5. Coloque a app modular em contentores
  6. Implemente a app num cluster do GKE

No tutorial anterior, Modularize o monolítico, viu como dividir a app Cymbal Books em módulos Flask independentes. Neste tutorial, vai aprender sobre uma única alteração que tem de ser feita à app modular para a preparar para a contentorização.

Custos

Pode concluir este tutorial sem incorrer em custos. No entanto, se seguir os passos no tutorial final desta série, incorre em custos na sua conta doGoogle Cloud . Os custos começam quando ativa o GKE e implementa a app Cymbal Books num cluster do GKE. Estes custos incluem cobranças por cluster do GKE, conforme descrito na página de preços, e cobranças pela execução de VMs do Compute Engine.

Para evitar cobranças desnecessárias, certifique-se de que desativa o GKE ou elimina o projeto assim que concluir este tutorial.

Antes de começar

Antes de começar este tutorial, certifique-se de que concluiu os tutoriais anteriores da série. Para uma vista geral da série completa e links para tutoriais específicos, consulte o Percurso de aprendizagem: transforme um monolítico numa app do GKE – Vista geral.

Se já concluiu o primeiro tutorial, clonou um repositório do GitHub. Todas as 3 versões da app Cymbal Books estão localizadas nesse repositório, nas seguintes pastas:

  • monolith/
  • modular/
  • containerized/

Verifique se estas pastas estão no seu computador antes de continuar.

Altere o código modular

No tutorial anterior, aprendeu que o módulo da página inicial comunica com os outros módulos. Envia pedidos aos pontos finais dos outros módulos para obter detalhes, críticas e imagens dos livros e, em seguida, apresenta estes dados em páginas HTML.

Na pasta modular/, os pontos finais estão codificados em home.py, usando localhost, da seguinte forma:

BOOK_SERVICE_URL = "http://localhost:8081"     # Book details module listens on port 8081
REVIEW_SERVICE_URL = "http://localhost:8082"   # Book reviews module listens on port 8082
IMAGE_SERVICE_URL = "http://localhost:8083"    # Image module listens on port 8083

Estes URLs funcionam quando todos os módulos são executados na mesma máquina. No entanto, num ambiente Kubernetes, os módulos podem ser movidos para diferentes máquinas para processar falhas ou equilibrar a carga, o que significa que os respetivos endereços IP podem mudar.

Para garantir que o módulo da página inicial continua a conseguir alcançar os outros módulos, os URLs têm de usar nomes de serviços do Kubernetes em vez de localhost. Um nome de serviço funciona como um alias que o Kubernetes usa para encaminhar pedidos para o módulo correto, independentemente de onde está a ser executado. Por exemplo, quando o módulo da página inicial envia um pedido para http://book-details-service/book/1, o Kubernetes garante que o pedido chega ao módulo book-details.

Não precisa de atualizar estes URLs. A versão da app na pasta containerized/ já inclui esta alteração: os URLs localhost codificados foram substituídos por nomes de serviços do Kubernetes. Pode ver a versão atualizada em containerized/home_app/home_app.py:

BOOK_SERVICE_URL = "http://book-details-service"
REVIEW_SERVICE_URL = "http://book-reviews-service"
IMAGE_SERVICE_URL = "http://images-service"

Esta atualização garante que a app funciona corretamente quando é executada num ambiente do Kubernetes.

O manifesto do Kubernetes

Na secção anterior, viu como os pontos finais dos módulos foram atualizados para usar os nomes dos serviços do Kubernetes. Define os nomes dos serviços no manifesto do Kubernetes.

O manifesto do Kubernetes é um ficheiro de configuração que define que tipo de cluster do Kubernetes quer criar para alojar a sua app modular. O manifesto é escrito em YAML ou JSON. Nele, define aspetos como os serviços (para o encaminhamento entre módulos), o número de réplicas (instâncias) de cada módulo e a quantidade de CPU e memória que cada módulo pode usar.

Poderia escrever-se uma série completa de tutoriais sobre os manifestos do Kubernetes. O manifesto é complexo porque define tudo sobre o cluster do Kubernetes: a sua estrutura, comportamento e capacidades. Neste tutorial, vai ver apenas como os nomes dos serviços no manifesto correspondem aos nomes usados nos pontos finais dos módulos. Num tutorial posterior, vai executar o comando kubectl apply para criar o cluster do GKE de acordo com a configuração definida no manifesto, mas, neste tutorial, apenas vai rever o manifesto.

Veja o manifesto

Nesta secção, vai examinar como os serviços são definidos num manifesto do Kubernetes que foi escrito para si. O ficheiro de manifesto, que é um ficheiro YAML, encontra-se na pasta containerized/ do repositório do GitHub que clonou no primeiro tutorial desta série. Siga estes passos para ver uma definição de serviço:

  1. No terminal, navegue para o diretório em contentor no repositório clonado:

    cd containerized

  2. Num editor de texto, abra o ficheiro de manifesto do Kubernetes:

    cat kubernetes_manifest.yaml

  3. Encontre a definição do serviço para o módulo book-details. Tem o seguinte aspeto:

    apiVersion: v1
kind: Service
metadata:
name: book-details-service
spec:
selector:
    app: book-details-app
ports:
    - protocol: TCP
    port: 80  # External traffic on port 80
    targetPort: 8080  # Targeting container port 8080
type: ClusterIP

O nome do serviço book-details-service no manifesto corresponde ao nome usado no ponto final do módulo: http://book-details-service. Quando a sua app é executada no Kubernetes, o Kubernetes usa estes nomes de serviços para encaminhar pedidos para os módulos corretos.

O manifesto do Kubernetes define as funcionalidades do seu cluster do Kubernetes, incluindo os serviços que processam o encaminhamento de pedidos. Cada módulo na sua app tem um serviço correspondente definido no manifesto. Ao atualizar os URLs no código modular para corresponderem a estes nomes de serviços, garante que o Kubernetes pode encaminhar pedidos para os módulos corretos quando a app é executada num cluster.

Resumo

Neste tutorial, viu como os URLs no código modular foram atualizados para usar nomes de serviços do Kubernetes, como http://book-details-service. Estes nomes de serviços permitem ao Kubernetes encaminhar pedidos entre módulos, mesmo quando as respetivas localizações no cluster mudam. Também examinou o manifesto do Kubernetes e viu como os nomes dos serviços no código modular correspondem aos nomes definidos no manifesto.

O que se segue?

No tutorial seguinte, Coloque a app modular em contentores, vai aprender a colocar um módulo em contentores, agrupando-o num elemento denominado imagem do contentor. Em seguida, vê como executar uma imagem de contentor como um contentor, testar as respetivas funcionalidades e enviar a imagem de contentor para o Artifact Registry da Google.