• postmortem
  • cloud-service
  • incident

Postmortem: Immagine Docker non trovata

Rapporto sull'incidente per l'interruzione del servizio Logto del 2023-12-17 a causa della perdita dell'immagine Docker di produzione.

Simeng
Simeng
Developer

Riassunto

Abbiamo sperimentato un'interruzione del servizio il 2023-12-17 a causa della perdita dell'immagine Docker di produzione di Logto.

  • Orario dell'incidente: 2023-12-17 03:56:00 UTC
  • Durata dell'incidente: 18 minuti
  • Impatto sul servizio: Il servizio cloud di Logto e il servizio core di Logto non erano disponibili durante l'incidente.
  • Livello di impatto: Critico
  • Causa principale: L'immagine Docker di produzione di Logto è stata cancellata per errore. Non è stato possibile recuperare l'immagine dal GitHub Container Registry.

Cronologia

OrarioEvento
Inizio 2023-12-17 (Orario specifico sconosciuto)Esecuzione del workflow automatizzato di conservazione delle immagini GitHub di Logto. Le immagini di produzione logto e logto-cloud sono state cancellate per errore.
2023-12-17 03:56:00 UTCIl servizio cloud di Logto e il servizio core di Logto sono diventati non disponibili. L'incidente è stato rilevato dal nostro sistema di monitoraggio.
2023-12-17 04:03:00 UTCL'incidente è stato riconosciuto dal nostro ingegnere reperibile.
2023-12-17 04:10:00 UTCNuovo deployment del servizio cloud di Logto e del servizio core di Logto avviato con l'ultima immagine disponibile.
2023-12-17 04:15:00 UTCIl servizio cloud di Logto e il servizio core di Logto sono tornati disponibili. L'incidente è stato risolto automaticamente

Analisi dell'incidente

Che cosa è successo

Le immagini di produzione del servizio Logto sono state cancellate dal workflow automatizzato di conservazione delle immagini GitHub. Il servizio cloud non è riuscito a recuperare l'immagine dal GitHub Container Registry e non è stato disponibile.

Service Log

Perché è successo

Il workflow automatizzato di conservazione delle immagini GitHub ha cancellato per errore le immagini di produzione. Il workflow era progettato per cancellare tutte le immagini non taggate che erano più vecchie di 3 giorni.

Abbiamo taggato le immagini di produzione con il tag prod per identificarle come immagini di produzione. Ogni volta che viene avviato un deployment di produzione, una nuova immagine con il tag prod viene costruita e inviata al GitHub Container Registry. Il tag prod viene rimosso dall'immagine vecchia dopo che la nuova immagine è stata costruita e inviata con successo. L'immagine vecchia diventa non taggata e verrà cancellata dal workflow automatizzato di conservazione delle immagini GitHub.

Le immagini del servizio Logto sono state costruite per supportare architetture multiple. L'immagine è stata costruita con buildx e inviata al GitHub Container Registry con il flag --platform. Tutti i tag sono stati applicati alla lista manifest principale. Anche il tag prod è stato applicato alla lista manifest principale. Tutte le sottocategorie di immagini elencate sotto la lista manifest multi-arch sono rimaste non taggate.

A causa della mancanza di un'attenta revisione della struttura dei tag e della lista manifest delle immagini Docker, abbiamo semplicemente configurato il workflow automatizzato di conservazione delle immagini GitHub per cancellare tutte le immagini non taggate. Il workflow ha cancellato tutte le sottocategorie di immagini elencate sotto la lista manifest multi-arch.

Impatto

Questo incidente ha causato l'indisponibilità del servizio cloud di Logto e del servizio core di Logto per circa 18 minuti. Gli utenti finali non sono stati in grado di accedere a Logto e alle loro applicazioni client. Anche il portale admin del cloud di Logto non era disponibile durante l'incidente.

Risoluzione

Abbiamo interrotto il workflow automatizzato di conservazione delle immagini GitHub e distribuito una nuova immagine con il tag prod sul GitHub Container Registry. La nuova immagine è stata recuperata con successo dal servizio cloud di Logto e dal servizio core di Logto. Il servizio è tornato disponibile.

Lezioni apprese

  • Non pubblicare mai un workflow senza una revisione e un test accurati nell'ambiente di produzione.
  • Eseguire una simulazione di qualsiasi lavoro di eliminazione di risorse prima di eseguirla.
  • Avere sempre un piano di riserva per l'ambiente di produzione.
  • Definire accuratamente una nuova politica di conservazione delle immagini.

Misure correttive e preventive

  • ✅ Interrompere immediatamente il workflow automatizzato di conservazione delle immagini GitHub.