mcpField
V
vpc-air-gapped

vpc-air-gapped

github.com/rivet-devクラウド・DevOps441.1k 回インストール1 日前に更新
リポジトリ

vpc-air-gapped について

プライベート VPC やエアギャップ環境で Rivet をセルフホストするためのスキルです。インストール、ストレージ、ネットワーク、監視、境界の保護を案内します。

主な機能

  1. 01単一バイナリでのエンジン導入
  2. 02単一ノード向けファイルシステムストレージ
  3. 03レジストリを使わない Docker イメージ転送
  4. 04プライベートネットワーク内の監視とヘルスチェック
  5. 05マルチノード導入の案内

活用シーン

  1. 01エアギャップ環境への Rivet の導入
  2. 02顧客の VPC 内でのソフトウェアとの同梱
  3. 03ノード増設時のストレージ選定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/rivet-dev/skills --skill vpc-air-gapped

インストール後、Claude Code で/vpc-air-gappedを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

BASE_SKILL.md
index.json
openapi.json
reference/actors/
access-control.md
actions.md
actor-runtime-socket.md
appearance.md
authentication.md
communicating-between-actors.md
connections.md
debugging.md
design-patterns.md
destroy.md
errors.md
events.md
fetch-and-websocket-handler.md
helper-types.md
http-api.md
input.md
inspector-tabs.md
keys.md
kv.md
lifecycle.md
limits.md
metadata.md
queues.md
reference/actors/quickstart/
backend.md
cloudflare.md
effect.md
next-js.md

詳細

VPC またはエアギャップネットワークへの Rivet のデプロイ

重要：作業を始める前に、このスキルのディレクトリにある BASE_SKILL.md を必ず読んでください。デバッグ、エラー処理、状態管理、デプロイ、プロジェクトのセットアップに関する重要なガイダンスが記載されています。これらのルールとパターンは、すべての RivetKit の作業に適用されます。以下の内容は、すでに読んで理解していることを前提としています。

インターネットへの送信接続がない VPC、オンプレミスのラック、完全なエアギャップ環境など、プライベートネットワーク内でセルフホスト版 Rivet を実行するためのパターンです。エンジンは単一のサービスで、推奨される単一ノードのストレージバックエンドはローカルファイルシステムです。また、エンジンはデフォルトでは外部への接続を行いません。エアギャップネットワークに対応する Rivet のデプロイモデルはセルフホストのみです。BYOC との詳しい比較については、セルフホスティングの概要を参照してください。

境界内で実行されるもの

セルフホスト型のデプロイには3つのコンポーネントがあり、すべてネットワーク内に配置されます。

コンポーネント役割境界内
お客様のバックエンドアクターコードを実行するランナーを含む、お客様のアプリケーションサーバーはい
Rivet Engineアクターのライフサイクルを管理し、メッセージをルーティングし、ダッシュボードと API を提供するオーケストレーションサービスはい
ストレージアクターの状態を永続化します。単一ノードではローカルファイルシステム、マルチノードでは PostgreSQL または FoundationDB を使用しますはい

ライセンスサーバーも Rivet Cloud アカウントもなく、rivet.dev へのコールバックもありません。境界内のクライアントは、プライベートネットワーク経由でエンジンのゲートウェイを通じてアクターに接続します。アーキテクチャを参照してください。

単一バイナリのインストール

エンジンは単一の rivet-engine バイナリにコンパイルされます。境界の外でソースからビルドし、その後バイナリを境界の内側にコピーします。

git clone https://github.com/rivet-dev/rivet.git
cd rivet
cargo build --release -p rivet-engine
# Copy target/release/rivet-engine into the perimeter.

ビルド済みバイナリは近日公開予定です。現在の選択肢については、Rivet Engine のインストールを参照してください。

ファイルシステムバックエンドを使って実行すると、すべてのデータがローカルディスクに保存されます。これは単一ノードのデプロイに適した、本番環境で使用可能な選択肢です。ファイルシステムのドキュメントでは、データベースのインフラストラクチャが不要なため、エアギャップ環境を主なユースケースとして挙げています。

RIVET__database__file_system__path="/var/lib/rivet/data" ./rivet-engine

設定はファイルから読み込むこともできます。エンジンは Linux では /etc/rivet/config.json にある設定を検出します（JSON、JSON5、JSONC、YAML、YML に対応）。また、--config でパスを上書きできます。環境変数には RIVET__ プレフィックスを使い、区切り文字には __ を使います。設定を参照してください。

エンジンはポート 6420 で独自のダッシュボードを提供するため、境界内のブラウザーだけで確認やネームスペースの管理ができます。

Docker Compose によるデプロイ

レジストリにアクセスできない Docker ホストでは、標準的な方法でエンジンイメージを境界の内側に移動します。

# Outside the perimeter.
docker pull rivetdev/engine:latest
docker save rivetdev/engine:latest -o rivet-engine.tar
# Inside the perimeter.
docker load -i rivet-engine.tar

次に、1つの Compose ファイルでエンジンとアプリを一緒に実行します。

