Terraform とツールキットを使用してノードと VCF をデプロイする

このドキュメントでは、Terraform の自動化を使用して、ベアメタル ESXi ノード、レイヤ 2 ブロードキャスト ネットワーク、Cloud DNS、VMware Cloud Foundation（VCF）を使用した Google Cloud の VMware ソリューション用のリージョン内部ロードバランサ（ILB）をデプロイする方法について説明します。

この自動化により、次のインフラストラクチャがプロビジョニングされます。

  • 専用のベアメタル ESXi ハイパーバイザ（z3-highmem-192-highlssd-metal または z3-highmem-192-metal）。
  • ジャンボ フレーム（MTU 8896）を備えたマルチ VLAN レイヤ 2 ブロードキャスト ネットワーク。
  • Cloud DNS 限定公開マネージド ゾーンとインバウンド クエリ転送ポリシー。
  • Gratuitous ARP / ルーター アドバタイズ（GARP_RA）高速 IP 移動高可用性を備えたリージョン ILB。
  • 管理インターフェースと NSX データパス インターフェースのゾーン ネットワーク エンドポイント グループ（NEG）。

始める前に

Terraform 自動化を実行する前に、必要なツールをインストールし、必要な API を有効にして、レイヤ 2 サブネット ネットワーキングを許可リストに登録し、 Google Cloud プロジェクトの次の要件を確認します。

  1. ターゲット リージョンとゾーンに、プロジェクトのベアメタル ノードの割り当てが十分にあることを確認します。必要な割り当てと、割り当ての増加を表示またはリクエストする方法については、割り当てと上限をご覧ください。
  2. 必要な Identity and Access Management（IAM）権限（Compute Admin（roles/compute.admin）など）があることを確認します。Cloud DNS を使用する場合は、DNS Administrator（roles/dns.admin）が必要です。
  3. 計画されているすべての ESXi ノードのホスト名と VCF アプライアンスのエンドポイントの正引きと逆引きをサポートするように、ドメイン ネーム システム（DNS）インフラストラクチャを計画します。
  4. ノードのホスト名: デプロイ時に各ノードの完全修飾ドメイン名（FQDN）を指定します。これにより、ESXi はホスト名を使用して証明書を生成します。
  5. 信頼できるイメージのポリシー: 組織で constraints/compute.trustedImageProjects 組織ポリシーが適用されていない場合、対応は必要ありません。組織でこのポリシーが適用されている場合は、Compute Engine がベアメタル ブートディスクを作成できるように projects/smve-prod-public-images を許可します。詳細については、イメージ アクセスの制限を設定するをご覧ください。

  6. VPC Service Controls: ターゲット プロジェクトがサービス境界内にない場合、対応は必要ありません。プロジェクトがサービス境界内にある場合は、smve-prod-public-images プロジェクト（projects/999037279871）への compute.googleapis.com オペレーションを許可する下り（外向き）ルールを追加します。

    - egressFrom:
    identityType: ANY_IDENTITY
  egressTo:
    operations:
    - serviceName: compute.googleapis.com
      methodSelectors:
      - method: "*"
    resources:
    - projects/999037279871

    詳細については、下り（外向き）ルールのリファレンスをご覧ください。

Terraform をインストールする

Terraform CLI バージョン 1.3.0 以降をインストールする必要があります。Terraform をインストールするには、オペレーティング システムのタブを選択します。

Debian または Ubuntu

Debian または Ubuntu に Terraform をインストールするには、次のコマンドを実行します。

sudo apt-get update && sudo apt-get install -y gnupg software-properties-common curl
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo 'deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com '"$(lsb_release -cs)"' main' | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt-get update && sudo apt-get install -y terraform

RHEL または CentOS

RHEL または CentOS に Terraform をインストールするには、次のコマンドを実行します。

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
sudo yum -y install terraform

汎用 Linux

バイナリを直接ダウンロードして Terraform をインストールするには、次のコマンドを実行します。

