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

エヴァ・ウォン

IceWhale author

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

How to Build a Recoverable Home Assistant Deployment With Containers - Zima Store Online

復旧可能なHome Assistantコンテナデプロイでは、コンテナイメージを使い捨てにし、状態、設定、シークレット、デバイスマッピング、ネットワーク動作、復元手順を実際のシステムとして扱います。

目的は、DockerでHome Assistantを再起動できるようにすることだけではありません。更新失敗、ディスク紛失、ホスト交換の後にクリーンなホスト上でサービスを再構築し、同じユーザー、インテグレーション、自動化、無線デバイス、データベース状態、ネットワークIDを、所要時間が把握された状態で復元することが目的です。

永続状態をコンテナイメージの外部に保持する

Home Assistantの設定ディレクトリ全体を永続的なホストストレージにマウントし、隠しディレクトリを含むすべての内容をバックアップします。コミュニティでの移行では、表示されるYAMLファイルだけをコピーし、UIで管理されるエンティティ、インテグレーション、その他の状態が保存されている.storageを見落とすことで、何度も失敗しています。あるコンテナ移行の失敗例では、シェルのワイルドカード展開によってドットファイルが気付かないうちに除外される仕組みが示されています。

Composeファイル、環境変数テンプレート、タイムゾーン、ネットワークモード、デバイスマッピング、バインドマウントのパス、必要なグループ権限を、バージョン管理されたインフラストラクチャノートに記録します。再現可能なビルドと別個の復旧用コピーがない限り、固有の家庭内状態をカスタムイメージに組み込まないでください。

ZimaSpaceのHome Assistantサーバートポロジー完全ガイドでは、より広いパターンを示しています。制御経路を小さく保ち、永続状態を大容量ストレージから分離し、サービスの依存関係を増やす前に、障害の影響範囲の外部に復旧手段を配置します。

頻度だけでなく、一貫性を保って状態をバックアップする

バックアップは、そのファイルが時点の整合した状態を表している場合にのみ役立ちます。単純なローカルSQLite構成では、メンテナンス時間に停止して永続設定ボリュームをコピーする方法が理解しやすく簡単です。外部データベースを使用する場合は、データベース整合性を保てる方法でバックアップし、どのHome Assistant設定バックアップと組み合わせるものかを記録します。

最近のDockerボリュームのバックアップワークフローでは、アーカイブコマンドが成功したからといって復旧可能だと判断せず、実際にコピーを復元することの重要性を強調しています。Dockerホストの外部に少なくとも1世代分を保持し、SSD、ファイルシステムの障害、誤ったpruneによってサービスとバックアップの両方が削除されないようにします。

バックアップの経過時間、アプリケーションバージョン、データベースバージョン、サイズ、チェックサム、暗号化キーの場所、クリーンなホストへの復元手順を記録します。復元メタデータのない保持ポリシーは、復旧システムではなくアーカイブの山を作るだけです。

Composeで依存関係と準備完了状態をモデル化する

Home AssistantがMQTT、外部データベース、プロキシ、その他のローカルサービスに依存する場合、コンテナの起動順序はサービスの準備完了を意味しません。プロセスが実行中でも、ソケット、スキーマ、ヘルスエンドポイントがまだ利用できないことがあります。Composeの準備完了状態ガイドでは、ヘルスチェックと依存条件によって起動時の競合を減らす方法を説明しています。

各依存サービスに固有のヘルスシグナルと障害時の動作を設定します。Home Assistantは起動中のデータベースに対して再試行すべきですが、繰り返し不健全なデータベースは、無限再起動の背後に隠さず障害として見えるようにします。プロセス終了からの復旧には再起動ポリシーを使い、サービスが実際に準備完了しているかの判断にはヘルスチェックと監視を使います。

可能な限り、オプションのサービスを重要な起動チェーンの外部に置きます。壊れたダッシュボードレンダラー、メディアツール、メトリクスエクスポーターによって、自動化コントローラーまでオフラインにならないようにします。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

変更の境界を固定し、ロールバック用のペアを保持する

更新前に、現在のHome Assistantイメージタグ、Compose定義、データベースバージョン、設定バックアップ、起動に関わる各補助サービスのバージョンを記録します。一度に変更するレイヤーは1つにします。設定やデータベースの移行によって永続状態が変更された後では、コンテナイメージだけをロールバックするのは安全でない場合があります。

大規模なホスト移行やデータベース移行の前に、ステージング環境への復元、または複製した復旧ディレクトリを使って対象バージョンをテストします。以前の正常動作が確認されたイメージと、更新直前に作成した状態スナップショットをペアで保持します。新バージョンで自動化、履歴、無線デバイス、ダッシュボード、通知、再起動テストに合格するまで、そのペアを削除しないでください。

より最近のHome Assistant Docker Compose設計記事では、ネットワーク、永続ストレージ、バックアップを明示的なデプロイ判断として扱っています。これはロールバックに適したモデルです。保持すべきなのは、交換用コンテナに必要な状態とデプロイ定義であり、使い捨てのコンテナファイルシステムではありません。

デプロイを復旧可能と呼ぶ前に、クリーンなホストで再構築する

予備マシン、VM、または分離されたテストディレクトリを用意し、稼働中のコンテナファイルシステムからファイルを読み取らずに復旧を実行します。コンテナランタイムをインストールし、Compose定義を配置し、永続状態を復元し、シークレットを再作成し、安定したデバイスパスで無線デバイスを接続し、必要な依存サービスを起動して、Home Assistantを開始します。

バックアップ不良と判断する前に、ファイルの所有者と権限を確認します。移行後の権限差異により、データが存在していても初回オンボーディング画面が表示されることがあります。あるDocker移行の復旧事例では、権限と隠し状態がそれぞれ独立して、復元したインストールが正しく表示されない原因になることが示されています。

既存の管理者アカウントでログインします。
インテグレーション、エンティティ、自動化、ダッシュボード、履歴を確認します。
Zigbee、Z-Wave、Thread、Bluetooth、その他の無線デバイスの所有権を確認します。
インターネットを切断し、重要なローカル自動化を実行します。
ホストと必要なすべての依存サービスを再起動します。
ホストが空の状態から家庭内の制御が動作するまでの総復元時間を測定します。

コンテナ化された各依存サービスに復旧契約を設ける

コンポーネント	永続オブジェクト	復旧の証明
Home Assistant	完全な`/config`状態	既存のアカウントと自動化が戻る
データベース	整合性のあるDBバックアップ	履歴クエリとRecorderへの書き込みが成功する
MQTT／ブローカー	必要に応じて、設定、認証情報、保持状態	デバイスが再接続し、公開できる
無線デバイス	デバイスID、ネットワークキー、マッピング	再ペアリングなしでコーディネーターが再接続する
ネットワーク／プロキシ	ポート、名前、証明書、ルート	ローカルおよび想定するリモートクライアントが再接続する

復旧可能なデプロイには、バージョン管理された定義、ホスト外の状態保存、依存サービスの準備完了確認、ロールバック用のペア、時間を計測したクリーンホストへの復元が備わっています。これらのテストに合格すれば、コンテナは本来あるべき姿になります。つまり、交換可能なランタイムユニットであり、かけがえのないペットではありません。