AndersonArruda

Artigos de tecnologia ao alcance de um clique!


Como Fazer Deploy Automático no Google Cloud Run Usando Artifact Registry
Deploy Automático GCP Google Cloud Run Tutorial Artifact Registry Docker CI/CD com GitHub Actions Google Cloud DevOps Deploy com Cloud Build GCP Cloud Run passo a passo Como configurar secrets GitHub Deploy contínuo GCP

Como Fazer Deploy Automático no Google Cloud Run Usando Artifact Registry

19/10/2025 20:59

Introdução


Quer aprender a automatizar seu deploy no Google Cloud Run usando o GCP Artifact Registry?


Hoje vou te mostrar um passo a passo que normalmente ninguém explica. Essa prática vai levar suas habilidades de Cloud Computing e DevOps para outro nível, aumentando suas oportunidades profissionais.


Dominar o deploy automatizado une o conhecimento de desenvolvimento de software com a infraestrutura em nuvem, criando uma expertise escassa e altamente valorizada no mercado.


1. Configurando a Conta de Serviço no GCP


Esse é o primeiro passo para dominar o deploy automatizado.


Aqui você vai entender como dar as permissões certas para sua conta de serviço e, ao mesmo tempo, aprender a manejar a nuvem com inteligência financeira. Isso porque não adianta só subir projeto na GCP: é preciso saber reduzir custos e maximizar valor, uma habilidade rara e que diferencia o profissional comum do verdadeiro especialista.


Passos:

  1. Vá em IAM e Admin > Contas de Serviço.
  2. Clique em + Criar conta de serviço.
  3. Defina um nome e descrição.
  4. Atribua as seguintes permissões:
  • Administrador de ambiente e de objetos do Storage
  • Concede controle total dos ambientes do Cloud Composer e dos objetos do Cloud Storage.
  • Administrador de armazenamento
  • Garante acesso total sobre buckets e objetos no Cloud Storage.
  • Administrador do Artifact Registry
  • Permite criar e gerenciar repositórios no Artifact Registry.
  • Administrador do Cloud Run
  • Dá controle total sobre os serviços e jobs no Cloud Run.
  • Administrador do Service Usage
  • Pode ativar e desativar serviços, inspecionar operações, consumir cota e gerar faturamento.
  • Consumidor do Service Usage
  • Permite inspecionar estados e operações de serviço, além de consumir cota e gerar faturamento.
  • Editor do Cloud Build
  • Consegue criar e cancelar builds no Cloud Build.
  • Gravador de bucket de registros
  • Autoriza gravar logs em buckets de registros.
  • Leitor
  • Consegue visualizar a maioria dos recursos do Google Cloud.
  • Usuário da conta de serviços
  • Permite executar operações em nome da conta de serviço criada.


Finalize clicando em Concluído.


2. Gerando a Chave JSON


Agora que criamos a conta de serviço, precisamos gerar a chave JSON para que o GitHub Actions consiga autenticar no Google Cloud.


  • Vá em IAM > Contas de Serviço > Gerenciar Chaves.
  • Clique em Adicionar chave > Nova chave > JSON.
  • O arquivo será baixado automaticamente. Guarde-o em segurança.
  • Esse arquivo será usado como secret no seu repositório GitHub
  • .

O download do arquivo JSON será feito automaticamente para o seu computador.


⚠️ Atenção máxima aqui:

  • Esse arquivo é a identidade da sua conta de serviço.
  • Ele contém todas as credenciais necessárias para autenticar e manipular recursos na GCP.
  • A chave só é exibida uma vez no momento do download.
  • Se você perder ou expor esse arquivo, será necessário gerar uma nova chave, pois não é possível visualizá-lo novamente dentro do console.


👉 Guarde esse JSON em um local seguro.

Mais à frente, vamos armazená-lo nos Secrets do GitHub, para que o workflow de deploy use essas credenciais de forma protegida, sem nunca expor os dados no repositório público.


3. Criando Repositório no Artifact Registry


No console da GCP, pesquise por Artifact Registry.

Habilite o serviço, clique em Criar Repositório e escolha o tipo Docker.