export TERRAFORM_VERSION='1.9.5'
curl -fsSLO 'https://releases.hashicorp.com/terraform/'"${TERRAFORM_VERSION}"'/terraform_'"${TERRAFORM_VERSION}"'_linux_amd64.zip'
unzip 'terraform_'"${TERRAFORM_VERSION}"'_linux_amd64.zip'
sudo mv terraform /usr/local/bin/
rm 'terraform_'"${TERRAFORM_VERSION}"'_linux_amd64.zip'

Google Cloud API を有効にする

ターゲットの Google Cloud プロジェクトで、次の必要な API を有効にします。

サービス エンドポイント 目的
compute.googleapis.com ベアメタル インスタンス、Virtual Private Cloud（VPC）ネットワーク、レイヤ 2 サブネット、ファイアウォール、NEG、リージョン ILB、静的 IP 予約。
dns.googleapis.com 限定公開の正引きおよび逆引き DNS マネージド ゾーン、受信転送ポリシー、DNS レコードセット。

gcloud CLI を使用して必要な API を有効にするには、次のコマンドを実行します。

gcloud services enable \
    compute.googleapis.com \
    dns.googleapis.com \
    --project='PROJECT_ID'

PROJECT_ID は、ターゲット Google Cloud プロジェクトの ID に置き換えます。

リージョンの割り当てを確認する

ベアメタル ノードをプロビジョニングする、またはクラスタを作成する前に、プロジェクトに十分なリージョンとグローバルの Compute Engine 割り当てがあることを確認します。リージョン内の既存のすべてのクラスタのリソースを次の増分値に追加してから、プロジェクトの割り当てと比較します。

割り当て指標 ベアメタル ノードごとに必要なリソース 3 ノードクラスタに必要なリソース
compute.googleapis.com/cpus_per_vm_family（Z3） 192 vCPU 3 × 192 = 576 vCPU
compute.googleapis.com/local_ssd_total_storage_per_vm_family（Z3） 72 TB 3 × 72 TB = 216 TB
compute.googleapis.com/hyperdisk_balanced_total_storage 128 GB 3 × 128 GB = 384 GB
compute.googleapis.com/resource_policies 既存のクラスタにノードを追加する場合は 0 クラスタごとに 1 つのスプレッド プレースメント ポリシー
compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha 新しいアプライアンスなしでノードまたはクラスタを追加する場合は 0 新しい VCF 管理アプライアンス VIP または NSX Edge エンドポイントごとに 1 つ

必要な割り当ての完全なリストと、割り当ての増加を表示またはリクエストする方法については、割り当てと上限をご覧ください。

VLAN ベースのレイヤ 2 サブネット ネットワーキングを許可リストに登録する

VMware ソリューションでは、VLAN ベースのネットワーキングをサポートするために、Virtual Private Cloud（VPC）ネットワークのサブネットで [サブネット マスクを解決する] プロパティを [学習を伴うプライマリ範囲のみをブロードキャストする] に設定する必要があります。Google Cloud コンソールのサポート センターで、次の情報を含むサポート チケットを開きます。

  • プロダクト: Google Cloud VMware Engine
  • 優先度: P2
  • カテゴリ: ネットワーク接続
  • ビジネスへの影響: 技術に関する一般的な質問
  • 詳細情報を提供する: Allowlist L2 network connectivity for my project、プロジェクト ID、プロジェクト番号、デプロイのターゲット リージョンとゾーン

VLAN ベースのネットワーキングのサポートの詳細については、レイヤ 2 エミュレーション: ARP ブロードキャストとカスタム MAC ラーニングをご覧ください。

組織のポリシーと VPC Service Controls を構成する

