Dockerシステムステータス: 全サービス中断

• Dockerの主要サービスで広範な障害が発生
• 障害の原因はクラウドサービスプロバイダーの問題として確認
• SaaS全体のサービスでエラー率の上昇が観測
• エラー復旧作業が進行し、バックログ処理と監視の段階に入る
• 最終的に問題が解決し、正常化が宣言

---

Dockerシステム障害概要

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、Docker Hardened ImagesなどのDockerの主要サービスにおいて、アクセスおよび利用に関する広範な問題が発生

2025年10月20日 00:16 PDT / 07:16 UTC

[調査中]
多数の製品サービス全体で接続および利用問題が発生したことを受けて、原因調査を開始

2025年10月20日 01:22 PDT / 08:22 UTC

[原因特定]
クラウドサービスプロバイダーの問題により障害の原因を特定
サービスプロバイダー障害が解消されることを見越して、システム準備と監視を進める

2025年10月20日 02:43 PDT / 09:43 UTC

[監視]
SaaSサービス全体でエラー率が徐々に回復する傾向を確認
バックログ処理とともに、継続的な状態監視を実施

2025年10月20日 03:05 PDT / 10:05 UTC

[解決]
この障害は正式に解決 サービス全体の正常化を確認

[GN⁺]

Hacker Newsのコメント

• こんにちは、DockerのTusharです。現在、AWSの問題により発生したDockerサービス停止についてお詫びします。私たちのチームはAWSと協力し、サービスをできるだけ早く復旧するために取り組んでいます。dockerstatus.comで継続的に更新しています。Docker Hubとそのサービスが世界中の数百万人の開発者にとってどれほど重要か、理解しています。できるだけ早く復旧するために最善を尽くします。今回の事象が完全に解決された後、今後の対応方針と合わせて詳細なポストモーテムを発表する予定です
  • 今回の連鎖障害の原因になったDynamoDBが、もしDockerイメージとしてDocker Hubでホスティングされていたなら、かなり面白いと思いました
• AWS障害の結果です 参考リンク
  • 「クラウドサービスプロバイダの一社で根本的な問題を見つけた」と言っていますが、最近はみんな複数のクラウド事業者を使っていないでしょうか？なぜ一社の障害でここまで影響を受けるのか気になります
