Docker Systemstatus: Vollständiger Ausfall der Dienste

• In den Kernservices von Docker ist ein umfassender Ausfall aufgetreten
• Die Ursache wurde als Problem bei einem Cloud-Service-Provider identifiziert
• Die Fehlerrate wurde über die gesamten SaaS-Services hinweg beobachtet
• Die Wiederherstellung lief; der Übergang in die Phase Backlog-Bearbeitung und Überwachung wurde eingeleitet
• Schließlich wurde die Problemlösung bestätigt und die Normalisierung erklärt

---

Übersicht der Docker-Systemstörung

Bei verschiedenen Docker-Services wie Docker Hub Registry, Docker Authentication, Docker Hub Web Services, Docker Billing, Docker Hub Automated Builds, Docker Hub Security Scanning, Docker Scout, Docker Build Cloud, Testcontainers Cloud, Docker Cloud und Docker Hardened Images traten umfassende Zugriffs- und Nutzungsprobleme auf.

20. Oktober 2025 00:16 PDT / 07:16 UTC

[Untersuchung läuft]
Aufgrund von Zugriffs- und Nutzungsproblemen in vielen Produktservices wurde die Ursachenanalyse gestartet.

20. Oktober 2025 01:22 PDT / 08:22 UTC

[Ursache identifiziert]
Die Ursache der Störung wurde als ein Problem eines Cloud-Service-Providers festgestellt.
Es wurden interne Systeme vorbereitet und Monitoring betrieben, für den Fall, dass die Störung des Service-Providers behoben wird.

20. Oktober 2025 02:43 PDT / 09:43 UTC

[Überwachung]
Über alle SaaS-Services hinweg wurde eine schrittweise Erholung der Fehlerquote festgestellt.
Die kontinuierliche Überwachung wird zusammen mit der Backlog-Bearbeitung fortgesetzt.

20. Oktober 2025 03:05 PDT / 10:05 UTC

[Gelöst]
Dieser Ausfall wurde offiziell behoben.
Die Wiederherstellung des gesamten Servicebetriebs wurde bestätigt

[GN⁺]

Hacker News Kommentar

• Hallo, ich bin Tushar von Docker. Ich möchte mich für den Docker-Serviceausfall entschuldigen, der durch ein AWS-Problem ausgelöst wurde. Unser Team arbeitet eng mit AWS zusammen, um den Service so schnell wie möglich wiederherzustellen, und aktualisiert den Stand kontinuierlich auf dockerstatus.com. Wir wissen, wie wichtig Docker Hub und die Dienste für Millionen von Entwicklern weltweit sind. Wir tun alles, um eine schnelle Wiederherstellung zu erreichen. Sobald dieser Vorfall vollständig abgeschlossen ist, werden wir mit einem detaillierten Post-Mortem und unseren weiteren Gegenmaßnahmen berichten.
  • Mir kam dabei der Gedanke, wie witzig es wäre, wenn die Kettenreaktion durch DynamoDB ausgelöst würde, die vielleicht als Docker-Image auf Docker Hub gehostet wird.
• Das ist das Ergebnis eines AWS-Ausfalls. Referenz
  • Es heißt, dass bei einem der großen Cloud-Anbieter ein grundlegendes Problem entdeckt wurde; heutzutage nutzen doch alle mehrere Cloud-Anbieter, oder? Warum sind wir so stark von einem einzigen Anbieter abhängig?
