デプロイモードと起動経路 Preview
LiteとSaaSは、対象利用者、入口、使うAWSサービス、現在の検証状態が異なります。 Liteの実行手順は競技開催者マニュアルを使います。 このページのSaaS節はコード構成の参考であり、最近の実環境で確認済みの導入手順ではありません。
2 つのデプロイモード
- Lite モード — 1つの運営グループが自分のAWSで競技を開くモードです。推奨入口の
lite-pipeline.yamlはCloudFormationでCodeBuildを作り、CodeBuildがmake deployを実行します。AWS CodePipelineは使いません。ローカルcheckoutからmake deployを直接実行することもできます。 - SaaS モード — 複数組織へテナントを提供するコード構成です。
make deploy-saas、プール型・サイロ型テナント、System Admin、既存テナント更新用CodePipelineがありますが、最近の新規AWS環境で導入から削除までを通した記録はありません。
Liteは現在の開催手順、SaaSは専用環境で再検証が必要な構成参考として扱います。
新しいテナントがプロビジョニングされる流れ
SaaS構成参考: ここから「SaaSパイプラインの役割」までは、現在のLite開催では 使用しません。
新規テナントのプロビジョニングと、パイプラインによるロールアウトは別々の経路です。旧ドキュメントが取り違えていたのがこの区別です。
- テナント作成イベント (
onboardingRequest) を SBT のBashJobRunnerが受け取り、provision-tenant.shを実行します。デフォルトではテナントはプール型（プール型スタックを共有）で、PLATINUMティアのテナントだけが専用のサイロスタックを直接デプロイされます (bun run cdk -- deploy tenkacloud-tenant-template-<id>)。
つまり、テナントを 1 つ作成しても CodePipeline は実行されません。実行されるのはプロビジョニングジョブです。
SaaS パイプラインの役割
tenkacloud-saas-pipeline (CodePipeline) は、テナントを作成するためではなく、既存の全テナントへテナントスタックをロールアウトするために存在します。ソースは S3 オブジェクト（source.zip。make deploy-saas 中に prepare-source-bundle.sh がアップロードします）で、パイプラインはこれをポーリングします。変更を検知すると、DynamoDB のテナント一覧をたどり、各テナントスタックをウェーブ単位でデプロイ / 更新します（Step Functions の WaveIterator が CodeBuild を駆動します）。このように、新規テナントの作成と既存テナントへのロールアウトは別のルートを通ります。
問題がデプロイされる流れ
主催者がコンソールで Deploy をクリックすると、次のように進みます。
- コンソールが Deploy API を呼び出します。API はリクエストを検証し、Deployments テーブルに行を書き込み、
DeployCreateRequestedイベントをバスに発行します。 - Step Functions の実行が CodeBuild ジョブを開始します (
.sync)。 - ワーカーがテナントの ExternalId（常に必須です）を使って競技者アカウントのロールを AssumeRole し、そのアカウント内で CloudFormation の
CreateStackを実行します。
その後、コンソールはスタックが終了状態に達するまでデプロイのステータスをポーリングします。
問題パック
問題パック（最初のパックのチュートリアルを参照）は Lite 経路だけを通ります。Lite は synth 時に固定のテナント id local のアクティベーションを読み取るため、make deploy の前に --tenant local でアクティベートしてください。一方 SaaS モードは、パックのアクティベーションが 1 つでも存在すると synth 時に明示的に失敗します。プール型カタログから黙って除外することはありません。CDK_PARAM_SAAS_IGNORE_PACKS=true を設定するとこれを上書きしてそのまま進められますが、その場合、アクティベーションは単にどのテナントのカタログにも現れなくなります。