Introdução

Nesse guia vou implantar os contêineres do sistema do TeoMeWhy da Twitch que hoje está na AWS, e colocar na GCP.

Estrutura atual na AWS

Arquitetura na GCP

Não será usada nenhuma ferramenta de automação complexa, tudo será feita pela console, integrando com o Github e fazendo o deploy das imagens a cada commit na main.
Usaremos:

• Cloud Run - Para as aplicações web
• Cloud SQL - Para o banco de dado MySQL
• GCE - Para rodar o Teomebot
• Cloud Storage - Object Storage (S3)
• Cloud Build - Para criar o deploy das aplicações
• Secret Manager - Salvar as credencias da aplicação de forma segura.

Obtendo as aplicações

1. Visite o GitHub do TeoMeWhy e faça o fork das aplicações relacionadas ao projeto.
2. Na página do repositório, clique em Starred e depois em Fork.
3. Na página de fork, dê um nome ao fork e clique em Create fork.
4. Repita o processo para os outros repositórios do projeto caso queira replicar todo o ambiente.
5. Faça o clone do fork para ajustar o necessário na aplicação antes de enviá-la para o GCP.

git clone git@github.com:cslemes/points-to-go.git

Criando o Dockerfile para criação da imagem de container

Navegue até a pasta do repositório clonado. O repositório já contém um Dockerfile pensado para o Docker. Vamos analisá-lo:

```
FROM golang:latest
WORKDIR /app/
COPY . .
RUN go build main.go
CMD ["./main"]
```

Esse Dockerfile está funcional, mas vamos otimizá-lo usando multi-stage builds para reduzir o tamanho da imagem final. Como o Go não requer dependências externas, podemos usar uma imagem base mínima como scratch.

1. Troque a imagem de build por uma versão mais leve e nomeie-a para referência em outros estágios.
   

   FROM golang:1.23.1-alpine3.20 AS build
   

2. Adicione o comando go mod download para cachear as dependências e go mod verify para garantir que elas correspondem aos checksums no arquivo go.sum.
   

   RUN go mod download && go mod verify
   

3. Para otimizar o binário para produção, adicione os parâmetros abaixo:

   • CGO_ENABLED=0: Desativa o suporte a CGO. CGO é a funcionalidade do Go que permite chamar código em C, mas ao desativá-lo, você obtém um binário completamente estático, sem dependências de bibliotecas externas.
   • GOARCH=amd64: Define a arquitetura de destino para a compilação. amd64 é a arquitetura usada em máquinas com processadores de 64 bits, como a maioria dos servidores e desktops modernos.
   • GOOS=linux: Define o sistema operacional de destino para a compilação. Aqui está configurado para linux, o que significa que o binário gerado será executável em sistemas Linux.
   • go build -o /app/points: Compila o código e salva o binário no caminho especificado (/app/points).
   • -a: Força a recompilação de todos os pacotes, incluindo dependências, mesmo que não tenham mudado. Pode ser útil para garantir que tudo seja recompilado com as novas flags e configurações.
   • -ldflags="-s -w": Essas são flags de otimização de tamanho.
   • -s remove a tabela de símbolos de depuração do binário.
   • -w remove as informações de stack tracing (rastreamento de pilha). Essas opções reduzem o tamanho do binário final.
   • -installsuffix cgo: Adiciona um sufixo ao diretório de instalação para diferenciar binários com CGO desativado. Isso pode evitar conflitos com binários que usam CGO.

   RUN CGO_ENABLED=0 GOARCH=amd64 GOOS=linux go build -o /app/points -a -ldflags="-s -w" -installsuffix cgo
   

4. (opcional) Para deixar a imagem ainda menor podemos comprimir o binário usando upx, O upx (Ultimate Packer for eXecutables) é uma ferramenta que comprime binários executáveis para reduzir o tamanho de arquivos, como binários Go. Os pontos negativos é que vai ter maior tempo de build, e um delay maior no startup do container, então deve ser avaliado o é mais benéfico para sua implantação. Como o objetivo e usar no cloud Run que já possui Cold Start, ele pausa o container quando está sem uso, não vamos utilizar porque vai aumentar o tempo de inicialização do container.
   

   RUN apk add --no-cache curl upx
   RUN upx --ultra-brute -qq points && upx -t points
   

• upx --ultra-brute -qq points: Comprime o binário points de forma agressiva, usando todas as opções de compressão possíveis e sem exibir mensagens de saída.
• upx -t points: Testa o binário comprimido para garantir que ele ainda funcione corretamente.