Aqui está um detalhe fundamental que diferencia um desenvolvedor de alguém que domina Cloud Economics: a escolha da região.

  • Defina um nome claro e objetivo para o repositório.
  • Escolha a região com atenção.


💡 Conselho de especialista:

Sempre que possível, configure o Artifact Registry na mesma região do seu Cloud Run e dos seus principais serviços.


👉 Por quê?

Porque a GCP não cobra apenas pela instância em execução, mas também pelo egress.


O que é Egress?

Egress é o tráfego de dados que sai de um serviço da GCP para outro local (pode ser outra região, outro provedor de cloud, ou até para a internet).

  • Se o Cloud Run estiver em São Paulo e o Artifact Registry em outra região, cada requisição gera custo de egress.
  • Se os dois estiverem na mesma região, esse custo simplesmente não existe.

Esse é o tipo de decisão que, quando multiplicada por milhões de requisições, pode economizar milhares de dólares para sua empresa.

É aqui que a expertise em arquitetura cloud e a visão de otimização de custos fazem toda a diferença.


  1. Pesquise por Artifact Registry no console GCP.
  2. Habilite o serviço.
  3. Clique em Criar Repositório.
  4. Escolha o tipo Docker.
  5. Defina um nome claro e escolha a região (recomendo São Paulo, southamerica-east1, para evitar custos de egress).
  6. Crie o repositório.


Agora você terá onde armazenar as imagens Docker do seu projeto.


4. Preparando o Ambiente com Google Cloud CLI


No seu servidor ou workflow de CI, instale o Google Cloud SDK:

sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates gnupg curl
curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee /etc/apt/sources.list.d/google-cloud-sdk.list
sudo apt update
sudo apt install google-cloud-cli


Verifique a instalação:

gcloud version


5. Autenticando e Fazendo o Build da Imagem


Autentique-se com a chave JSON:

gcloud auth activate-service-account --key-file=./gcp-auth-file.json


Selecione o projeto:

gcloud config set project PROJECT_ID


Faça o build e envie para o Artifact Registry:

gcloud builds submit --tag southamerica-east1-docker.pkg.dev/SEU_PROJECT_ID/MEU_REPO/NOME_IMAGEM:latest


6. Configurando o Google Cloud Run


Agora que já temos a imagem Docker no Artifact Registry, é hora de configurar o Cloud Run, que será responsável por rodar seu serviço.


Por que usar o Cloud Run?


O Google Cloud Run é uma plataforma serverless que roda containers. Isso traz várias vantagens:

  • Escalabilidade automática: o Cloud Run aumenta ou reduz instâncias automaticamente de acordo com a demanda. Se não houver requisições, você não paga nada além do storage.
  • Custo por uso: você só paga enquanto o serviço está processando requisições. Nada de gastar com máquinas ociosas.
  • Sem precisar gerenciar servidores: não há manutenção de VMs, patches de segurança ou sistemas operacionais. Você foca só no seu código e container.
  • Flexibilidade: qualquer linguagem, framework ou biblioteca pode ser usada, desde que empacotada em um container.
  • Integração nativa com GCP: funciona em conjunto com IAM, Artifact Registry, Pub/Sub e outros serviços da Google Cloud.
  • Latência otimizada: se configurado corretamente (por exemplo, mantendo uma instância mínima), você reduz drasticamente o problema de cold start.


Esse é o poder de uma plataforma serverless moderna: você ganha velocidade, reduz custos e ainda leva para o mercado a expertise de entregar soluções que escalam sozinhas.


Criando o serviço no Cloud Run


  1. No console GCP, busque por Cloud Run.
  2. Clique em Criar serviço.
  3. Escolha a imagem Docker enviada ao Artifact Registry.
  4. Defina a mesma região usada no repositório.
  5. Configure:
  • Porta 8080
  • Recursos (ex.: 1 vCPU e 512 MB RAM)
  • Escalonamento automático (mínimo 1 instância para reduzir cold start)
  • Timeout e simultaneidade conforme sua necessidade


Clique em Criar e o deploy será iniciado.


7. Criando o Script deploy.sh


