פריסת צמתים ו-VCF באמצעות Terraform וערכת הכלים

במאמר הזה מוסבר איך להשתמש באוטומציה של Terraform כדי לפרוס צומתי ESXi ללא מערכת הפעלה, רשתות שידור בשכבה 2, ‏Cloud DNS ומאזני עומסים פנימיים (ILB) אזוריים לפתרון VMware ב- Google Cloud עם VMware Cloud Foundation ‏ (VCF).

האוטומציה מקצה את התשתית הבאה:

• מנהלי Hypervisor ייעודיים של ESXi ללא מערכת הפעלה (z3-highmem-192-highlssd-metal או z3-highmem-192-metal).
• רשתות שידור Multi-VLAN Layer 2 עם מסגרות ג'מבו (MTU 8896).
• תחומים מנוהלים פרטיים של Cloud DNS וכללי מדיניות להעברת שאילתות נכנסות.
• מאזני עומסים פנימיים (ILB) אזוריים עם Gratuitous ARP או Router Advertisement‏ (GARP_RA) ו-Fast IP Move לזמינות גבוהה.
• קבוצות של נקודות קצה ברשת (NEG) לפי אזור, לניהול ולממשקים של נתיב הנתונים של NSX.

לפני שמתחילים

לפני שמריצים את האוטומציה של Terraform, צריך להתקין את הכלים הנדרשים, להפעיל את ממשקי ה-API הנדרשים, להוסיף לרשימת ההיתרים את הרשת של רשת המשנה של שכבה 2 ולוודא שהפרויקט ב- Google Cloud עומד בדרישות הבאות:

1. מוודאים שבפרויקט יש מספיק מכסה לצומתי Bare Metal באזור ובאזור הזמין הרצויים. במאמר מכסות ומגבלות מוסבר אילו מכסות נדרשות ואיך אפשר לראות את המכסות או לבקש להגדיל אותן.
2. מוודאים שיש לכם את ההרשאות הנדרשות לניהול זהויות והרשאות גישה (IAM), כולל Compute Admin (roles/compute.admin). אם אתם משתמשים ב-Cloud DNS, אתם צריכים גם את ההרשאה DNS Administrator (roles/dns.admin).
3. תכננו את תשתית ה-DNS כך שתתמוך בחיפושים קדימה ואחורה של כל שמות המארחים המתוכננים של צומתי ESXi ונקודות הקצה של מכשירי VCF.
4. שמות מארחים של צמתים: צריך לספק את שם הדומיין שמוגדר במלואו (FQDN) של כל צומת במהלך הפריסה. כך מוודאים ש-ESXi יוצר אישורים באמצעות שמות מארחים.
5. מדיניות בנושא קובצי אימג' מהימנים: אם הארגון שלכם לא אוכף את מדיניות הארגון constraints/compute.trustedImageProjects, אתם לא צריכים לעשות כלום. אם הארגון שלכם אוכף את המדיניות הזו, צריך לאפשר את projects/smve-prod-public-images כדי ש-Compute Engine יוכל ליצור דיסקים לאתחול של Bare Metal. מידע נוסף זמין במאמר הגדרת מגבלות גישה לתמונות.

6. ‫VPC Service Controls: אם פרויקט היעד לא נמצא בהיקף שירות, לא צריך לעשות כלום. אם הפרויקט נמצא בהיקף שירות, צריך להוסיף כלל תעבורת נתונים יוצאת שמאפשר פעולות של compute.googleapis.com לפרויקט smve-prod-public-images (projects/999037279871):

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

   למידע נוסף, קראו את ההסבר על כללי תעבורת נתונים יוצאת.

התקנת Terraform

צריך להתקין את Terraform CLI בגרסה 1.3.0 ואילך. כדי להתקין את Terraform, בוחרים את הכרטיסייה של מערכת ההפעלה:

‫Debian או Ubuntu

כדי להתקין את Terraform ב-Debian או ב-Ubuntu, מריצים את הפקודות הבאות:

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

כדי להתקין את Terraform ב-RHEL או ב-CentOS, מריצים את הפקודות הבאות:

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

