2台のホームサーバー間でDockerの名前付きボリュームを移行するワークフロー

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Docker Named Volume Migration Workflow Between Two Home Servers - Zima Store Online

安全なアプローチでは、静止状態にしたアーカイブまたは明示的に特定したターゲットボリュームへの同期コピー、その後のチェックサム検証とアプリケーション検証を、単一のコマンドではなく、観測可能なゲートの連続として扱います。

Docker Composeを実行する2台のLinuxホームサーバーでは、実際のリスクは、稼働中のボリュームや名前を誤ったボリュームをコピーせずに、ステートフルコンテナを別のホストへ移動しなければならないことです。現在の識別情報と復旧ポイントを記録し、最も影響の少ない判別から始め、別の変数を変更する前に成功・失敗の結果を解釈し、ストレージが不安定になった場合や、復旧可能なコピーが危険にさらされる場合は停止します。以下のワークフローは、元のワークロードが正常に動作するか、証拠がエスカレーションの境界に達した時点でのみ完了します。

ソースとターゲットのボリューム契約を特定する

ソースコンテナのイメージダイジェスト、Composeプロジェクト名、サービス、ボリュームキー、実際のDockerボリューム名、マウント先、ボリュームドライバー、アプリケーションのバージョンを記録します。docker inspectとdocker volume inspectを使用し、YAMLのラベルだけから物理パスを推測しないでください。

Composeでは通常、明示的な名前や外部ボリュームが指定されていない限り、プロジェクト名が名前付きボリュームに付加されます。ターゲットではCompose設定を展開して確認し、意図した空のボリュームを明示的に作成します。これにより、移行先が一方のボリュームである一方、サービスが別のボリュームを起動する事態を防げます。

ボリュームにデータベースが含まれる場合は、移植可能な主な復旧手段としてデータベース固有のダンプまたはサポートされているバックアップを使用し、ボリュームコピーは同一バージョン向けの復旧ポイントとして扱います。ドライバーがリモートの場合、ソースストレージが不安定な場合、または対象範囲に含まれていない追加ボリュームにアプリケーションの状態がまたがっている場合は停止します。

書き込みを静止させ、メタデータを保持したコピーを作成する

アプリケーションをメンテナンスモードにし、バックグラウンドジョブを停止してから、アプリケーションとデータベースを正常に停止します。ボリュームを読み書き可能な状態でマウントしているコンテナがないことを確認します。一時コンテナを介してアーカイブを作成するか、数値ユーザー・グループ所有権、アクセス権、シンボリックリンク、必要に応じて拡張属性、スパースファイルを保持する制御されたファイルシステムコピーを使用します。

rsyncを使用したDockerボリュームの移行に関する独立したガイドでは、rsyncによるDockerボリュームデータの移動を説明しています。重要なのは、ソースを静止状態にし、コピーコマンドがデーモンの使用中にDockerの内部ディレクトリを盲目的に操作するのではなく、特定したボリュームの内容に対して実行されることです。

ファイル数、合計バイト数、代表的なハッシュ、アーカイブのチェックサムを含むマニフェストを生成します。ソースボリュームとネイティブバックアップは変更せずに保持します。コピー段階は、転送された成果物をターゲットホストで読み取れる場合にのみ合格とします。

明示的なターゲットボリュームに復元する

ターゲットファイルシステムの容量、使用可能なinode、UIDとGIDの想定値、同じアプリケーションイメージのバージョンを確認します。空のターゲットボリュームに、トップレベルディレクトリ構造を平坦化せずにアーカイブを復元し、その後、所有権、件数、サイズ、選択したハッシュを比較します。

名前付きボリュームの移行失敗事例に関するコミュニティの議論は、Dockerのボリューム内部にあるファイルを直接置き換えると、失敗したり、分かりにくい状態が残ったりする理由を示しています。ランタイムを使用してボリュームをヘルパーコンテナにマウントし、その制御されたインターフェースを介して復元してください。

まずはサービスの使い捨てコピーだけを接続し、代替ポートを使用して、本番環境のピアにはアクセスできないようにします。アプリケーションがスキーマのアップグレードや状態の破損を報告した場合は停止し、バージョン互換性を解決した後、変更していない成果物からボリュームを再度復元します。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

切り替えを行い、ロールバック用ホストを保持する

アプリケーションより先に依存サービスを起動し、ログ、ログイン、最近のレコード、添付ファイル、スケジュール済みジョブ、使い捨ての書き込みを確認します。ターゲットスタックを再起動し、同じ名前付きボリュームが再アタッチされることを確認します。これらの確認に合格してから、プロキシまたはDNSを更新します。

整合性のあるコンテナデータのバックアップに関するZimaSpaceの関連記事は、コピーが正常に完了したにもかかわらずターゲットが空の状態で起動する場合に役立ちます。データを再度コピーする前に、ランタイムのマウント元と意図したボリュームを比較してください。誤ったターゲットへのコピーを繰り返すだけでは、混乱が増すだけです。

ターゲットで新しいバックアップと復元テストが成功するまで、ソースアプリケーションは停止したままにし、旧ボリュームは読み取り専用で保持します。ターゲットで新しい書き込みが受け付けられていない場合に限り、変更されていないソースへトラフィックを戻してロールバックします。それ以外の場合は停止し、意図的にデータを突き合わせます。