Posts

冒頭まとめ docker pull、docker run、docker compose up、docker build で次のエラーが出た場合、ログイン不足だけが原因とは限りません。 Error response from daemon: pull access denied for OWNER/IMAGE, repository does not exist or may require 'docker login': denied: requested access to the resource is denied この文は、考えられる原因をそのまま2つ並べています。 repository does not exist → 指定したリポジトリが存在しない may require 'docker login' → 非公開リポジトリで、認証またはpull権限が足りない 重要なのは、access denied と表示されても、リポジトリが存在するとは限らないことです。反対に、repository does not exist と表示されても、削除済みとは限りません。非公開リポジトリは、権限を持たない利用者からは存在を確認できない場合があります。 ただし、Registryの仕様が404と403を同じものとして定義しているわけではありません。CNCF DistributionのRegistry HTTP API V2仕様は、次のように区別しています。 状態 HTTP Registryのエラーコード 認証が必要 401 UNAUTHORIZED 操作を許可されていない 403 DENIED リポジトリ名が存在しない 404 NAME_UNKNOWN リポジトリはあるがタグやdigestがない 404 MANIFEST_UNKNOWN 混同が起きるのは、その手前に認証処理があるためです。Registryは最初に401と WWW-Authenticate を返し、クライアントは指定された認証サービスへ、対象リポジトリの pull 権限を含むトークンを要求します。権限のない主体には、要求した権限を含まないトークンが返ることがあります。その後のRegistry要求は拒否され、Docker CLIは不存在と権限不足の両方を含む案内へまとめます。 ...

冒頭まとめ GitHub Actionsで次のエラーが出た場合、APIが壊れているのではなく、リクエストに使ったトークンがその操作を許可されていません。 RequestError [HttpError]: Resource not accessible by integration status: 403 同じリポジトリで、push や組織内部からの実行が起点なら、解決は失敗した操作に対応する permissions をワークフローへ追加することです。 たとえば、コードを読み、IssueとPull Requestへ書き込むジョブなら次のようにします。 permissions: contents: read issues: write pull-requests: write 必要な権限は操作ごとに違います。 リポジトリをcheckoutする → contents: read コミット、タグ、Releaseを書く → contents: write Issueへ書く → issues: write Pull Requestへ書く → pull-requests: write Check Runを作る → checks: write commit statusを書く → statuses: write コードスキャン結果を送る → security-events: write パッケージを公開する → packages: write OIDCトークンを発行する → id-token: write ただし、permissions を書けば必ず直るわけではありません。次の実行では、ワークフロー側から書き込み権限へ引き上げられないことがあります。 外部フォークからのpull_request Dependabotが作成したPull Request 呼び出し元が権限を与えていない再利用ワークフロー GITHUB_TOKENの対象外である別リポジトリや組織資源への操作 特に、外部フォークの失敗を直すために pull_request_target へ置き換え、Pull Request側のコードをcheckoutして実行するのは危険です。書き込み可能なトークンやシークレットを、信頼できないコードから利用できる状態にしないでください。 ...

冒頭まとめ git clone、git pull、git push で次のエラーが出た場合、GitHubとのSSH認証が完了していません。 git@github.com: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 最初に押さえるべきは、この時点では対象リポジトリの権限確認まで進んでいないことです。GitHub公式の説明でも、Permission denied はサーバーが接続を拒否した状態とされています。共同編集者の権限、ブランチ保護、リポジトリの公開・非公開を調べる前に、SSH認証を直します。 また、末尾の publickey は「公開鍵ファイルが壊れた」という意味ではありません。サーバーが続行を許可した認証方式が公開鍵認証だけで、その方式では利用者を確認できなかったという意味です。実際の認証では、端末にある秘密鍵で署名し、GitHubに登録した公開鍵で検証します。GitHubへ追加するのは .pub 側だけです。秘密鍵は送信も貼り付けもしません。 最初の診断は次の1行です。 ssh -vT git@github.com 注目するのは、長い出力の中に Offering public key があるかどうかです。 Offering public key がない → 使える鍵を見つけていない、または選択していない Offering public key はあるが、認証されない → 提示した鍵がGitHubの該当アカウントに登録されていない、または別の鍵を提示している Server accepts key の後に signing failed → 鍵は認識されたが、ssh-agentなどが署名できていない Hi USERNAME! You've successfully authenticated... → SSH認証は成功。次にリポジトリ権限、remote、SSOを確認する つまり、新しい鍵を作ることから始めないのが要点です。まず、失敗したGit操作と同じ端末・同じSSHクライアントが、どの鍵を提示したかを確定します。 ...