Antes de configurar o workflow do GitHub Actions, precisamos criar o script que vai orquestrar o processo de deploy: o deploy.sh.

Esse script é quem faz todo o trabalho pesado: autenticação, build da imagem, atualização do Cloud Run e até a limpeza de imagens antigas no Artifact Registry.

Ou seja, é a peça que garante que seu deploy não só acontece, mas acontece de forma organizada e sustentável.


Crie um arquivo chamado deploy.sh na raiz do projeto e adicione o seguinte conteúdo:

#!/bin/bash
set -e

# Verifica se todas as variáveis necessárias estão definidas
: "${PROJECT_ID:?Missing PROJECT_ID}"
: "${REPO_NAME:?Missing REPO_NAME}"
: "${REGION:?Missing REGION}"
: "${IMAGE_NAME:?Missing IMAGE_NAME}"
: "${IMAGE_TAG:?Missing IMAGE_TAG}"
: "${GCP_AUTH_KEY:?Missing GCP_AUTH_KEY}"
: "${CLOUD_RUN_JOB:?Missing CLOUD_RUN_JOB}"

KEEP_IMAGES=1

FULL_IMAGE_NAME="$REGION-docker.pkg.dev/$PROJECT_ID/$REPO_NAME/$IMAGE_NAME:$IMAGE_TAG"
AUTH_FILE=$(mktemp)

cleanup() {
    rm -f "$AUTH_FILE"
}
trap cleanup EXIT

echo "$GCP_AUTH_KEY" > "$AUTH_FILE"

echo "🔐 Authenticating with Google Cloud..."
gcloud auth activate-service-account --key-file="$AUTH_FILE"
gcloud config set project "$PROJECT_ID"

echo "📸 Getting current Cloud Run job image (for rollback reference)..."
CURRENT_IMAGE=$(gcloud run jobs describe "$CLOUD_RUN_JOB" --region="$REGION" --format="value(spec.template.spec.template.spec.containers[0].image)" 2>/dev/null || echo "none")
echo "Current image: $CURRENT_IMAGE"

echo "✅ Submitting build to GCP..."
gcloud builds submit --tag "$FULL_IMAGE_NAME"

echo "✅ Fetching latest image name..."
NEW_IMAGE=$(gcloud builds list --limit=1 --format="value(images)")
echo "✅ Build completed. Image: $NEW_IMAGE"

echo "🚀 Updating Cloud Run job: $CLOUD_RUN_JOB"
gcloud run jobs update "$CLOUD_RUN_JOB" \
    --image="$NEW_IMAGE" \
    --region="$REGION"

echo "✅ Cloud Run job updated successfully!"

echo "🧹 Cleaning up old images from Artifact Registry..."

echo "Fetching image list..."
OLD_IMAGES=$(gcloud artifacts docker images list "$REGION-docker.pkg.dev/$PROJECT_ID/$REPO_NAME/$IMAGE_NAME" \
    --format="value(IMAGE)" \
    --sort-by="~CREATE_TIME" \
    --limit=100)

if [ -z "$OLD_IMAGES" ]; then
    echo "No images found to clean up"
