Programa de treinamentos: transformar um monólito em um app do GKE: conteinerizar o app modular


Este é o quarto tutorial de um programa de aprendizado que ensina a modularizar e contentorizar 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 a criação de contêineres
  5. Colocar o app modular em um contêiner (este tutorial)
  6. Implantar o app em um cluster do GKE

No tutorial anterior, Preparar o app modular para contêinerização, você viu quais mudanças precisavam ser feitas na versão modular do app Cymbal Books para prepará-lo para a contêinerização. Neste tutorial, você vai colocar o app em contêineres.

Custos

Você pode concluir este tutorial sem custos. No entanto, seguir as etapas do próximo tutorial 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.

Configurar o ambiente

Nesta seção, você configura um ambiente em que vai criar um contêiner do app modular. Especificamente, você realiza as seguintes etapas:

  1. Selecione ou crie um Google Cloud projeto
  2. Ative as APIs necessárias
  3. Conecte o Cloud Shell ao seu Google Cloud projeto
  4. Definir as variáveis de ambiente padrão
  5. Criar um repositório no Artifact Registry
  6. Configurar o Docker para o Artifact Registry
  7. Acessar o código do tutorial

Selecione ou crie um projeto do Google Cloud

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Make sure that billing is enabled for your Google Cloud project.

Ativar as APIs necessárias

Para trabalhar com imagens de contêiner e o Kubernetes no seu projeto Google Cloud , você precisa ativar as seguintes APIs:

  • API Artifact Registry: ativa o Artifact Registry, um serviço para armazenar e gerenciar imagens de contêiner.
  • API Kubernetes Engine: oferece acesso ao GKE.

Para ativar essas APIs, acesse ativar as APIs no console Google Cloud .

Conectar o Cloud Shell ao seu projeto do Google Cloud

Agora que você configurou seu projeto Google Cloud , é necessário iniciar uma instância do Cloud Shell e conectá-la ao projeto Google Cloud. O Cloud Shell é uma ferramenta de linha de comando que permite criar e gerenciar recursos de um projeto diretamente no navegador. O Cloud Shell vem pré-instalado com duas ferramentas importantes: a CLI gcloud e a CLI kubectl. Neste tutorial, você usa a CLI gcloud para interagir com o Google Cloud e, no próximo, usa a CLI kubectl para gerenciar o app Cymbal Books executado no GKE.

Para conectar uma instância do Cloud Shell ao seu projeto Google Cloud , siga estas etapas:

  1. Acesse o console do Google Cloud :

    Google Cloud console

  2. No console, clique no botão Ativar o Cloud Shell: Ativar o Cloud Shell

    Uma sessão do Cloud Shell é aberta dentro de um quadro inferior no console.

  3. Defina o projeto padrão na Google Cloud CLI usando o seguinte comando:

    gcloud config set project PROJECT_ID
    

    Substitua PROJECT_ID pelo ID do projeto que você criou ou selecionou na seção anterior, Selecionar ou criar Google Cloud projeto. O ID do projeto é uma string exclusiva que diferencia seu projeto de todos os outros em Google Cloud. Para localizar o ID do projeto, acesse o seletor de projetos. Nessa página, você pode conferir os IDs de cada um dos seus projetos do Google Cloud.

Definir as variáveis de ambiente padrão

Para simplificar os comandos que você executa ao longo deste tutorial, defina algumas variáveis de ambiente no Cloud Shell. Essas variáveis armazenam valores como ID do projeto, região do repositório e tag da imagem. Depois de definir essas variáveis, você pode reutilizá-las em vários comandos referenciando o nome da variável (por exemplo, $REPOSITORY_NAME) em vez de digitar ou substituir valores a cada vez. Essa abordagem facilita o acompanhamento do tutorial e reduz o risco de erros.

Para configurar o ambiente com o Cloud Shell, siga estas etapas:

export PROJECT_ID=$(gcloud config get project)
export REPOSITORY_REGION=REPOSITORY_REGION
export REPOSITORY_NAME=REPOSITORY_NAME
export REPOSITORY_DESCRIPTION="REPOSITORY_DESCRIPTION"
export TAG=TAG