VMware ソリューションのベアメタル ESXi インスタンスは、smve-prod-public-images プロジェクト（プロジェクト番号 999037279871）でホストされている Google 提供の ESXi イメージから起動します。デフォルトでは、追加の構成は必要ありません。組織で信頼できるイメージのポリシーが適用されている場合、または VPC Service Controls を使用している場合にのみ、次の構成を適用します。

  • 信頼できるイメージのポリシー: 組織で constraints/compute.trustedImageProjects 組織ポリシーが適用されていない場合、対応は必要ありません。組織でこのポリシーが適用されている場合は、Compute Engine がベアメタル ブートディスクを作成できるように projects/smve-prod-public-images を許可します。詳細については、イメージ アクセスの制限を設定するをご覧ください。

  • VPC Service Controls の下り（外向き）ルール: ターゲット プロジェクトがサービス境界内にない場合、対応は必要ありません。プロジェクトがサービス境界内にある場合は、smve-prod-public-images プロジェクト（projects/999037279871）への compute.googleapis.com オペレーションを許可する下り（外向き）ルールを追加します。

    - egressFrom:
    identityType: ANY_IDENTITY
  egressTo:
    operations:
    - serviceName: compute.googleapis.com
      methodSelectors:
      - method: "*"
    resources:
    - projects/999037279871

    詳細については、下り（外向き）ルールのリファレンスをご覧ください。

IAM の権限とロールを構成する

Terraform を実行する ID（人間の管理者または自動化された CI/CD サービス アカウント）には、ターゲットのGoogle Cloud プロジェクトに対する次の IAM ロールが必要です。

ロール 役割 ID 使用範囲
Compute 管理者 roles/compute.admin ベアメタル コンピューティング インスタンスをプロビジョニングし、カスタム ブートディスク イメージをアタッチして、プレースメント ポリシーを構成し、マルチ NIC インターフェースを管理します。VPC ネットワーク、レイヤ 2 ブロードキャスト サブネット、静的 IP 予約、リージョン ILB、バックエンド サービス、転送ルール、ゾーン NEG を管理します。VPC の上り（内向き）ファイアウォール セキュリティ ルールを作成して管理します。
DNS 管理者 roles/dns.admin Cloud DNS のプライベート転送ゾーンと逆引きゾーン、インバウンド クエリ転送ポリシー、A リソース レコードセットと PTR リソース レコードセットを管理します。
サービス アカウント ユーザー roles/iam.serviceAccountUser デフォルトの Compute Engine サービス アカウント（PROJECT_NUMBER-compute@）にこのロールを付与して、cloud-platform スコープでインスタンスをプロビジョニングできるようにします。

gcloud CLI を使用してロールを付与する

必要なプロジェクト レベルのロールとサービス アカウントの権限を割り当てるには、次のコマンドを実行します。

# Assign required project-level roles (use 'serviceAccount:SA_EMAIL' if granting to a service account)
for ROLE in \
    roles/compute.admin \
    roles/dns.admin; do
  gcloud projects add-iam-policy-binding 'PROJECT_ID' \
      --member='user:USER_EMAIL' \
      --role=${ROLE}
done
# Grant Service Account User role on the Compute Engine default service account
gcloud iam service-accounts add-iam-policy-binding \
    'PROJECT_NUMBER-compute@' \
    --member='user:USER_EMAIL' \
    --role='roles/iam.serviceAccountUser' \
    --project='PROJECT_ID'

コマンドを実行する前に、次のように置き換えます。

  • PROJECT_ID: ターゲット Google Cloud プロジェクトの ID。
  • PROJECT_NUMBER: ターゲット Google Cloudプロジェクトのプロジェクト番号。
  • USER_EMAIL: ユーザー ID のメールアドレス。

Terraform ランナーを認証する

運用環境に応じて、次のいずれかの認証戦略を選択します。

サービス アカウントの権限借用を使用して認証する

