セルフホスト型アプリのアップデート前に、コンテナのUID/GIDとボリュームの所有権を固定する方法
セルフホスト型アプリの更新では、デプロイ時に数値ユーザーの契約を固定し、コンテナを置き換える前にボリュームの所有権を検証することで、root所有のファイルが作成される可能性を低減できます。
予防策は、イメージ内部のユーザー名を安定したストレージの識別子として扱わないことです。永続データを書き込む実効UIDとGIDを記録し、それらをホストのディレクトリまたは名前付きボリュームに対応付け、PUID/PGIDやユーザーネームスペースの設定を維持し、完全な展開の前に小さな書き込み可能パスで新しいイメージをテストします。これにより、イメージ更新によって設定、アップロード、データベース、メディアのメタデータの数値所有者が知らないうちに変わるのを防げます。
更新前に数値UIDとGIDを記録する
実行中のプロセスユーザー、プライマリグループ、補助グループ、および各書き込み可能マウント内の代表的なファイルの数値所有権を取得します。その所有権の基準情報と併せて、イメージのダイジェストまたはバージョンも保存します。
Dockerのイメージ構築に関するガイダンスでは、明示的なIDによって再ビルド時のずれを防げると説明されています。これは、自動的に割り当てられるイメージユーザーが、再ビルドごとに異なる数値IDを受け取る可能性があるためです。
appやmediaなどの名前だけでなく、数値も記録してください。新しいイメージで同じユーザー名が再利用されても、UIDが変わる可能性があり、ホスト上のファイルは数値の所有権を保存しているためです。
デプロイ契約で実行ユーザーを固定する
イメージがroot以外のアカウントで直接実行できる場合は、Composeまたはランタイム設定で意図したユーザーとグループを明示的に指定します。イメージにrootでの初期化フェーズが必要な場合は、その後に実際に永続データへ書き込むプロセスを文書化してください。
Open Containerイメージ仕様では、Userがランタイムのデフォルトとして定義されています。そのため、デプロイ側で意図的に上書きまたは検証しない限り、イメージの変更によってランタイムの識別情報が変わる可能性があります。
サポートされている初期化モデルが必要なイメージに、任意の非root UIDを強制しないでください。永続ファイルの所有者を予測可能に保ちながら、契約はアプリケーションに文書化された設計に従う必要があります。
PUIDとPGIDをホストの所有権に合わせる
PUIDとPGIDの変数を公開しているイメージでは、バージョン管理されたComposeまたは環境設定でそれらの値を固定し、ホスト側のボリュームディレクトリが対応するサービスアカウントによって所有されていることを確認します。
LinuxServerは、PUIDによってコンテナからの書き込みが対応付けられるため、マッピングされたボリューム内で作成されたファイルをコンテナ外でも管理しやすくなると説明しています。
更新前に、設定したIDをホスト上のidの結果および既存ファイルの所有権と比較してください。1000が別のユーザーやサービスに割り当てられているサーバーで、例の値として1000を無条件にコピーしないでください。
ユーザーネームスペースとrootlessマッピングを考慮する
rootless DockerやPodmanでは、コンテナ内ではプロセスがrootとして表示されても、ホスト上では非rootのUIDにマッピングされることがあります。所有権の変化を判断する前に、ネームスペースモードとサブUID/GIDの設定を記録してください。
Podmanのランタイムオプションでは、keep-idによってユーザーマッピングが維持されることが示されています。
コンテナ内でrootに見える所有者を「修正」する前に、ホスト側の数値IDを確認してください。ネームスペース内のrootとホストのrootは、必ずしも同じ識別情報ではありません。
テストボリュームで新しいイメージを事前検証する
本番コンテナを置き換える前に、意図したUID/GIDと、本番と同じ権限を持つ一時ディレクトリを使って新しいイメージを実行します。起動時の初期化によってファイルとディレクトリを1つずつ作成させ、ホスト側での所有権を確認します。
Red Hatのrootlessボリュームのデバッグガイドでは、ホストの所有権はUIDマッピングに従うため、コンテナ内に表示されるユーザー名だけでは十分な証拠にならないことが示されています。
カナリアテストで予期しないroot所有または再マッピングされたファイルが作成された場合は、ロールアウトを中止し、イメージのユーザー、エントリーポイント、ネームスペース、マウント設定を比較してください。再帰的な起動時移行によって写真やデータベースのツリー全体が変更された後に気付くよりも、はるかに安全です。
補助グループと書き込み可能なパスを検証する
アプリによっては、プライマリサービスUIDに加えて、共有メディア、ダウンロード、またはデバイス用グループを通じたアクセスが必要です。設定とすべての書き込み可能なパスを記録し、設定ディレクトリだけでなく、すべてのパスをテストしてください。
Kubernetesでは、runAsUserとrunAsGroupの明示的な制御が使用されます。これは、単純なDocker Composeのデプロイ以外でも同じLinuxの所有権原則が適用されることを示しています。
新しいイメージがすべての永続パスで期待どおりのホスト所有権を持つファイルを作成し、コンテナの再作成を1回行っても問題なく動作すれば、更新ポリシーは完成です。ロールアウト後にすでにroot所有のデータが生成されている場合は、関連するZimaSpaceの記事イメージ更新後にroot所有のファイルが作成される場合が復旧手順となります。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