Substitua:

  • REPOSITORY_REGION: a região em que você quer hospedar o repositório do Artifact Registry. Por exemplo, us-central1 (Iowa), us-west1 (Oregon) ou europe-west1 (Bélgica). Para uma lista completa de regiões, consulte Regiões e zonas.
  • REPOSITORY_NAME: o nome do seu repositório Por exemplo, book-review-service-repo.
  • REPOSITORY_DESCRIPTION: uma breve descrição da finalidade do repositório. Por exemplo, "Repository for storing Docker images for the book review service".
  • TAG: a tag que você quer aplicar a uma imagem. Uma tag é um rótulo que pode ser anexado a uma versão específica de uma imagem de contêiner. Você pode usar convenções de nomenclatura de tag como estas para indicar claramente diferentes versões de uma imagem:
    • v1
    • v1.2.3
    • Uma tag descritiva, como feature-x-dev
    • Uma tag que indica o ambiente, como test

Criar um repositório no Artifact Registry

Em seguida, crie um repositório no Artifact Registry. Um repositório é um local de armazenamento onde você mantém imagens de contêiner. Ao criar uma imagem de contêiner, você precisa de um lugar para armazená-la para que ela possa ser implantada em um cluster do Kubernetes. Com o Artifact Registry, é possível criar e gerenciar esses repositórios no seu projeto Google Cloud .

Para criar um repositório no Artifact Registry, execute o seguinte comando:

gcloud artifacts repositories create ${REPOSITORY_NAME} \
    --repository-format=docker \
    --location=${REPOSITORY_REGION} \
    --description="${REPOSITORY_DESCRIPTION}"

A saída bem-sucedida do comando será semelhante a esta:

Waiting for operation [...] to complete...done.
Created repository [book-review-service-repo].

Configurar o Docker para o Artifact Registry

Em seguida, configure o Docker para que ele possa se comunicar com segurança com o Artifact Registry deGoogle Cloud. O Docker é uma ferramenta que pode ser usada para empacotar e executar software de maneira consistente em diferentes ambientes. Você vai aprender mais sobre como o Docker funciona na próxima seção. Por enquanto, é necessário configurá-lo para que ele possa se conectar ao Artifact Registry.

Se você não configurar o Docker dessa forma, não será possível enviar as imagens de contêiner para o Artifact Registry (uma tarefa que você vai realizar mais adiante neste tutorial). Também não é possível extrair as imagens de contêiner do Artifact Registry e implantá-las em um cluster do GKE (uma tarefa que você realiza no próximo tutorial).

Para configurar o Docker para autenticação com o Artifact Registry, execute este comando:

gcloud auth configure-docker ${REPOSITORY_REGION}-docker.pkg.dev

Acessar o código do tutorial

Agora que o ambiente do Cloud Shell está configurado, baixe o código do tutorial no Cloud Shell. Mesmo que você já tenha clonado o repositório na sua máquina local, é necessário cloná-lo novamente aqui na sua instância do Cloud Shell.

Embora seja possível concluir este tutorial na sua máquina local, você precisaria instalar e configurar manualmente várias ferramentas, como Docker, kubectl e CLI gcloud. Usar o Cloud Shell é mais fácil porque ele já vem pré-configurado com todas essas ferramentas.

Na instância do Cloud Shell, execute o comando a seguir para clonar o repositório do GitHub:

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples.git

Princípios básicos da contêinerização: imagens de contêiner, contêineres e Dockerfiles

Agora que você configurou o ambiente e baixou o código em contêineres, é hora de colocar o app em contêineres. Isso consiste em usar um Dockerfile para empacotar cada módulo do Cymbal Books (página inicial, detalhes do livro, imagens e avaliações do livro) em uma imagem de contêiner. Quando o aplicativo é implantado no cluster do GKE, o Kubernetes usa essas imagens de contêiner para criar contêineres em execução no cluster.