else
    IMAGE_ARRAY=($OLD_IMAGES)
    TOTAL_IMAGES=${#IMAGE_ARRAY[@]}
    
    echo "Found $TOTAL_IMAGES total images"
    echo "Keeping $KEEP_IMAGES most recent images"
    
    if [ $TOTAL_IMAGES -gt $KEEP_IMAGES ]; then
        IMAGES_TO_DELETE=${IMAGE_ARRAY[@]:$KEEP_IMAGES}
        echo "Deleting $(($TOTAL_IMAGES - $KEEP_IMAGES)) old images..."
        
        for img in $IMAGES_TO_DELETE; do
            echo "Deleting: $img"
            gcloud artifacts docker images delete "$img" --quiet --async || echo "⚠️  Failed to delete $img"
        done
        
        echo "✅ Cleanup initiated (running asynchronously)"
    else
        echo "No old images to delete (only $TOTAL_IMAGES images, keeping $KEEP_IMAGES)"
    fi
fi

echo "🎉 Deployment completed successfully!"
echo "📋 Summary:"
echo "  - Previous image: $CURRENT_IMAGE"
echo "  - New image: $NEW_IMAGE"
echo "  - Cloud Run job: $CLOUD_RUN_JOB (updated)"
echo "  - Old images: cleanup initiated"


Por que esse script é importante?

  • Rollback inteligente: guarda referência da imagem atual antes de atualizar, permitindo voltar atrás em caso de problema.
  • Automação total: você não precisa rodar dezenas de comandos manualmente.
  • Manutenção de custos: remove imagens antigas automaticamente para não pagar por storage desnecessário.
  • Padronização: qualquer membro da equipe pode rodar o mesmo fluxo de deploy sem erros.

Salve o arquivo, dê permissão de execução:

chmod +x deploy.sh

E pronto: agora você tem um motor de deploy inteligente pronto para ser chamado pelo GitHub Actions.


8. Automatizando Deploy com GitHub Actions


Crie o script deploy.sh para autenticar, buildar e atualizar o Cloud Run.

Em seguida, crie o arquivo .github/workflows/deploy.yml:


name: Build and Deploy Image to Artifact Registry

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      PROJECT_ID: ${{ secrets.PROJECT_ID }}
      REPO_NAME: ${{ secrets.REPO_NAME }}
      REGION: ${{ secrets.REGION }}
      IMAGE_NAME: ${{ secrets.IMAGE_NAME }}
      IMAGE_TAG: ${{ secrets.IMAGE_TAG }}
      GCP_AUTH_KEY: ${{ secrets.GCP_AUTH_KEY }}
      CLOUD_RUN_JOB: ${{ secrets.CLOUD_RUN_JOB }}

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Google Cloud CLI
        uses: google-github-actions/setup-gcloud@v2
        with:
          project_id: ${{ secrets.PROJECT_ID }}
          service_account_key: ${{ secrets.GCP_AUTH_KEY }}
          export_default_credentials: true

      - name: Run deploy script
        run: |
          chmod +x ./deploy.sh
          ./deploy.sh


9. Configurando Secrets no GitHub


Todos os valores usados no arquivo deploy.yml são carregados a partir de secrets do GitHub.

Isso garante que informações sensíveis, como sua chave JSON do GCP, ID do projeto e outros dados, não fiquem expostos no repositório.

Passos para configurar:

  1. No seu repositório no GitHub, clique em Settings (Configurações).
  2. No menu lateral, vá em Secrets and variables > Actions.
  3. Clique em New repository secret.
  4. Insira o nome do secret exatamente como está no seu deploy.yml (ex.: PROJECT_ID, REPO_NAME, REGION, IMAGE_NAME, IMAGE_TAG, GCP_AUTH_KEY, CLOUD_RUN_JOB).
  5. No campo Value, cole o valor correspondente:
  • PROJECT_ID: ID do seu projeto no GCP
  • REPO_NAME: Nome do repositório no Artifact Registry
  • REGION: Região (ex.: southamerica-east1)
  • IMAGE_NAME: Nome da imagem Docker
  • IMAGE_TAG: Normalmente latest ou outra tag de sua escolha
  • GCP_AUTH_KEY: conteúdo completo do arquivo JSON da conta de serviço
  • CLOUD_RUN_JOB: Nome do seu serviço/job no Cloud Run
  1. Clique em Add secret.
  2. Repita o processo para cada variável de ambiente necessária.

Depois de configurados, os secrets poderão ser acessados no workflow através da sintaxe:

${{ secrets.NOME_DO_SECRET }}


Conclusão

Com esses passos, você configurou um deploy automático no GCP Cloud Run usando Artifact Registry e GitHub Actions.

Isso garante mais agilidade, menos erros e uma cultura DevOps mais sólida.

Se quiser que eu aprofunde em rollback, ambientes de staging ou uso de GPU no Cloud Run, comente abaixo.

Artigo por Anderson Arruda.

Espaço para publicidade
0 Comentário(s)
Seja o primeiro a comentar o nosso artigo!
Todos os direitos reservados. © 2021-2031
SBBlog Powered By Powered By Sysborg | Powered By Anderson Arruda