サービス アカウントの権限借用では、有効期間の短い OAuth 2.0 アクセス トークンを生成することで、有効期間の長い認証情報キーを排除します。Terraform は指定されたサービス アカウントとして実行されますが、認証は個人の ID で行われます。Google Cloud は、Terraform がサービス アカウントに対して実行したアクションを監査します。

  1. ランナー サービス アカウントに対するサービス アカウント トークン作成者のロール（roles/iam.serviceAccountTokenCreator）を個人の Google Cloud ID に付与します。

    gcloud iam service-accounts add-iam-policy-binding 'SA_EMAIL' \
   --member='user:USER_EMAIL' \
   --role='roles/iam.serviceAccountTokenCreator' \
   --project='PROJECT_ID'

    コマンドを実行する前に、次のように置き換えます。

    • SA_EMAIL: Terraform ランナー サービス アカウントのメールアドレス。
    • USER_EMAIL: 個人の Google CloudID のメールアドレス。
    • PROJECT_ID: ターゲット Google Cloud プロジェクトの ID。

  2. ローカル環境を認証します。

    gcloud auth application-default login

  3. GOOGLE_IMPERSONATE_SERVICE_ACCOUNT 環境変数を設定して、Terraform の実行全体で権限借用を適用します。

    export GOOGLE_IMPERSONATE_SERVICE_ACCOUNT='SA_EMAIL'

アプリケーションのデフォルト認証情報を使用して認証する

ユーザー ID に必要な権限が直接付与されている開発環境とテスト環境で、アプリケーションのデフォルト認証情報（ADC）を使用します。Google Cloud は、個人の ID に対するアクションを監査します。

gcloud auth application-default login
gcloud config set project 'PROJECT_ID'

PROJECT_ID は、ターゲット Google Cloud プロジェクトの ID に置き換えます。

サービス アカウント キーファイルを使用して認証する

インタラクティブなユーザー ログインがサポートされておらず、認証が有効期間の長いサービス アカウント認証情報キーに依存している自動 CI/CD パイプライン（Cloud Build、GitHub Actions、Jenkins など）でサービス アカウント キーファイルを使用します。GOOGLE_APPLICATION_CREDENTIALS 環境変数をサービス アカウント キーファイルのパスに設定します。

export GOOGLE_APPLICATION_CREDENTIALS='KEY_FILE'

KEY_FILE は、サービス アカウントの JSON キーのパスに置き換えます。

モジュラー アーキテクチャを確認する

Terraform は、4 つのモジュラー ステージにわたってリソースのプロビジョニングを調整します。このモジュラー設計では、厳格な依存関係の順序付けが適用され、コンピューティング ホスト、ロードバランサ、DNS レコードをデプロイする前に、ネットワーキングの前提条件が満たされていることが確認されます。

+-----------------------------------------------------------------------------------+
| STAGE 1: VPC Network Infrastructure, Firewalls & Cloud DNS (modules/vpc)          |
| - Custom VPC Network (MTU 8896 jumbo frames)                                      |
| - VPC Ingress Allow-All Firewall Rule                                             |
| - Dedicated Standard Subnetwork (for DNS inbound resolver)                        |
| - Cloud DNS Private Forward & Reverse Managed Zones                               |
| - Cloud DNS Inbound Forwarding Policy (Dynamic DNS_RESOLVER IP discovery)         |
+-----------------------------------------------------------------------------------+
                                         │
                                         ▼
+-----------------------------------------------------------------------------------+
| STAGE 2: L2 Broadcast Subnetworks & Zonal NEGs (modules/subnets)                  |
| - Primary Management Subnet (Untagged Native VLAN, ARP broadcast learning)        |
| - Storage & Infrastructure Subnets: vSAN (VLAN tagged), vMotion, NSX TEP          |
| - Optional Dynamic Workload Subnets                                               |
| - Zonal Network Endpoint Groups (GCE_VM_IP_DEDICATED_BACKEND) for Mgmt & NSX TEP   |
+-----------------------------------------------------------------------------------+
                                         │
                                         ▼