As seções a seguir explicam esses conceitos em detalhes.

O que é contêinerização?

A conteinerização empacota um módulo e todas as dependências dele, como bibliotecas e arquivos de configuração, em uma unidade chamada imagem de contêiner. Os desenvolvedores usam essa imagem de contêiner para criar e executar contêineres em qualquer ambiente, desde um notebook de desenvolvedor até um servidor de teste ou um cluster do Kubernetes de produção.

O que são imagens de contêiner?

Uma imagem de contêiner contém todos os arquivos necessários para executar um aplicativo. Esses arquivos incluem o código do aplicativo, bibliotecas do sistema, o ambiente de execução (por exemplo, o interpretador Python), dados estáticos e outras dependências.

Neste tutorial, você vai criar uma imagem de contêiner para cada módulo do app de avaliações de livros.

O que é um contêiner?

Um contêiner é um ambiente isolado em que o código de uma imagem de contêiner é executado. É possível criar contêineres de duas maneiras: usando o comando docker run para testes durante o desenvolvimento ou implantando imagens de contêiner em um cluster do Kubernetes.

Na versão em contêineres do app Cymbal Books, cada módulo do app modular é executado no próprio contêiner:

  • O contêiner da página inicial executa o módulo da página inicial e processa solicitações para /.
  • O contêiner de detalhes do livro executa o módulo de detalhes do livro e veicula dados para endpoints como /book/1 ou /book/3.
  • O contêiner de avaliações de livros executa o módulo de avaliações e gerencia solicitações para endpoints como /book/2/reviews.
  • O contêiner de imagens executa o módulo de imagens e veicula imagens de capas de livros para endpoints como /images/fungi_frontier.jpg.

Uma das principais vantagens dos contêineres é que o Kubernetes pode criar mais contêineres automaticamente quando necessário. Por exemplo, se vários usuários estiverem lendo avaliações de livros, o Kubernetes poderá iniciar mais contêineres de avaliações para lidar com a carga.

Para implementar o escalonamento em um app modular que não usa contêineres, é necessário escrever um código personalizado para iniciar novas instâncias de um módulo e distribuir o tráfego entre elas. Com o Kubernetes, essa capacidade de escalonamento é integrada: não é necessário escrever nenhum código de escalonamento personalizado.

O que são Dockerfiles?

Um Dockerfile é um script que define como empacotar um módulo em uma imagem de contêiner. Neste tutorial, não é necessário criar nenhum Dockerfile. Eles já estão disponíveis para você no repositório do GitHub que você clonou anteriormente. O diretório de cada módulo na sua cópia local de kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/ contém um Dockerfile próprio.

Por exemplo, você pode encontrar o Dockerfile do módulo home_app na sua instância do Cloud Shell em kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/home_app/Dockerfile. Este Dockerfile tem a seguinte aparência:

# Dockerfile for home_app
FROM python:3.9-slim #line 1
WORKDIR /app #line 2
COPY requirements.txt . #line 3
RUN pip install --no-cache-dir -r requirements.txt #line 4
COPY home_app.py . #line 5
COPY templates/ ./templates/ #line 6
COPY static/ ./static/ #line 7
CMD ["python", "home_app.py"] #line 8

Esse Dockerfile executa as seguintes etapas para criar a imagem do contêiner para o módulo home_app:

  • Linha 1:FROM python:3.9-slim baixa um interpretador do Python 3.9 e os arquivos necessários para a imagem do contêiner. Esses arquivos permitem que o módulo seja executado.
  • Linha 2:WORKDIR /app cria um diretório chamado /app dentro do contêiner e define esse diretório como o diretório de trabalho atual. Todos os comandos executados dentro do contêiner serão executados nesse diretório.
  • Linhas 3 e 4:COPY requirements.txt . copia o arquivo requirements.txt da sua máquina local para o diretório /app da imagem do contêiner. O arquivo requirements.txt lista todas as bibliotecas Python que o home_app.py precisa. A linha RUN pip install instala essas bibliotecas na imagem do contêiner.
  • Linhas 5 a 7:os comandos COPY que aparecem nessas linhas copiam o código do módulo (home_app.py) e os arquivos de suporte dele (modelos e recursos estáticos) para o diretório /app na imagem do contêiner.
  • Linha 8: CMD especifica o comando padrão que o Docker executa quando o contêiner é iniciado. Neste Dockerfile, CMD ["python", "home_app.py"] informa ao Docker para usar o interpretador Python e executar o módulo home_app.py automaticamente quando o contêiner é iniciado.

