Git、Dockerイメージ、データベース、プレビューアプリ用のホーム開発サーバーの構築方法
安定したサービス基盤を1つ構築し、永続データと再構築可能なアーティファクトを分離して、ホスト自体を保存しなくてもすべての開発者サービスを復旧できるようにします。
自宅で1〜2人の開発者が利用する場合、1台のLinuxサーバーでGit、イメージレジストリ、データベース、プレビューアプリケーションをホストできます。サービス同士が依存し始める前に、ID管理、ストレージの役割、ネットワーク公開範囲、バックアップ、復元を計画しておくことで、設計を管理しやすく保てます。
ハードウェアを選ぶ前にサービスの役割を割り当てる
Git、コンテナレジストリ、データベースエンジン、プレビューアプリケーションは、1台のホストを共有する場合でも別々のサービス役割として扱います。Gitはソース履歴を保持し、レジストリは再構築可能なアーティファクトを保存し、データベースは変更されるアプリケーション状態を保持し、プレビューアプリは使い捨ての実行環境です。
CPUとメモリは、同時実行されるビルド、データベースのワーキングセット、アクティブなプレビューを基準に見積もります。ストレージは、リポジトリ、レジストリの保持量、データベースの増加、ログ、バックアップの一時保管領域を基準に見積もります。これにより、大容量ディスクを購入したのにメモリが最初のボトルネックになる事態を避けられます。
障害が開発に許容できる範囲であれば、最初は1台のコンピュートノードを使用します。コンパイルの負荷が急増し、データベースや対話的なプレビューの処理を圧迫し始めたら、後からビルドワーカーを分離します。
永続データ、再構築可能なデータ、復旧データを分離する
| データの役割 | 例 | 保護方法 |
|---|---|---|
| 永続状態 | Gitリポジトリ、データベースボリューム | スナップショットと独立したバックアップ |
| 再構築可能なアーティファクト | コンテナイメージ、ビルドキャッシュ | 保持ポリシー、必要に応じたバックアップ |
| シークレットと設定 | デプロイキー、環境ファイル | 暗号化されたエクスポートとオフラインの復旧用コピー |
| 復旧メディア | OSインストーラー、復元手順 | サーバー外に保管 |
すべてのバイトを同じようにバックアップしてはいけません。レジストリは通常、ソースコードとビルド手順から再構築できますが、データベースは再構築できません。データベースのダンプまたは整合性のあるスナップショットは、稼働中のデータベースボリュームとは別に保存します。
実用的なセルフホスト型バックアップ計画では、NAS自体をバックアップだと見なすのではなく、Gitとオフサイトコピーを別々のジョブとして自動化することの重要性が示されています。
プライベートなアクセス経路を1つ作成する
サーバーに安定したLANアドレスとローカルDNS名を割り当てます。Git、レジストリ、データベース、プレビューへの経路は、それを必要とするネットワークにのみ公開します。リモートアクセスは、サービスごとにポートを転送するのではなく、プライベートVPNまたは認証付きリバースプロキシ経由で行います。
サービスアカウントとデプロイキーは分けて使用します。開発者同士で管理者パスワードを共有してはならず、プレビューアプリケーションにGitリポジトリやレジストリを変更できる認証情報を継承させてはいけません。
SMBまたはNFSは、共有マウントを本当に必要とするファイルワークフローにのみ使用します。SMBとNFSのクライアント適合性ガイドを参考にすると、プロトコルの選択とアプリケーションサービスへのアクセスを分けて考えられます。
デプロイ順序を依存関係グラフに合わせる
ストレージマウント、ID管理、データベース、レジストリ、Git、そしてプレビューアプリケーションの順に起動します。ヘルスチェックでは実際の依存関係を検証しつつ、アプリケーションのウォームアップが続いているだけで起動に時間のかかるデータベースを再起動しないようにします。
デプロイ定義、スキーマ移行、リバースプロキシの経路はバージョン管理します。シークレットはリポジトリの外部に保管し、復元先を明確にします。交換用ホストは、定義と保護された状態データからサービスを再作成できなければなりません。
クリーンなチェックアウトからプレビューアプリを1つ再構築し、そのイメージを取得し、テスト用データベースの復元を適用して、意図したクライアント経路からアクセスできることを確認します。
収集のためではなく、復元のためにバックアップする
リポジトリ、データベース固有のダンプ、サービス設定、暗号化されたシークレットを、すべてのサービスから書き込みマウントされていない保存先にバックアップします。少なくとも1つのコピーは、サーバーの電源管理範囲と管理者権限の境界の外部に保管します。
四半期ごとに、分離した名前空間へ復元します。ファイルが存在するかどうかだけでなく、ユーザー、拡張機能、スケジュール済みジョブ、リポジトリ権限、レジストリ認証、DNS経路を確認します。
ビルドキューが対話的な作業を遅らせる、イメージのプッシュ中にデータベースのレイテンシが上昇する、またはバックアップ時間帯が勤務時間と重なる場合は拡張します。実験的なサービス1つが、安定したサービス基盤に必要なリソースや認証情報を使い切る可能性がある場合は、同じホストに役割を追加するのをやめます。
最終的なセットアップの原則
すべてのサービスに明確な役割、保護された状態、管理されたアクセス経路、テスト済みの復元手順、そしてトポロジーを分割または拡張するための測定可能な基準があれば、セットアップは合格です。
おすすめ商品
NAS＆サーバー設定
もっと読む
研究論文、ノート、プライベートドキュメント向けのローカルRAG環境
元のドキュメントを正本として扱い、インデックス作成を再現可能にし、引用を必須とし、交換可能なモデルを非公開のソースデータから分離する。
開発者はなぜプライベートDNS、VPN、テストアプリにゲートウェイノードを使うのか？
ゲートウェイノードにより、プライベートアプリには管理された1つの名前とアクセス経路を提供し、コンピュートノードは外部に公開せず、交換可能な状態に保てます。
Composeファイル、シークレット、永続データを分離して再現性のあるアプリケーションスタックを構築する方法
Compose定義の移植性を保ち、シークレットを保護し、アプリデータを個別にバックアップして、クリーンなホスト上でスタックを再構築できるようにします。