+-----------------------------------------------------------------------------------+
| STAGE 3: Bare-Metal ESXi Hosts, IP Allocations & Host DNS (modules/hosts)         |
| - Compute Resource Placement Policy (Availability Domain Count: 5-8, default: 6)  |
| - Universal IP Allocator: Static reservations & dynamic allocation for all NICs   |
| - Bare-Metal ESXi Instances (z3-highmem-192-highlssd-metal, 4+ Multi-NICs)        |
| - Automated NEG Endpoint Attachments (in cluster_creation mode)                   |
| - Cloud DNS Forward (A) and Reverse (PTR) Records for all ESXi Hosts              |
+-----------------------------------------------------------------------------------+
                                         │
                                         ▼
+-----------------------------------------------------------------------------------+
| STAGE 4: Regional Internal Load Balancers & Appliances (modules/appliances)       |
| - Regional Backend Services (GARP_RA Fast IP Move HA Policy)                      |
| - Regional Forwarding Rules (L3_DEFAULT / ALL_PORTS / allow_global_access)        |
| - Automated Cloud DNS Forward (A) and Reverse (PTR) Records for Mgmt Appliances   |
+-----------------------------------------------------------------------------------+

管理クラスタのリソースをプロビジョニングする

管理ドメイン管理クラスタは、コア VCF コントロール プレーン アプライアンス（SDDC Manager、vCenter Server、NSX Management クラスタ、VMware Aria Suite）と ESXi ハイパーバイザをホストします。

Terraform ワークスペースを設定する

専用のワークスペース ディレクトリを作成し、Git を使用してツールキット リポジトリのクローンを作成します。

mkdir -p ~/vcf-deployments/mgmt-cluster
cd ~/vcf-deployments/mgmt-cluster
git clone https://github.com/GoogleCloudPlatform/self-managed-vmware-solution-toolkit

変数定義ファイルを構成する

ターゲット環境の値を使用して変数定義ファイル（management_cluster.tfvars）を作成します。sample_management_cluster.tfvars ファイルを e2e-terraform ディレクトリから management_cluster.tfvars ファイルにコピーし、インラインの手順とコメントに沿って、必要に応じてフィールドを更新します。

cp self-managed-vmware-solution-toolkit/e2e-terraform/sample_management_cluster.tfvars \
    self-managed-vmware-solution-toolkit/e2e-terraform/management_cluster.tfvars

Terraform 構成を適用する

self-managed-vmware-solution-toolkit/e2e-terraform ディレクトリに移動し、Terraform 構成を初期化して適用します。

cd self-managed-vmware-solution-toolkit/e2e-terraform
terraform init
terraform plan -var-file='management_cluster.tfvars' -out=tfplan
terraform apply tfplan

Terraform の出力を確認してエクスポートする

terraform apply を実行すると、Terraform は次の 4 つのカテゴリにわたる構造化された出力を公開します。

  • gcp_resources_self_links: VPC ネットワーキング、サブネット、インスタンス、プレースメント ポリシー、NEG、バックエンド サービス、転送ルール、ファイアウォール、Cloud DNS ゾーンの完全な Google Cloud リソース セルフリンク URL。
  • neg_attachment_commands:
    • deployment_mode 変数が "cluster_creation" に設定されている場合: Terraform がクラスタの作成時に NEG を自動的に接続することを示すステータス メッセージを返します。
    • deployment_mode 変数が "node_addition" に設定されている場合: 新しくプロビジョニングされた ESXi ホスト インスタンスを管理 NEG と NSX NEG の両方に接続するために必要な gcloud compute network-endpoint-groups update コマンドを提供します。
    • deployment_mode 変数が "appliance_addition" に設定されている場合: NEG が既存のクラスタノードに接続されたままであり、アプライアンスの追加中に Terraform が変更しないことを示すステータス メッセージを返します。
  • python_scripts_input_config: ツールキットの python ディレクトリにあるダウンストリーム VCF インストーラ デプロイ自動化スクリプトの構造化パラメータ構成ペイロード。この出力は、次のセクションで説明するヘルパー スクリプトを実行することで、ツールキットの Python スクリプトで想定される JSON 形式に変換できます。
  • management_domain_deployment_input_config: 管理ドメインのデプロイ用の構造化入力。ほとんどのフィールドはエンドツーエンドのプロビジョニングから事前入力されます。この入力は、必要に応じて、または指示に従って編集できます。また、次のセクションで説明するエクスポート スクリプトを使用して、管理ドメインのデプロイ用の JSON ファイルに変換できます。