Generic 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'

הפעלת ממשקי ה-API של Google Cloud

מפעילים את ממשקי ה-API הנדרשים הבאים בפרויקט היעד ב- Google Cloud :

נקודת קצה של שירות	מטרה
compute.googleapis.com	מכונות Bare-Metal, רשתות של ענן וירטואלי פרטי (VPC), תת-רשתות של שכבה 2, חומות אש, קבוצות של נקודות קצה ברשת (NEG), מאזני עומסים פנימיים (ILB) אזוריים והקצאות של כתובות IP סטטיות.
dns.googleapis.com	תחומים מנוהלים של DNS פרטי להעברה ו-DNS הפוך, כללי מדיניות להעברה של תנועה נכנסת וקבוצות של רשומות DNS.

כדי להפעיל את ממשקי ה-API הנדרשים באמצעות ה-CLI של gcloud, מריצים את הפקודה הבאה:

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

מחליפים את PROJECT_ID במזהה של פרויקט היעד ב- Google Cloud .

אימות המכסה האזורית

לפני שאתם מקצים צומתי Bare Metal או יוצרים אשכול, ודאו שיש לפרויקט מספיק מכסות אזוריות וגלובליות ב-Compute Engine. מוסיפים את המשאבים של כל האשכולות הקיימים באזור לערכים המצטברים הבאים, לפני שמשווים אותם למכסת הפרויקט:

מדד המכסה	המשאבים הנדרשים לכל צומת Bare Metal	המשאבים שנדרשים לאשכול עם 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 × 128GB‏ = 384GB
compute.googleapis.com/resource_policies	0 כשמוסיפים צמתים לאשכול קיים	מדיניות אחת למיקום מרווח לכל אשכול
compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha	0 כשמוסיפים צמתים או אשכולות בלי מכשירים חדשים	‫1 לכל VIP של מכשיר ניהול VCF חדש או נקודת קצה (endpoint) של NSX Edge

במאמר מכסות ומגבלות מפורטות כל המכסות הנדרשות, ומוסבר איך להציג אותן או לבקש להגדיל אותן.

רשימת היתרים של רשתות משנה בשכבה 2 שמבוססות על VLAN

כדי לתמוך ברשתות שמבוססות על VLAN, בפתרון של VMware צריך להגדיר את המאפיין Resolve Subnet Mask של רשתות המשנה של רשת ה-VPC לערך Broadcast primary range only with learning. פותחים כרטיס תמיכה במרכז התמיכה של מסוףGoogle Cloud ומציינים את הפרטים הבאים:

• המוצר: Google Cloud VMware Engine
• עדיפות: P2
• קטגוריה: קישוריות רשת
• ההשפעה על העסק: שאלה טכנית כללית
• לספק פרטים נוספים: Allowlist L2 network connectivity for my project, יחד עם מזהה הפרויקט, מספר הפרויקט, והאזור והתחום של הפריסה.

מידע נוסף על תמיכה ברשתות מבוססות-VLAN זמין במאמר אמולציה של שכבה 2: שידור ARP ולמידת MAC בהתאמה אישית.

הגדרת מדיניות הארגון ו-VPC Service Controls

מכונות ESXi ללא מערכת הפעלה בפתרון VMware מופעלות מאימג'ים של ESXi ש-Google מספקת, שמתארחים בפרויקט smve-prod-public-images שמספרו 999037279871. כברירת מחדל, לא נדרשת הגדרה נוספת. צריך להחיל את ההגדרות הבאות רק אם הארגון אוכף מדיניות בנושא קובצי אימג' מהימנים או משתמש ב-VPC Service Controls:

• מדיניות בנושא קובצי אימג' מהימנים: אם הארגון שלכם לא אוכף את מדיניות הארגון constraints/compute.trustedImageProjects, אתם לא צריכים לעשות כלום. אם הארגון שלכם אוכף את המדיניות הזו, צריך לאפשר את projects/smve-prod-public-images כדי ש-Compute Engine יוכל ליצור דיסקים לאתחול של Bare Metal. מידע נוסף זמין במאמר הגדרת מגבלות גישה לתמונות.

