起動と配置の境界 Preview

未公開の統合 candidate の手順です。ローカルの大会・チーム運用は実装されていますが、クラウド基盤の配置や全カタログのプレイ確認が完了した公開版ではありません。

ローカル基盤

make local は Bun のサーバーと二つの画面を起動し、SQLite へ状態を保存します。make down は所有するローカル環境を止め、大会データを保持します。旧 host target は別モードとして残しません。はじめにで初期管理者、大会作成、参加者ログインを確認してください。

クラウド基盤の対応範囲と検証状況

make deploy と make destroy は、この版の Lambda と選択した Turso/DynamoDB の配置・基盤撤収 CLI を実行します。標準の CDKToolkit を再利用し、存在しない場合だけ make deploy 内で対象と権限を表示して公式 cdk bootstrap を実行します。標準の CloudFormation 実行 role はデフォルトで AdministratorAccess を持つため、bootstrap の信頼設定、呼び出し元の権限、アプリケーションの IAM 変更を確認してください。既存 Toolkit は変更せず、以前の独自 TenkaCloud Toolkit も削除・移行しません。クラウド開催は Lambda・Cognito と選択した Turso / DynamoDB で、汎用 CloudFormation 配置、flag / multi-flag・定期採点、参加者の Console / CLI アクセス、Cryptography Battle などの組み込み coordination を実行します。Docker / Compose 問題はローカル開催専用で、クラウドのカタログには表示しません。実 AWS・hosted Turso での大会性能は未検証です。撤収ではアカウント、リージョン、所有対象を表示し、基盤とデフォルトの所有データを削除します。外部 Turso の行は通常残し、make destroy-all で明示的にリセットします。問題環境は基盤を削除する前に大会の Teardown で撤収します。保持リソースには料金が発生する場合があります。infrastructure/templates/cloud-pipeline.yaml のデフォルトは現行 CLI と明示的に承認する無人 bootstrap・配置です。launcher の作成・build 開始前に広い権限を持つ CodeBuild role とソース ref を確認してください。コンテナの build 成功は、配置済みや費用ゼロの証明ではありません。

クラウドの大会と配置は、catalog の各 map、hint、plugin、元の問題ファイルを含む非公開 snapshot の catalogKey を保存します。A で作成した大会は、B の配置や B からの問題削除後も A を使います。Lambda は固定した source の hash を検証し、CodeBuild は保存した source ZIP の key と正確な S3 VersionId を使います。pin のない旧データは、元の snapshot を確認して復元した場合だけ CDK_LEGACY_CATALOG_KEY で回復します。現在の catalog を推測で割り当ててはいけません。この回復設定だけで開催中の旧環境を更新してはいけません。配置済みの版で大会を完了し、進行中の大会がないことの事前確認を満たしてから更新します。

クラウド配置ごとに <configured-key>.executions/<uuid>.zip を新しく upload し、source bucket の versioning を必須とします。別々の key の current version は noncurrent version 用の lifecycle で削除されません。参照する大会が終了し、所有する source bucket を別途確認して清掃するまで保存料金が発生します。基盤の destroy は所有する execution snapshot を削除しますが、別の source archive bucket は残ります。ソースのテストや synth は実 AWS・hosted Turso のリハーサルではありません。

問題環境の配置は別の操作

ローカル大会では所有情報付きの Docker Compose project と組み込み Battle を使います。AWS サービスの問題はクラウド開催専用で、確認した競技者アカウント、region、role、必須の ExternalId を使います。Docker / Compose 問題はローカル開催専用で、クラウドのカタログには表示しません。組み込みの Cryptography Battle は両方の開催方法に対応します。問題リソースには費用が発生する場合があります。ローカル停止では、以前の AWS 対応版が作成した stack を削除しません。

cloud pipeline は固定した現行ソースで CodePipeline/CodeBuild の配置・撤収を実行します。DB の選択やソース変更でデータは自動移行しません。

新規クラウド環境の stack 名は tenkacloud-cloud 系です。既存の tenkacloud-lite 系 stack は名前を維持します。CLI は Lite / cloud の既存 stack を検出し、両方ある場合は TENKACLOUD_STACK_LAYOUT=lite または cloud の明示指定が必要です。旧 Lite の更新は所有情報と永続 resource ID を検証します。 catalog pin のない旧 Lite 環境は、resource / schema の検査後、bootstrap・source upload・配置の前に、進行中の大会がないことを初回だけ明示確認します。開催中の大会は完了まで配置済みの版で継続してください。大会が残っていないことを運用者が確認してから対話で承認し、非対話の更新には CLOUD_ARGS="--confirm-no-active-events" を使います。通常の --yes ではこの確認を省略できません。legacy catalog key だけでは安全な更新を証明できず、過去のデータも自動移行しません。新規環境と復旧済み環境は通常の make deploy で自動配置します。公開 cloud-v1 の resource / DB schema への上書き更新は拒否し、データは自動移行しません。--drain-events は使えません。問題環境を大会の Teardown で撤収してから基盤を削除してください。

両 DB とも 99 チーム、SQL coordination は旧 4 MiB 上限です。現行 catalog の 9 template は TemplateBody の 51,200 bytes 上限を超え、TemplateURL は未実装です。全 AWS 問題の配置確認済みを意味しません。