Percurso de aprendizagem: transforme um monolítico numa app do GKE – Coloque a app modular em contentores

Este é o quarto tutorial de um percurso de aprendizagem que ensina a modularizar e 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
  5. Coloque a app modular num contentor (este tutorial)
  6. Implemente a app num cluster do GKE

No tutorial anterior, Prepare a app modular para a contentorização, viu que alterações tinham de ser feitas à versão modular da app Cymbal Books para a preparar para a contentorização. Neste tutorial, vai contentorizar a app.

Custos

Pode concluir este tutorial sem incorrer em custos. No entanto, seguir os passos no tutorial seguinte desta série incorre em custos na suaGoogle Cloud conta. 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 de toda a série e links para tutoriais específicos, consulte o Percurso de aprendizagem: transforme um monolítico numa app do GKE – Vista geral.

Configure o seu ambiente

Nesta secção, configura um ambiente no qual coloca a app modular em contentores. Especificamente, realiza os seguintes passos:

  1. Selecione ou crie um Google Cloud projeto
  2. Ative as APIs necessárias
  3. Associe o Cloud Shell ao seu Google Cloud projeto
  4. Defina as variáveis de ambiente predefinidas
  5. Crie um repositório no Artifact Registry
  6. Configure o Docker para o Artifact Registry
  7. Obtenha o código do tutorial

Selecione ou crie um Google Cloud projeto

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

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  2. Verify that billing is enabled for your Google Cloud project.

Ative as APIs necessárias

Para trabalhar com imagens de contentores e o Kubernetes no seu projeto Google Cloud , tem de ativar as seguintes APIs:

  • API Artifact Registry: esta API ativa o Artifact Registry, que é um serviço para armazenar e gerir as suas imagens de contentores.
  • API Kubernetes Engine: esta API fornece acesso ao GKE.

Para ativar estas APIs, visite a página para ativar as APIs na Google Cloud consola.

Associe o Cloud Shell ao seu projeto Google Cloud

Agora que configurou o seu Google Cloud projeto, tem de iniciar uma instância doCloud Shell e associá-la ao seu Google Cloudprojeto. A Cloud Shell é uma ferramenta de linha de comandos que lhe permite criar e gerir os recursos de um projeto diretamente a partir do navegador. O Cloud Shell vem pré-instalado com duas ferramentas importantes: a CLI gcloud e a CLI kubectl. Neste tutorial, vai usar a CLI gcloud para interagir com o Google Cloud e, no tutorial seguinte, vai usar a CLI kubectl para gerir a app Cymbal Books que é executada no GKE.

Para associar uma instância do Cloud Shell ao seu Google Cloud projeto, siga estes passos:

  1. Aceda à Google Cloud consola:

    Google Cloud consola

  2. Na consola, clique no botão Ativar Cloud Shell: Ativar Cloud Shell

    É aberta uma sessão do Cloud Shell num frame na parte inferior da consola.

  3. Defina o seu projeto predefinido na CLI Google Cloud através do seguinte comando:

    gcloud config set project PROJECT_ID

    Substitua PROJECT_ID pelo ID do projeto que criou ou selecionou na secção anterior, Selecionar ou criar Google Cloud projeto. Um ID do projeto é uma string exclusiva que diferencia o seu projeto de todos os outros projetos no Google Cloud. Para localizar o ID do projeto, aceda ao seletor de projetos. Nessa página, pode ver os IDs dos seus Google Cloud projetos.

Defina as variáveis de ambiente predefinidas

Para simplificar os comandos que executa ao longo deste tutorial, vai definir algumas variáveis de ambiente na Cloud Shell. Estas variáveis armazenam valores como o ID do projeto, a região do repositório e a etiqueta da imagem. Depois de definir estas variáveis, pode reutilizá-las em vários comandos fazendo referência ao nome da variável (por exemplo, $REPOSITORY_NAME) em vez de voltar a escrever ou substituir os valores de cada vez. Esta abordagem facilita a compreensão do tutorial e reduz o risco de erros.

Para configurar o seu ambiente com o Cloud Shell, siga estes passos:

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 o seguinte:

  • REPOSITORY_REGION: a região onde quer que o seu repositório do Artifact Registry seja alojado. Por exemplo, us-central1 (Iowa), us-west1 (Oregão) ou europe-west1 (Bélgica). Para ver uma lista completa de regiões, consulte o artigo 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 etiqueta que quer aplicar a uma imagem. Uma etiqueta é um rótulo que pode anexar a uma versão específica de uma imagem do contentor. Pode usar convenções de nomenclatura de etiquetas como estas para indicar claramente diferentes versões de uma imagem:
    • v1
    • v1.2.3
    • Uma etiqueta descritiva, como feature-x-dev
    • Uma etiqueta que indica o ambiente, como test

