Git、Dockerイメージ、データベース、プレビューアプリ用のホーム開発サーバーを構築する方法

安定したサービス基盤を1つ構築し、永続データと再構築可能な成果物を分け、ホスト本体を保持しなくても開発者向けサービスをすべて復旧できるようにします。

自宅で開発者が1人か2人なら、1台のLinuxサーバーでGit、イメージレジストリ、データベース、プレビューアプリをホストできます。各サービスが相互に依存し始める前に、ID管理、ストレージの役割、ネットワーク公開範囲、バックアップ、復元を計画しておけば、管理しやすい設計を維持できます。

ハードウェアを選ぶ前にサービスの役割を割り当てる

Git、コンテナレジストリ、データベースエンジン、プレビューアプリは、同じホストを共有していても、それぞれ別のサービス役割として扱います。Gitはソースの履歴を保持し、レジストリは再構築可能な成果物を保存します。データベースは変更されるアプリケーション状態を保持し、プレビューアプリは破棄可能な実行環境です。

同時実行するビルド数、データベースのワーキングセット、アクティブなプレビューを基に、CPUとメモリの必要量を見積もります。リポジトリ、レジストリの保持量、データベースの増加量、ログ、バックアップの一時保存領域を基に、ストレージの必要量を見積もります。これにより、大容量ディスクを購入したのにメモリが最初のボトルネックになる事態を避けられます。

開発環境で障害が許容できる場合は、まず1台のコンピュートノードを使います。コンパイルが集中した際にデータベースや対話型プレビューの処理が圧迫されるようになったら、ビルドワーカーを分離しましょう。

永続データ、再構築可能なデータ、復旧用データを分ける

すべてのバイトを同じようにバックアップする必要はありません。レジストリは通常、ソースとビルド手順から再構築できますが、データベースはできません。データベースのダンプや一貫性のあるスナップショットは、稼働中のデータベースボリュームとは別に保存してください。

実用的なセルフホスト型バックアップ計画では、Gitの自動化とオフサイトコピーを別々の作業として扱うことの価値を示します。NAS自体をバックアップとみなしてはいけません。

プライベートなアクセス経路を1つ作成

サーバーに安定したLANアドレスとローカルDNS名を割り当てます。Git、レジストリ、データベース、プレビューへのルートは、必要とするネットワークだけに公開します。リモートアクセスには、サービスのポートをいくつも転送するのではなく、プライベートVPNまたは認証済みのリバースプロキシ経路を使用します。

サービスアカウントとデプロイキーは個別に用意します。開発者同士で管理者パスワードを共有してはならず、プレビューアプリにGitリポジトリやレジストリを変更できる認証情報を引き継がせてはいけません。

共有マウントが本当に必要なファイル処理に限って、SMBまたはNFSを選びましょう。SMBとNFSのクライアント適合性ガイドを参考にすると、プロトコルの選択とアプリケーションサービスへのアクセスを切り分けられます。

Featured

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

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

デプロイ順序を依存関係グラフに合わせる

ストレージのマウント、ID管理、データベース、レジストリ、Git、プレビューアプリの順に起動します。アプリケーションの起動がまだ完了していないというだけで遅いデータベースを再起動することのないよう、ヘルスチェックでは実際の依存関係をテストしてください。

デプロイ定義、スキーママイグレーション、リバースプロキシのルートはバージョン管理します。シークレットはリポジトリの外に保管し、復元先を明確にしておきます。交換用ホストでは、定義と保護された状態からサービスを再作成できる必要があります。

クリーンなチェックアウトからプレビューアプリを1つ再構築し、そのイメージをプルして、テスト用データベースの復元を適用し、想定されたクライアント経路からアクセスできることを確認します。

収集ではなく、復元のためにバックアップする

リポジトリ、データベースネイティブのダンプ、サービス設定、暗号化されたシークレットを、すべてのサービスから書き込みマウントできる場所とは別の保存先にバックアップします。サーバーの電源系統と管理者権限の境界の外にも、少なくとも1つコピーを保管してください。

四半期ごとに、隔離された名前空間へ復元します。ファイルが存在するかだけでなく、ユーザー、拡張機能、スケジュール済みジョブ、リポジトリの権限、レジストリ認証、DNSルートも確認します。

ビルドキューによって対話型作業が遅れる、イメージのプッシュ中にデータベースのレイテンシが上昇する、またはバックアップ時間が稼働時間帯と重なる場合は拡張します。実験用サービスが1つでも、安定稼働するサービス群に必要なリソースや認証情報を使い果たす可能性があるなら、同じホストへの役割の追加はやめましょう。

最終セットアップのルール

各サービスに明確な役割があり、状態が保護され、アクセス経路が制御され、復元テストが行われ、トポロジーを分割または拡張するための測定可能な条件が定められていれば、セットアップは合格です。