• כלל תעבורת נתונים יוצאת (egress) של VPC Service Controls: אם פרויקט היעד לא נמצא בגבולות גזרה לשירות, לא צריך לעשות כלום. אם הפרויקט נמצא בגבולות גזרה לשירות, צריך להוסיף כלל תעבורת נתונים יוצאת שמאפשר פעולות של compute.googleapis.com לפרויקט smve-prod-public-images (projects/999037279871):

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

  למידע נוסף, קראו את ההסבר על כללי תעבורת נתונים יוצאת.

הגדרת הרשאות ותפקידים ב-IAM

הזהות שמריצה את Terraform (אדמין אנושי או חשבון שירות אוטומטי של CI/CD) צריכה את תפקידי ה-IAM הבאים בפרויקטGoogle Cloud היעד:

תפקיד	מזהה התפקיד	היקף השימוש
אדמין של Compute	roles/compute.admin	הקצאת מכונות Bare Metal, צירוף קובצי אימג' של דיסק אתחול בהתאמה אישית, הגדרת מדיניות מיקום וניהול ממשקי multi-NIC. ניהול רשתות VPC, רשתות משנה לשידור בשכבה 2, הקצאות של כתובות IP סטטיות, מאזני עומסים פנימיים אזוריים, שירותים לקצה העורפי, כללי העברה וקבוצות של נקודות קצה של רשתות אזוריות. ליצור ולנהל כללי אבטחה של חומת אש לתעבורת נתונים נכנסת (ingress) ב-VPC.
אדמין ב-DNS	roles/dns.admin	ניהול של תחומים פרטיים להעברה ותחומים פרטיים הפוכים ב-Cloud DNS, מדיניות העברה של שאילתות נכנסות וקבוצות של רשומות משאבים מסוג A ו-PTR.
משתמש בחשבון שירות	roles/iam.serviceAccountUser	כדי לאפשר הקצאת מכונות עם ההיקף cloud-platform, צריך להקצות את התפקיד הזה לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine‏ (PROJECT_NUMBER-compute@).

הקצאת תפקידים באמצעות ה-CLI של gcloud

כדי להקצות את התפקידים הנדרשים ברמת הפרויקט ואת ההרשאות לחשבון השירות, מריצים את הפקודות הבאות:

# 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 .
• ‫PROJECT_NUMBER: מספר הפרויקט של פרויקט היעד ב- Google Cloud.
• ‫USER_EMAIL: כתובת האימייל של זהות המשתמש שלכם.

אימות של Terraform runner

בוחרים באחת משיטות האימות הבאות, בהתאם לסביבת העבודה:

• אימות באמצעות התחזות לחשבון שירות (מומלץ)
• ביצוע אימות באמצעות Application Default Credentials
• אימות באמצעות קובץ מפתח של חשבון שירות

אימות באמצעות התחזות לחשבון שירות

התחזות לחשבון שירות מבטלת את הצורך במפתחות של פרטי כניסה לטווח ארוך, על ידי יצירת טוקני גישה לטווח קצר מסוג OAuth 2.0. הזהות האישית שלכם מאומתת, ו-Terraform פועל כחשבון השירות הייעודי.Google Cloud בודק את הפעולות שבוצעו על ידי Terraform בחשבון השירות.

1. מקצים לזהות האישית שלכם ב- Google Cloud את התפקיד "יצירת אסימונים בחשבון שירות" (roles/iam.serviceAccountTokenCreator) בחשבון השירות של ה-runner:

   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 Cloud.
   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

2. מאמתים את הסביבה המקומית:

   gcloud auth application-default login
   

3. מגדירים את משתנה הסביבה GOOGLE_IMPERSONATE_SERVICE_ACCOUNT כדי לאכוף התחזות בכל ההפעלות של Terraform:

   export GOOGLE_IMPERSONATE_SERVICE_ACCOUNT='SA_EMAIL'
   

ביצוע אימות באמצעות Application Default Credentials