Como a contêinerização pode impor um isolamento de dados mais rigoroso

As linhas 5 a 7 do Dockerfile, descritas na seção anterior, mostram como a contêinerização pode impor um isolamento de dados mais rigoroso do que a versão modularizada do app. Em um tutorial anterior, na seção Conceder a cada módulo acesso apenas aos dados de que ele precisa, você aprendeu que a versão modular do app organizava os dados em diretórios separados, mas os módulos ainda compartilhavam o mesmo sistema de arquivos e podiam acessar os dados uns dos outros.

Aqui, na versão em contêineres do app, o contêiner de cada módulo inclui apenas os arquivos necessários. Por exemplo, se o módulo home_app não precisar acessar dados de avaliações de livros, esses dados simplesmente não vão existir no contêiner home_app. Por padrão, um contêiner não pode acessar arquivos de outro contêiner, a menos que seja explicitamente configurado para isso. Isso ajuda a garantir que cada módulo esteja totalmente isolado e também evita o acesso acidental ou não autorizado a dados.

Na próxima seção, você vai ver como o comando docker build usa um Dockerfile como entrada e segue as instruções nele para criar uma imagem de contêiner.

criar imagens de contêiner usando o Docker

Nesta seção, você vai criar imagens de contêiner do Docker para cada um dos módulos de avaliação de livros e enviá-las para o repositório do Artifact Registry. Você vai usar essas imagens de contêiner em um tutorial a seguir para implantar e executar o app de exemplo Cymbal Books no Kubernetes.

  1. Navegue até o diretório raiz do aplicativo em contêiner:

    cd kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/
    
  2. Crie as imagens de contêiner usando o comando docker build:

    docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app:${TAG} ./home_app
    docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG} ./book_details_app
    docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG} ./book_reviews_app
    docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG} ./images_app
    
  3. Confira as imagens de contêiner criadas na sua instância do Cloud Shell:

    docker images
    

    Verifique se as seguintes imagens aparecem na lista:

    • home-app
    • book-details-app
    • book-reviews-app
    • images-app

    Se todas as quatro imagens forem listadas, você terá criado as imagens de contêiner com sucesso.

Testar contêineres no Cloud Shell

Para verificar se as imagens de contêiner foram criadas corretamente, execute-as como contêineres e teste os endpoints no Cloud Shell.

Os contêineres book_details_app, book_reviews_app e images_app podem ser testados individualmente porque não precisam se comunicar entre si. No entanto, testar o contêiner home_app usando o Docker é difícil porque o home_app está configurado para encontrar os outros contêineres que usam nomes de serviço como http://book-details-service:8081.

Embora seja possível testar o contêiner home_app encontrando o endereço IP de cada contêiner e configurando o home_app para usá-los em vez de nomes de serviço, essa abordagem exige muito esforço. Em vez disso, é recomendável adiar o teste do contêiner home_app até depois de implantar o aplicativo em um cluster do Kubernetes. Depois que o app estiver no cluster, você poderá determinar se o módulo inicial está funcionando corretamente.