• 私たちも複数のpublic Dockerイメージに依存しており、通常Dockerはdocker.ioを使用しているためビルドが壊れました。幸い、AWSがdocker.ioミラーサービスを提供していたので、
  FROM public.ecr.aws/docker/library/{image_name}
  に変更したところ、すべて正常にビルドされました。エラーログでは認証エンドポイント(https://auth.docker.io)で
  「リクエストを処理できるサーバーがありません」というエラーがほとんどでした。AWSミラーに切り替えた後、問題なくビルドが成功しました
  • DockerがAWS障害でダウンしているのに、AWSミラーリポジトリが問題なく動いているのはやや皮肉です
  • docker.ioにはレート制限もかかるため、組織がある程度成長するとビルド失敗が頻繁に起き始めます。ちなみに、別のイメージホスティングサービスであるquay.io（Red Hat所有）も、今日一日中read-onlyの状態でした。コンテナイメージに依存する場合、他人の船にただ乗るのではなく、適切なホスティングソリューションを整えるのが良いです
  • public.ecr.awsも今日のAWS障害で5XXエラーが表示され、私の環境では失敗しました 参考リンク
  • この方法はうまくいきませんでしたが、Googleのミラー（mirror.gcr.io）を使うとちゃんと動きました。
    FROM {image_name}
    から
    FROM mirror.gcr.io/{image_name}
    に置き換えるだけです。役立てば幸いです。 関連ガイド
  • 私は大規模なビルドシステムを運用しており、ECRでのイメージpullが一日中不安定でした
• Nexusなどの自前レジストリを運用し、共通のベースイメージとして直接コンテナイメージをビルドしている人たちは、今日こそその選択が堅牢だと感じているのではないかと思います。このような障害がどれだけ多くのビルドや再デプロイを潰してしまうのか気になります。DockerやDocker Hubへの反感はなく、私は実用的に使っています
  • Dockerイメージキャッシュを中間に置くのは本当に大事な習慣です。dockerでupstreamイメージを突然削除すると、K8sノードを交換する際にベースイメージが見つからずサービス起動が難しくなります。これはエンジニアリングの健全性だと考えます
  • 私たちもベースイメージを使用していますが、GitHub Actionsの準備段階でdockerイメージを取得する部分があるため、アプリケーションビルドはできてもデプロイはできませんでした。CI/CDがdockerhubに依存しており、いくつかのイメージはpull-through cacheでパスを変更できないため、この状態になります
  • 私たちはHarborを運用しており、Proxy Cacheで全てのベースイメージをミラーリングしています。この構成を何年も使っており、よく機能しています。Harborにも少し欠点はありますが、全体としてはかなり満足しています
  • コンテナ自体をまったく使わないので、さらに安心できる瞬間です
  • 手作業のワークアラウンドなしではdevやprod環境で新しい作業ができない状態です。影響は相当大きいと思います。ちなみにSignalも今日問題があったようです
• AWS障害の報道より、この障害の方がHNメインに載っているのがかなり興味深いです
  • 本当の秘密メインページではありません！ activeページ
• 多少は恥ずかしい広告になりますが、Docker Hubへの依存が大きい場合はKubernetesクラスターにSpegelをインストールすることを推奨します
  • 本当にフルオープンソースなら、ランディングページにもっと明確に表示してほしいです。すぐにインストールして試せれば、エンジニアとして本当に大きな差になります。なぜなら、購入プロセスを経ないで済むからです
  • kuikとの違いが気になります。Spegelは私のホームラボにはややオーバースペックですが、会社の環境には良いアップグレードになりそうです。Kuik: 参考
  • Docker Hub以外にも、より多くのリポジトリをミラーリングする代替手段があります。ほとんどはエンタープライズ級の使いにくさがありますが、仕様どおりにしっかり動作します。Artifactory、Nexus Repository、Cloudsmith、ProGetなどがあります。これらのおかげで、何度も危機から脱する経験があります
  • Spegelは良いと思いますが、私たちはGKEを使っているため、現時点では少し抜け道としてのみ動作しています。GKEで正式にサポートされる予定があるか気になります
• これはある意味、意図的な設計です。
  dockerはプライベートレジストリの設定機能のリクエストを受けましたが、自己保身のため拒否しました
  関連 stackoverflow
  Red Hatはdockerと互換性のあるpodmanを作って、この部分を埋められるようにしました
  /etc/config/docker:
  BLOCK_REGISTRY='--block-registry=all'
  ADD_REGISTRY='--add-registry=registry.access.redhat.com'
  • 私はこれを飛躍しすぎていると見ています。デフォルトレジストリをdocker.ioの代わりに別の場所へ変更できたとしても、ほとんどの人は面倒でやらないだろうと思います。実際、イメージ名にタグを正しく付けるだけで十分だと思います。私たちの会社では、1つとしてdocker.ioからイメージをpullしません。イメージ名の前に<company-repo>/を付けるのに2秒しかかかりません
  • この種の「誤作動を招く設計（footgun）」をある程度許容してよいと考えます。domainを含むイメージタグの表現力から生まれる誤解より、メリットの方が大きいと感じます。たとえば、チームのドキュメントにコマンドが書かれていてdocker設定が古くなっていると、たまたまグローバルなパブリックレジストリからpullしてしまう可能性があります。個人的には、グローバルレジストリ自体をなくし、どこから取得しているかを明確に見えるようにするほうがいいと思います（ただしdockerがこれを真剣に検討しないと思います）
  • us-east-1リージョンでECRをプライベートレジストリとして使っていた場合、この方法は役に立ちませんでした
• Dockerが落ちていてO'Reillyにもログインできないのですが、だから『Dockerダウンなら他のことを学べば』と思っていたのがこの障害のせいなのか気になります
  • 最近使っていたすべてのパッケージを保存するpull-through proxyをインストールすればよいです
• 同様の問題に直面している他の人に役立った方法はghcrの使用でした。完全な代替にはなりませんが
  例: docker pull ghcr.io/linuxcontainers/debian-slim:latest
  • このイメージは1年以上更新がありませんでした 関連リンク。Google Container Registryからpull-throughミラーを提供しているため、mirror.gcr.ioをprefixとして付けるだけでよいです。Docker Official Imagesの場合はlibraryをユーザとして使い、例えばmirror.gcr.io/library/redisを使います redis公式ページ
• 2025年10月20日 09:43 UTC時点で徐々に復旧中です。SaaSサービス全体でエラー率が下がっていることが観測されています。バックログを処理しながら、状況を継続してモニタリングしています