Postmortem: Imagem Docker não encontrada
Relatório de incidente para a interrupção do serviço Logto em 2023-12-17 devido à perda da imagem de produção do Docker.
Developer
Resumo
Experimentamos uma interrupção do serviço em 2023-12-17 devido à perda da imagem de produção do Docker do Logto.
- Horário do incidente: 2023-12-17 03:56:00 UTC
- Duração do incidente: 18 minutos
- Impacto no serviço: Serviço em nuvem Logto e serviço núcleo Logto ficaram indisponíveis durante o incidente.
- Nível de impacto: Crítico
- Causa raiz: Imagem de produção do Docker do Logto foi deletada por engano. Falha ao buscar a imagem no GitHub Container Registry.
Linha do tempo
| Horário | Evento |
|---|---|
| Início de 2023-12-17 (Horário específico desconhecido) | Workflow de retenção de imagens automatizado do GitHub do Logto sendo executado. Imagens de produção logto e logto-cloud foram deletadas por engano. |
| 2023-12-17 03:56:00 UTC | Serviço em nuvem Logto e serviço núcleo Logto ficaram indisponíveis. Incidente detectado por nosso sistema de monitoramento. |
| 2023-12-17 04:03:00 UTC | Incidente reconhecido pelo nosso engenheiro de plantão. |
| 2023-12-17 04:10:00 UTC | Novo deployment do serviço em nuvem Logto e serviço núcleo Logto iniciado com a imagem mais recente. |
| 2023-12-17 04:15:00 UTC | Serviço em nuvem Logto e serviço núcleo Logto ficaram disponíveis. Incidente resolvido automaticamente. |
Análise do incidente
O que aconteceu
As imagens de produção do serviço Logto foram deletadas pelo nosso workflow de retenção de imagens automatizado do GitHub. O serviço em nuvem falhou ao buscar a imagem no GitHub Container Registry e ficou indisponível.
Por que aconteceu
O workflow de retenção de imagens automatizado do GitHub deletou as imagens de produção por engano. O workflow foi projetado para deletar todas as imagens legadas sem tag que têm mais de 3 dias.
Nós tagueamos as imagens de produção com a tag prod para identificá-las como imagens de produção. Sempre que um deployment de produção é iniciado, uma nova imagem com a tag prod é construída e enviada para o GitHub Container Registry. A tag prod será removida da imagem antiga após a nova imagem ser construída e enviada com sucesso. A imagem antiga se tornará sem tag e será deletada pelo workflow de retenção de imagens automatizado do GitHub.
A imagem do serviço Logto foi construída para suportar múltiplas arquiteturas. A imagem foi construída com buildx e enviada ao GitHub Container Registry com a flag --platform. Todas as tags foram aplicadas à lista de manifestos raiz. A tag prod também foi aplicada à lista de manifestos raiz. Todas as subimagens listadas sob a lista de manifestos multi-arquitetura permaneceram sem tag.
A falta de revisão cuidadosa da estrutura de tags e lista de manifestos da imagem Docker nos levou a configurar o workflow de retenção de imagens automatizado do GitHub para deletar todas as imagens sem tag. O workflow deletou todas as subimagens listadas sob a lista de manifestos multi-arquitetura.
Impacto
Este incidente causou a indisponibilidade do serviço em nuvem Logto e do serviço núcleo Logto por cerca de 18 minutos. Os usuários finais não conseguiram fazer login no Logto e acessar suas aplicações cliente. O portal de administração em nuvem do Logto também ficou indisponível durante o incidente.
Resolução
Paramos o workflow de retenção de imagens automatizado do GitHub e implantamos uma nova imagem com a tag prod no GitHub Container Registry. A nova imagem foi buscada com sucesso pelo serviço em nuvem Logto e pelo serviço núcleo Logto. O serviço tornou-se disponível novamente.
Lições aprendidas
- Nunca publique um workflow sem revisão cuidadosa e testes no ambiente de produção.
- Faça um teste de execução (dry run) de qualquer trabalho de deleção de recursos antes de executá-lo.
- Sempre tenha um plano de backup para o ambiente de produção.
- Defina cuidadosamente uma nova política de retenção de imagens.
Medidas corretivas e preventivas
- ✅ Imediatamente parar o workflow de retenção de imagens automatizado do GitHub.