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

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

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

永続状態をコンテナイメージの外に保つ

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

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

ZimaSpaceのHome Assistantサーバーの全体構成は、より広い設計パターンを示しています。制御経路をシンプルに保ち、永続状態と大容量ストレージを分離し、サービスへの依存関係を増やす前に、稼働中の障害領域の外に復旧手段を確保しましょう。

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

バックアップが役立つのは、含まれるファイルが一貫した時点の状態を表している場合だけです。シンプルなローカルSQLite構成なら、メンテナンス時間中にサービスを停止して永続設定ボリュームをコピーする方法は分かりやすく、確実です。外部データベースを使う場合は、データベースの整合性を保つ方法でバックアップし、どのHome Assistant設定バックアップと組み合わせるものかを記録しておきましょう。

最近のDockerボリュームのバックアップワークフローでは、アーカイブコマンドが成功すれば復元可能だと決めつけず、コピーからの復元を重視しています。SSD、ファイルシステムの障害、または誤ったpruneによってサービスとバックアップの両方が失われないよう、少なくとも1世代分をDockerホストの外に保管してください。

バックアップの経過日数、アプリケーションのバージョン、データベースのバージョン、サイズ、チェックサム、暗号化キーの保管場所、およびクリーンなホストへの復元手順を記録してください。復元に関するメタデータがないまま保持期間だけを設定しても、復旧システムではなくアーカイブの山ができるだけです。

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

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

各依存サービスに、それぞれのヘルスシグナルと障害時の動作を設定してください。Home Assistantは起動中のデータベースへの再試行を行うべきですが、データベースが繰り返し異常な状態になる場合は、再起動を延々と繰り返して隠すのではなく、障害として把握できるようにしてください。プロセス終了からの復旧には再起動ポリシーを使い、サービスが実際に準備完了かどうかの判断にはヘルスチェックと監視を使います。

可能な限り、オプションのサービスは起動のクリティカルパスから外してください。ダッシュボードのレンダラー、メディアツール、またはメトリクスエクスポーターが壊れても、自動化コントローラーがオフラインにならないようにします。

Featured

ZimaBoard 2 - 大きなアイデアを実現するミニホームサーバー

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

変更の境界を明確にし、ロールバック用のペアを保管する

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

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

より新しいHome Assistant Docker Composeの設計記事では、ネットワーク、永続ストレージ、バックアップを明示的なデプロイメント上の判断事項として扱っています。ロールバックにはこのモデルが適しています。使い捨てのコンテナファイルシステム自体ではなく、代替コンテナに必要な状態とデプロイメント定義を保持します。

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

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

バックアップの破損を疑う前に、ファイルの所有権とアクセス権限を確認してください。移行後の権限の違いにより、データが存在していても初期設定画面が表示されることがあります。Docker移行からの復旧事例では、権限と隠れた状態がそれぞれ独立して、復元したインストール環境の表示を妨げる仕組みを紹介しています。

1. 既存の管理者アカウントでログインします。
2. インテグレーション、エンティティ、オートメーション、ダッシュボード、履歴を検証します。
3. Zigbee、Z-Wave、Thread、Bluetooth、その他の無線機器の所有権を確認します。
4. インターネットを切断し、重要なローカルオートメーションを実行します。
5. ホストとすべての必須依存関係を再起動します。
6. 空のホストから家庭の制御が機能するまでの総復元時間を計測します。

コンテナ化された依存関係ごとに復旧契約を用意する

復旧可能なデプロイメントには、バージョン管理された定義、ホスト外の状態保存、依存関係の準備完了、ロールバック用のバックアップ一式、クリーンなホストでの所要時間を計測した復元手順が必要です。これらのテストに合格すれば、コンテナは本来あるべき姿、つまり手放せないペットではなく、交換可能なランタイム単位になります。