ローカルのビルド済みデプロイ候補

対象読者：サーバーのデプロイと保守を行う運用者。

R1 / G6A は Contracts 0.4.0-alpha.1、schema 000025 のデプロイ準備とローカル分離検証を提供します。現在も development/evaluation 候補です。実サーバー、HTTPS、本番メール、R1 正式リリースは、別途開始する G6B の対象です。

ゲーム開発者は引き続き固定 SDK パッケージを利用します。運用者は Infra の release/rc.py で7リポジトリの commit/tree を固定し、check と build を実行します。独立した bundle/ には入力、イメージ識別情報、SDK の出所、checksum が含まれます。実行コンテナーはアプリの checkout をマウントせず、Go のコンパイルや npm のインストールを行いません。同じ入力から再ビルドできますが、Docker tar のバイト単位の再現性は保証しません。対応プラットフォームは実際の検証記録に従います。

最小例

配布された bundle/ 内で、管理者ではないホストユーザーとして実行します。Docker/Compose、Python 3.12+、Bash が必要です。新しい専用プロジェクト名を使ってください。公開ポートはループバックのみにバインドします。init は異なるランダムな認証情報と非公開設定を作成し、既存ファイルを上書きしません。

python3 deploy.py --env ./private.env --project echo-g6a-example init
python3 deploy.py --env ./private.env --project echo-g6a-example load
python3 deploy.py --env ./private.env --project echo-g6a-example validate
python3 deploy.py --env ./private.env --project echo-g6a-example deps
python3 deploy.py --env ./private.env --project echo-g6a-example migrate
python3 deploy.py --env ./private.env --project echo-g6a-example initialize
python3 deploy.py --env ./private.env --project echo-g6a-example up

migration と API 起動は独立しています。migrator が schema を所有し、アプリと運用者は異なる制限付き DB 認証情報を使用します。アプリは migration 記録の変更や DDL を実行できません。アプリ起動と初期化済み DB の保守では schema checksum 全体を確認します。空の対象での archive/admission 確認は独立バックアップと最新 seal を検証します。S3 の管理者、Public、Admin、運用プログラムも別々の認証情報を使い、アプリにストレージ管理権限を与えません。サーバー側 consent/feature gate と現在の membership/session 認可は維持されます。

よくある間違い

設定には機密情報があります。ファイルや docker compose config の全出力を共有しないでください。Console が受け取るのは公開 Admin API、ゲーム用 Public API、Docs の origin だけです。CONSOLE_URL は Admin CORS、S3_PUBLIC_ENDPOINT は添付ファイルの署名先を指定します。実行設定を変更して同じイメージを再起動できます。Key、JWT、SMTP 認証情報、署名 URL をフロントエンド設定に入れないでください。

ローカル検証は HTTP と Mailpit による合成メールの捕捉を使います。将来のリバースプロキシは5つの公開入口をループバックポートに転送できます。実ドメイン、証明書の信頼と更新、実際の Godot HTTPS、本番 SMTP は G6B で検証します。Public API は Forwarded/X-Forwarded-For を信頼しないため、クライアント単位の入口制限はプロキシ側の責任です。

運用と復元

datactl と accountctl はビルド済みです。既定は dry-run で、変更には --apply が必要です。observe は回数と時間を制限した単発の health/readiness 確認を行い、ローカル JSON を出力します。失敗時は非ゼロの終了コードになります。外部通知やホストへの定期タスク登録は行いません。

python3 deploy.py --env ./private.env --project echo-g6a-example datactl --action inspect
python3 deploy.py --env ./private.env --project echo-g6a-example observe
COMPOSE_ENV_FILE=./private.env COMPOSE_PROJECT_NAME=echo-g6a-example python3 scripts/backup-local.py --root ./private-backups --apply

保存期限はフィードバック/コメント/添付90日、バックアップ7日、機密除去済み監査180日、SDK ローカル7日のままです。PostgreSQL、オブジェクト、独立 recovery-journal、別保存の最新 recovery-witness、非公開バックアップルート、現在の復元制御ディレクトリを保持してください。候補の authority ファイルは各永続ボリュームの authority/ 配下にあります。journal/witness は DB/オブジェクトのバックアップに含めません。同一ホストの複数ボリュームは別ホストの災害復旧ではありません。