Crie um repositório no Artifact Registry

Em seguida, cria um repositório no Artifact Registry. Um repositório é uma localização de armazenamento onde guarda imagens de contentores. Quando cria uma imagem de contentor, precisa de um local para a armazenar, de modo que possa ser implementada posteriormente num cluster do Kubernetes. O Artifact Registry permite-lhe criar e gerir estes repositórios no seu Google Cloud projeto.

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

O resultado bem-sucedido do comando tem o seguinte aspeto:

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

Configure o Docker para o Artifact Registry

Em seguida, configure o Docker para que possa comunicar de forma segura com o Artifact Registry deGoogle Cloud. O Docker é uma ferramenta que pode usar para criar pacotes e executar software de forma consistente em diferentes ambientes. Saiba mais sobre o funcionamento do Docker na secção seguinte. Por agora, tem de configurá-lo para que possa estabelecer ligação ao Artifact Registry.

Se não configurar o Docker desta forma, não pode enviar as imagens de contentores para o Artifact Registry (uma tarefa que realiza mais tarde neste tutorial). Também não pode extrair as imagens de contentores do Artifact Registry e implementá-las num cluster do GKE (uma tarefa que realiza no tutorial seguinte).

Para configurar o Docker para autenticar com o Artifact Registry, execute este comando:

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

Obtenha o código do tutorial

Agora que o ambiente do Cloud Shell está configurado, tem de transferir o código do tutorial no Cloud Shell. Mesmo que tenha clonado anteriormente o repositório na sua máquina local, tem de o clonar novamente aqui na sua instância do Cloud Shell.

Embora seja possível concluir este tutorial na sua máquina local, teria de instalar e configurar manualmente várias ferramentas, como o Docker, o kubectl e a CLI gcloud. A utilização do Cloud Shell é mais fácil porque vem pré-configurado com todas estas ferramentas.

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

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

Noções básicas sobre a contentorização: imagens de contentores, contentores e Dockerfiles

Agora que configurou o seu ambiente e transferiu o código contentorizado, já pode contentorizar a app. A contentorização da app consiste em usar um Dockerfile para criar um pacote de cada módulo do Cymbal Books (página inicial, detalhes do livro, imagens e críticas de livros) numa imagem de contentor. Quando a aplicação é implementada no cluster do GKE, o Kubernetes usa estas imagens de contentores para criar contentores em execução no cluster.

As secções seguintes explicam estes conceitos detalhadamente.

O que é a contentorização?

A contentorização agrupa um módulo e todas as respetivas dependências, como bibliotecas e ficheiros de configuração, numa unidade denominada imagem de contentor. Os programadores usam esta imagem de contentor para criar e executar contentores em qualquer ambiente, desde o portátil de um programador a um servidor de testes ou um cluster do Kubernetes de produção.

O que são imagens de contentores?

Uma imagem de contentor contém todos os ficheiros necessários para executar uma aplicação. Estes ficheiros incluem o próprio código da aplicação, bibliotecas do sistema, o ambiente de execução (por exemplo, o intérprete Python), dados estáticos e quaisquer outras dependências.

Neste tutorial, cria uma imagem de contentor para cada módulo da app de críticas de livros.

O que é um contentor?

Um contentor é um ambiente isolado onde o código de uma imagem de contentor é executado. Pode criar contentores de duas formas: usando o comando docker run para testar durante o desenvolvimento ou implementando imagens de contentores num cluster do Kubernetes.

Na versão contentorizada da app Cymbal Books, cada módulo da app modular é executado no seu próprio contentor:

  • O contentor da página inicial executa o módulo da página inicial e processa pedidos para /.
  • O contentor de detalhes do livro executa o módulo de detalhes do livro e disponibiliza dados para pontos finais, como /book/1 ou /book/3.
  • O contentor de críticas de livros executa o módulo de críticas de livros e gere pedidos para pontos finais, como /book/2/reviews.
  • O contentor de imagens executa o módulo de imagens e disponibiliza imagens de capas de livros para pontos finais, como /images/fungi_frontier.jpg.