Siga estas etapas para testar os contêineres:

  1. Inicie os contêineres book_details_app, book_reviews_app e images_app:

    docker run -d -p 8081:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG}
    docker run -d -p 8082:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG}
    docker run -d -p 8083:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG}
    
  2. Verifique se os contêineres estão em execução listando todos os contêineres ativos:

    docker ps
    

    A saída desse comando vai mostrar três contêineres em execução, com o status Up:

    CONTAINER ID   IMAGE                PORTS                        STATUS
    a1b2c3d4e5f6   REGION/.../details   0.0.0.0:8081->8080/tcp       Up
    g7h8i9j0k1l2   REGION/.../reviews   0.0.0.0:8082->8080/tcp       Up
    m3n4o5p6q7r8   REGION/.../images    0.0.0.0:8083->8080/tcp       Up
    
  3. Para testar os endpoints do contêiner book_details_app, use os seguintes comandos curl:

    curl http://localhost:8081/books
    curl http://localhost:8081/book/1
    curl http://localhost:8081/book/2
    curl http://localhost:8081/book/3
    

    Cada um desses comandos retorna dados no formato JSON. Por exemplo, a saída do comando curl http://localhost:8081/book/1 tem esta aparência:

    {"author":"Aria Clockwork","description":"In a world where time is a tangible substance, a young clockmaker discovers she can manipulate the fabric of time itself, leading to unforeseen consequences in her steampunk-inspired city.","id":1,"image_url":"zephyrs_timepiece.jpg","title":"Zephyr's Timepiece","year":2023}
    
  4. Recupere as avaliações de livros do contêiner book_reviews_app usando este comando curl:

    curl http://localhost:8082/book/1/reviews
    

    Esse comando retorna uma lista de 20 avaliações do livro 1 no formato JSON. Confira um exemplo de avaliação da lista:

    {
    "content": "The concept of time as a tangible substance is brilliantly explored in 'Zephyr's Timepiece'.",
    "rating": 5
    }
    
  5. Teste o contêiner images_app:

    1. Clique no botão **Web Preview** Botão de visualização da Web

    2. Selecione Alterar porta e insira 8083. Uma janela do navegador será aberta com um URL semelhante a este:

      https://8083-your-instance-id.cs-your-region.cloudshell.dev/?authuser=0
      
    3. Remova ?authuser=0 do final do URL e adicione o caminho para um arquivo de imagem, como /images/fungi_frontier.jpg. Veja um exemplo abaixo.

      https://8083-your-instance-id.cs-your-region.cloudshell.dev/images/fungi_frontier.jpg
      

      A imagem da capa do livro Fungi Frontier vai aparecer no navegador.

  6. Depois do teste, pare os contêineres para liberar recursos:

    1. Liste os contêineres em execução e encontre os IDs deles:

      docker ps
      
    2. Interrompa cada contêiner:

      docker stop CONTAINER_ID
      

      Substitua CONTAINER_ID pelo ID do contêiner que você quer parar.

Envie as imagens de contêiner para o Artifact Registry

Antes de implantar o app em um cluster do Kubernetes, as imagens de contêiner precisam ser armazenadas em um local acessível ao cluster. Nesta etapa, você envia as imagens para o repositório do Artifact Registry criado anteriormente. No próximo tutorial, você vai implantar essas imagens do repositório do Artifact Registry em um cluster do GKE:

  1. Para enviar as imagens de contêiner ao Artifact Registry, execute estes comandos:

    docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app:${TAG}
    docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG}
    docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG}
    docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG}
    
  2. Depois de enviar as imagens, verifique se elas foram enviadas corretamente listando-as:

    gcloud artifacts docker images list ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}
    

    A resposta será semelhante a esta:

    Listing items under project ${PROJECT_ID}, location ${REPOSITORY_REGION}, repository ${REPOSITORY_NAME}.
    
    IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app
    DIGEST: sha256:f7b78f44d70f2eedf7f7d4dc72c36070e7c0dd05daa5f473e1ebcfd1d44b95b1
    CREATE_TIME: 2024-11-14T00:38:53
    UPDATE_TIME: 2024-11-14T00:38:53
    SIZE: 52260143
    
    IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app
    DIGEST: sha256:875ac8d94ef54db2ff637e49ad2d1c50291087623718b854a34ad657748fac86
    CREATE_TIME: 2024-11-14T00:39:04
    UPDATE_TIME: 2024-11-14T00:39:04
    SIZE: 52262041
    
    IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app
    DIGEST: sha256:70ddc54ffd683e2525d87ee0451804d273868c7143d0c2a75ce423502c10638a
    CREATE_TIME: 2024-11-14T00:33:56
    UPDATE_TIME: 2024-11-14T00:33:56
    SIZE: 52262412
    
    IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app
    DIGEST: sha256:790f0d8c2f83b09dc3b431c4c04d7dc68254fecc76c48f00a83babc2a5dc0484
    CREATE_TIME: 2024-11-14T00:39:15
    UPDATE_TIME: 2024-11-14T00:39:15
    SIZE: 53020815
    

    A saída inclui os seguintes detalhes para cada imagem:

    • IMAGE: o caminho do repositório e o nome da imagem.
    • DIGEST: um identificador exclusivo da imagem.
    • CREATE_TIME ou UPDATE_TIME: quando a imagem foi criada ou modificada pela última vez.
    • SIZE: o tamanho da imagem em bytes.