• Agora com o binário pronto vamos fazer o segundo estágio, que é copiar o binário para uma imagem limpa.
  

   FROM scratch AS prod
   WORKDIR /app
   COPY --from=build /app/points /
   CMD ["./points"]
  

  • scratch é uma imagem base especial no Docker que representa uma imagem completamente vazia, sem qualquer sistema operacional ou dependência. Usar FROM scratch é comum em imagens minimalistas para aplicações Go, onde um binário estático é suficiente.

• Arquivo completo
  

  FROM golang:1.23.1-alpine3.20 AS build
  WORKDIR /app/
  COPY . .
  RUN go mod download && go mod verify
  RUN CGO_ENABLED=0 GOARCH=amd64 GOOS=linux go build -o /app/points -a -ldflags="-s -w" -installsuffix cgo
  
  ## Comprime o binário opcional
  RUN apk add --no-cache curl upx 
  RUN upx --ultra-brute -qq points && upx -t points
  
  FROM scratch AS prod
  WORKDIR /app
  COPY --from=build /app/points /
  CMD ["./points"]
  

1. Comparando builds
2. A otimização do Dockerfile e o uso do upx resultam em uma imagem até 3 vezes menor.
3. A análise da imagem original com Trivy mostra 904 CVEs, enquanto a imagem scratch é livre de CVEs.

1. Repita essas definições para os outros repositórios.

Implantando o banco de dados

1. No console, acesse SQL no menu lateral.
2. Ou busque "SQL" na barra de pesquisa e selecione SQL na lista.
3. Na página do Cloud SQL, clique em Criar Instância e escolha MySQL.
4. Selecione Enterprise em edição.
5. Em "Predefinições da edição", escolha Sandbox.
6. Deixe a versão do banco de dados em MySQL 8.0.
7. Dê um nome à instância em ID da Instância e defina uma senha.
8. você consegue especificar as politicas de senha expandindo política de senha
9. Defina a zona e região, e vamos deixar em uma única zona.
10. Em personalizar instância podemos ajustar o hardware de acordo com nossas necessidades, as opções vão variar de acordo com a edição que escolhemos.
11. Ajuste a CPU para 1 e o disco para 10GB conforme necessário.
12. Em conexões, desmarque IP público e marque IP particular.
13. Em conexão de acesso privado clique em Configurar Conexão
14. Selecione use um intervalo alocado automaticamente
15. Clique em Continuar
16. Clique em Criar conexão
17. Clique em Criar Instância e aguarde a criação.

18. Para conectar à instância, ative o Cloud Shell e execute:
    

    gcloud sql connect tmwdb --user=root
    

1. Coloque a senha atribuída na etapa anterior.
2. E então você vai receber um erro de conexão, porque o cloud shell não tem acesso a sua VPC privada.
3. Para simplificar a conexão via Cloud shell, vamos editar a instância e marcar IP público, no apêndice vou mostrar como criar o VPC peering para acessar o DB pelo Cloud Shell
4. Tente conectar novamente.

5. Crie o banco de dados da aplicação:
   

   CREATE DATABASE points;
   

6. O Cloud Shell ainda tem um editor de texto baseado no VSCode, é possível fazer algumas atividades direto por ele, ele tem 5GB de volume persistente no seu /home, o hardware é um VM e2-small com 1vCPU e 1.7GB de RAM.
   

Criando containers no Cloud Run

1. No console do Google Cloud, acesse o Cloud Run pelo menu lateral ou barra de pesquisa.
2. Na página do Cloud Run, clique em Implantar Contêiner e escolha a opção Serviço.
3. Escolhendo o Método de Implantação
4. Existem três opções para implantar um serviço:
   • Usar uma imagem de contêiner de um registry.
   • Conectar diretamente a um repositório.
   • Criar uma função (utilizando o Cloud Functions, integrado ao Run).
5. Para este guia, selecione Implantação Contínua com GitHub, permitindo que o Google configure a pipeline de CI/CD automaticamente.

6. Clique em Configurar com o Cloud Build.
   

7. Configurando a Conexão com o GitHub

8. Clique em Autenticar para permitir a integração do Google com seu GitHub.

9. Autorize o acesso, escolhendo entre permitir acesso a todos os repositórios ou apenas um específico.

10. Após concluir o login, clique em Próxima.
    

