Posts

冒頭まとめ Docker の 404 は「指定したものが見つからない」ことを示しますが、探した場所によって原因も対処も変わります。系統は3つです。第一に、手元のデーモンが管理する資源が見つからない場合で、No such container: や No such image: という文言になります。第二に、レジストリ（Docker Hub などのイメージ保管先）にリポジトリはあるがタグが見つからない場合で、manifest for … not found という文言になります。第三に、リポジトリ自体にたどり着けない場合で、pull access denied for …, repository does not exist or may require ‘docker login’ という文言になります。この3つ目の文言が「存在しない」と「権限がない」を並記しているのは意図的な設計で、Docker Hub は非公開リポジトリの存在を外部に確認させないため、両者を区別しないエラーを返します。 つまり Docker の404の調査は、エラー文言を読んで「手元」「タグ」「リポジトリ（または権限）」のどれかを確定するところから始まります。 エラーの概要 docker コマンドのエラーで Error response from daemon: と付くものは、Docker デーモンまで指示が届いたうえで、デーモンが処理を拒否したことを示します。デーモンは、コンテナやイメージなどの資源が見つからない場合、API 上は 404 として応答し、CLI には No such container: <名前> のような文言で表示されます（この対応は Docker のソースコードで確認できます）。一方、docker pull や docker push でレジストリとやり取りする場合の404は、レジストリ側の応答に由来します。レジストリの標準仕様では、リポジトリ名が不明な場合のエラーコードは NAME_UNKNOWN（repository name not known to registry）で、これも HTTP 404 に対応付けられています。 どの場合も、エラーコードの数字より文言のほうが多くを語ります。以下、文言ごとに切り分けます。 まず最初に：エラー文言で3つに分岐する No such container: <名前> や No such image: <名前> なら、手元のデーモンの中に該当する資源がありません（原因1）。 ...

エラーの概要 Dockerの409エラーは、HTTP標準仕様で「Conflict」を示すステータスコードです。Docker Daemonがコンテナやイメージの操作を受け付けられない状態を表します。通常、リソースの重複、ポートの競合、不正なコンテナの状態遷移などが原因となります。このエラーが発生した場合、現在のシステム状態と実行しようとしている操作に矛盾があることを意味しており、Dockerコマンド実行時やAPI呼び出し時に頻繁に遭遇します。 実際のエラーメッセージ例 { "message": "Error response from daemon: Conflict. The container name \"/web-app\" is already in use by container \"abc123def456\". You have to remove (or rename) that container to be able to reuse that name." } $ docker run --name myapp nginx docker: Error response from daemon: Conflict. The container name "/myapp" is already in use by container "e7f8c9a2b1d4". You have to remove (or rename) that container to be able to reuse that name. よくある原因と解決手順 原因1：コンテナ名の重複 同じ名前のコンテナが既に存在する場合、新たに同じ名前でコンテナを作成しようとすると409エラーが発生します。停止中のコンテナであっても名前は保持されるため、docker run --name で既存の名前を指定するとエラーになります。 ...

エラーの概要 Dockerで 422 エラーが発生するのは、Docker APIまたはコンテナレジストリへのリクエストが構文的には正しいものの、含まれるデータが処理要件を満たしていない場合です。Docker Daemon、Docker Compose、レジストリ APIとの通信時にこのエラーが返される典型的なシナリオは、不正なイメージタグ指定、設定値の型違反、あるいは APIスキーマの検証失敗です。 実際のエラーメッセージ例 { "message": "invalid tag format", "code": 422 } $ docker push myregistry.example.com/app:invalid@tag Error response from daemon: invalid tag format # docker-compose.yml でエラーが発生 ERROR: The Compose file is invalid because: Service 'web' has invalid value for ports: ports must be an integer or string よくある原因と解決手順 1. イメージタグの形式が不正 Dockerレジストリ APIは RFC 6391 に基づいたタグ形式を要求します。許可されない文字（@や大文字の混在）が含まれている場合に 422 が返されます。 Before（エラーが起きる例）： docker tag myimage:latest myregistry.example.com/app:INVALID@latest docker push myregistry.example.com/app:INVALID@latest # Error: invalid tag format After（修正後）： # タグは小文字のみで、「:」で区切る docker tag myimage:latest myregistry.example.com/app:v1.0.0 docker push myregistry.example.com/app:v1.0.0 2. docker-compose.yml の設定値の型違反 ports、mem_limit、cpu_sharesなど、数値型を期待するフィールドに文字列を指定するとバリデーション失敗で 422 が返されます。 ...