冒頭まとめ Liveness probe failed は、kubeletが対象コンテナの生存確認に失敗した記録です。 Warning Unhealthy kubelet Liveness probe failed: Get "http://10.244.1.17:8080/healthz": dial tcp 10.244.1.17:8080: connect: connection refused 失敗が failureThreshold の回数だけ連続すると、kubeletは失敗したコンテナを終了させます。その後の再起動は restartPolicy に従います。Pod lifecycleの公式資料では、Pod単位の値は Always、OnFailure、Never で、既定値は Always と定義されています。そのため、Deploymentなど一般的なPodでは同じPod内でコンテナが再起動します。 Liveness probeが失敗 ↓ failureThreshold回連続 kubeletが対象コンテナを終了 ↓ restartPolicyがAlwaysまたはOnFailure 同じPod、同じNodeでコンテナを再起動 ↓ 失敗が続けば再起動待ちが長くなり、CrashLoopBackOffになり得る ここで、Podが削除されて新しいPodへ置き換わるわけではありません。Pod名とUIDは同じまま、コンテナの restartCount が増えます。複数コンテナのPodなら、probeに失敗したコンテナが対象です。 Kubernetes公式のprobe資料は、liveness probeを、停止しているように見えないまま処理が進まなくなったコンテナを再起動する仕組みとして説明しています。一時的な高負荷、外部データベースの停止、起動の遅さを検出するためのものではありません。 同じ接続失敗でも、readiness probeとは結果が違います。 Liveness probe failed → 対象コンテナを終了し、再起動対象にする Readiness probe failed → コンテナは動かしたまま、PodをServiceの通常転送先から外す 一時的に要求を受けられないだけなら、readinessProbeでServiceから外します。起動に時間がかかるなら startupProbe で、livenessの開始を待たせます。再起動しなければ回復できない状態だけを livenessProbe で判定します。 最初に確認するのは再起動回数ではなく、イベント末尾の失敗理由です。 connect: connection refused → 指定したportで待ち受けていない context deadline exceeded / timeout → timeout内に応答できない HTTP probe failed with statuscode: 500 → endpointが失敗用statusを返した command timed out / exit code != 0 → exec probeのcommandが失敗した エラーの概要 probeは、kubeletがコンテナへ定期的に行う診断です。HTTP、TCP、exec、gRPCの4方式があります。 ...

冒頭まとめ Readiness probe failed は、kubeletが「このコンテナは現在、利用者からの要求を受ける準備ができていない」と判定した記録です。 Warning Unhealthy kubelet Readiness probe failed: Get "http://10.244.1.18:8080/readyz": context deadline exceeded 失敗が failureThreshold の回数だけ連続すると、kubeletはコンテナを終了せず、Podの Ready conditionを False にします。該当Podを選択するServiceでは、EndpointSliceの通常転送対象から外れます。 Readiness probeが失敗 ↓ failureThreshold回連続 コンテナはRunningのまま ↓ Container Ready=False ↓ Pod Ready=False ↓ 該当Serviceの通常転送先から外れる ↓ probeが再び成功 同じPodがReady=Trueへ戻り、転送先へ復帰する したがって、readiness失敗だけでは RESTARTS は増えません。kubectl get pod では次のように、STATUS は Running のまま、READY が 0/1 になることがあります。 NAME READY STATUS RESTARTS AGE app-0 0/1 Running 0 12m 同じprobe失敗でも、livenessProbeとは結果が反対です。 Readiness probe failed → 動かしたままServiceの通常転送先から外す Liveness probe failed → 対象コンテナを終了し、restartPolicyに従って再起動する ただし、readinessはPodのnetworkを切断する機能ではありません。Kubernetes公式のprobe資料が変更すると説明しているのは、PodのReady状態と、該当ServiceのEndpointSliceです。 ...