デプロイ構成をエクスポートする

このツールキットには、Terraform 出力から構成ブロックを抽出し、ダウンストリーム ワークフロー用にフォーマットされたスキーマ準拠の JSON ファイルにエクスポートするヘルパー スクリプト（scripts/export_deployment_config.py）が含まれています。

  • management_domain_deployment_input_config: VCF 管理ドメインのデプロイ用の入力 JSON。
  • python_scripts_input_config: ツールキットの Python 自動化スクリプト（vcf_deployer）の入力 JSON（config.json）。

ヘルパー スクリプトを実行する

次のいずれかのオプションを選択して、e2e-terraform ディレクトリからヘルパー スクリプトを実行します（または -d フラグまたは -i フラグを指定します）。

  • 両方の構成を同時にエクスポートします。

    python3 ../scripts/export_deployment_config.py --config all --output-dir .

    このコマンドにより、次のファイルが生成されます。

    • management_domain_deployment_input.json
    • python_scripts_input_config.json

  • VCF 管理ドメインのデプロイ入力 JSON のみをエクスポートします。

    python3 ../scripts/export_deployment_config.py --config mgmt -o management_domain_deployment_input.json

  • Python ツールキットの入力 JSON のみをエクスポートします。

    python3 ../scripts/export_deployment_config.py --config python -o config.json

  • 保存された Terraform 出力またはパイプされた標準入力（stdin）からエクスポートします。

    # From stdin pipe:
terraform output -json | python3 ../scripts/export_deployment_config.py --config all --output-dir .

# From a saved JSON file:
terraform output -json > outputs.json
python3 ../scripts/export_deployment_config.py -i outputs.json --config all --output-dir .

次のステップ

  1. ノード準備ツールキットを実行して、各ホストの初期 ESXi root パスワードをリセットし、VCF デプロイ用にノードを準備します。また、エンドツーエンドの Terraform 構成の python_scripts_input_config 出力（ヘルパー スクリプトを使用して JSON に変換）を使用して、VCF インストーラ アプライアンスをデプロイします。手順については、ツールキットを使用してノードを準備し、VCF をデプロイするをご覧ください。
  2. VCF インストーラでリージョン オフライン デポへの接続を構成して、必要なソフトウェア バンドルをダウンロードします。
    • プロトコル: HTTPS
    • FQDN（IP アドレスは使用しないでください）: offline-depot.REGION.selfmanagedvmwareengine.goog（REGION は、ベアメタルノードが存在する Google Cloudリージョンに置き換えます）
    • ポート: 443
    • ユーザー名: vcf-depot-user
    • パスワード: Google1!
  3. management_domain_deployment_input_config JSON ファイル（ヘルパー スクリプトを使用してエクスポート）を VCF インストーラに提供して、管理ドメインをデプロイします。入力構成で user_should_input とマークされているすべてのフィールドを、ターゲット値に置き換えてください。VCF の初期化ワークフローを完了する手順については、Broadcom のドキュメントの新しい VCF フリートまたは新しい VCF インスタンスをデプロイするをご覧ください。
  4. Terraform を使用してノード容量を管理するでノードを追加して、クラスタ容量を拡張する。
  5. Terraform を使用して VCF アプライアンスを追加するで、追加の VCF アプライアンスのロードバランサと DNS レコードをプロビジョニングします。