ハクソク

世界を動かす技術を、日本語で。

Dockerシステムの状況: 完全なサービス障害

217日前原文(dockerstatus.com)

概要

Dockerの複数サービスでアクセス障害が発生。 原因はクラウドサービスプロバイダーに起因。 段階的に復旧し、最終的に解決済み。 運用チームは継続的な監視を実施。 ユーザーへの影響や対応状況の時系列まとめ。

Dockerサービス障害の時系列

  • 2025年10月20日 07:16 UTC 多数のDockerサービスで アクセス障害 発生 ・影響範囲：Registry, Hub, Scout, DBC, DHIOperationalComponents, 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 Web Services ・ユーザーがサービス利用不可状態

  • 2025年10月20日 08:22 UTC 原因特定 ・クラウドサービスプロバイダー側の問題を確認 ・状況を監視しつつ、サービス復旧準備

  • 2025年10月20日 09:43 UTC 復旧傾向 ・SaaSサービスのエラー率が減少 ・バックログ処理と継続的な監視を実施

  • 2025年10月20日 10:05 UTC 障害解決 ・全サービスが正常稼働に復帰 ・インシデントは 解決済み

影響と対応

  • 影響サービス ・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 Web Services

  • ユーザー影響 ・イメージのプル・プッシュ不可 ・自動ビルドやセキュリティスキャンの停止 ・一部有料サービスの利用停止

  • 運用側対応 ・障害発生時から 即時調査・監視強化 ・クラウドプロバイダーと連携し状況把握 ・復旧後もシステム安定化を継続監視

今後の対策

  • 障害発生時の迅速な情報共有 体制強化
  • クラウド依存度のリスク管理
  • バックログ処理の自動化強化
  • 障害発生時のユーザー通知プロセス 見直し

Hackerたちの意見

AWSの障害の結果 https://news.ycombinator.com/item?id=45640754

└

クラウドサービスプロバイダーの一つに根本的な問題があることを特定しました。今の時代、みんな複数のクラウドプロバイダーを使ってるんじゃないの？なんで一つのクラウドプロバイダーの障害で影響を受けるの？

自分でNexusみたいなレジストリを運営して、共通のベースイメージからコンテナイメージを作ってる人たちは、今はちょっと安心してるんじゃないかな。これでどれだけビルドや再デプロイが壊れるのか気になる。個人的には、DockerやDocker Hubに対して特に文句はないけど、便利だと思ってるよ。

└

もし他のところからベースイメージを取得してるならね…

└

うちはHarborを運営してて、Proxy Cache機能を使ってすべてのベースイメージをミラーしてるんだ。これが結構いい感じ。もう何年もこの設定でやってるけど、うまくいってる一方で、Harborにはちょっとした粗さもあるよ。

└

Nexusをどこでホスティングしてるか、想像つく？

└

現在、dev/prod環境で新しいことをするのが手動の回避策なしではほとんどできない状態。影響はかなり大きいと思う。ちなみに、Signalも問題があるみたい。マジか。

└

ベースイメージは使ってるけど、残念ながらいくつかのGitHubアクションが準備段階でDockerイメージを引っ張ってるんだ。だからアプリはビルドできても、CI/CDがDocker Hubに依存してるからデプロイできないんだよね。イメージの引き先を変えられないから（プルスルーキャッシュを通せないし）…

うちのビルドが壊れちゃったのは、いくつかの公開Dockerイメージに依存してるからで、デフォルトでDockerはdocker.ioを使うんだ。ありがたいことに、AWSは待てない人のためにdocker.ioのミラーを提供してるよ： FROM public.ecr.aws/docker/library/{image_name} エラーログを見ると、問題は主に認証エンドポイントに関係してた： ▪ https://auth.docker.io → "このリクエストを処理できるサーバーがありません" AWSのミラーに切り替えたら、すべて問題なくビルドできたよ。

└

これをうまく動かすことはできなかったけど、Googleのミラーは問題なく使えたよ。 FROM {image_name}をFROM mirror.gcr.io/{image_name}に変更するだけだった。これが役に立てばいいな！

└

AWSの障害のせいでDockerがダウンしてるのはちょっと皮肉だね。でもAWSのミラーレポはまだ動いてるし…

└

public.ecr.awsは、AWSの障害のせいで5XXエラーが出てて使えなかったよ: https://news.ycombinator.com/item?id=45640754

AWSの9つの9は減るのかな？

└

マーケティング部門が計算した結果、ダメって言われた。

これが原因でO'Reillyにログインできないのかな。「Dockerがダウンしてるから、何か別のことをしないと」っていうトレーニングをやりたかったのに…

└

最近使ったパッケージを全部保存するプルスループロキシをインストールすればいいよ。

ちょっと宣伝だけど、Docker Hubに依存してるなら、KubernetesクラスターにSpegelをインストールするいいタイミングかも。 https://spegel.dev/

└

Docker Hub以外にもミラーリングしてる代替品はいくつかあるよ。大体はちょっと重たくて企業向けだけど、ちゃんと機能してくれるし、何度も助けられた。Artifactory、Nexus Repository、Cloudsmith、ProGetなんかがそうだね。

└

もし本当に完全にオープンソースなら、そのことをもっと目立たせてほしいな。技術者としてすぐに調査や導入ができるのは大きなポイントだし、ソフトウェア購入のために内部の手続きを全部通らなくて済むのは助かる。

└

kuikとの違いは何？ Spegelはうちのホームラボにはちょっと複雑すぎるけど、会社のためにはいいアップグレードになりそう。Kuik: https://github.com/enix/kube-image-keeper?tab=readme-ov-file...

└

これ良さそうだけど、うちはGKEを使ってるから、ちょっとハックしないと動かないみたい。GKEでちゃんと動くようにするタイムラインはあるの？

2025年10月20日09:43 UTC 現在回復中 > [モニタリング] SaaSサービスのエラー率が回復してきています。バックログを処理しながら引き続き監視しています。

影響を受けた他の人たちへ、今朝助けになったのはghcrを使うことだったよ。ただ、これは完全な置き換えではないけどね。例えば: docker pull ghcr.io/linuxcontainers/debian-slim:latest

└

そのイメージはもう1年以上前のものだよ: https://github.com/linuxcontainers/debian-slim/pkgs/containe... Google Container Registryはプルスルーミラーを提供してるから、mirror.gcr.ioをプレフィックスにして、Docker公式イメージ用にユーザーをlibraryにすればいいよ。例えば、mirror.gcr.io/library/redisはhttps://hub.docker.com/_/redisに対応してる。

registry-1.docker.ioが503エラーを返しているのに、「Docker Registry Uptime」を100%に保てるのはすごいね。

└

そうだね、サーバーは動いてたけど、ただHTTP 503を返してただけなんだよね…

Dockerにはまだあまり詳しくないんだけど、みんな本当に本番環境でパブリックイメージやレジストリに頼ってるの？ちょっと脆弱な戦略に思えるんだけど。