Um deploy substitui a API e o health check falha. Fazer pull de latest mais uma vez pode trazer exatamente a imagem que acabou de falhar. Um rollback reproduzível precisa identificar o artefato anterior e conservar as condições para executá-lo.

Registre o digest após promover uma versão

Guarde a referência completa da imagem com seu digest, além da versão da configuração de deploy. Depois que a nova versão passa nas verificações, a versão ativa anterior se torna a candidata de rollback. Mantenha as duas imagens disponíveis no registry ou no host conforme seu plano de recuperação. Se houver limpeza automática, teste se a imagem anterior continua disponível após a retenção.

Um health check que só confirma que o processo iniciou é insuficiente para promover uma API que depende do banco. Separe a verificação de processo da verificação de prontidão e valide uma operação representativa. Em uma VPS que roda uma réplica por vez, considere a interrupção causada pela substituição e meça o tempo de recuperação.

O banco também faz parte do rollback

Imagine que a versão nova remove uma coluna ainda lida pela versão anterior. Voltar o container deixa a API antiga incompatível com o banco. Para uma mudança desse tipo, faça primeiro uma migração aditiva, publique uma versão que funciona durante a transição e retire a coluna depois que a janela de rollback fechar.

Teste o retorno usando uma imagem anterior e o schema que permaneceria após um deploy malsucedido. O resultado precisa demonstrar que a versão anterior inicia e executa uma chamada real.

Docker image pull por digest · Testes de integração com PostgreSQL