冒頭まとめ Terminating は、Podの phase ではありません。削除要求を受け、.metadata.deletionTimestamp が入ったPodを kubectl が一覧で示す表示です。 NAME READY STATUS RESTARTS AGE app-7d8f767544-pk4ch 1/1 Terminating 0 3d 削除要求がAPI Serverに受理されても、Podはすぐには消えません。Kubernetes公式のPod終了処理では、既定で30秒の猶予期間が設けられ、その間に preStop、終了シグナル、接続の退避、コンテナ停止などが進みます。finalizerがある場合は、そのfinalizerを管理するコントローラーの後処理が終わるまで、API上のオブジェクトも残ります。 したがって、数十秒の Terminating は異常とは限りません。長時間変わらない場合は、次の4つを分けて確認します。 猶予期間中の正常な終了処理なのか。 preStop またはアプリケーションの終了処理が完了しないのか。 finalizerを管理するコントローラーが後処理を完了できないのか。 配置先ノードまたはkubeletと通信できず、停止を確認できないのか。 ここで最も重要な事実訂正があります。 kubectl delete pod <Pod名> -n <名前空間> --grace-period=0 --force この強制削除は、ノード上のプロセスを確実に停止してからPodを消す操作ではありません。kubectl delete の公式リファレンスは、API Serverがkubeletによる終了確認を待たず、同じ識別情報を持つ処理が別のマシンで動き続け、データの不整合や損失につながる可能性を警告しています。 強制削除は一覧をきれいにする操作ではありません。古い処理が停止済み、または二度と共有資源へ接続できないと確認した後に限る、最後の手段です。 エラーの概要 Podを通常削除すると、API Serverはオブジェクトへ削除時刻と猶予期間を記録します。 metadata: deletionTimestamp: "2026-08-05T03:12:44Z" deletionGracePeriodSeconds: 30 この時点で削除要求は失敗していません。finalizerの公式説明によれば、finalizerを持つオブジェクトへの削除要求は 202 Accepted で受理され、.metadata.deletionTimestamp が設定されます。その後、必要な後処理が済み、finalizerの一覧が空になると削除が完了します。 Terminating は、この途中経過を kubectl が表示したものです。API上のPodの status.phase は、終了処理中も Running や Pending のままの場合があります。 kubectl get pod <Pod名> -n <名前空間> \ -o jsonpath='{.status.phase}{"\t"}{.metadata.deletionTimestamp}{"\t"}{.metadata.finalizers}{"\n"}' Running 2026-08-05T03:12:44Z [batch.kubernetes.io/job-tracking] もう1つ混同しやすいのが、次の3種類の時間です。 ...

冒頭まとめ Inconsistent dependency lock file は、現在のTerraform設定が必要とするプロバイダーと、.terraform.lock.hcl に記録された選択が一致しないときに出ます。 Error: Inconsistent dependency lock file The following dependency selections recorded in the lock file are inconsistent with the current configuration: - provider registry.terraform.io/hashicorp/aws: locked version selection 5.100.0 doesn't match the updated version constraints "~> 6.0" To update the locked dependency selections to match a changed configuration, run: terraform init -upgrade この場合は、required_providers や子モジュールの変更に対して、ロックファイルが古いままです。設定変更を行った作業環境で次を実行し、差分を確認して .terraform.lock.hcl も一緒に版管理へ入れます。 terraform init -upgrade git diff -- .terraform.lock.hcl ただし、CIで発生するロックファイル関連の失敗が、すべて init -upgrade で直るわけではありません。開発環境とCIのOSやCPUが違い、対象環境の検査値がロックファイルにない場合は、次のような別のエラーになります。 ...

冒頭まとめ docker compose の実行中に現れる 429 Too Many Requests は、ほぼ例外なく Docker Hub の pull 回数制限です。制限そのものの仕組み（匿名は IP 単位、認証済みはアカウント単位）は Compose に固有の話ではありません（Docker の 429 の記事）。 Compose に固有なのは、同じ作業でも要求の回数と同時実行数が増えやすいという点です。増幅の要因は3つあります。 1つ目は並列度です。公式のリファレンスによれば、--parallel の既定値は -1、つまり無制限です。15 サービスの構成なら、15 件の取得要求がほぼ同時に飛びます。 2つ目はタグです。公式文書には、既定の missing という方針であっても latest タグだけは常に取得される、と明記されています。実装を読むと、手元にイメージがあるかを判定する関数が、タグが latest のときは「無い」と扱う作りになっています。image: nginx のようにタグを省略した記述は latest を指すため、up のたびにレジストリへ問い合わせが行きます。 3つ目は取得方針です。pull_policy: always や docker compose up --pull always を使っていると、手元にあっても毎回取得します。 さらに、Compose の取得処理には再試行の仕組みがありません。制限に当たれば、その場で失敗します。 したがって対処の順序は、上限を増やすことではなく、この3つの増幅要因を減らすことから始まります。 エラーの概要 docker compose pull や docker compose up の実行中に、次の形で現れます。 [+] Pulling 3/5 ✔ redis Pulled ✘ web Error toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: ... ✘ api Error toomanyrequests: You have reached your pull rate limit. Error response from daemon: toomanyrequests: You have reached your pull rate limit. 注目すべきは、複数のサービスが同時に失敗する点です。単発の docker pull なら1件で終わるところが、並列に走っているため、残り枠を一気に使い切ってまとめて弾かれます。 ...

