Nachbesprechung: Docker-Image nicht gefunden
Vorfallsbericht für den Ausfall des Logto-Dienstes am 17.12.2023 aufgrund des Verlusts des Produktions-Docker-Images.
Developer
Zusammenfassung
Wir haben am 17.12.2023 einen Diensteseitigen Ausfall erlebt, da das Logto-Produktions-Docker-Image verloren ging.
- Vorfallszeit: 2023-12-17 03:56:00 UTC
- Dauer des Vorfalls: 18 Minuten
- Dienstauswirkung: Logto-Cloud-Dienst und Logto-Kerndienst waren während des Vorfalls nicht verfügbar.
- Auswirkungsgrad: Kritisch
- Ursache: Logto-Produktions-Docker-Image wurde versehentlich gelöscht. Fehler beim Abrufen des Images aus dem GitHub Container Registry.
Zeitachse
| Zeit | Ereignis |
|---|---|
| Früher 2023-12-17 (genaue Uhrzeit unbekannt) | Logto automatisierter GitHub-Image-Rückhalteprozess wurde ausgeführt. logto und logto-cloud Produktionsimages wurden versehentlich gelöscht. |
| 2023-12-17 03:56:00 UTC | Logto-Cloud-Dienst und Logto-Kerndienst wurden nicht verfügbar. Vorfall wurde von unserem Überwachungssystem erkannt. |
| 2023-12-17 04:03:00 UTC | Vorfall wurde von unserem Bereitschaftsingenieur anerkannt. |
| 2023-12-17 04:10:00 UTC | Neue Bereitstellung des Logto-Cloud-Dienstes und Logto-Kerndienstes wurde mit dem neuesten Image ausgelöst. |
| 2023-12-17 04:15:00 UTC | Logto-Cloud-Dienst und Logto-Kerndienst wurden wieder verfügbar. Vorfall wurde automatisch gelöst. |
Vorfallsanalyse
Was passiert ist
Logto-Produktionsimages wurden durch unseren automatisierten GitHub-Image-Rückhalteprozess gelöscht. Der Cloud-Dienst konnte das Image nicht aus dem GitHub Container Registry abrufen und wurde nicht verfügbar.
Warum es passiert ist
Der automatisierte GitHub-Image-Rückhalteprozess hat die Produktionsimages versehentlich gelöscht. Der Workflow war so konzipiert, dass alle nicht gekennzeichneten alten Images, die älter als 3 Tage sind, gelöscht werden.
Wir haben die Produktionsimages mit dem Tag prod versehen, um sie als Produktionsimages zu identifizieren. Jedes Mal, wenn eine Produktionsbereitstellung ausgelöst wird, wird ein neues Image mit dem Tag prod erstellt und in das GitHub Container Registry hochgeladen. Der prod Tag wird von dem alten Image entfernt, sobald das neue Image erfolgreich erstellt und hochgeladen wurde. Das alte Image wird dadurch nicht gekennzeichnet und vom automatisierten GitHub-Image-Rückhalteprozess gelöscht.
Logto-Dienst-Images wurden so aufgebaut, dass sie mehrere Architekturen unterstützen. Das Image wurde mit buildx gebaut und mit dem --platform Flag in das GitHub Container Registry hochgeladen. Alle Tags wurden auf die Hauptmanifest-Liste angewendet. Der prod Tag wurde ebenfalls auf die Hauptmanifest-Liste angewendet. Alle Teil-Images, die unter der Multi-Arch-Manifest-Liste aufgelistet sind, bleiben unmarkiert.
Aufgrund eines Mangels an sorgfältiger Überprüfung der Tag- und Manifestlistenstruktur des Docker-Images haben wir einfach den automatisierten GitHub-Image-Rückhalteprozess so konfiguriert, dass alle unmarkierten Images gelöscht werden. Der Workflow löschte alle Teil-Images, die unter der Multi-Arch-Manifest-Liste aufgeführt sind.
Auswirkung
Dieser Vorfall führte dazu, dass der Logto-Cloud-Dienst und der Logto-Kerndienst etwa 18 Minuten lang nicht verfügbar waren. Endbenutzer konnten sich nicht bei Logto anmelden und nicht auf ihre Clientanwendungen zugreifen. Das Logto-Cloud-Admin-Portal war während des Vorfalls ebenfalls nicht verfügbar.
Lösung
Wir haben den automatisierten GitHub-Image-Rückhalteprozess gestoppt und ein neues Image mit dem Tag prod in das GitHub Container Registry hochgeladen. Das neue Image wurde erfolgreich vom Logto-Cloud-Dienst und dem Logto-Kerndienst abgerufen. Der Dienst wurde wieder verfügbar.
Lektionen gelernt
- Niemals einen Workflow ohne sorgfältige Überprüfung und Tests in der Produktionsumgebung veröffentlichen.
- Jede Ressourcenlöschungsaufgabe im Vorfeld simulieren, bevor sie ausgeführt wird.
- Immer einen Backup-Plan für die Produktionsumgebung haben.
- Sorgfältig eine neue Image-Rückhaltepolitik definieren.
Korrektive und präventive Maßnahmen
- ✅ Sofortiger Stopp des automatisierten GitHub-Image-Rückhalteprozesses.