• Wir sind auch auf mehrere öffentliche Docker-Images angewiesen. Standardmäßig nutzte Docker docker.io und die Builds wurden unterbrochen. Glücklicherweise bietet AWS einen Mirror-Dienst für docker.io an. Als wir auf
  FROM public.ecr.aws/docker/library/{image_name}
  umgestellt haben, liefen alle Builds wieder stabil. In den Fehlerprotokollen kam der Fehler am Authentifizierungs-Endpunkt (https://auth.docker.io) am häufigsten vor: „no server available to handle this request“. Nach dem Wechsel auf den AWS-Mirror liefen die Builds ohne Probleme.
  • Dass Docker durch den AWS-Ausfall nicht erreichbar war, während die AWS-Mirror-Registry intakt geblieben ist, ist etwas ironisch.
  • docker.io hat auch ein Rate Limit, und sobald ein Team ein gewisses Wachstum erreicht, treten Build-Fehler öfter auf. Auch der andere Image-Hosting-Service quay.io (im Besitz von Red Hat) war heute den ganzen Tag im Read-Only-Modus. Wenn ihr eine starke Abhängigkeit von Container-Images habt, lohnt sich eher eine eigene Hosting-Lösung, anstatt sich einfach auf fremde Infrastruktur zu stützen.
  • public.ecr.aws hat heute ebenfalls wegen des AWS-Ausfalls 5XX-Fehler geliefert, sodass es bei mir ebenfalls fehlgeschlagen ist. Referenz
  • Bei mir hat dieser Ansatz nicht funktioniert, aber mit dem Google-Mirror (mirror.gcr.io) hat es bestens geklappt. Es reicht, von
    FROM {image_name}
    auf
    FROM mirror.gcr.io/{image_name}
    zu wechseln. Vielleicht hilft das. Leitfaden
  • Ich betreibe ein großes Build-System, und der Image-Pull aus der ECR war den ganzen Tag instabil.
• Wenn man eigene Registry-Lösungen wie Nexus betreibt und auf gemeinsamen Basis-Images direkt eigene Container-Images baut, werden die Leute heute wohl froh sein über ihre Entscheidung. Ich frage mich, wie viele Builds oder Re-Deployments dieser Ausfall ruiniert hat. Gegen Docker oder Docker Hub habe ich nichts, ich nutze sie weiter aktiv.
  • Es ist eine wirklich wichtige Gewohnheit, einen Docker-Image-Cache dazwischenzulegen. Wenn Docker ein Upstream-Image plötzlich zurückzieht, kann ein Kubernetes-Knoten bei einem Node-Wechsel das Basis-Image nicht mehr finden und der Dienst startet nicht. Das ist für mich einfach sauberes Engineering.
  • Wir nutzen zwar Basis-Images, aber in der Bereitstellungsphase von GitHub Actions werden die Docker-Images gezogen, sodass die App-Builds funktionieren, aber das Deployment nicht. CI/CD hängt an Docker Hub, und bei manchen Images lässt sich der Pfad nicht über einen Pull-Through-Cache umleiten, was zu genau diesem Verhalten führt.
  • Wir betreiben Harbor und spiegeln mit einem Proxy-Cache alle Basis-Images; diese Konfiguration nutzen wir seit Jahren erfolgreich. Harbor hat zwar ein paar Nachteile, insgesamt aber ist es ziemlich zufriedenstellend.
  • Es beruhigt zusätzlich, dass wir gar keine Container verwenden.
  • Ohne manuelle Workarounds ist in Dev- oder Prod-Umgebungen keine neue Arbeit möglich. Ich glaube, der Impact ist ziemlich groß. Nebenbei scheint auch Signal betroffen zu sein.
• Der AWS-Ausfall ist auf HN interessanterweise stärker präsent als dieses Ereignis.
  • Nicht auf der eigentlichen Hauptseite, sondern auf der active page!
• Auch wenn es ein bisschen peinlich ist: Wenn ihr stark von Docker Hub abhängig seid, empfehle ich, Spegel in eurem Kubernetes-Cluster zu installieren.
  • Wenn Spegel wirklich vollständig Open Source wäre, sollte das klarer auf der Landingpage stehen. Die Möglichkeit, es sofort zu installieren und auszuprobieren, macht für uns als Ingenieur:innen einen riesigen Unterschied, weil dann kein Kaufprozess nötig ist.
  • Ich frage mich nach den Unterschieden zu Kuik. Spegel ist für mein Home-Lab etwas überdimensioniert, könnte in Unternehmensumgebungen aber ein gutes Upgrade sein. Kuik: Referenz
  • Es gibt Alternativen, die mehr Repositories als Docker Hub spiegeln. Die meisten sind etwas „Enterprise“-lastig, funktionieren aber wie beschrieben verlässlich. Artifactory, Nexus Repository, Cloudsmith und ProGet gehören dazu. Mit diesen habe ich schon mehrmals Krisen überstanden.
  • Spegel macht einen guten Eindruck, aber wir nutzen GKE, daher läuft es hier derzeit eher als provisorische Lösung. Ich bin neugierig, ob eine ordentliche GKE-Unterstützung dafür geplant ist.
• Das ist eine Art absichtliches Design.
  docker hat den Wunsch nach einer Private-Registry-Konfiguration erhalten, dies jedoch aus eigenem Interesse abgelehnt.
  Relevanter Stack Overflow-Thread
  Red Hat hat podman eingeführt, kompatibel mit Docker, und ermöglicht so eine Lösung dafür:
  /etc/config/docker:
  BLOCK_REGISTRY='--block-registry=all'
  ADD_REGISTRY='--add-registry=registry.access.redhat.com'
  • Ich halte diese Aussage für etwas weit hergeholt. Auch wenn man das Default-Registry-Verhalten von docker.io auf etwas anderes umstellen könnte, wäre es für die meisten zu viel Aufwand, das tatsächlich zu tun. In Wahrheit reicht es, Images korrekt zu taggen. In unserem Unternehmen ziehen wir kein einziges Image von docker.io; einfach <company-repo>/ vor den Image-Namen zu setzen, dauert zwei Sekunden.
  • Ich finde es akzeptabel, solche „Footguns“ in gewissem Maß zu tolerieren. Ich sehe den Nutzen domänenbasierter Image-Tags größer als das Missverständnis, das daraus entstehen kann. Wenn in Team-Dokumenten ein alter Befehl steht, kann man bei veralteter Docker-Konfiguration versehentlich aus dem globalen Public Registry ziehen. Persönlich wäre es besser, die globale Registry komplett zu entfernen und klar zu machen, woher ein Image stammt (aber ich glaube nicht, dass Docker das ernsthaft in Betracht zieht).
  • Für ECR als private Registry in der Region us-east-1 war dieser Ansatz im Testfall wirkungslos.
• Weil Docker down war, konnte ich mich nicht bei O'Reilly einloggen, und ich frage mich, ob die Idee „Wenn Docker down ist, lerne ich etwas anderes“ gerade deshalb aufkam.
  • Ein Pull-Through-Proxy mit allen kürzlich genutzten Paketen hilft.
• Eine Alternative, die anderen mit ähnlichen Problemen geholfen hat, war ghcr. Es ist kein vollständiger Ersatz, aber
  z. B.: docker pull ghcr.io/linuxcontainers/debian-slim:latest
  • Dieses Image ist seit über einem Jahr nicht mehr aktualisiert worden. Weitere Infos. Da Google Container Registry einen Pull-Through-Mirror anbietet, kann man einfach mirror.gcr.io als Präfix setzen und bei Docker Official Images library als Namespace verwenden, z. B. mirror.gcr.io/library/redis. Redis offizielle Seite
• Stand 20. Oktober 2025, 09:43 UTC: Die Wiederherstellung verläuft schrittweise. Die Fehlerquote bei SaaS-Diensten sinkt insgesamt. Wir bearbeiten den Backlog und überwachen die Situation weiter.