冒頭まとめ exec format error は Docker が作った文言ではありません。Linux がプログラムを起動する際に返す ENOEXEC という結果を、そのまま表示したものです。 公式のマニュアルには、この結果の意味が1文で書かれています。実行可能ファイルが認識できる形式でない、アーキテクチャが違う、あるいは実行できない何らかの形式上の問題がある、という3つが並記されています。 したがって原因は2系統に分かれます。1つ目は CPU アーキテクチャの不一致です。Docker の公式文書は理由まで説明しています。コンテナはホストのカーネルを共有するため、中で動くコードはホストのアーキテクチャと互換でなければならない。だから linux/amd64 のコンテナを arm64 のホストで（エミュレーションなしに）動かすことはできない、と明記されています。 2つ目は、実行しようとした対象がそもそも実行可能な形式でない場合です。先頭行に実行系の指定が無いスクリプトを直接起動しようとした場合が典型です。 そして重要な境界があります。no such file or directory は別の系統です。マニュアルでは、指定したファイルや、スクリプトの実行系、あるいは必要な共有ライブラリが見つからない場合の結果として区別されています。ファイルは確かにあるのに「無い」と言われる現象は、こちらの系統です。 エラーの概要 実行時に出る文言は、実行系の階層をそのまま反映した形になります。 docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec /entrypoint.sh: exec format error 長く見えますが、読むべきは末尾だけです。unable to start container process: までは実行系が付け加えた前置きで、実装でもこの文言でくるむ処理が確認できます。その後ろの exec <対象>: exec format error が本体です。 ...

冒頭まとめ no space left on device は Docker が判定した結果ではありません。書き込みを試みた先のファイルシステムが返した結果を、そのまま表示したものです。 したがって最初にやるべきことは、対処ではなくどこが満杯なのかの確定です。候補は3つあります。 1つ目はホスト上のデータ保存先です。既定では /var/lib/docker で、イメージ、コンテナ、ボリューム、構築のキャッシュ、そしてログがすべてここに集まります。 2つ目は Docker Desktop の仮想ディスクです。この場合、ホストのディスクに空きがあっても関係ありません。上限は設定で決まっており、その中が満杯になれば同じエラーになります。 3つ目はコンテナの中です。共有メモリ用の領域は既定で 64MiB しかなく、これを超える書き込みでも同じ文言が出ます。 そしてもう1つ、見落とされやすい前提があります。Docker には自動的に減る仕組みがほとんどありません。公式文書によれば、ログの上限は既定で無制限、ボリュームはデータ破壊を避けるため自動削除されません。放置すれば埋まるのは仕様どおりの挙動です。 エラーの概要 文言は操作によって前後が変わりますが、末尾は共通です。 # 構築時 ERROR: failed to solve: failed to create temp dir: mkdir /var/lib/docker/tmp/buildkit-mount123: no space left on device # 起動時 docker: Error response from daemon: mkdir /var/lib/docker/tmp/docker-builder553623694: no space left on device 読むべきはどの経路への書き込みで失敗したかです。/var/lib/docker 配下ならホストのデータ保存先、コンテナ内の経路ならコンテナ側の問題です。 使用量の全体像は専用のコマンドで確認できます。 $ docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 15 3 21.71GB 18.17GB (83%) Containers 7 0 5.417kB 5.417kB (100%) Local Volumes 3 0 90.72MB 90.72MB (100%) Build Cache 295 0 20.77GB 20.77GB RECLAIMABLE の欄が、整理によって取り戻せる量です。どの種類が大きいかで、次にやることが決まります。 ...