Home Assistantを単一のコンテナから回復性の高いサービススタックに移行する方法

まず稼働中のHome Assistantの状態を保持し、そのうえで永続データ、連携サービス、ネットワーク経路、起動時の依存関係、バックアップを明確な役割ごとに分けて、Home Assistantを単一コンテナから耐障害性の高いサービススタックへ移行します。コンテナを増やすことが目的ではありません。1つのサービス障害でスマートホーム全体が停止する可能性を下げることが目的です。

移行は段階的に行います。新しいスタックが起動し、ローカル制御のテストに合格し、ホストの再起動後も動作し、バックアップから復元できるまでは、元のコンテナとそのデータに手を加えずに残しておきます。耐障害性の高いスタックとは、Composeファイルが長いものではなく、障害発生時に状況を把握できるものです。

稼働中のコンテナを維持し、依存関係をすべて洗い出す

構成を変更する前に、Home Assistantの正確なイメージとバージョン、設定パス、環境変数、ネットワークモード、USBデバイスの割り当て、マウントパス、ホスト側のポートを記録します。次に、MQTTブローカー、データベース、Zigbee2MQTT、リバースプロキシ、VPN、DNS、証明書、バックアップ、ネットワーク共有など、コンテナ外でHome Assistantが依存しているものをすべて書き出します。これが移行計画の基礎になります。

依存関係をそれぞれ、正規の状態、再構築可能なサービス、外部インフラのいずれかに分類します。Home Assistantの設定とデータベースの状態は正規の状態です。取得したコンテナイメージは再構築可能です。DNSとルーティングは外部インフラの場合があります。この分類により、コンテナ定義だけをバックアップし、機能に必要なデータやサービスを忘れるというよくあるミスを防げます。

永続データと交換可能なコンテナを分ける

状態を保持する各サービスには、明示的な永続パスまたは名前付きボリュームを割り当て、所有権とバックアップ方針を把握しておきましょう。Home Assistantの設定、保持される場合のMQTTの状態、データベースファイル、証明書、自動化関連のシークレットを、コンテナの書き込み可能レイヤーだけに保存してはいけません。家庭内のデータを失わずに、イメージやコンテナを入れ替えられるようにします。

ボリュームの復旧には、アプリケーションへの配慮も必要です。移植可能なDockerボリュームのバックアップと復元パターンでは、実行中のディレクトリをそのままコピーすることと、移植可能なバックアップを作成することは同じではない理由を説明しています。データベースの場合は、書き込み中にコピーしたファイルが整合性を保つと決めつけず、バックアップ方法をデータベースに合わせてください。

ヘルスチェック、再起動ポリシー、起動時の依存関係を慎重に設定する

再起動ポリシーが答えるのは「このプロセスが終了したとき、ランタイムはどう動作すべきか？」という問いです。ヘルスチェックが答えるのは「このサービスは実際に使用できる状態か？」という問いです。この2つは別の問題です。データベースのコンテナはログを再生中でも実行中と表示されることがあります。MQTTブローカーも、プロセスは起動していても、Home Assistantが想定する接続をまだ受け付けていない場合があります。

意味のある準備完了条件があるサービスにはヘルスチェックを設定し、依存関係の順序付けは、依存するサービスが本当に必要とする場合にだけ追加してください。別の記事再起動ポリシーとサービスのヘルス状態が異なるシグナルである理由では、自動再起動が準備完了を保証するわけではないことを説明しています。また、固定の待機タイマーではなく実際のヘルス状態を条件として依存サービスの起動を制御したい場合は、別の記事依存サービス向けCompose準備完了パターンが役立ちます。

Featured

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

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

ネットワーク、リソース、メンテナンスの順序で障害の影響範囲を限定する

Home Assistantが応答性を保つ必要があるときに、メディアのスキャン、データベースの移行、実験的なコンテナによってCPUサイクル、使用可能なRAM、またはアプリ用SSD全体を使い切らないようにしましょう。負荷の高い周辺サービスには明確なリソース要件を設定し、可能であれば使い捨てのキャッシュは重要な状態データから離れた場所に置き、Home Assistantの制御経路は安定したローカルネットワーク上に維持してください。

更新の順序も分けて管理します。ホスト、コンテナランタイム、Home Assistant、データベース、任意の補助サービスの順に、各レイヤーを一度に1つずつ変更します。1回のメンテナンス時間内にすべてを更新してスタックが失敗すると、どのレイヤーが性能低下を引き起こしたのか特定できなくなります。ZimaSpaceのコンピューティング、ストレージ、バックアップの役割を分けたHome Assistantのトポロジーでは、コンピューティング、ストレージ、ネットワーク、復旧の役割をより広く把握できます。

再起動と復元のテストに合格してから切り替える

設定のコピーまたは管理された復元を使って、新しいスタックを起動します。ローカルダッシュボードを1つ、ローカルオートメーションを1つ、ZigbeeまたはThreadの接続経路を1つ、使用している場合はMQTT、履歴／データベースへのアクセス、通知、設計に含まれる場合はリモートアクセスをテストします。その後、コンテナだけでなくホスト全体を再起動し、手動操作なしで起動順序とデバイスマッピングが機能することを確認します。

最後に、復旧できることを実証します。クリーンな一時ターゲットに復元するか、少なくとも状態を保持するコンポーネントを別のテスト用名前空間に復元してください。ワークロードのボリュームが除外されていると、管理プレーンのバックアップは誤解を招くことがあります。この管理プレーンのバックアップにワークロードデータが含まれない場合がある理由では、スタック定義とアプリケーションデータをそれぞれ別に復旧対象としてカバーする必要があることを説明しています。

1. 正常に動作している単一コンテナの状態をスナップショットまたはバックアップします。
2. 依存関係を把握し、状態を保持するコンポーネントと再構築可能なコンポーネントに分類します。
3. 永続化するパスとサービス定義を明示的に作成します。
4. ヘルスチェック、再起動、リソースポリシーは、実際の障害モードを解決する場合にのみ追加します。
5. ローカル制御、無線機器、データベース、リモート接続経路、完全な再起動、復元をテストします。
6. 新しいスタックがすべてのテストに合格してから、古いコンテナを廃止します。

回復性の高いエンドポイントとは、「サービスを増やす」ことではありません。Home Assistantを状態を失わずに再構築でき、依存関係が既知の順序で復旧し、負荷の大きい隣接サービスが制御プレーンを圧迫せず、更新に失敗しても家全体の原因不明なトラブルに発展させずに切り分けられる構成です。