services:
  rivet-engine:
    image: rivetdev/engine:latest
    ports:
      - "6420:6420"
    volumes:
      - rivet-data:/data
    environment:
      RIVET__FILE_SYSTEM__PATH: "/data"
    restart: unless-stopped

  my-app:
    build: .
    environment:
      RIVET_ENDPOINT: "http://default:admin@rivet-engine:6420"
    depends_on:
      - rivet-engine
    restart: unless-stopped

volumes:
  rivet-data:

RIVET_ENDPOINT は http://namespace:token@host:port 形式で、アプリがスタンドアロンで実行される代わりに、ランナーとしてエンジンに接続するための設定です。両方のサービスを起動した後、ダッシュボードまたはその API を通じてランナーをエンジンに登録します。マルチノードデプロイ向けの PostgreSQL のセットアップを含む詳しい手順は、Docker Composeを参照してください。

外部へのテレメトリー送信なし

エンジンがトレースとメトリクスをエクスポートするのは、OpenTelemetry を有効にした場合のみです。RIVET_OTEL_ENABLED=1 を設定しない限りエクスポートは無効で、エクスポート先はデフォルトで http://localhost:4317 のローカルコレクターです。設定がなければ、境界を越えるものはありません。

オブザーバビリティを利用する場合は、ネットワーク内にとどめてください。

  • RIVET_OTEL_ENABLED=1 を設定し、RIVET_OTEL_GRPC_ENDPOINT に境界内で稼働させるコレクターを指定します。
  • RIVET_OTEL_SAMPLER_RATIO を調整して、トレースのサンプリングを制御します。
  • エンジンのヘルスエンドポイントを、ライブネスプローブとレディネスプローブに使用します。

監視に関するガイダンスは、本番環境のチェックリストを参照してください。

顧客環境への Rivet の組み込み

顧客の VPC 内で動作するソフトウェアを提供している場合、同じセットアップを使って Rivet を、顧客がインターネット経由でアクセスする必要のあるサービスではなく、製品の内部コンポーネントとして稼働させることができます。

  • アプリと一緒にエンジンを提供します。 すでに提供している Compose ファイルまたはチャートに rivetdev/engine を追加します。アプリはプライベートネットワーク経由で RIVET_ENDPOINT を使ってエンジンを検出するため、1 つのアーティファクトでスタック全体をデプロイできます。
  • インストールごとに 1 つのネームスペースを使用します。 エンドポイント URL にネームスペースとトークンが含まれるため（http://namespace:token@host:port）、顧客ごとのデプロイで同じイメージを使用できます。エンドポイントを参照してください。
  • インストールごとに強力な管理者トークンを生成します。 デフォルトのトークンを置き換え、サーバー側で保持してください。管理者トークンを RIVET_PUBLIC_ENDPOINT に含めたり、クライアントが読み取れる場所に置いたりしないでください。
  • 必要な場合にのみパブリックエンドポイントを使用します。 パブリックトークン（pk_）を使う RIVET_PUBLIC_ENDPOINT が必要なのは、ブラウザクライアントがサーバーレスランタイムモードのアクターに接続する場合のみです。バックエンドのみのデプロイでは、完全に省略できます。
  • 顧客のエッジで TLS を終端します。 エンジンの前段にある顧客のリバースプロキシまたはロードバランサーで TLS を終端します。

1 ノードを超えるスケーリング

バックエンド用途ステータス
ファイルシステム（RocksDB ベース）エアギャップ環境へのインストールを含む、単一ノードのデプロイ本番環境対応、単一ノードのみ
PostgreSQLマルチノードのデプロイ現時点でマルチノード向けに推奨されていますが、実験的です
FoundationDB最大規模の本番環境へのデプロイエンタープライズ

マルチノードのデプロイでは、ロードバランサーの背後で 2 つ以上のエンジンノードを実行し、高スループット時にデフォルトの PostgreSQL LISTEN/NOTIFY 経路を置き換える pub/sub 用の NATS を追加します。単一ノードのファイルシステムインストールでは、どちらも必要ありません。本番環境チェックリストを参照してください。

境界セキュリティのチェックリスト

  • 管理者トークン：エンジン認証用に強力でランダムなトークンを生成し、クライアントに公開されていないことを確認します。
  • TLS 終端：リバースプロキシまたはロードバランサー経由で、エンジンへの接続を暗号化します。
  • パブリック公開を避ける：境界外のクライアントからのアクセスが本当に必要な場合を除き、ポート 6420 には境界内からのみアクセスできるようにします。
  • ヘルスチェック：エンジンのヘルスエンドポイントに対するライブネスプローブとレディネスプローブを設定します。
  • テレメトリー：OpenTelemetry のエクスポートをオフにするか、ネットワーク内のコレクターを指定します。
  • バックアップ：ファイルシステムバックエンドの場合は、データディレクトリをバックアップします。PostgreSQL の場合は、自動バックアップとフェイルオーバーを設定します。

設定の詳細

リファレンスマップ

アクター
CLI
クライアント
クックブック
デプロイ
全般
セルフホスティング

コメント

Markdown 対応