再デプロイ後、Composeスタックが新しい空の名前付きボリュームをアタッチするのはなぜですか？
Composeスタックは、再デプロイ時にプロジェクトスコープのボリューム名が変わった場合や、元のボリュームが見つからない場合、新しい空の名前付きボリュームをアタッチすることがあります。
古いデータは別のDockerボリュームに残っている一方で、再作成されたサービスが同じコンテナパスに新しく生成されたボリュームをマウントしている可能性があります。よくある原因には、スタック名またはプロジェクト名の変更、ボリュームキーの変更、ボリュームを削除するコマンドによる削除、外部ボリューム宣言の消失、別の管理ツール経由でのデプロイ、現在は異なる場所に解決される明示的なボリューム名などがあります。データを復元したりアプリを初期化したりする前に、マウントされているボリュームと孤立している候補の両方を確認してください。
新しいコンテナにマウントされている正確なボリュームを特定する
実行中のコンテナのマウント情報を確認し、ボリューム名、ドライバー、マウントポイント、ラベル、作成日時、コンテナ側の接続先、読み書きモードを記録します。再デプロイ前の記録と比較してください。
Ubuntuのdocker volume inspectコマンドではボリュームの識別情報を確認できます。これにより、新しい空のボリュームと、似た名前を持つ古い未マウントのボリュームを区別できます。
元のボリュームが見つかるまで、新しいボリュームにデータをコピーしないでください。アプリを起動すると新しいデータベースが作成され、保存先が意図的に初期化されたように見える可能性があります。
Composeプロジェクト名が変更されていないか確認する
以前と現在のプロジェクト名、スタック名、Composeディレクトリ、-pオプション、COMPOSE_PROJECT_NAME、トップレベルのname:、デプロイに使用した管理ツールを比較します。
Dockerの説明によると、Composeでは通常、明示的な名前または外部ボリュームの検索が設定されていない限り、ボリューム名はプロジェクト名とボリュームキーを組み合わせた名前になります。
そのため、同じComposeファイルを別のディレクトリに移動すると、サービス名とボリュームキーが変わっていなくても、2つ目のプロジェクトと2つ目のボリュームが作成されることがあります。
安定した名前と外部ボリュームの設定を確認する
再デプロイ前後のトップレベルのボリューム定義を比較します。name:、external:、ドライバーオプション、補間変数、想定しているボリュームの存在を確認してください。
MicrosoftのDocker Composeチュートリアルでは、名前付きボリュームはコンテナの置き換えとは独立して保持されると説明されています。そのため、新たに空の状態になった場合は通常、別のボリューム識別子がアタッチされたか、古いボリュームが削除されたことを意味します。
ボリュームのライフサイクルを意図的にスタック外で管理する場合にのみ、そのボリュームを外部として指定してください。外部ボリュームが存在しない場合、Composeが代替ボリュームを黙って作成するのではなく、明確に失敗するようにします。
クリーンアップによって元のボリュームが削除されていないか確認する
デプロイログ、スクリプト、UI操作、プルーニングジョブ、ボリューム削除コマンドを確認します。ボリュームの作成日時と再デプロイの発生時刻を比較してください。
Red Hatのドキュメントでは、コンテナが管理する名前付きボリュームには、コンテナの書き込み可能レイヤーとは別の保存場所があると説明されています。そのため、コンテナの削除と名前付きボリュームの削除は異なるライフサイクルイベントです。
元のボリュームが存在しない場合は、自動起動を停止し、検証済みのバックアップからのみ復元してください。空の代替ボリュームに、削除されたレイヤーから復元可能なデータが含まれているとは考えないでください。
スタック管理ツールの識別情報とデプロイ方法を比較する
スタックがCLI、Portainer、NASアプリストア、Gitデプロイ、その他の自動化ツールのどれによって起動されたかを記録します。その管理ツールに保存されているスタック名と環境変数を比較してください。
Portainerではデプロイ時に分かりやすいスタック名が必要です。この管理ツールが使用する識別情報は、手動のComposeコマンドで使われるディレクトリベースのプロジェクト名とは異なる場合があります。
そのため、手動で行った緊急起動によって、別のプロジェクトプレフィックスでリソースが作成されることがあります。デプロイの所有者を1つに決め、そこで解決されるボリューム名を記録してください。
新しいボリュームのマウント下に隠れているデータを除外する
コンテナを停止し、使い捨てのテスト環境で名前付きボリュームをアタッチせずに、イメージまたはバインドパスを確認します。ボリュームがマウントされる前に、起動処理がコンテナレイヤーへデータを書き込んでいないか確認してください。
Linuxのmountマニュアルでは、マウントによって既存のディレクトリ内容が隠れると説明されています。そのため、新しい空のボリュームが、イメージまたは書き込み可能レイヤー内に作成されたファイルを覆い隠すことで、データが消えたように見えることがあります。
隠れているレイヤーと古い永続ボリュームを、考えずに統合しないでください。どちらの状態を正とするかを判断し、アプリケーションがサポートする復旧方法を使用してください。
制御されたテストで元のボリュームを再接続する
スタックを停止し、候補となる両方のボリュームをバックアップしたうえで、元のボリュームを使い捨てコンテナまたは一時サービスのパスにアタッチし、アプリケーションファイル、データベースの識別情報、所有者、タイムスタンプを確認します。
ZimaSpaceのマウントを壊さずにコンテナデータを移動するガイドでは、関連するパスのマッピング手順を説明しています。この記事では、プロジェクトスコープの名前付きボリュームの識別情報に焦点を当てています。
意図した古いボリュームが安定した明示名または外部名でマウントされ、再デプロイを繰り返しても別の空の候補が作成されず、そのボリュームが再利用されれば問題は解決です。
よくある質問
空の名前付きボリュームは、古いデータが削除されたことを意味しますか？
必ずしもそうではありません。新しいコンテナが別の空のボリュームを使用している一方で、古いボリュームが別のプロジェクトプレフィックスまたは明示的な名前で残っている可能性があります。
Composeフォルダーの名前を変更すると、新しいボリュームが作成されることがありますか？
はい。プロジェクト名を固定していない場合、Composeはプロジェクトディレクトリからプロジェクト名を導出し、異なるプレフィックスのリソースを作成することがあります。
重要なボリュームは外部として指定すべきですか？
外部ボリュームにすると、スタックの削除によってライフサイクルが管理されるのを防げます。ただし、意図的な作成、命名、バックアップ、デプロイ時の確認が必要です。
おすすめ商品
サポートとヒント
もっと読む
ライブTV録画の容量・保存期間・クリーンアップガイド
実際の録音を測定し、ヘッドルームを確保し、経過時間と容量の制限を組み合わせ、ストレージが満杯になる前に最も古い対象プログラムが削除されることを確認する。
データベース復元後のホームメディアメタデータ復旧ワークフロー
復元した状態を保護し、メディアの識別情報とパスを確認してから、メタデータを広範囲に変更する前に、パイロットライブラリで不足しているアートワークや一致項目を修復します。
オーディオ、ビデオ、字幕のJellyfinクライアント互換性チェックリスト
代表的なファイルを一度に1つの変数だけテストし、すべてのクライアントについて、ダイレクトプレイ、リマックス、音声変換、動画トランスコード、または失敗を記録します。
