コンテナで復旧可能なPlex環境を構築する方法

復旧可能なコンテナ化Plex環境では、実行環境を使い捨てにできる一方、永続状態、メディアパス、ID、バックアップを明示的に管理できます。

設計の目的は、永続し続けるコンテナではなく、再構築可能なサービスにすることです。Plexの状態を安定したホストパスに置き、メディアのマウント先を予測可能にし、UID/GIDとデバイスアクセスを文書化して、少なくとも1つのバックアップを稼働中の状態保存デバイスとは別の場所に配置します。そのうえで、実行環境をゼロから再構築してレイアウトを検証します。

実行環境とPlexの状態を分離する

新しい場当たり的な場所にデータベースをコピーせずに、イメージとコンテナ定義を置き換えられるようにします。永続状態には、文書化された専用マウントとバックアップポリシーが必要です。

信頼性の高いPlex状態の移行には、実行環境が変わってもサーバーデータとパスの継続性を維持することが重要です。

空の実行環境で、同じ状態マウントを使用してコンテナを再作成します。Plexが期待したライブラリとID情報を伴って復帰しない場合、永続性はまだ適切に分離されていません。

マウントとサービスIDを標準化する

メディアとアプリデータのパスには、安定したホストのルートと予測可能な数値所有者を使用します。そうしないと、ホストの交換によって、正常に動作する復元作業が権限修正の作業になってしまいます。

一貫したUIDとGIDのマッピングにより、バインドマウント全体でコンテナのアクセス権とファイルシステムの所有権を一致させられます。

すべてのホストパス、コンテナパス、必要な所有者を文書化します。PlexのサービスIDでアプリデータのマウントに対して、無害な作成、名前変更、削除の操作をテストします。

バックアップを稼働中の状態保存デバイスの外部に保管する

同じプール内のスナップショットは便利ですが、あらゆるストレージ障害から保護できるわけではありません。復旧経路には、稼働中のアプリデータデバイスを失っても残るコピーを少なくとも1つ用意する必要があります。

バックアップの容量と変更量は、稼働中のデータベースの隣にある余剰領域ではなく、独立したストレージの役割として計画します。

1つの復旧用バックアップ階層を稼働中の状態保存デバイスとは別に保持し、復元先を定義します。バックアップへのアクセスが、復旧しようとしている同じマウントに依存していないことを確認します。復旧可能なコンテナスタックは、サーバー状態を手作業で再構築せず、クリーンな実行環境に接続できる永続アプリデータレイアウトから始まります。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

受け入れテストとして実行環境を再構築する

最も確実な証明は、文書化した構成からクリーンなコンテナを作成し、コピーした状態を接続して、隠れたホスト側の調整なしで検証することです。

復元テストによって、状態、権限、サービスの動作が置き換え後も維持されることが確認できれば、復旧が実証されたことになります。

再構築は、使い捨てのホストまたは分離されたネットワーク上で実施します。所要時間とすべての手作業を記録し、記憶に頼っている手順ではなく構成に依存するよう、不要な手順を簡素化します。