Atualizar o manifesto do Kubernetes com caminhos para imagens de contêiner

Como você aprendeu no tutorial anterior, Prepare o app modular para contêinerização, um manifesto do Kubernetes é um arquivo YAML que define como o app é executado em um cluster do Kubernetes. Ele inclui detalhes como:

  • Os módulos do seu app (por exemplo,home-app, book-details-app)
  • Caminhos para as imagens de contêiner
  • Detalhes da configuração, como limites de recursos
  • Definições de serviço para rotear solicitações entre módulos

Nesta seção, você vai atualizar o mesmo arquivo de manifesto que analisou no tutorial anterior. Esse arquivo é kubernetes-manifest.yaml e contém valores de marcador de posição para os caminhos de imagem. Substitua esses marcadores de posição pelos caminhos reais das imagens de contêiner que você enviou para o repositório do Artifact Registry na seção anterior.

Para atualizar o arquivo de manifesto do Kubernetes kubernetes-manifest.yaml, siga estas etapas:

  1. No Cloud Shell, navegue até o diretório containerized/, que contém o arquivo de manifesto do Kubernetes kubernetes-manifest.yaml:

    cd kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/
    
  2. Abra o arquivo kubernetes-manifest.yaml em um editor de texto:

    vim kubernetes-manifest.yaml
    
  3. Localize os campos image que contêm marcadores de posição como este:

    image: REPOSITORY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/home-app:TAG
    

    Substitua cada marcador de posição pelos caminhos reais das imagens de contêiner que você enviou ao Artifact Registry:

    Veja como um caminho pode ficar depois de fazer essas substituições:

    image:us-west1-docker.pkg.dev/your-project-id/book-review-service-repo/home-app:v1
    
  4. Atualize os caminhos de todas as imagens de contêiner:

    • home-app
    • book-details-app
    • book-reviews-app
    • images-app
  5. Depois de atualizar os caminhos, salve o arquivo de manifesto e feche o editor. Por exemplo, se você estiver usando o vim, pressione Esc para entrar no modo de comando, digite wq e pressione Enter para salvar e sair.

Agora, o manifesto do Kubernetes está configurado para implantar as imagens de contêiner do repositório do Artifact Registry em um cluster do Kubernetes.

Resumo

Neste tutorial, você preparou o app modular Cymbal Books para implantação em um cluster do Kubernetes realizando as seguintes tarefas:

  1. Configure um projeto Google Cloud e o Cloud Shell para seu ambiente.
  2. Revisou os Dockerfiles fornecidos para cada módulo do app.
  3. Crie imagens de contêiner para os módulos do app usando o Docker.
  4. Testei contêineres no Cloud Shell para verificar a funcionalidade deles.
  5. Enviou as imagens de contêiner para o Artifact Registry para armazenamento.
  6. Atualizamos o manifesto do Kubernetes para usar os caminhos corretos de imagens de contêiner do Artifact Registry.

A seguir

No próximo tutorial, Implantar o app em um cluster do GKE, você implanta o aplicativo em contêineres em um cluster do GKE.