APRENDER. PRATICAR. EVOLUIR.Relacionar imagem, revisão e pedido
Uma tag de imagem pode mudar no registry, mas a revisão Cloud Run conserva o digest resolvido na publicação. No exercício, stable passa de A para B e produção continua a executar A porque não houve nova revisão selecionada. O ticket deve indicar digest e revisão, não apenas a tag. Depois confirma quais clientes usam o URL normal e quais usam URLs com tag de revisão. Esse mapa evita misturar teste funcional de um artefacto com evidência de que o tráfego de produção já o alcança.
Ensaiar o caminho que recebe a percentagem
Com 90% para a revisão antiga e 10% para a nova no URL normal, uma chamada direta ao URL com tag da nova seleciona essa revisão. Não demonstra falha da distribuição 90/10. Usa o URL adequado para cada objetivo de teste e regista a revisão observada. Pequenas amostras não têm de corresponder exatamente às percentagens configuradas; não transformes uma contagem pequena em prova definitiva. Mantém autenticação e identidade representativas para que um teste de release não contorne o controlo que os clientes reais têm de satisfazer.
Escolher o contrato de versão dos secrets
Um secret exposto como variável de ambiente é obtido no arranque da instância. Usar latest pode fazer instâncias arrancadas em momentos diferentes receberem versões distintas. Fixar uma versão ajuda a tornar a release previsível e a planear rotação. Segredos montados como ficheiros têm outro momento de leitura, que deve ser analisado no respetivo contrato. Em qualquer caso, a service identity precisa do acesso aplicável. O deployer conseguir ler o secret não demonstra que a aplicação consegue arrancar com ele. Não incorpores o valor na imagem para contornar a falha.
Verificar rollback com arranque novo
A revisão anterior pode ser imutável e depender de um secret que entretanto foi desativado. Instâncias já iniciadas podem continuar a responder enquanto novas falham. Um gate de rollback deve incluir arranque novo e compatibilidade com a versão de dados e segredos disponível. Se a versão antiga foi retirada por um motivo válido, não a reatives automaticamente; pode ser preferível publicar configuração corrigida com uma versão aprovada. Se houve operações de resultado incerto, conserva as identidades de negócio para reconciliação antes de reenviar trabalho.
Calcular capacidade sem prometer uma barreira rígida
Doze instâncias com pools de cinco ligações dão uma estimativa nominal de sessenta. Um limite configurado de instâncias pode ser excedido brevemente e outros clientes também podem usar a base. Portanto, não uses a multiplicação como garantia de admissão estrita. Reserva headroom, controla pools e observa ligações efetivas no destino. Se o limite útil for sessenta e dez estiverem reservadas, dez instâncias de cinco usam as cinquenta restantes neste modelo. Ainda é necessário ensaiar picos, sobreposição de revisões e comportamento quando a dependência recusa novas ligações.
Comparar revisões com denominadores corretos
Na mesma janela, doze erros em duzentos pedidos da nova revisão dão 6%; oito em oitocentos da antiga dão 1%. O agregado é 20/1000=2% e pode esconder a regressão. Compara também o tipo de pedido e a população para não atribuir causalidade apenas à percentagem. Para procurar logs, usa projeto, serviço, revisão e janela relevantes. Um filtro preso à revisão antiga exclui a evidência pretendida. Mantém correlação suficiente para seguir uma operação sem registar tokens ou valores de secrets no diagnóstico.
Entregar evidência que permita repetir a decisão
O registo de release deve ligar digest, revisão, configuração de secrets, identidade runtime, destino de tráfego e critérios observados. Define o limiar para interromper promoção e quem aceita a recuperação. Uma taxa de erro menor não basta se os pedidos críticos deixaram de chegar ao serviço. No handover, inclui um ensaio de arranque e um de operação útil por consumidor. Os cálculos e modelos desta aula são sintéticos; não representam uma execução real de Cloud Run nem garantem o comportamento de uma subscrição sem o ensaio autorizado correspondente.
O rollback responde numa instância quente mas falha ao escalar porque o secret fixado foi desativado. O teste de arranque revela a dependência antes de declarar recuperação.
Armadilhas comuns
Confundir retagging com deployment; usar tag URL para avaliar percentagens globais; assumir atualização simultânea de env secrets; tratar máximo de instâncias como limite absoluto de ligações.
Tópicos relacionados: Cloud Run e observabilidade · Gestão de segredos e rollback
Uma release recuperável precisa de artefacto identificado, caminho observado e dependências que também suportem um novo arranque.
Referência: Cloud Run traffic and rollback · Standard exam guide linked 2026-09-29; edition date unconfirmed