בסביבות פיתוח ובדיקה שבהן זהות המשתמש שלכם כוללת את ההרשאות הנדרשות באופן ישיר, השתמשו ב-Application Default Credentials‏ (ADC). Google Cloud מבצע ביקורת על פעולות שקשורות לזהות האישית שלכם:

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

מחליפים את PROJECT_ID במזהה של פרויקט היעד ב- Google Cloud .

אימות באמצעות קובץ מפתח של חשבון שירות

השתמשו בקובץ מפתח של חשבון שירות בצינורות עיבוד נתונים אוטומטיים של CI/CD (כמו Cloud Build, ‏ GitHub Actions או Jenkins) שבהם אין תמיכה בהתחברות אינטראקטיבית של משתמשים, והאימות מסתמך על מפתחות של פרטי כניסה לחשבון שירות לטווח ארוך. מגדירים את משתנה הסביבה GOOGLE_APPLICATION_CREDENTIALS לנתיב של קובץ המפתח של חשבון השירות:

export GOOGLE_APPLICATION_CREDENTIALS='KEY_FILE'

מחליפים את KEY_FILE בנתיב למפתח ה-JSON של חשבון השירות.

בדיקת הארכיטקטורה המודולרית

‫Terraform מתאמת את הקצאת המשאבים בארבעה שלבים מודולריים. העיצוב המודולרי הזה אוכף סדר תלויות קפדני כדי לוודא שהדרישות המוקדמות של הרשת קיימות לפני שפורסים מארחי מחשוב, מאזני עומסים ורשומות 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   |
+-----------------------------------------------------------------------------------+

הקצאת משאבים לאשכול הניהול

זהירות: לכל אשכול נפרד (אשכול הניהול של דומיין הניהול או אשכול נתונים של דומיין עומס עבודה נפרד) צריכה להיות ספרייה ייעודית משלו או קצה עורפי מבודד של מצב Terraform.

אשכול הניהול של דומיין הניהול מארח מכשירי ליבה של מישור הבקרה של VCF (‏SDDC Manager,‏ vCenter Server, אשכול NSX Management ו-VMware Aria Suite) ו-hypervisors של 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 חושפת פלט מובנה בארבע קטגוריות:

• ‫gcp_resources_self_links: כתובות URL מלאות של קישורים עצמיים למשאבים של Google Cloud לרשתות VPC, רשתות משנה, מכונות, מדיניות מיקום, קבוצות של נקודות קצה ברשת (NEG), שירותים לקצה העורפי, כללי העברה, חומות אש ואזורי Cloud DNS.
• neg_attachment_commands:
  • כשהמשתנה deployment_mode מוגדר לערך "cluster_creation": מוחזרת הודעת סטטוס שמציינת ש-Terraform מצרף באופן אוטומטי קבוצות NEG במהלך יצירת האשכול.
  • כשהמשתנה deployment_mode מוגדר לערך "node_addition": מספק את הפקודות של gcloud compute network-endpoint-groups update שנדרשות כדי לצרף מכונות מארחות של ESXi שהוקצו לאחרונה גם ל-NEG של הניהול וגם ל-NEG של NSX.
  • כשהמשתנה deployment_mode מוגדר לערך "appliance_addition": מוחזרת הודעת סטטוס שמציינת שקבוצות ה-NEG נשארות מחוברות לצומתי האשכול הקיימים, ו-Terraform לא משנה אותן במהלך הוספת המכשיר.
• ‫python_scripts_input_config: מטען ייעודי (payload) של הגדרת פרמטרים מובנים לסקריפטים של אוטומציה לפריסת תוכנת ההתקנה של VCF במורד הזרם בספרייה python של ערכת הכלים. כדי להמיר את הפלט הזה לפורמט JSON שנדרש לסקריפטים של Python בערכת הכלים, מריצים את סקריפט העזר שמתואר בקטע הבא.
• ‫management_domain_deployment_input_config: קלט מובנה לפריסת דומיין ניהול, כשרוב השדות מאוכלסים מראש מהקצאה מקצה לקצה. אפשר לערוך את הקלט הזה במקומות שבהם צריך או שבהם יש אינדיקציה לכך, ולהמיר אותו לקובץ JSON לפריסה של דומיין ניהול באמצעות סקריפט הייצוא שמתואר בקטע הבא.

