先日、Amazon EVS 上での VCF 9.1 デプロイが EVS Deployment Orchestrator で CloudFormation スタック1つにまで簡単になった、という全体像を整理しました。
概要編では CLI 例を中心に流れをまとめましたが、今回は 実際に東京リージョン (ap-northeast-1) で最後まで構築してみた 実践編です。マネジメントコンソールから起動する手順、途中の進捗が SNS でどう届くか、そして完成した vSphere 環境まで、スクリーンショットつきで追っていきます。
結論から言うと、手を動かしたのは最初の準備だけで、あとは 実測で約6時間 待つだけでした。しかも SNS 通知を設定しておいたおかげで、その待ち時間はログに張り付く必要すらありませんでした。
- GitHub:
今回試した構成
| 項目 | 値 |
|---|---|
| リージョン / AZ | 東京リージョン ap-northeast-1 / ap-northeast-1c |
| VCF バージョン | 9.1.0.0 |
| ESXi ホスト | i7i.metal-24xl × 3 台 |
| ハイパーバイザー | VMware ESXi 9.1.0.0200 |
| runner インスタンス | t3.large（デフォルト） |
| SNS 通知 | 有効（メール購読） |
ESXi ホストには、東京リージョンでも使えるようになった第 5 世代 Intel Xeon 搭載の i7i.metal-24xl を選びました。このインスタンスの中身は以前デプロイして覗いてみたので、興味があればこちらもどうぞ。
ホストは 3 台構成にしました。VCF 9 の 2・3 ホスト（Simple モデル）構成の考え方は別記事で整理しています。
そもそも、何がそんなに簡単なのか
参考にした AWS 公式ブログでは、Terraform（フェーズ 1）→ Python（フェーズ 2）→ ESXi UI での手動作業 約30分 → Python（フェーズ 3）という 3フェーズ の手順が紹介されています。
今回使う EVS Deployment Orchestrator は、この後継にあたるソリューションです。Terraform も、途中の手動30分も不要で、CloudFormation スタックを1つ起動するだけ。あとはアカウント内に自動で立ち上がる runner（小さな EC2 インスタンス）が、ネットワーク構築からベアメタルホストのプロビジョニング、VCF 本体のインストール、NSX Edge クラスターの構築まで、すべての工程を無人で代行してくれます。
やっていること自体は3フェーズ方式と同じなので、対比の詳しい表は概要編に譲ります。ここでは「フェーズごとにコマンドを叩く」「途中で ESXi UI にログインして手作業する」がまるごと消えた、とだけ押さえておけば十分です。
準備：3ファイルとシークレットを用意する（Mac / CLI）
手を動かす準備は、大きく「シークレットを1つ作る」「blueprint を書き換える」「S3 に3ファイル置く」の3つだけです。ここでは Mac のターミナル（AWS CLI v2）で進めます。
1. Broadcom デポトークンをシークレットに登録
VCF のバイナリをダウンロードするためのデポトークンを、Secrets Manager のシークレットにしておきます。名前は任意ですが、スタック起動時の DepotSecretName パラメーターと一致させる必要があります（既定名 evs-depot-token）。
SECRET_NAME=evs-depot-token
REGION=ap-northeast-1
aws secretsmanager create-secret \
--name "$SECRET_NAME" \
--secret-string "<YOUR-DEPOT-TOKEN>" \
--region "$REGION"
2. blueprint を用意して2箇所だけ書き換える
リポジトリの blueprints/ フォルダにあるサンプルを blueprint.yaml にコピーし、必ず書き換えるのは次の2箇所だけです。推奨値は最初から埋まっています。
-
dns.fqdn— 好きなプライベートドメイン名（今回はmastoy.evsにしました）。プライベート DNS ゾーンは自動作成されるので、ドメインの登録などは不要です -
evs.environment_name— この環境の表示名
instance_type と vcf_version は選んだ blueprint 側で設定済みなので触りません。ホストを増やしたいときは hostnames.esxi のリストにエントリを追加します。
起動前に、リポジトリ同梱の読み取り専用スクリプト check-quotas.py でクォータ不足がないか確認しておくと安心です。ベアメタルの vCPU クォータが「ホスト数 × ホストあたり vCPU」を満たしている必要があります（i7i.metal-24xl は 96 vCPU/台なので、3台なら 288 vCPU 以上）。
3. blueprint・OVA・ovftool を S3 にアップロード
Broadcom Support Portal から取得した SDDC Manager OVA と Linux 版 ovftool（zip）を、blueprint とあわせて S3 バケットに置きます。OVA のバージョンは blueprint の vcf_version と一致させる必要があります（9.1.0 の環境には 9.1.0 の OVA）。
BUCKET=<your-bucket-name>
REGION=ap-northeast-1
BLUEPRINT=blueprint.yaml
OVA=VCF-SDDC-Manager-Appliance-9.1.0.0300.25536191.ova
OVF=VMware-ovftool-9.1.1-25678992-lin.x86_64.zip
aws s3 cp "$BLUEPRINT" "s3://$BUCKET/blueprint.yaml" --region "$REGION" \
&& aws s3 cp "$OVA" "s3://$BUCKET/" --region "$REGION" \
&& aws s3 cp "$OVF" "s3://$BUCKET/" --region "$REGION"
これで準備は完了です。ここまでの3ファイルが揃えば、あとはコンソールでスタックを起動するだけです。
スタックを起動する（マネジメントコンソール）
今回はマネジメントコンソールからテンプレート evs-deployment-orchestrator.yaml を起動しました。
パラメーター入力画面では、先ほど用意した3ファイルの S3 URI と、AZ・デポトークンのシークレット名を入れていきます。Notification SNS topic ARN（後述）や CIDR プレフィックス、runner のインスタンスタイプもここで指定できます。
このテンプレートは IAM ロールを作成するため、次の画面で「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します」にチェックを入れます。
なお最終確認画面では、同じパラメーターで起動できる クイック作成リンク を生成できます。同じ構成を再現したり共有したりするときに便利です。
参考までに、このスタックが作る土台のリソース（runner インスタンス、VPC、サービスアクセス用サブネット、セキュリティグループなど）を CloudFormation デザイナーで見るとこんな構成です。
スタックは2つできる、進捗はログで追える
起動すると、1つ目のスタック（今回は evs-vcf91）は約5分で CREATE_COMPLETE になります。ただしこの時点では runner と基本ネットワークができただけで、VCF のデプロイはまだ始まっていません。
その後、runner が2つ目のスタック evs-vcf91-amazon-evs-9-1-0-0-infrastructure を 自動生成 します。これがデプロイ用インフラ（NAT Gateway・Route Server・DNS ゾーンなど）を持つスタックで、以降の本番デプロイはここから進みます。この2つ目のスタックは手で触る必要はありません。
進捗は、1つ目のスタックの Outputs タブ にある OrchestratorLogsUrl から CloudWatch Logs でリアルタイムに追えます。ログに ALL STAGES COMPLETE が出れば完了、FAIL [<stage-id>] が出ていなければ正常進行中、という見分け方です。
SNS 通知が想像以上に便利だった
GitHub の README でも推奨されていた SNS 通知（SnsTopicArn パラメーター）を設定しておいたところ、これがとても便利でした。4〜7時間のデプロイに張り付く必要がまったくなくなります。
通知は、開始時・各ステージ完了時・長いステージ中は約2時間ごと・最後の成功／失敗時に届きます。実際に届いたメールを時系列に並べると、こんな流れでした。
| 時刻 | 件名 | 内容 |
|---|---|---|
| 9:13 | Deployment started - about 4-7 hours | デプロイ開始。完全無人で 4〜7 時間の見込み |
| 9:16 | Preparation complete - creating environment + hosts | ネットワーク・DNS 検証が完了、ベアメタルホスト作成へ（45〜100分） |
| 9:59 | Infrastructure ready - starting VCF bringup (~3-5.5h) | ホスト・OVA が準備完了、最長の VCF bringup + NSX Edge へ |
| 11:59 | Still in progress - VCF bringup + NSX edge cluster | bringup 継続中（約2時間経過）。正常 |
| 13:59 | Still in progress - VCF bringup + NSX edge cluster | bringup 継続中（約4時間経過）。正常 |
| 15:20 | EVS deployment SUCCEEDED | 完成。ログイン URL と認証情報の場所を案内 |
開始の通知はこんな内容です。「約 4〜7 時間、完全無人で走る」「節目ごとにメールする」「操作は不要」と、最初にきちんと見通しを教えてくれます。
長い bringup フェーズに入る手前でも、「ここから最長のフェーズ、約2時間ごとに進捗を送る」と予告してくれます。
その予告どおり、長いフェーズ中は約2時間ごとに「まだ処理中、これは正常です」という通知が届きます。無音が続いても止まっていないと分かるので、精神衛生上とても良かったです。
そして最後に成功通知。vCenter / NSX Manager / SDDC Manager のログイン URL と、認証情報が Secrets Manager のどこにあるかまで教えてくれます。
9:13 開始・15:20 完了なので、実測は 約6時間 でした。この間に手を動かした操作はゼロです。
デプロイ完了：vSphere Client で確認
成功通知が届いたら、環境は完成しています。VPC 内のプライベートネットワーク越しに vCenter へアクセスすると、esxi01〜esxi03 の3ホストと edge01・edge02 の NSX Edge、そして各管理アプライアンスがそろっているのが確認できました。ホストのモデルは狙いどおり i7i.metal-24xl、ハイパーバイザーは ESXi 9.1.0.0200 です。
各 UI の URL は次のとおりです（<fqdn> は blueprint で指定したドメイン）。
- vCenter:
https://vc.<fqdn> - NSX Manager:
https://nsx.<fqdn> - SDDC Manager:
https://sddcm.<fqdn>
これらは VPC 内のプライベートネットワーク上にあるので、外部から直接は開けません。手軽にアクセスしたい場合は、blueprint で jumpbox.enabled: true にしておくと Windows のジャンプボックスが一緒に作られます。VPN や AWS Client VPN 経由でも到達できます。
各種パスワードは自動生成され、evs-<environment-id>_<role> という名前で Secrets Manager に保存されています。たとえば vCenter SSO 管理者はこう取り出します。
REGION=ap-northeast-1
ENVIRONMENT_ID=<your-environment-id>
aws secretsmanager get-secret-value --region "$REGION" \
--secret-id "evs-${ENVIRONMENT_ID}_vcenterSso" \
--query 'SecretString' --output text
vcenterSso のほかに vcenterRoot、nsxAdmin、nsxRoot、sddcManagerRoot、operationsAdmin などのロールがあります。
撤去（Teardown）
検証が終わったら、同梱の destroy.py で片付けます。
STACK_NAME=evs-vcf91
REGION=ap-northeast-1
# 環境のみ削除（最も安全。インフラは再利用のため残す）
python3 destroy.py --bootstrap-stack "$STACK_NAME" --region "$REGION"
# VPC・runner も含めて全部消す
python3 destroy.py --bootstrap-stack "$STACK_NAME" --region "$REGION" --all
1点だけ注意があります。ESXi ホストは CloudFormation ではなく EVS の API 経由で作られているため、CloudFormation スタックを先に消すとホストが残って課金され続けます。片付けるときは、スタック削除の前に必ず destroy.py を実行するのが正解です。スクリプトは環境 ID や VPC を自動で見つけてくれて、べき等なので再実行も安全です。
まとめ
Amazon EVS 上での VCF 9.1 の構築を、CloudFormation スタック1つで最後まで走らせてみました。
- 手を動かすのは準備（シークレット・blueprint・S3 の3ファイル）だけ
- 起動はコンソールから。IAM 承認にチェックして起動するだけ
- スタックは2つできるが、2つ目は runner が自動生成するので触らない
- SNS 通知を設定しておくと、節目ごとにメールが届いて待ち時間に張り付かずに済む
- 今回の実測は約6時間、その間の操作はゼロ
- 撤去は
destroy.py。スタック削除より先に実行するのがポイント
実際に東京リージョンで通してみて、Amazon EVS での VCF 9 デプロイの手軽さを体感できました。特に SNS 通知は、長丁場のデプロイを放っておける作業に変えてくれるので、設定しておくことを個人的にはおすすめします。