テクノロジー · 実用ガイド
Docker Compose の孤立コンテナ警告：削除前にプロジェクトの所有関係を監査する
孤立コンテナの警告は、削除してよいという証明ではありません。有効な Compose プロジェクト、所有ラベル、データマウントを確認し、サービス名変更、プロジェクト名衝突、別ファイル構成、one-off 実行を切り分けてから最小限の操作を選びます。
Docker Compose がコンテナを孤立状態と呼ぶのは、そのコンテナが現在の有効なプロジェクト ID に属する一方で、今回のコマンドが使う有効な Compose モデルに該当サービスがないときです。意図したサービス名変更の結果かもしれませんが、無関係な二つの構成が同じプロジェクト名を使っている、別のファイル集合で起動した、停止済みの one-off 実行が残った、といった可能性もあります。
したがって警告は証拠であり、削除の許可ではありません。確認すべきなのは `--remove-orphans` の有無だけではなく、各コンテナを作成したプロジェクトとサービス、現在の設定が今も管理対象としているか、マウントに保持すべきデータがあるかです。
このガイドは読み取り専用の確認から始めます。最初から全体 prune を行わず、名前付きボリュームや external volume を削除せず、所有関係が判明するまで警告を隠しません。最終成果物は小さな所有台帳と、範囲を限定した一つの操作です。
1. 正確な警告を保存し、削除判断を保留する
警告全文、発生させたコマンド、作業ディレクトリ、すべての `-f`、`--project-directory`、`-p`、`--project-name` を保存します。所有関係が未解決の間は `docker container prune`、`docker compose down -v`、`--remove-orphans` を付けた再実行を行いません。
`docker compose version`、現在の Docker context、対象の Compose ファイル名を記録します。自動化から実行された場合は、`COMPOSE_PROJECT_NAME` やその呼び出しで選ばれた `.env` など、プロジェクト名に影響する環境も保全します。
`docker ps -a --no-trunc` で警告に挙がったコンテナを列挙し、完全な ID、状態、名前を記録します。名前は手掛かりですが、所有の根拠はラベルと有効な Compose モデルです。
2. 覚えているファイル名ではなく、有効な Compose プロジェクト名を求める
Docker が示すプロジェクト名の優先順位は、コマンドラインの `-p`、`COMPOSE_PROJECT_NAME`、指定ファイル群の最後のトップレベル `name`、プロジェクトディレクトリの基本名、最後に現在のディレクトリです。二つの構成が別プロジェクトだと判断する前に、実際の呼び出しを再現します。
同じファイル、profiles、環境、プロジェクト指定で `docker compose config` を実行し、導入済みバージョンが対応する名前表示オプションも使ってモデルをレンダリングします。秘密値は出さず、最終プロジェクト名とサービス一覧を保存します。
二つのリポジトリがともに `docker` というディレクトリから起動される場合や、自動化が同じ明示的プロジェクト名を渡す場合は衝突します。この分岐では警告対象が別の有効なアプリケーションのコンテナかもしれません。安定した異なる名前で分離し、警告を消す目的だけで他方のコンテナを削除しません。
3. 警告対象ごとに Compose の所有ラベルを読む
各コンテナの正確な ID を inspect し、`com.docker.compose.project`、`com.docker.compose.service`、`com.docker.compose.project.config_files`、`com.docker.compose.project.working_dir`、および使用中の Compose が提供する one-off 指標を記録します。省略された名前から推測せず、`docker inspect` の JSON を使います。
project ラベルを現在の呼び出しで求めた有効プロジェクト名と比較します。異なるラベルは停止条件です。削除する前に、なぜ今回の実行がそのコンテナを警告に含めたのかを調べます。同じ project ラベルでサービスがモデルにない場合も、孤立候補であるだけで削除安全性の証明にはなりません。
config file と working directory のラベルも現在のファイル集合と比較します。ファイル名変更、`-f` の順序変更、別ディレクトリからの自動化、以前の実行が意図して追加サービスを管理していた事実を発見できます。
4. 四つの代表的な分岐を区別する
サービス名変更または削除では project ラベルは一致しますが、旧 service ラベルが現在のモデルから消えています。古いと判断する前に、バージョン管理またはデプロイ記録で意図した変更か確認します。
プロジェクト名衝突では同じ project ID に見えても、実際のアプリケーションやファイルルートが異なります。各アプリに安定した固有名を設定して再確認します。削除を先に行っても誤った衝突は再発します。
`docker compose run` の one-off コンテナは、コマンド終了後や中断後に停止状態で残ることがあります。上流 issue には特定バージョンで run コンテナと警告が蓄積した例があります。これは一つの分岐として扱い、ラベル、状態、終了コード、バージョンを確認してから一般化します。
古いファイル集合の分岐は、同じプロジェクトが複数の `-f` 組み合わせや profiles を意図的に使う場合です。今日のモデルにサービスがないだけで、別の対応済み呼び出しからも不要とは限りません。所有するモデルを記録してから処理します。
5. コンテナに触れる前にマウントとボリュームを監査する
各候補について `docker inspect` から bind mount、名前付きボリューム、匿名ボリュームを記録します。停止済みコンテナでも、他に文書化されていないデータの用途を知る最短の地図になり得ます。バックアップと復元の想定をサービス所有者と確認します。
Compose down のリファレンスはコンテナとネットワークの削除を、ボリューム削除とは分けています。アプリが宣言した名前付きボリュームは使い捨てのコンテナ層ではなく、external volume は Compose プロジェクト外で管理されます。孤立警告だけを理由に `-v` を追加してはいけません。
コンテナがポートを公開している、または処理を続けている場合は、停止前に利用者と依存関係を特定します。孤立という分類は現在のモデルにないという意味で、処理やデータが不要という証明ではありません。
6. 最も狭い操作を選び、結果を記録する
コンテナが古い、現在のプロジェクトに属する、必要な処理を担っていない、データを保全した、という四点を確認した後にだけ、同じファイル集合とプロジェクト名に対応する project-scoped な Compose コマンドを使います。`docker compose up --remove-orphans` は現在のファイルに定義されないサービスのコンテナを削除するため、先に範囲の正しさを証明します。
原因が名前衝突なら、削除せず project ID を変えて再実行します。別 profile やファイル集合で期待されるコンテナなら保持して正しい呼び出しを記録します。one-off 実行が原因なら、全体 prune より通常のライフサイクル制御とバージョン固有の修正を優先します。
操作後は同じ context で元のコマンドを再実行して警告の変化を保存します。残ったコンテナを再び inspect し、無関係なプロジェクト、ポート、ネットワーク、データマウントが変わっていないことを確認します。
証拠 | 考えられる分岐 | 最小限の安全な操作 project ラベルが想定プロジェクトと異なる | 所有不一致 | 停止し、呼び出しと命名を解決してから削除する 同じ project で、意図した改名後に旧サービスがない | 確認済みの古いサービス | データ保全後、project-scoped な孤立削除を使う 無関係なファイルルートが同じ名前を解決する | プロジェクト名衝突 | 安定した別名を割り当て、有効なコンテナを保持する 停止済み one-off に一致する実行証拠がある | one-off ライフサイクル | 終了状態とバージョンを確認し、そのコンテナだけ処理する 別の対応済みファイル/profile 集合に属する | 期待されるリソース | 保持し、所有する呼び出しを記録する
7. 操作を検証し、サポート用の所有台帳を作る
合格条件を具体化します。警告にある全コンテナの project/service 所有者が記録済みで、保持対象は対応済み呼び出しに属し、削除対象は古いと証明され、必要なマウントが残り、元の Compose コマンドが別プロジェクトへ干渉しないことです。
サポートには、秘密を除いた Compose/Engine バージョン、Docker context、有効プロジェクト名、ファイル順序、コンテナ ID、project/service/config-file ラベル、状態、終了コード、マウント種別を提出します。資格情報、秘密の環境値、プライベートレジストリのトークンは含めません。
project 名の優先順位、ファイル集合差、ラベル、one-off 状態、通常のライフサイクルを除外した後にだけ、Compose の回帰としてエスカレーションします。警告が `--remove-orphans` に触れるだけでは、正確なサブコマンドにそのフラグが適用できることも、観測した分岐を直せることも証明しません。
よくある質問
Docker Compose の孤立コンテナとは何ですか？ 有効な Compose プロジェクトに関連付けられている一方、サービスが現在のモデルにないコンテナです。サービス削除、プロジェクト名衝突、別ファイル/profile 集合、one-off 実行などが原因です。
`--remove-orphans` は常に安全ですか？ いいえ。プロジェクト範囲が正しく、候補が本当に古く、必要なマウントやデータが保全済みの場合に限ります。誤った名前やファイル集合では危険な範囲になります。
無関係な Compose ファイルが互いのコンテナを見るのはなぜですか？ ディレクトリの既定値、環境変数、トップレベルの name、明示した `-p` により同じプロジェクト名へ解決されることがあります。無関係なアプリには安定した異なる名前を使います。
警告を消すために `docker container prune` を使うべきですか？ 最初の手段にはしません。全体 prune は範囲が広く所有関係も説明しません。ラベル、命名、状態、マウントを調べ、古いと証明できたコンテナだけを処理します。
