Docker

冒頭まとめ Docker の 429 Too Many Requests は、そのほとんどが Docker Hub の pull 回数制限です。公式文書に明記された現行の制限は、匿名（未認証）が6時間あたり100回、認証済みの Docker Personal が6時間あたり200回、Pro・Team・Business の有料プランはフェアユースの範囲で無制限です。ここで最も重要なのは回数の数字ではなく、数える単位です。匿名の枠は IPv4 アドレス（または IPv6 の /64 サブネット）単位で数えられるため、同じ NAT の下にいる社内の全マシン、CI の全ジョブ、Kubernetes クラスタの全ノードが1つの枠を共有します。自分はほとんど pull していないのに突然429になる場合、枠を使い切ったのは同じ IP を共有する誰かです。認証すると枠がアカウント単位に変わるため、対処の第一歩は回数を増やすことではなく、帰属を IP からアカウントに切り替えることです。 数えられ方も公式に定義されています。ローカルの確認だけで済む version check は消費に数えられず、通常のイメージの pull はマニフェスト1つで1回、マルチアーキテクチャのイメージは取得したアーキテクチャごとに1回と数えます。対処は3方向に整理できます。認証してアカウント単位の枠にする（原因1）、ミラーやキャッシュで pull の回数自体を減らす（原因2）、そして帰属や別種の制限を確認する（原因3）です。 エラーの概要 制限を超えた状態でマニフェストを要求すると、Docker Hub は 429 と次の本文を返します。この文言は公式文書に掲載されているものです。 You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limits CLI や Docker Engine のログでは toomanyrequests: を先頭に付けた形で現れます。Kubernetes 経由では、kubelet のイベント（ErrImagePull / ImagePullBackOff の理由）に同じ文言が記録されます。 ...

冒頭まとめ Docker で 500 Internal Server Error が出たときは、どこが500を返したかを最初に見極めます。原因はほぼ次の3系統のいずれかです。第一に、Windows の Docker Desktop でエンジンが起動していない状態です。この場合「request returned Internal Server Error for API route and version …」という形式のメッセージになります。第二に、docker pull や docker push の相手であるレジストリ（イメージの配布サーバー）側の障害です。この場合「received unexpected HTTP status: 500 Internal Server Error」という形式になります。第三に、Docker デーモン自身の内部エラーで、この場合はメッセージに具体的な原因（ディスク不足など）が含まれるのが普通です。 なお、デーモンが停止しているだけなら500にはなりません。その場合は「Cannot connect to the Docker daemon … Is the docker daemon running?」という接続エラーになります。500は「相手まで届いたうえで、相手が内部エラーを返した」ことを示すコードです。 エラーの概要 Docker のコマンド（docker ps、docker run など）は、裏側で Docker デーモンの API に HTTP リクエストを送って動いています。500 Internal Server Error は、その応答としてサーバー側（デーモン、その手前の中継役、またはレジストリ）が「内部でエラーが起きた」と返してきたことを意味します。 このため、500が出たという事実は「相手までリクエストが届いた」ことの証拠でもあります。デーモンのプロセスが停止している、ソケットファイルにアクセスできない、といった場合は HTTP の応答自体を受け取れないので、500ではなく Cannot connect to the Docker daemon という別のエラーになります。500の調査でデーモンの死活だけを疑うと原因を取り違えるので、まずエラーメッセージの文言全体を読みます。 まず最初に：エラーメッセージの全体を読む 500エラーの文言は、発生源ごとに形式が決まっています。手元のメッセージと突き合わせてください。 「request returned Internal Server Error for API route and version http:////./pipe/docker_engine/…」という形式で、経路に docker_engine という文字が見えるなら、Windows の Docker Desktop の経路で発生しています（原因1）。 ...

エラーの概要 502 Bad Gateway は、Docker コンテナ内で実行されるアプリケーションやリバースプロキシが、上流のサーバーから不正な応答を受け取ったときに発生します。Docker Compose や Kubernetes でマルチコンテナを運用する環境では、コンテナ間通信の失敗、プロキシ設定のミス、ネットワーク分断などが典型的な原因です。特に、Nginx や Apache をリバースプロキシとして使用している場合に頻出します。 実際のエラーメッセージ例 Bad Gateway The proxy server received an invalid response from an upstream server. { "error": "bad_gateway", "message": "502 Server Error: Bad Gateway for url: http://upstream-service:8080/api", "timestamp": "2024-01-15T10:30:45Z" } $ curl -v http://localhost:80/api < HTTP/1.1 502 Bad Gateway < Server: nginx/1.21.0 < Content-Type: text/html よくある原因と解決手順 原因1：上流コンテナが起動していない、またはヘルスチェックに失敗している 上流アプリケーション（Node.js、Python、Java など）が起動に失敗していたり、クラッシュしていたりする場合、プロキシは接続できずに 502 を返します。 Before（エラーが起きている設定） version: '3.8' services: nginx: image: nginx:latest ports: - "80:80" volumes: - ./nginx.conf:/etc/nginx/nginx.conf depends_on: - app app: image: myapp:latest # ヘルスチェックがない、起動スクリプトが不安定 After（修正後） ...