復元には独立した空の対象、承認済みバックアップ、最新 cutover seal が必要です。元のアプリは fenced/stopped のままにし、対象は元の独立 authority を参照します。アクセス再開前に削除/失効を補正し、オブジェクトを実際に清掃します。旧パスワード、session、コード、保留中の招待は無効になります。完了済み復元の再実行は現在のデータを確認し、旧 dump を再投入しません。authority の欠損/古さ、帰属不一致、清掃失敗時は閉鎖を維持します。具体的なコマンドと再試行は配布 README とデータライフサイクルを参照してください。

stop はアプリを停止し、down は永続ボリュームを保持します。対象が利用中の元 authority を down -v で削除してはいけません。アプリ交換/ロールバックは、明示的に検証済みの契約/schema/復元プロトコルの範囲内に限定します。DB migration は常に forward-only です。

次のステップ

モジュール、ヘッドレスブラウザー、実依存サービスの検証記録は区別します。実際の Godot エディター/OS 入力は別の必須手順であり、native acknowledgement を捏造してはいけません。ソース canonical clean-stack とイメージ成果物の検証も別の証拠です。成果物検証では実イメージ、マウント、プログラム、checksum を確認し、必須 browser suite の失敗/skip/再試行をゼロにします。

G6B ではサーバー/アーキテクチャ、Git/CI/registry、証明書、本番 SMTP、独立バックアップ/authority 保存先、通知先を決め、容量/プロジェクトコスト上限、実 RPO/RTO、ライセンスと対応/エクスポート範囲を確定します。MinIO はオープンソース配布の保守を終了しており、固定イメージはローカル評価に限定します。本番ストレージの保守元は未決定です。SDK は development/evaluation ライセンスのままで、ローカルで動作する候補は正式リリースを意味しません。

許可されたテスト環境

別途許可されたテスト環境では rc.py lock --images release/images.amd64.lock.json で AMD64 の入力を固定できます。元の ARM64 候補は変更しません。対象ホストで正確な AMD64 イメージを読み込み、HTTPS、メール、SDK、運用を実際に検証してください。ビルドやクロスコンパイルだけではプラットフォームの対応を証明できません。

明示的な永続ディレクトリを使う場合、bundle の非公開環境で CANDIDATE_DATA_ROOT を Compose project と同名の非公開絶対パスに設定します。親ディレクトリは事前に 0700 で作成してください。deps は新しい所有ディレクトリに PostgreSQL、オブジェクト、journal、witness の個別パスを作り、管理対象の名前付きボリュームをバインドします。所有記録のない既存データや異なるバインドは拒否します。同梱のデプロイ、バックアップ、復元は同じ構成を読みます。復元先は独自の DB/オブジェクトを使い、元の journal/witness を外部 authority として保持します。元の authority を削除しないでください。同一ホストの復元という制限は変わりません。

テスト project は echo-g6b-<name> です。非 local テストでは SMTP_RECIPIENT_ALLOWLIST に許可された受信者一件だけを設定します。Admin API は SMTP のエンベロープや本文を書く前に確認します。他の受信者には従来の一般化された API 応答を返しますが、メールは送信しません。メールを発生させる入口ルートも許可されたテスターに制限し、実際の送信回数を限定してください。SMTP の受理と受信箱への到着は別に検証します。アドレスと資格情報は非公開設定に保持します。これらはメール認証の迂回や本番利用の承認を意味しません。

SMTP の接続期限は2秒、会話全体の期限は10秒で、要求の期限が先ならそちらを優先します。STARTTLS と認証の複数往復を有限時間で処理しますが、受信箱への到着を証明するものではありません。

コード要求は受信資格を調べる前に、共通のメール接続に最大5秒を使います。その後は対象・対象外のアドレスに同じ3秒の送信期限と応答下限を適用します。合計最大8秒で Console の既存10秒タイムアウト内に収まり、受信資格による処理時間の差を隠します。