冒頭まとめ 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 やロードバランサー）だ」という強い証拠になります。 ...

冒頭まとめ GCP の 503 Service Unavailable は、まず「どの URL が返したか」で2系統に分けると迷いません。第一に、Google Cloud の各 API（googleapis.com への呼び出し）が返す503です。これは Google 公式のエラーコード定義（google/rpc/code.proto）で UNAVAILABLE に割り当てられたもので、定義の原文に「多くの場合は一時的な状態であり、バックオフつきの再試行で回復しうる。ただし非冪等な操作の再試行が常に安全とは限らない」と、性質と対処と注意点まで書かれています。第二に、自分がデプロイしたサービス（Cloud Run など）の URL が返す503です。こちらは Google 側の障害ではなく、コンテナの待ち受け設定やメモリなど、自分のワークロード側の調査になります。 境界も公式定義で引けます。クォータや利用枠の超過は RESOURCE_EXHAUSTED で429、処理の時間切れは DEADLINE_EXCEEDED で504、Google 内部の深刻なエラーは INTERNAL で500に割り当てられており、これらが503として返ることはありません。「クォータ超過で503」という説明は Google のエラーモデルに合いません。 エラーの概要 Google Cloud の API のエラーは、公式のエラーモデルに沿った JSON で返ります。503の場合、切り分けの決め手になるのは status フィールドです。 { "error": { "code": 503, "message": "The service is currently unavailable.", "status": "UNAVAILABLE" } } status が UNAVAILABLE なら、この記事の原因1（API 側の一時的な利用不能）です。message の文言はサービスにより異なりますが、status の値はエラーモデルで定義された名前がそのまま入ります。一方、Cloud Run にデプロイした自分のサービスの URL への503は、Google の公式トラブルシューティング文書で「HTTP 応答が不正だったか、インスタンスへの接続でエラーが起きた」場合と説明されており、応答本文は自分のアプリや基盤の状態次第です（原因2）。 まず最初に：どの URL の503かで2つに分岐する 失敗したリクエストの宛先を確認します。googleapis.com 系の API 呼び出し（Cloud Storage、BigQuery、各サービスの管理 API など）で、応答の status が UNAVAILABLE なら原因1です。自分のサービスの URL（run.app のドメインや独自ドメイン）への503なら原因2です。あわせて、応答に error.status がある場合は値を必ず読みます。RESOURCE_EXHAUSTED（429）や DEADLINE_EXCEEDED（504）が本来のコードとともに返っているなら、調査は503ではなくそれぞれの系統に切り替えます。 ...

冒頭まとめ GitHub API の 400 Bad Request は、リクエストの形式そのものが壊れていて、サーバーが中身の検証に進めない場合に返されます。公式ドキュメントが 400 として挙げているのは、リクエスト本文が JSON として読めない（Problems parsing JSON）、本文が JSON オブジェクトの形になっていない（Body should be a JSON object）、API バージョン指定のヘッダーに存在しない値を指定した、の3つです。 一方、JSON としては正しく読めたうえで、必須パラメータが足りない・値が仕様に合わないという場合に返るのは、400 ではなく 422 Unprocessable Entity です。400 の調査で最初にすべきことは、設定やパラメータの見直しではなく、応答の message を読んで 400 と 422 のどちらの問題かを確定することです。400 は形式の問題なので、同じリクエストを再試行しても結果は変わりません。修正が必要です。 エラーの概要 GitHub API の 400 の応答本文は次の形です。 { "message": "Problems parsing JSON", "documentation_url": "https://docs.github.com/rest" } 公式のトラブルシューティング文書は、400 と 422 の境界を明確に定めています。リクエスト本文に不正な JSON を送ると 400 と Problems parsing JSON が返ります。エンドポイントが JSON オブジェクトを期待しているのに本文がその形になっていないと 400 と Body should be a JSON object が返ります。これに対し、必須パラメータの省略やパラメータの型の誤りは 422 と Invalid request、リクエストを処理できない場合は 422 と Validation Failed です。つまり「JSON として読めるかどうか」が 400 と 422 のおおまかな境界線です。 ...