ייצוא הגדרות פריסה

ערכת הכלים כוללת סקריפט עזר (scripts/export_deployment_config.py) שמחלץ בלוקים של הגדרות מהפלט של Terraform ומייצא אותם לקובצי JSON בפורמט שתואם לסכימה, בשביל תהליכי עבודה במורד הזרם:

• management_domain_deployment_input_config: קובץ JSON של קלט לפריסת דומיין הניהול של VCF.
• ‫python_scripts_input_config: קלט JSON‏ (config.json) לסקריפטים של Python לאוטומציה (vcf_deployer) של ערכת הכלים.

הרצת סקריפט העזר

מריצים את סקריפט העזר מהספרייה e2e-terraform (או מציינים את הדגלים -d או -i) על ידי בחירה באחת מהאפשרויות הבאות:

• מייצאים את שתי ההגדרות בו-זמנית:

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

  הפקודה הזו יוצרת את הקבצים הבאים:

  • management_domain_deployment_input.json
  • python_scripts_input_config.json

• מייצאים רק את קובץ ה-JSON של קלט הפריסה של דומיין הניהול של VCF:

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

• מייצאים רק את קובץ ה-JSON של הקלט של ערכת הכלים של Python:

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

• ייצוא מפלט שמור של Terraform או מקלט סטנדרטי (stdin) בצינור עיבוד נתונים (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 .
  

המאמרים הבאים

זהירות: מטעמי אבטחה, לפני השימוש צריך לאפס את הסיסמה הראשונית של ESXi root בכל מכונה חדשה שהוקצתה ללא מערכת הפעלה. הפעלת ערכת הכלים להכנת הצומת מאפסת באופן אוטומטי את סיסמת ESXi root בכל מארח לסוד esxi-root-password שמאוחסן ב-Secret Manager. אם לא מריצים את ערכת הכלים להכנת הצומת, צריך לאפס ידנית את הסיסמה של root בכל מכונה של ESXi ללא מערכת הפעלה.

1. מריצים את ערכת הכלים להכנת הצמתים כדי לאפס את הסיסמה הראשונית של ESXi root בכל מארח, מכינים את הצמתים לפריסת VCF ופורסים את מכשיר ההתקנה של VCF באמצעות הפלט של python_scripts_input_config מההגדרה מקצה לקצה של Terraform (שהומרה ל-JSON באמצעות סקריפט העזר). הוראות מפורטות במאמר הכנת צמתים ופריסת VCF באמצעות ערכת הכלים.
2. מגדירים את החיבור למאגר האזורי אופליין במתקין ה-VCF כדי להוריד את חבילות התוכנה הנדרשות:
   • פרוטוקול: HTTPS
   • ‫FQDN (אל תשתמשו בכתובת IP): offline-depot.REGION.selfmanagedvmwareengine.goog (החליפו את REGION באזור Google Cloudשבו נמצאים הצמתים של Bare Metal)
   • יציאה: 443
   • שם משתמש: vcf-depot-user
   • סיסמה: Google1!
3. פורסים את דומיין הניהול על ידי הזנת קובץ ה-JSON של management_domain_deployment_input_config (שיוצא באמצעות סקריפט העזר) למתקין ה-VCF. חשוב להחליף את כל השדות שמסומנים ב-user_should_input בהגדרות הקלט בערכי היעד. הוראות להשלמת תהליך העבודה של הפעלת VCF מופיעות במאמר פריסת צי חדש של VCF או מכונה חדשה של VCF במסמכי התיעוד של Broadcom.
4. הרחבת הקיבולת של האשכול על ידי הוספת צמתים ב-ניהול הקיבולת של הצמתים באמצעות Terraform.
5. הקצאת מאזני עומסים ורשומות DNS למכשירי VCF נוספים בהוספת מכשירי VCF באמצעות Terraform.