先日、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.py 1コマンド

前回の3コマンド方式でも十分ラクになったと感じていましたが、今回のはさらにその上を行っていて、正直「ここまで簡単になったのか」という印象です。VCF の構築に張り付く時間がほぼゼロになるので、EVS 上で VCF 9 を試したい方は、まずこちらを使ってみるのがよさそうです。

各ステージの中身や blueprint のカスタマイズは、また別記事で掘り下げていく予定です。

参考リンク