ブートドライブ交換に備えた復旧可能な開発者向けホームラボ構成

復旧可能な開発者向けホームラボでは、Gitサービス、レジストリ、データベース、Runner、プレビューアプリの動作方法を記録した唯一の媒体ではなく、ブートドライブを交換可能なメディアとして扱います。

実際の目標は、インストールメディア、バージョン管理された定義、保護されたシークレット、外部にバックアップされたアプリケーション状態、そして簡潔な復旧手順から、クリーンなディスクを動作するホストへ再構築できる状態にすることです。

交換可能なホストと永続状態を分離する

オペレーティングシステム、パッケージキャッシュ、コンテナイメージ、使い捨てのビルド成果物はブートドライブに置きます。データベースファイル、レジストリオブジェクト、Gitリポジトリ、アップロードファイル、失われると復元できない設定は、明示的なアプリデータまたはストレージマウントに配置します。

`/srv/appdata`、`/srv/projects`、`/srv/registry`のような安定したパスを使用し、UUIDなどの永続識別子でマウントします。必要なマウントが存在しない場合にサービスが明確に失敗するよう設定し、交換後のブートディスク上にある空のディレクトリへ書き込まないようにします。

状態を保持するすべてのコンポーネントと、その整合性を保つ方法を一覧化します。データベース固有のダンプ、リポジトリのバックアップ、オブジェクトストアのコピーは、3つすべてが1つのアプリケーションに属していても、異なるスケジュールが必要になる場合があります。

失敗まで複製せず、ホストを再現可能にする

Composeファイル、インフラストラクチャコード、パッケージリスト、ファイアウォールルール、DNSレコード、systemdユニット、シークレット以外の設定をバージョン管理に保存します。再構築時にすべてのサービスが一度にひそかに変更されないよう、バージョンは意図的に固定します。

シークレットは暗号化して別途バックアップします。対象には、サービスの認証情報、レジストリトークン、継続性が重要な場合のSSHホストキー、証明書素材、リカバリーコード、ストレージ暗号化キーが含まれます。それぞれのシークレットをどのように復元またはローテーションするかを文書化します。

最小限の再構築用インベントリとして、以下の復旧マップを使用します。

安全な依存関係を持つ交換手順を作成する

ベースOSをインストールしてパッチを適用し、ネットワークとリモート管理を復元し、保護されたストレージをマウントしてシークレットを復元します。その後、依存するアプリケーションより先に基盤サービスを起動します。プレビューアプリやRunnerが作業を始める前に、データベースとIDサービスが正常な状態になっている必要があります。

ホスト型Gitリモート、エクスポートしたレジストリイメージ、2台目のRunnerなど、重要な開発作業用の一時的なフォールバックを用意します。復旧手順は、障害が発生したホストが必要な手順を取得することを前提にしてはいけません。

関連するZimaSpaceのホームラボのストレージトポロジーでは、ブート、アプリデータ、バルクストレージの役割を分離しています。

独立したコンテナ復旧の概要でも、イメージ、設定、永続データにはそれぞれ異なる保護が必要であることが説明されています。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

空のターゲットで復旧を実証する

古いルートファイルシステム全体をそのままコピーせず、予備のSSD、一時VM、または隔離したマシンへスタックを復元します。SSHアクセスが可能になるまでの時間、最初のサービスが正常になるまでの時間、データセット全体の復元時間、通常の開発者ワークフローに戻るまでの時間を記録します。

リポジトリの整合性、データベースの一貫性、レジストリからのプル、TLS名、Runnerの登録、ファイル所有権、バックアップスケジュール、再起動順序を検証します。サンプルのアーティファクトまたはプロジェクトを元のものと比較します。

新しいブートドライブから、古いディスク上の隠しファイルに依存せず、文書化されたサービス状態へ到達できた場合にのみ、セットアップは合格となります。プラットフォーム、ネットワーク、ストレージに大きな変更を加えた後は、テストを繰り返します。