エラーの概要 DockerのHTTP 503エラーは、「Service Unavailable」を意味し、リクエスト対象のサーバーが一時的に利用不可能な状態にあることを示します。Docker環境では、Docker HubなどのレジストリサーバーやローカルのDockerデーモンが応答しない場合に頻発します。コンテナイメージの取得やプッシュ時に最も多く遭遇するエラーであり、その原因は多岐にわたります。 実際のエラーメッセージ例 $ docker pull ubuntu:latest Error response from daemon: Get "https://registry-1.docker.io/v2/library/ubuntu/manifests/latest": net/http: request canceled $ docker push myregistry.azurecr.io/myapp:latest The push refers to repository [myregistry.azurecr.io/myapp] error: unexpected status code 503 Service Unavailable { "status": "Service Unavailable", "errors": [ { "code": "UNAVAILABLE", "message": "Service is temporarily unavailable. Please try again later." } ] } よくある原因と解決手順 原因1: Docker Hubまたはレジストリサーバーの障害 Docker Hubやプライベートレジストリが障害状態にあるか、メンテナンス中の場合にエラーが発生します。この場合、クライアント側の設定に問題がなくても、サーバー側の復旧を待つ必要があります。 まずは、対象レジストリの状態確認コマンドを実行してください。 Before（エラーが起きるコード）： # エラーが出たらすぐに再度pull/pushを試みている $ docker pull myimage:latest Error response from daemon: Get "https://registry-1.docker.io/...": 503 Service Unavailable $ docker pull myimage:latest # 再試行（失敗） After（修正後）： ...

冒頭まとめ Docker まわりの 504 Gateway Timeout で最初に確定させるべき事実は、Docker デーモン自身は504を返さない、ということです。デーモンがエラーを HTTP のステータスに割り当てる実装（moby のソースコード）には504がそもそも存在せず、時間切れ系の内部エラー（deadline exceeded）ですら500に割り当てられています。したがって、Docker の操作で504を見たとき、それを返しているのは必ずデーモン以外のどこかの「中継役」です。実際に起きる場所は3つに絞れます。第一に、docker pull / push の通信経路にあるゲートウェイ（自前レジストリの前段の Nginx や ingress、Docker Hub 側の基盤）です。第二に、リモートの Docker デーモンをリバースプロキシ越しに公開している構成の、そのプロキシです。第三に、コンテナで動かしているアプリケーションの前段のプロキシで、これは Docker ではなくプロキシとアプリの調査になります。 見分けは文言でつきます。received unexpected HTTP status: 504 Gateway Time-out や error parsing HTTP 504 response body なら、pull / push の経路の504です（原因1）。docker コマンド全般がリモートデーモン相手に504になるなら、デーモンの前のプロキシです（原因2）。ブラウザや curl でコンテナ上のアプリにアクセスして504が返るなら、それは Docker の問題ではありません（原因3として境界を示します）。 エラーの概要 Docker デーモンは、エラーの種類ごとに返す HTTP ステータスを割り当てます。この割り当てはソースコード（moby の daemon/server/httpstatus/status.go）で確認でき、404・400・409・503・500 などへの割り当てはあっても、504への割り当ては存在しません。つまり Error response from daemon: で始まるエラーの中に504の数字が現れた場合も、その504はデーモンが作ったものではなく、デーモンがレジストリなどの通信相手から受け取ったものの転記です。 pull / push で504を受け取ったときの文言は、レジストリクライアントの実装（docker/distribution の registry/client/errors.go）で決まっており、2種類あります。 Error response from daemon: received unexpected HTTP status: 504 Gateway Time-out Error response from daemon: error parsing HTTP 504 response body: invalid character '<' looking for beginning of value: "<html>\r\n<head><title>504 Gateway Time-out</title></head>\r\n..." 前者は、レジストリ API として想定外のステータスを受け取ったことを示します。後者はさらに手がかりが濃く、応答の本文がレジストリの返す JSON ではなく HTML だったことを示します。レジストリ本体は HTML のエラーページを返さないため、この文言は「応答したのはレジストリではなく、その手前にいる何か（Nginx やロードバランサー）だ」という強い証拠になります。 ...