Analiza powypadkowa: obraz Docker nie znaleziony
Raport z incydentu w związku z przerwą w działaniu usługi Logto w dniu 2023-12-17 z powodu utraty produkcyjnego obrazu Docker.
Developer
Podsumowanie
Doświadczyliśmy przerwy w działaniu usługi w dniu 2023-12-17 z powodu utraty produkcyjnego obrazu Docker dla Logto.
- Czas incydentu: 2023-12-17 03:56:00 UTC
- Czas trwania incydentu: 18 minut
- Wpływ na usługę: Usługa chmurowa Logto i usługa podstawowa Logto były niedostępne podczas incydentu.
- Poziom wpływu: Krytyczny
- Główna przyczyna: Produkcyjny obraz Docker Logto został przypadkowo usunięty. Nie udało się pobrać obrazu z GitHub Container Registry.
Chronologia
| Czas | Wydarzenie |
|---|---|
| Wczesny 2023-12-17 (dokładny czas nieznany) | Automatyczny przepływ pracy retencji obrazów GitHub Logto został wykonany. Obrazy produkcyjne logto i logto-cloud zostały usunięte przypadkowo. |
| 2023-12-17 03:56:00 UTC | Usługa chmurowa Logto i usługa podstawowa Logto stały się niedostępne. Incydent wykryty przez nasz system monitorowania. |
| 2023-12-17 04:03:00 UTC | Incydent został potwierdzony przez naszego inżyniera na wezwanie. |
| 2023-12-17 04:10:00 UTC | Nowe wdrożenie usługi chmurowej Logto i usługi podstawowej Logto zostało uruchomione z najnowszym obrazem. |
| 2023-12-17 04:15:00 UTC | Usługa chmurowa Logto i usługa podstawowa Logto stały się dostępne. Incydent rozwiązany automatycznie. |
Analiza incydentu
Co się stało
Produkcja obrazów usługi Logto została usunięta przez nasz automatyczny przepływ pracy retencji obrazów GitHub. Usługa chmurowa nie zdołała pobrać obrazu z GitHub Container Registry i stała się niedostępna.
Dlaczego to się stało
Automatyczny przepływ pracy retencji obrazów GitHub przypadkowo usunął produkcyjne obrazy. Przepływ pracy został zaprojektowany do usuwania wszystkich nieotagowanych starszych obrazów, które mają więcej niż 3 dni.
Otagowaliśmy produkcyjne obrazy tagiem prod w celu identyfikacji jako obrazy produkcyjne. Kiedy zostaje uruchomione wdrożenie produkcyjne, nowy obraz z tagiem prod jest budowany i wysyłany do GitHub Container Registry. Tagi prod są usuwane ze starego obrazu po pomyślnym zbudowaniu i wysłaniu nowego obrazu. Stary obraz staje się nieotagowany i zostanie usunięty przez automatyczny przepływ pracy retencji obrazów GitHub.
Obraz usługi Logto został zbudowany do obsługi wielu architektur. Obraz został zbudowany z użyciem buildx i wysłany do GitHub Container Registry z flagą --platform. Wszystkie tagi zostały przypisane do głównej listy manifestów. Tag prod również został przypisany do głównej listy manifestów. Wszystkie podobrazy wymienione pod listą manifestów multi-arch pozostają nieotagowane.
Brak starannego przeglądu struktury tagów i listy manifestów obrazu Docker, po prostu skonfigurowaliśmy automatyczny przepływ pracy retencji obrazów GitHub do usuwania wszystkich nieotagowanych obrazów. Przepływ pracy usunął wszystkie podobrazy wymienione pod listą manifestów multi-arch.
Wpływ
Ten incydent spowodował, że usługa chmurowa Logto i usługa podstawowa Logto były niedostępne przez około 18 minut. Użytkownicy końcowi nie mogli zalogować się do Logto i uzyskać dostępu do swoich aplikacji klienckich. Portal administracyjny chmury Logto również był niedostępny podczas incydentu.
Rozwiązanie
Zatrzymaliśmy automatyczny przepływ pracy retencji obrazów GitHub i wdrożyliśmy nowy obraz z tagiem prod do GitHub Container Registry. Nowy obraz został pomyślnie pobrany przez usługę chmurową Logto i usługę podstawową Logto. Usługa stała się ponownie dostępna.
Wnioski
- Nigdy nie publikuj przepływu pracy bez starannej oceny i testowania w środowisku produkcyjnym.
- Wykonaj próbne uruchomienie dowolnego zadania usunięcia zasobów przed jego wykonaniem.
- Zawsze miej plan awaryjny dla środowiska produkcyjnego.
- Starannie zdefiniuj nową politykę retencji obrazów.
Środki naprawcze i zapobiegawcze
- ✅ Natychmiast zatrzymaj automatyczny przepływ pracy retencji obrazów GitHub.