11. Escolhendo Tipo de Build

12. Na etapa de build, selecione entre usar um Dockerfile ou Aplicações com suporte e Buildpacks do GCP.

13. Opte por Dockerfile e ajuste o caminho/nome do arquivo, se necessário
    

14. Configurações de Serviço

15. Configure os seguintes parâmetros:

    • Autenticação: Selecione Permitir chamadas não autenticadas.
    • Alocação de CPU: Escolha A CPU é alocada somente durante o processamento da solicitação.
    • Controle de entrada: Selecione Interno.

16. Ajuste a porta do container, conforme a necessário para a aplicação.
    

17. Na aba segurança, em conta de serviço, clique em criar Nova conta de serviço
    

18. Adicione as roles

    • Administrador de objeto do Storage
    • Administrador do Cloud Run
    • Assessor de secret do Secret Manager
    • Cliente do Cloud SQL
    • Conta de serviço do Cloud Build
    • Gravador do Artifact Registry
    • Usuário da conta de serviço

19. Analisando o código da aplicação, precisamos passar as variáveis de ambiente para o banco de dados.
    

    // db.go
    ...
    func OpenDBConnection() (*gorm.DB, error) {
    
    godotenv.Load(".env")
        HOST_DB := os.Getenv("HOST_DB")
            PORT_DB := os.Getenv("PORT_DB")
    USER_DB := os.Getenv("USER_DB")
    PASSWORD_DB := os.Getenv("PASSWORD_DB")
    
    ...
    

20. Vamos ter que alterar o código da aplicação para o padrão do Cloud Sql que usa Unix sockets, e o Cloud Run não acessa diretamente o DB ele usa o Cloud SQL Auth Proxy.
    

    // db.go
    ...
            HOST_DB := os.Getenv("HOST_DB")
         //PORT_DB := os.Getenv("PORT_DB")
            USER_DB := os.Getenv("USER_DB")
        PASSWORD_DB := os.Getenv("PASSWORD_DB")
    
     //log.Println(PORT_DB)
         // UNIX dsn
        dsn := "%s:%s@unix(/cloudsql/%s)/%s?      charset=utf8mb4&parseTime=True&loc=Local"
        //dsn := "%s:%s@tcp(%s:%s)/%s?charset=utf8mb4&parseTime=True&loc=Local"
           dsn = fmt.Sprintf(dsn, USER_DB, PASSWORD_DB, HOST_DB, "points")
     ...   
    

21. Em contêiner, vamos na aba variáveis e secrets e clicar em adicionar variável.

22. Adicione as variáveis necessárias.

23. O endereço do banco segue o padrão, PROJECT_ID:REGION:INSTANCE_NAME, você também pode obter o nome mais abaixo, no item 16.
    

24. A senha do banco vamos botar em REFERENCIAR UM SECRET

25. Se a opção criar novo secret estiver desativado é porque precisa ativar a Api.

26. Clique em CRIAR NOVO SECRET
    

27. Defina o nome da secret e clique em Criar Secret
    

28. Em Conexões do Cloud SQL vamos adicionar a URL do banco que criamos
    

29. Para criação do schema da da aplicação, no código exige que passemos o argumento migrations=true.

30. Vamos adicionar migrations=true ao argumento da função, depois removemos na próxima revisão do container.
    

31. Deixe os demais campos no padrão e clique em Criar
    

32. Testando a aplicação usando Thunder Client.

33. criando um cliente
    

34. lendo os clientes cadastrados
    

Criando serviço Teomebot

O chatbot não será implantado no Cloud Run, será instalando no Google Compute Engine (GCE). Diferente do Cloud Run, o Compute Engine é ideal porque o chatbot precisa estar ativo continuamente para interagir com o chat.

Além disso, abordaremos o uso de containers, gerenciamento de secrets e a configuração do Cloud Build para automação do deploy.

Criando uma VM no Google Compute Engine (GCE)

1. Acesse o Compute Engine no menu lateral do Console do GCP.
2. Clique em Criar Instância.
3. Insira um nome para a instância (ex.: teomebot-instance).
4. Configure a região e a zona conforme necessário e anote essas informações para uso posterior.
5. Em Configuração da máquina, escolha o tipo E2 e, em Predefinição, selecione e2-micro.
6. Clique na aba Contêiner e clique em Implantar Contêiner.
7. Use temporariamente a imagem nginx:latest para concluir a configuração inicial.
8. Adicione as variáveis de ambiente:
   • TWITCH_BOT: Nome do bot.
   • TWITCH_CHANNEL: Nome do canal da Twitch.
   • HOST_DB: IP privado do banco de dados Cloud SQL.
   • USER_DB: Usuário do banco.
   • PORT_DB: Porta do banco.
   • URL_POINTS: Endpoint do serviço Points-to-Go.
9. Clique em Selecionar
10. Em Identidade e acesso à API, selecione a conta de serviço configurada para este projeto.
11. Deixe o restante das configurações no padrão e clique em Criar.

Adicionando Secrets com o Secret Manager

1. Você deve ter percebido que não passamos as secrets, no compute engine não tem um jeito simples de passar como no cloud run. Minha solução foi adicionar uma função no código da aplicação para ler a informação direto do secret manager.
2. Acesse o Secret Manager no Console do GCP.
3. Clique em Criar Secret
4. Insira um nome descritivo (ex.: twitch-token) e adicione o valor correspondente.
5. Copie o caminho do secret gerado (ex.: projects/123456/secrets/twitch-token/versions/latest).
   1. Crie um novo arquivo utils/gcp.go

6. Altere o utils/db.go para chamar a função, passando o caminho do secret manager como parâmetro.
   

   func OpenDBConnection() (*gorm.DB, error) {
   
       PASSWORD_DB := accessSecretVersion("projects/******/secrets/tmwdb-root/versions/latest")
   
       //godotenv.Load(".env")
       HOST_DB := os.Getenv("HOST_DB")
       PORT_DB := os.Getenv("PORT_DB")
       USER_DB := os.Getenv("USER_DB")
       //PASSWORD_DB := os.Getenv("PASSWORD_DB")
       
       dsn := "%s:%s@tcp(%s:%s)/%s?charset=utf8mb4&parseTime=True&loc=Local"
       dsn = fmt.Sprintf(dsn, USER_DB, PASSWORD_DB, HOST_DB, "teomebot")
       db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
       return db, err
   }
   

7. Altere o main.go para pegar as credencias da Twitch
   

   func main() {
   

    migration := flag.Bool("migrations", false, "Realizar migrations do banco de dados")

    flag.Parse()

    godotenv.Load()
    user := os.Getenv("TWITCH_BOT")
    // alteração
    oauth := utils.AccessSecretVersion("projects/551619572964/secrets/twitch-token/versions/latest")

    channel := os.Getenv("TWITCH_CHANNEL")
```

Cloud Build

Configurando o Cloud Build

O Cloud Build será usado para automatizar a criação da imagem do container e sua implantação no Compute Engine.

1. Crie um arquivo cloudbuild.yaml na raiz do repositório com o conteúdo abaixo:

2. Substitutions
   

   substitutions:
     _VERSION: "v1.0.${COMMIT_SHA}"
   

A variável _VERSION é definida com um valor que combina v1.0. com o hash do commit atual (${COMMIT_SHA}). Isso cria uma versão única para cada build, garantindo que cada imagem seja identificável pela versão e pelo commit.

• Steps
  A seção steps define as etapas que o Cloud Build deve executar. Aqui, temos quatro etapas: build, push (duas vezes) e update.

• Etapa 1: Build da Imagem Docker
  

    - name: "gcr.io/cloud-builders/docker"
      args:
        - "build"
        - "--no-cache"
        - "-t"
        - "gcr.io/$PROJECT_ID/teomebot:$_VERSION"
        - "-t"
        - "gcr.io/$PROJECT_ID/teomebot:latest"
        - "."
      id: Build
  

Esta etapa executa um build da imagem Docker:

• "--no-cache": força o build sem utilizar o cache.
• "-t": define tags para a imagem criada:
  • gcr.io/$PROJECT_ID/teomebot:$_VERSION: imagem com a tag que usa o hash do commit.
  • gcr.io/$PROJECT_ID/teomebot:latest: imagem com a tag latest.
• ".": define o diretório atual como o contexto do build.

A tag id: Build é um identificador opcional para a etapa, útil para referência e depuração.

• Etapa 2: Push da Imagem com Tag de Versão

  - name: "gcr.io/cloud-builders/docker"
    args:
      - "push"
      - "gcr.io/$PROJECT_ID/teomebot:$_VERSION"
    id: Push

Essa etapa faz o push da imagem com a tag específica ($_VERSION) para o Google Container Registry, permitindo que a versão gerada no build seja armazenada no repositório.

• Etapa 3: Push da Imagem com Tag latest
  

    - name: "gcr.io/cloud-builders/docker"
      args:
        - "push"
        - "gcr.io/$PROJECT_ID/teomebot:$_VERSION"
      id: Push
  

Esta etapa faz o push da imagem com a tag latest para o Google Container Registry, atualizando a imagem latest com a versão mais recente.

• Etapa 4: Atualização do Container em uma Instância GCE
  

    - name: "gcr.io/cloud-builders/gcloud"
      args:
        - "compute"
        - "instances"
        - "update-container"
        - "teomebot-instance"
        - "--container-image=gcr.io/$PROJECT_ID/teomebot:latest"
        - "--zone=$_DEPLOY_ZONE"
        - "--container-restart-policy=always"
  

Essa etapa usa o comando gcloud para atualizar o container em uma instância do Google Compute Engine:

• "teomebot-instance": especifica o nome da instância que executa o container.
• --container-image: define a imagem do container que a instância deve usar. Aqui, usa a versão latest da imagem.
• --zone=$_DEPLOY_ZONE: usa uma variável para especificar a zona de implantação.
• --container-restart-policy=always: define a política de reinicialização do container para sempre reiniciar em caso de falha.

• Options
  

  options:
    logging: CLOUD_LOGGING_ONLY
  

A opção logging: CLOUD_LOGGING_ONLY especifica que o Cloud Build deve registrar apenas no Cloud Logging, economizando dados e foco nos logs do GCP.

• Arquivo final
  

  substitutions:
    _VERSION: "v1.0.${COMMIT_SHA}"
  steps:
    - name: "gcr.io/cloud-builders/docker"
      args:
        - "build"
        - "--no-cache"
        - "-t"
        - "gcr.io/$PROJECT_ID/teomebot:$_VERSION"
        - "-t"
        - "gcr.io/$PROJECT_ID/teomebot:latest"
        - "."
      id: Build
    - name: "gcr.io/cloud-builders/docker"
      args:
        - "push"
        - "gcr.io/$PROJECT_ID/teomebot:$_VERSION"
      id: Push
    - name: "gcr.io/cloud-builders/docker"
      args:
        - "push"
        - "gcr.io/$PROJECT_ID/teomebot:latest"
    - name: "gcr.io/cloud-builders/gcloud"
      args:
        - "compute"
        - "instances"
        - "update-container"
        - "teomebot-instance"
        - "--container-image=gcr.io/$PROJECT_ID/teomebot:latest"
        - "--zone=$_DEPLOY_ZONE"
        - "--container-restart-policy=always"
  
  options:
    logging: CLOUD_LOGGING_ONLY
  

Criando Gatilho para Criação da Imagem de Container

Configurando a Conta de Serviço

1. Acesse o Cloud Build no console do Google Cloud.
2. Vá em Configurações.
3. Clique em Permissões de Conta de Serviço.
4. Localize a conta de serviço criada para o Cloud Run.
5. Ative a opção Definir como conta de serviço preferida
6. Habilite a função Administrador da Instância do Compute à conta de serviço. Criando o Gatilho
7. No menu lateral, clique em Gatilhos e depois em Criar Gatilho.
8. Insira um nome descritivo para o gatilho.
9. Em Repositórios, clique em Conectar Repositório e selecione o repositório Teomebot.
10. Em Configuração, selecione a opção Arquivo de Configuração do Cloud Build.
11. Adicione a variável de substituição _DEPLOY_ZONE com o valor correspondente à zona em que a instância foi criada.
12. Em conta de serviço verifique a conta selecionada se está conforme configuramos no passo 6.
13. Clique em Salvar. Executando o Gatilho
14. Na tela de visão geral, na linha do gatilho recém criado, clique em executar para rodar o processo manualmente.
15. Nos detalhes do processo, acompanhe os passos do build da imagem para verificar possíveis erros.

Testando a Aplicação

1. No painel do Compute Engine, copie o comando de ssh para acessar a instancia, ou use o cliente web ssh, e connect a instância.

2. Conecte-se à instância e execute os comandos abaixo para verificar o estado do container:
   

   docker ps
   docker container logs <container_id>
   

Resolvendo Problemas de Certificado

1. Caso ocorra um erro relacionado a certificados (causado pela imagem base scratch), substitua-a pela imagem distroless. No Dockerfile, altere a linha que define a imagem base de:
   

   FROM scratch
   

para:

```
FROM gcr.io/distroless/static-debian12
```

Dockerfile atualizado:

```Dockerfile
FROM golang:1.23.1-alpine3.20 AS build
WORKDIR /app
COPY . .
RUN go mod download && go mod verify
RUN CGO_ENABLED=0 GOARCH=amd64 GOOS=linux go build -o /app/tmwbot -a -ldflags="-s -w" -installsuffix cgo

FROM gcr.io/distroless/static-debian12 AS prod
WORKDIR /app
COPY --from=build /app/tmwbot /
ENTRYPOINT ["/tmwbot"]
```

Ajustando Permissões para o Secret Manager

1. Alterar o escopo da conta de serviço para acessar o Secret Manager.
2. Acesse o Console do Google Cloud.
3. No menu lateral, vá para Compute Engine > Instâncias de VM.
4. Encontre e clique no nome da sua instância de VM.
5. Na página de detalhes da VM, clique em Parar para desligar a instância (essa etapa é necessária, pois o escopo de conta de serviço só pode ser modificado com a instância parada).
6. Depois que a instância for interrompida, clique em Editar na parte superior da página.
7. Role até a seção Identidade e API de acesso.
8. Em Conta de Serviço, selecione a conta de serviço que sua aplicação usa.
9. Em Escopos de acesso da API, selecione Permitir acesso total a todas as APIs do Cloud ou clique em Definir escopos específicos de acesso da API e adicione o escopo https://www.googleapis.com/auth/cloud-platform.
10. Após ajustar o escopo, clique em Salvar para aplicar as mudanças.
11. Reinicie a instância clicando em Iniciar.

12. Ou pela linha de comando, parando a instância, rodando o comando e iniciando depois.
    

     gcloud compute instances set-service-account teomebot-instance --scopes=https://www.googleapis.com/auth/cloud-platform --zone "us-central1-a"
    

Adicionando mais containers

Os demais serviços seguem o mesmo processo do points-to-go, para os serviços que comunicam entre si crie variáveis de ambiente para configurar o endereço dos endpoints, que serão sempre https porta 443.

Para comunicação com outros serviços ajustei o código para receber mais uma variável de ambiente com a url do serviço, no points por exemplo ficou assim:

```go
...
var URL_POINTS = os.Getenv("URL_POINTS")
...

url := fmt.Sprintf("https://%s/customers/", URL_POINTS)

...
```

Testanto o bot

Testando a comunicação do bot com a Twitch.

Ajuste de Segurança na Rede
Após finalizar os testes, coloque os container para ser acessados somente internamente na VPC.

Conclusão

Com isso finalizamos a migração do sistema do TeoMeWhy, o guia serve de base para migrar os outros serviços do TeoMeWhy.

Os principais objetivos alcançados foram:

Realizações Técnicas

• Migração de aplicações conteinerizadas para o Cloud Run, permitindo escalabilidade automática e redução de custos
• Otimização de imagens Docker através de multi-stage builds, reduzindo significativamente o tamanho das imagens e vulnerabilidades
• Implementação de banco de dados gerenciado com Cloud SQL, garantindo alta disponibilidade e segurança
• Configuração de CI/CD automatizado usando Cloud Build, possibilitando deploys automáticos a partir do GitHub
• Gestão segura de credenciais utilizando Secret Manager

Melhorias na Arquitetura

• Separação clara de responsabilidades entre serviços
• Utilização de conexões privadas para maior segurança
• Implementação de padrões serverless para otimização de custos
• Automação de processos de build e deploy
• Integração contínua com repositórios do GitHub

Benefícios Obtidos

1. Custos: Redução de custos através do modelo serverless e otimização de recursos
2. Manutenibilidade: Facilidade de manutenção com deploys automatizados
3. Segurança: Gestão apropriada de secrets e conexões privadas
4. Escalabilidade: Capacidade de escalar automaticamente conforme a demanda
5. Monitoramento: Melhor visibilidade da infraestrutura através das ferramentas nativas da GCP

Apêndice

Habilitar a API do Secret Manager

1. No console do Google Cloud, pesquise por Secret Manager API.
2. Clique na API nos resultados da pesquisa.
3. Na tela de detalhes, clique em Ativar.

Referências

• Github TeoMeWhy
• Twitch Teo Me Why
• Cloud Run Docs
• Compute Engine Docs
• Cloud Build Docs
• Secrect Manager Docs