コンテナは読み取り専用の設定マウントと書き込み可能なアプリデータの両方を使用できますか？

エヴァ・ウォン

IceWhale author

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

Can a Container Use Both a Read-Only Config Mount and Writable App Data? - Zima Store Online

はい。設定を読み取り専用でバインドマウントし、アプリケーションの状態には、必要なUID、GID、バックアップポリシーを正確に設定した、別の書き込み可能なボリュームを割り当てます。

この判断が重要になるのは、セルフホストアプリで設定を書き換えさせたくない一方、データベース、アップロードファイル、キャッシュを永続化する必要がある場合です。競合する2つの状態は、読み取り専用の設定パスと、別に用意した書き込み可能な状態・一時パスです。保存済みの設定と破棄可能なデータから始め、一度に1つの分岐だけを観察し、データ損失、権限、可用性のリスクが拡大する場合はテストを中止します。

読み取り専用設定と書き込み可能なデータを混在させたマウントの判断条件を定義する

変更前に環境を記録します。ソフトウェアとファームウェアのバージョン、デバイスID、マウントまたはネットワークパス、空き容量、権限、観測された症状を含めてください。ベースラインには、設定を書き換えさせたくない一方で、データベース、アップロードファイル、キャッシュを永続化する必要があるセルフホストアプリを再現できるだけの詳細を残します。

最初の候補は読み取り専用の設定パスです。2番目の候補は、別に用意した書き込み可能な状態・一時パスです。現在のDockerボリュームの動作は、テストで使用する仕組みまたはコマンド境界を定義するものですが、この特定のホームサーバーでの観測に取って代わるものではありません。

判別テストを実行する前に、合格条件と中止条件を書き出します。合格とは、一方の分岐が予測した証拠が変化し、無関係なサービスには変化がないことです。不合格の場合は、推測に基づく修正を連鎖させるのではなく、保存済みの状態に戻せる必要があります。

元の要件を下げずに主張をテストする

次の判別テストを使用します。イメージのパスを確認し、設定をro、データをrwでマウントしてから、再作成する前に設定への書き込みと通常のデータ処理を試みます。結果が変更した変数に起因するように、負荷、クライアント、パス、ファイルセット、タイミングを一定に保ちます。

読み取り専用コンテナファイルシステムを使って、分岐を実際に区別できる項目を選びます。そのうえで、タイムスタンプ、終了ステータス、エラーテキスト、デバイスまたはスナップショットID、レイテンシ、転送バイト数、権限、復旧状態を記録します。ID、耐久性、アプリケーション状態がテスト対象の主張である場合、コマンドが正常終了しただけでは不十分です。

再起動、再接続、再マウント、またはキャッシュのコールド状態が元の条件に含まれる場合は、そのイベントの後にテストをもう一度実行します。最初の実行で破壊的な操作が行われる場合や、環境を復元できない場合は中止し、代わりに破棄可能なコピーで再現してください。

volumes:
  - ./config.yml:/etc/app/config.yml:ro
  - app-data:/var/lib/app:rw

合格、不合格、例外の結果を解釈する

合格: 設定への書き込みが失敗し、アプリデータが再作成後も保持され、一時パスの使用量が上限内に収まる。結論が普遍的な主張にならないよう、合格した正確なバージョン、ID、負荷を記録します。

不合格: アプリが設定の書き換えを要求する、データがコンテナレイヤーに保存される、または所有者情報によって起動が妨げられる。不合格だからといって、ネットワーク、メモリ、権限、ソースの整合性が両方の分岐に影響する可能性があるため、直ちに反対の分岐が正しいとは限りません。エスカレーションする前に、これらの共有依存関係を切り分けます。

例外または曖昧な結果: 以前のマウントを復元し、生成された設定と運用担当者が管理する設定を分離します。復元可能なコピーが存在するまで、ログを保持し、修復、prune、破棄、再パーティション、再帰的な所有者変更のコマンドは実行しないでください。

Featured

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

ZimaCube2

元の負荷で判断を確認する

観測された分岐に対応する処置を適用し、その後、縮小した代替条件ではなく元の条件を繰り返します。設定への書き込みが失敗し、アプリデータが再作成後も保持され、一時パスの使用量が2サイクル、または該当する再起動、スリープ、中断、負荷遷移の後も上限内に収まる場合にのみ、その判断が有効になります。

読み取り専用のアプリケーションルートを使って、最も近い依存ワークフローを確認します。ただし、元のトリガーは変更しないでください。無関係なデータセット、共有、コンテナ、ユーザー、復旧ポイントは、以前のアクセス状態とタイミングを維持する必要があります。

中止基準は明確です。アプリが設定の書き換えを要求する、データがコンテナレイヤーに保存される、または所有者情報によって起動が妨げられる場合は、最後に検証済みの構成に戻し、証拠を保持します。分岐が再現可能な場合にのみ、より深いプラットフォームまたはハードウェアテストへエスカレーションしてください。

目的の結果が得られたら、コンテナデータの所有権と比較し、リスクが隣接するサービスに移らないようにします。新たなバックアップ、ID、タイムアウト、可用性の障害が発生する場合、目的のテストに成功していても変更は失敗です。

よくある質問

読み取り専用設定と書き込み可能なデータを混在させたマウントについて、残る検索は通常、ルートファイルシステム全体も読み取り専用にできるか、起動時にアプリが設定を書き換える場合はどうするか、書き込み可能なデータとキャッシュを同じボリュームに置くべきか、といった内容です。以下の回答では、これらのエッジケースを主要な判断から分けて扱います。

合格条件は変わりません。設定への書き込みが失敗し、アプリデータが再作成後も保持され、一時パスの使用量が上限内に収まることです。後続の条件によってファイルシステム、ID、ネットワークパス、アプリケーションバージョンが変わる場合は、その変更の影響を受ける判別テストだけを繰り返します。

アプリが設定の書き換えを要求する、データがコンテナレイヤーに保存される、または所有者情報によって起動が妨げられる場合は、実験を広げるのをやめます。その時点で以前のマウントを復元し、生成された設定と運用担当者が管理する設定を分離します。プラットフォーム、ストレージ、ハードウェアの担当者へエスカレーションする前に、証拠を保持してください。

ルートファイルシステム全体も読み取り専用にできますか？

はい。一時ディレクトリやランタイムディレクトリを含め、必要な書き込み可能なパスがすべて個別に提供されている場合に可能です。

起動時にアプリが設定を書き換える場合はどうすればよいですか？

生成された書き込み可能なコピーまたはイメージのビルド手順を使用し、権威ある設定を黙って書き込み可能にしないでください。

書き込み可能なデータとキャッシュを同じボリュームに置くべきですか？

保持ルールと復元ルールが同じ場合に限ります。再生成できるキャッシュは、通常、分離したほうが適しています。

読み取り専用設定と書き込み可能なデータを混在させたマウントについて、実際の答えは引き続き条件付きです。設定への書き込みが失敗し、アプリデータが再作成後も保持され、一時パスの使用量が上限内に収まる必要があります。アプリが設定の書き換えを要求する、データがコンテナレイヤーに保存される、または所有者情報によって起動が妨げられる場合は、以前のマウントを復元し、生成された設定と運用担当者が管理する設定を分離してください。元の負荷に耐えられない部分的な成功は、互換性があるとはいえません。