Uma vantagem fundamental dos contentores é que o Kubernetes pode criar automaticamente mais contentores quando necessário. Por exemplo, se vários utilizadores estiverem a ler críticas de livros, o Kubernetes pode iniciar contentores de críticas de livros adicionais para processar a carga.

Para implementar o escalamento numa app modular que não usa contentores, teria de escrever código personalizado para iniciar novas instâncias de um módulo e distribuir o tráfego entre elas. Com o Kubernetes, esta capacidade de escalabilidade está integrada: não tem de escrever código de escalabilidade personalizado.

O que são ficheiros Docker?

Um Dockerfile é um script que define como embalar um módulo numa imagem de contentor. Neste tutorial, não precisa de criar nenhum Dockerfile. Estes já lhe foram fornecidos no repositório do GitHub que 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 o seu próprio Dockerfile.

Por exemplo, 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 ficheiro Docker tem o seguinte aspeto:

# 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

Este Dockerfile executa os seguintes passos para criar a imagem do contentor para o módulo home_app:

  • Linha 1: FROM python:3.9-slim transfere um intérprete do Python 3.9 e os respetivos ficheiros necessários para a imagem do contentor. Estes ficheiros permitem a execução do módulo.
  • Linha 2: WORKDIR /app cria um diretório denominado /app no contentor e define este diretório como o diretório de trabalho atual. Todos os comandos executados no contentor são executados a partir deste diretório.
  • Linhas 3 e 4: COPY requirements.txt . copia o ficheiro requirements.txt do seu computador local para o diretório /app da imagem do contentor. O ficheiro requirements.txt lista todas as bibliotecas Python que o home_app.py precisa. A linha RUN pip install instala essas bibliotecas na imagem do contentor.
  • Linhas 5 a 7: os comandos COPY que aparecem nestas linhas copiam o código do módulo (home_app.py) e os respetivos ficheiros de apoio (modelos e recursos estáticos) para o diretório /app na imagem do contentor.
  • Linha 8: CMD especifica o comando predefinido que o Docker executa quando o contentor é iniciado. Neste Dockerfile, CMD ["python", "home_app.py"] indica ao Docker que use o intérprete Python para executar o módulo home_app.py automaticamente quando o contentor é iniciado.

Como a contentorização pode aplicar um isolamento de dados mais rigoroso

As linhas 5 a 7 do Dockerfile, que foram descritas na secção anterior, mostram como a contentorização pode aplicar um isolamento de dados mais rigoroso do que a versão modularizada da app. Num tutorial anterior, na secção Conceda a cada módulo acesso apenas aos dados de que precisa, aprendeu que a versão modular da app organizava os dados em diretórios separados, mas os módulos continuavam a partilhar o mesmo sistema de ficheiros e podiam potencialmente aceder aos dados uns dos outros.

Aqui, na versão contentorizada da app, o contentor de cada módulo inclui apenas os ficheiros necessários. Por exemplo, se o módulo home_app não precisar de acesso aos dados de críticas de livros, esses dados simplesmente não existem no contentor home_app. Por predefinição, um contentor não pode aceder a ficheiros de outro contentor, a menos que esteja explicitamente configurado para o fazer. Isto ajuda a garantir que cada módulo está totalmente isolado e também ajuda a evitar o acesso acidental ou não autorizado aos dados.

Na secção seguinte, vai ver como o comando docker build usa um Dockerfile como entrada e segue as instruções no Dockerfile para criar uma imagem de contentor.

Crie imagens de contentores com o Docker

Nesta secção, cria imagens de contentores Docker para cada um dos módulos de críticas de livros e envia-as para o repositório do Artifact Registry. Vai usar estas imagens de contentores num tutorial seguinte para implementar e executar a app de exemplo Cymbal Books no Kubernetes.

  1. Navegue para o diretório raiz da aplicação contentorizada:

    cd kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/

  2. Crie as imagens de contentores 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. Veja as imagens de contentores criadas na 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 as quatro imagens forem apresentadas, criou com êxito as imagens do contentor.

Teste contentores no Cloud Shell

Para verificar se as imagens de contentores foram criadas corretamente, pode executá-las como contentores e testar os respetivos pontos finais no Cloud Shell.

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

Embora seja possível testar o contentor home_app encontrando o endereço IP de cada contentor e configurando o home_app para os usar em vez dos nomes dos serviços, esta abordagem requer muito esforço. Em alternativa, é uma boa ideia adiar o teste do contentor home_app até depois de implementar a aplicação num cluster do Kubernetes. Depois de a app estar no cluster, pode determinar se o módulo de casa está a funcionar corretamente.

