先日、Amazon EVS 上で VCF 9.1 をエンドツーエンドに自動デプロイする流れを、3コマンド＋手動30分の全体像として書きました。
記事で紹介したのは Deploy/VCF9-Phased-Deployment というツールキットで、Terraform（Phase 1）→ Python（Phase 2）→ 手動 OVA デプロイ（約30分）→ Python（Phase 3）という3フェーズ構成でした。手を動かすのは実質3コマンド、というものです。
その3フェーズでのステップを紹介したばかりですが、、さらに簡単な EVS Deployment Orchestrator が追加されました。こちらは Terraform も、途中の手動30分も不要で、CloudFormation スタックを1つ起動するだけで完成まで走り切ります。前回の3フェーズ方式の後継にあたるもので、今後はこちらを主に使っていくことになりそうなので、あらためて全体像を整理してみます。
- GitHub:
EVS Deployment Orchestrator とは
aws/solutions-for-amazon-evs リポジトリの Deploy/EVS-Deployment-Orchestrator にある、Amazon EVS 上で VCF 9 をデプロイするための CloudFormation ベースのソリューションです。現時点では、VCF 9.0.2 と 9.1.0 に対応しています。
いちばんの特徴は、ユーザーが起動するのが CloudFormation スタック1つだけ、という点です。スタックを起動すると、アカウント内に小さな runner（EC2 インスタンス）が自動で立ち上がり、この runner がネットワーク構築からベアメタルホストのプロビジョニング、VCF 本体のインストール・設定、NSX Edge クラスターの構築まで、すべての工程を無人で代行してくれます。前回の方式であった「フェーズごとにコマンドを叩く」「途中で ESXi UI にログインして手作業する」といった操作が丸ごと不要になりました。
所要時間はおおよそ4〜7時間。ただしこの時間はほぼ待ち時間で、人が張り付いて操作する必要はありません。
何が変わったのか：旧方式との比較
前回の3コマンド方式（VCF9-Phased-Deployment）と何が違うのか、並べてみます。
| 旧: VCF9-Phased-Deployment | 新: EVS Deployment Orchestrator | |
|---|---|---|
| 実行方式 | Terraform + Python の3フェーズ ＋ 手動30分 | CloudFormation スタック1つを起動して待つだけ |
| ローカルに必要なもの | Terraform、jumpbox 上での作業 | 基本なし（S3 に3ファイル置くだけ） |
| 実行主体 | 手元のワークステーション | アカウント内に自動起動する runner |
| 手動作業 | ESXi UI での約30分（データストア・VLAN タグ・OVA デプロイ） | なし |
| 所要時間 | 約3.5〜6時間 | 約4〜7時間（完全無人） |
| 撤去 |
terraform destroy ほか |
destroy.py 1コマンド |
やっていること（ゼロから稼働する VCF 環境を組み上げる）は同じですが、「人が触る回数」がぐっと減っています。特に、前回の記事で「唯一の手作業」と書いた途中の30分の手動ステップが自動化されたのが大きな変化です。
全体アーキテクチャ（デプロイ完了後）
デプロイが完了すると、次のものが揃った状態になります。
- VPC とネットワーク一式（DNS・NAT Gateway・VPC Route Server・セキュリティグループ）。既存 VPC への展開（BYO-VPC）も可能
- 自アカウント内のベアメタル EC2 上に構成された ESXi ホスト（インスタンスタイプと台数は blueprint で指定）
- VCF 9 一式 — vCenter Server / NSX Manager / SDDC Manager / VCF Operations
- NSX オーバーレイと VPC をつなぐ NSX Edge クラスター
- 全アプライアンスの認証情報を格納した AWS Secrets Manager のシークレット群
構成そのものは前回のツールキットとほぼ同じで、デフォルトは3ホストの Simple モデルです。ホスト数や Simple / HA の考え方は以前の記事で掘り下げているので、そちらもどうぞ。
全体の流れ：3つの準備 ＋ スタック1つ
まず全体像から。手を動かすのは、実質「シークレットを1つ作る」「S3 に3ファイル置く」「スタックを1つ起動する」の3つだけです。
| ステップ | 実行場所 | 所要時間 | やること |
|---|---|---|---|
| 1. デポトークンの登録 | ローカル / CLI | 数分 | Broadcom デポトークンを Secrets Manager のシークレットにする |
| 2. blueprint の準備 | ローカル | 数分 | サンプルをコピーして2箇所だけ書き換える |
| 3. S3 へアップロード | ローカル / CLI | ファイルサイズ次第 | blueprint・OVA・ovftool の3ファイルを S3 に置く |
| 4. スタックの起動 | CloudFormation | 起動は約5分 | テンプレートを起動して、あとは待つだけ |
| （自動）VCF デプロイ | runner（自動） | 約4〜7時間 | ネットワーク → ホスト → VCF → NSX Edge を無人構築 |
1つ目のスタックは約5分で完了しますが、この時点では runner と基本ネットワークができただけで、VCF のデプロイはまだ始まっていません。その後 runner が2つ目のスタック（デプロイ用インフラ）を自動生成し、そこから本番のデプロイが4〜7時間かけて進みます。
以下、準備するものと流れをもう少し具体的に見ていきます。
事前に用意するもの
CloudFormation スタックを起動する前に、次の4つを用意します。前回の記事で扱ったデポトークンや OVA がそのまま使える、と考えると分かりやすいです。
-
Broadcom デポトークン — VCF のバイナリをダウンロードするために必要なトークン。Broadcom Support Portal の VCF エンタイトルメント配下で発行し、Secrets Manager にシークレットとして登録します（既定名
evs-depot-token）。取得でつまずきやすいポイントなので、初めての方は取得手順をまとめた記事（別途公開予定）もあわせて確認してみてください。 -
VCF SDDC Manager OVA — 同じく Broadcom Support Portal からダウンロードします。ここで大事なのは、OVA のバージョンを blueprint の
vcf_versionと一致させること。9.1.0 の環境を作るなら 9.1.0 の OVA が必要です。 - VMware ovftool（Linux 版 zip） — OVA をデプロイするためのツール。これも Broadcom Support Portal から取得します。
-
blueprint（YAML） — 環境定義ファイル。リポジトリの
blueprints/にインスタンスタイプ × VCF バージョン別のサンプルが用意されているので、それをコピーして使います。
このうち OVA と ovftool は一度ローカルにダウンロードし、blueprint とあわせて3ファイルを S3 バケットにアップロードします。
なお、前提として Business または Enterprise サポートプランが有効な AWS アカウントが必要です。また、ベアメタルの vCPU クォータ（L-1216C47A）が「ホスト数 × ホストあたり vCPU」を満たしている必要があります（i4i.metal は128 vCPU/台、i7i.metal-24xl は96 vCPU/台）。リポジトリには check-quotas.py という読み取り専用のクォータ事前チェックスクリプトも同梱されているので、起動前に走らせておくと安心です。
blueprint は2箇所だけ書き換える
blueprint は環境の設計図で、blueprints/ フォルダから自分の構成に合うものを選んで blueprint.yaml にコピーします。たとえば i4i.metal で VCF 9.1.0 の vSAN 構成なら i4i.metal.vcf91.vsan.example.yaml です。
サンプルには推奨値がすべて埋まっているので、必ず書き換えるのは2箇所だけです。
-
dns.fqdn— 好きなプライベートドメイン名（例:vcf.example.internal）。プライベート DNS ゾーンが自動作成されるので、ドメインを登録したりする必要はありません -
evs.environment_name— この環境の表示名
instance_type と vcf_version は選んだ blueprint 側で設定済みなので、触る必要はありません。ホストを増やしたいときは hostnames.esxi のリストにエントリを追加します（Simple モデルは3ホストから、HA モデルは4ホストから）。踏み台サーバー（ジャンプボックス）や HCX を有効にしたい場合も、この blueprint 内のフラグで切り替えます。
デプロイの流れ（実際の操作）
準備ができたら、あとは起動して待つだけです。CLI で起動する場合はこんなイメージです。
# 1. デポトークンをシークレットに登録
aws secretsmanager create-secret \
--name evs-depot-token \
--secret-string "<YOUR-DEPOT-TOKEN>" \
--region us-east-2
# 2. blueprint・OVA・ovftool を S3 にアップロード（バケットは事前に用意）
aws s3 cp blueprint.yaml s3://$BUCKET/blueprint.yaml --region us-east-2
aws s3 cp $OVA s3://$BUCKET/ --region us-east-2
aws s3 cp $OVF s3://$BUCKET/ --region us-east-2
# 3. CloudFormation スタックを起動
aws cloudformation create-stack \
--stack-name my-evs-deployment \
--region us-east-2 \
--template-body file://evs-deployment-orchestrator.yaml \
--capabilities CAPABILITY_IAM \
--parameters \
ParameterKey=BlueprintKey,ParameterValue=s3://$BUCKET/blueprint.yaml \
ParameterKey=OvaKey,ParameterValue=s3://$BUCKET/$OVA \
ParameterKey=OvfKey,ParameterValue=s3://$BUCKET/$OVF \
ParameterKey=AvailabilityZone,ParameterValue=us-east-2a \
ParameterKey=DepotSecretName,ParameterValue=evs-depot-token
もちろん、テンプレートのアップロードとパラメーター入力を CloudFormation コンソールから行っても構いません。
起動後の進捗は、1つ目のスタックの Outputs タブにある OrchestratorLogsUrl から CloudWatch Logs でリアルタイムに追えます。SnsTopicArn パラメーターに SNS トピックを指定しておくと、開始・各ステージ完了・成功／失敗の通知も飛ばせます（長いステージ中は約2時間ごとにも通知されます）。ログに ALL STAGES COMPLETE が出れば完了です。
4〜7時間のあいだ、ログの出力が止まって見える時間帯があります。ベアメタルホストの作成に45〜100分、VCF bringup と NSX Edge に3〜5.5時間ほどかかるので、無音が続くのは正常です。失敗しているかどうかは、ログに FAIL [<stage-id>] が出ていないかで見分けます。
中で何が起きているのか — runner と9つのステージ
「スタック1つ」といっても、中では runner が段階を追って処理を進めています。前回の3フェーズ方式を知っていると、対応関係が見えてきて面白いところです。runner 上の処理は、次の9つのステージに分かれています。
| # | ステージ | 内容 |
|---|---|---|
| 1 | aws_config |
ランディングゾーン（NAT Gateway・Route Server・セキュリティグループ）の作成 |
| 2 | generate_config |
デプロイ設定の生成 |
| 3 | validate_dns |
DNS の検証 |
| 4 | phase2_deploy |
EVS 環境とベアメタルホストの作成 |
| 5 | esxi_vlan_tag |
ESXi 準備：VLAN タグ付け |
| 6 | esxi_vmfs_create |
ESXi 準備：VMFS データストア作成 |
| 7 | esxi_ova_deploy |
ESXi 準備：SDDC Manager OVA のデプロイ |
| 8 | esxi_ova_verify |
ESXi 準備：OVA デプロイの検証 |
| 9 | phase3_deploy |
VCF bringup と NSX Edge クラスターの構築 |
前回の記事で「唯一の手作業」として紹介した、データストア作成・VLAN タグ付け・OVA デプロイの3つ（ステージ5〜7）が、そっくりそのまま自動化されているのが分かります。各ステージは checkpoint で記録されるので、途中で失敗しても未完了のステージから再開できます（完了済みはスキップされます）。
パスワードの扱いも前回同様よくできていて、vCenter や NSX、SDDC Manager などの認証情報は自動生成され、evs-<environment-id>_<role> という名前で Secrets Manager に保存されます。平文がディスクに残らない設計です。
デプロイ後の環境とアクセス
完成すると、各コンポーネントの管理 UI に次の URL でアクセスできます。
- vCenter:
https://vc.<fqdn> - NSX Manager:
https://nsx.<fqdn> - SDDC Manager:
https://sddcm.<fqdn>
ただしこれらは VPC 内のプライベートネットワーク上にあるので、外部から直接は開けません。手軽にアクセスしたい場合は、blueprint で jumpbox.enabled: true にしておくと Windows のジャンプボックスが一緒に作られます（このジャンプボックスも、インバウンドは自分の IP から RDP を開けるまでは閉じたままなので安心です）。VPN や AWS Client VPN 経由でも到達できます。
各種パスワードは、先ほどの Secrets Manager から取り出します（vcenterSso、nsxAdmin、sddcManagerRoot など）。
撤去（Teardown）
使い終わったら、同梱の destroy.py で片付けます。
# 環境のみ削除（最も安全。インフラは再利用のため残す）
python3 destroy.py --bootstrap-stack my-evs-deployment --region us-east-2
# 全部消す（VPC・runner 含む）
python3 destroy.py --bootstrap-stack my-evs-deployment --region us-east-2 --all
ここで1点だけ注意があります。ESXi ホストは CloudFormation ではなく EVS の API 経由で作られているため、CloudFormation スタックを先に消すとホストが残って課金され続けます。片付けるときは、スタック削除の前に必ず destroy.py を実行するのが正解です。スクリプトは環境 ID や VPC を自動で見つけてくれて、べき等なので再実行も安全です。
まとめ
Amazon EVS 上での VCF 9 のデプロイが、CloudFormation スタック1つで完結するところまで、さらに簡単になりました。
- 用意するのは前回と同じ材料（デポトークン・OVA・ovftool）＋ blueprint
- blueprint は2箇所だけ書き換える
- スタックを1つ起動したら、あとは4〜7時間待つだけ
- 前回「唯一の手作業」だった途中の30分も自動化された
- 撤去も
destroy.py1コマンド
前回の3コマンド方式でも十分ラクになったと感じていましたが、今回のはさらにその上を行っていて、正直「ここまで簡単になったのか」という印象です。VCF の構築に張り付く時間がほぼゼロになるので、EVS 上で VCF 9 を試したい方は、まずこちらを使ってみるのがよさそうです。
各ステージの中身や blueprint のカスタマイズは、また別記事で掘り下げていく予定です。