Programa de treinamentos: transformar um monólito em um app do GKE: preparar o app modular para contêinerização

Este é o terceiro tutorial de um programa de aprendizado que ensina a modularizar e criar contêineres de um app monolítico.

O programa de aprendizado consiste nos seguintes tutoriais:

  1. Visão geral
  2. Entender o monolítico
  3. Modularizar o monolítico
  4. Preparar o app modular para contêinerização (este tutorial)
  5. Colocar o app modular em um contêiner
  6. Implantar o app em um cluster do GKE

No tutorial anterior, Modularizar o monólito, você aprendeu a dividir o app Cymbal Books em módulos independentes do Flask. Neste tutorial, você vai aprender sobre uma única mudança que precisa ser feita no app modular para prepará-lo para a contêinerização.

Custos

Você pode concluir este tutorial sem custos. No entanto, seguir as etapas do tutorial final desta série gera cobranças na sua conta doGoogle Cloud . Os custos começam quando você ativa o GKE e implanta o app Cymbal Books em um cluster do GKE. Esses 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, desative o GKE ou exclua o projeto depois de concluir este tutorial.

Antes de começar

Antes de começar este tutorial, confira se você concluiu os tutoriais anteriores da série. Para uma visão geral de toda a série e links para tutoriais específicos, consulte Programa de aprendizado: transformar um monólito em um app do GKE – Visão geral.

Se você já concluiu o primeiro tutorial, clonou um repositório do GitHub. Todas as três versões do app Cymbal Books estão localizadas nesse repositório, dentro das seguintes pastas:

  • monolith/
  • modular/
  • containerized/

Verifique se essas pastas estão na sua máquina antes de continuar.

Mudar o código modular

No tutorial anterior, você aprendeu que o módulo da página inicial se comunica com os outros módulos. Ele envia solicitações aos endpoints dos outros módulos para recuperar detalhes, avaliações e imagens de livros e apresenta esses dados em páginas HTML.

Na pasta modular/, os endpoints são codificados em home.py usando localhost, assim:

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

Esses URLs funcionam quando todos os módulos são executados na mesma máquina. No entanto, em um ambiente do Kubernetes, os módulos podem ser movidos para máquinas diferentes para lidar com falhas ou balancear a carga, o que significa que os endereços IP podem mudar.

Para garantir que o módulo da página inicial ainda possa acessar os outros módulos, os URLs precisam usar nomes de serviço do Kubernetes em vez de localhost. Um nome de serviço funciona como um alias que o Kubernetes usa para encaminhar solicitações ao módulo correto, não importa onde ele esteja sendo executado. Por exemplo, quando o módulo da página inicial envia uma solicitação para http://book-details-service/book/1, o Kubernetes garante que a solicitação chegue ao módulo de detalhes do livro.

Não é necessário atualizar esses URLs manualmente. A versão do app na pasta containerized/ já inclui essa mudança: os URLs localhost codificados foram substituídos por nomes de serviços do Kubernetes. Confira 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"

Essa atualização garante que o app funcione corretamente quando executado em um ambiente do Kubernetes.

O manifesto do Kubernetes

Na seção anterior, você viu como os endpoints dos módulos foram atualizados para usar nomes de serviços do Kubernetes. Você define os nomes de serviço no manifesto do Kubernetes.

O manifesto do Kubernetes é um arquivo de configuração que define o tipo de cluster do Kubernetes que você quer criar para hospedar seu app modular. O manifesto é escrito em YAML ou JSON. Nele, você define coisas como os serviços (para roteamento 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.

Uma série completa de tutoriais poderia ser escrita sobre manifestos do Kubernetes. O manifesto é complexo porque define tudo sobre o cluster do Kubernetes: estrutura, comportamento e recursos. Neste tutorial, você vai analisar apenas como os nomes de serviço no manifesto correspondem aos nomes usados nos endpoints dos módulos. Em um tutorial posterior, você vai executar o comando kubectl apply para criar o cluster do GKE de acordo com a configuração definida no manifesto. Neste tutorial, você só vai revisar o manifesto.

Ver o manifesto

Nesta seção, você vai examinar como os serviços são definidos em um manifesto do Kubernetes criado para você. O arquivo de manifesto, que é um arquivo YAML, está na pasta containerized/ do repositório do GitHub que você clonou no primeiro tutorial desta série. Siga estas etapas para conferir uma definição de serviço:

  1. No terminal, navegue até o diretório em contêineres no repositório clonado:

    cd containerized

  2. Em um editor de texto, abra o arquivo de manifesto do Kubernetes:

    cat kubernetes_manifest.yaml

  3. Encontre a definição de serviço para o módulo book-details. Ele é semelhante ao exemplo a seguir:

    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 endpoint do módulo: http://book-details-service. Quando o app é executado no Kubernetes, ele usa esses nomes de serviço para rotear solicitações aos módulos corretos.

O manifesto do Kubernetes define os recursos do cluster do Kubernetes, incluindo os serviços que processam o roteamento de solicitações. Cada módulo do app tem um serviço correspondente definido no manifesto. Ao atualizar os URLs no código modular para corresponder a esses nomes de serviço, você garante que o Kubernetes possa direcionar solicitações aos módulos corretos quando o app for executado em um cluster.

Resumo

Neste tutorial, você viu como os URLs no código modular foram atualizados para usar nomes de serviços do Kubernetes, como http://book-details-service. Esses nomes de serviço permitem que o Kubernetes encaminhe solicitações entre módulos, mesmo quando os locais deles no cluster mudam. Você também analisou o manifesto do Kubernetes e viu como os nomes de serviço no código modular correspondem aos nomes definidos no manifesto.

A seguir

No próximo tutorial, Colocar o app modular em contêineres, você vai aprender a colocar um módulo em contêineres empacotando-o em algo chamado imagem de contêiner. Em seguida, você vai aprender a executar uma imagem de contêiner como um contêiner, testar os recursos dela e enviar a imagem para o Artifact Registry do Google.