Siga estes passos para testar os contentores:

  1. Inicie os contentores 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 contentores estão em execução listando todos os contentores ativos:

    docker ps

    O resultado deste comando deve mostrar três contentores em execução com o estado 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 pontos finais do contentor book_details_app, use os seguintes comandoscurl:

    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 destes comandos devolve dados no formato JSON. Por exemplo, o resultado do comando curl http://localhost:8081/book/1 tem o seguinte aspeto:

    {"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 críticas de livros do contentor book_reviews_app através do seguinte comando:curl

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

    Este comando devolve uma lista de 20 críticas do livro 1 no formato JSON. Segue-se um exemplo de uma crítica da lista:

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

  5. Teste o contentor images_app:

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

    2. Selecione Alterar porta e introduza 8083. É aberta uma janela do navegador com um URL semelhante a este:

      https://8083-your-instance-id.cs-your-region.cloudshell.dev/?authuser=0

    3. Remova ?authuser=0 no final do URL e adicione o caminho para um ficheiro de imagem, como /images/fungi_frontier.jpg. Segue-se um exemplo:

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

      Deverá ver a imagem da capa do livro Fungi Frontier apresentada no seu navegador.

  6. Após o teste, pare os contentores para libertar recursos:

    1. Liste os contentores em execução e encontre os respetivos IDs dos contentores:

      docker ps

    2. Parar cada contentor:

      docker stop CONTAINER_ID

      Substitua CONTAINER_ID pelo ID do contentor que quer parar.

Envie as imagens de contentor para o Artifact Registry

Antes de poder implementar a sua app num cluster do Kubernetes, as imagens de contentores têm de ser armazenadas numa localização à qual o cluster possa aceder. Neste passo, envia as imagens para o repositório do Artifact Registry que criou anteriormente. No tutorial seguinte, implementa essas imagens do repositório do Artifact Registry num cluster do GKE:

  1. Para enviar as imagens de contentores para o 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 foram carregadas com êxito listando-as:

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

    Deverá ver uma saída semelhante à seguinte:

    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.

Atualize o manifesto do Kubernetes com caminhos para imagens de contentores

Como aprendeu no tutorial anterior, Prepare a app modular para a contentorização, um manifesto do Kubernetes é um ficheiro YAML que define como a sua app é executada num cluster do Kubernetes. Inclui detalhes como os seguintes:

  • Os módulos da sua app (por exemplo,home-app, book-details-app)
  • Caminhos para as imagens de contentores
  • Detalhes da configuração, como limites de recursos
  • Definições de serviço para pedidos de encaminhamento entre módulos

Nesta secção, atualiza o mesmo ficheiro de manifesto que reviu no tutorial anterior. Esse ficheiro é kubernetes-manifest.yaml e contém valores de marcador de posição para os caminhos das imagens. Tem de substituir esses marcadores de posição pelos caminhos reais das imagens de contentores que enviou para o repositório do Artifact Registry na secção anterior.

Para atualizar o ficheiro de manifesto do kubernetes-manifest.yaml Kubernetes, siga estes passos:

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

    cd kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/

  2. Abra o ficheiro kubernetes-manifest.yaml num 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 contentores que enviou para o Artifact Registry:

    Veja o aspeto de um caminho após fazer estas 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 contentores:

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

  5. Depois de atualizar os caminhos, guarde o ficheiro de manifesto e feche o editor. Por exemplo, se estiver a usar o vim, prima Esc para entrar no modo de comando, escreva wq e prima Enter para guardar e sair.

O manifesto do Kubernetes está agora configurado para implementar as imagens de contentores do repositório do Artifact Registry num cluster do Kubernetes.

Resumo

Neste tutorial, preparou a app modular Cymbal Books para implementação num cluster do Kubernetes através da realização das seguintes tarefas:

  1. Configurou um Google Cloud projeto e configurou o Cloud Shell para o seu ambiente.
  2. Reviu os Dockerfiles fornecidos para cada módulo de app.
  3. Criou imagens de contentores para os módulos da app através do Docker.
  4. Testou contentores no Cloud Shell para verificar a respetiva funcionalidade.
  5. Enviou as imagens de contentores para o Artifact Registry para armazenamento.
  6. Atualizou o manifesto do Kubernetes para usar os caminhos de imagens de contentores corretos do Artifact Registry.

O que se segue?

No tutorial seguinte, Implemente a app num cluster do GKE, implementa a aplicação em contentor num cluster do GKE.