ข้ามไปยังเนื้อหา

การติดตั้งใช้งานเดโม

  • Terraform ที่เวอร์ชันขั้นต่ำใน terraform/versions.tf>= 1.8 เพื่อรองรับ ฟังก์ชันที่กำหนดโดยผู้ให้บริการ (provider-defined functions) และบล็อก check ที่ป้องกัน VIP
  • ผู้ให้บริการ xcsh ไม่มีการตรึงเวอร์ชันใด ๆ: .terraform.lock.hcl ถูก gitignore ไว้ และ ข้อจำกัดเป็นเพียงค่าขั้นต่ำแบบปลายเปิด ดังนั้นทุกครั้งที่ init จะแก้ไขไปเป็นรีลีสล่าสุดที่เผยแพร่แล้ว นั่นเป็นความตั้งใจสำหรับโครงการที่ยังอยู่ในช่วงก่อนเผยแพร่ — เดโมควรล้มเหลวเมื่อผู้ให้บริการถดถอย แทนที่จะค้างอยู่บนเวอร์ชันเก่าที่ปิดบังปัญหานั้นไว้
  • ข้อมูลรับรอง API ของ F5 XC สำหรับ tenant ใน var.expected_xc_tenant ที่ export เป็น XCSH_API_TOKEN (หรือคู่ P12/PEM) โดย export เฉพาะข้อมูลรับรองเท่านั้น ไม่ต้อง export URL — ดู ด้านล่าง
  • ข้อมูลรับรอง Azure ที่มีสิทธิ์สร้าง resource group, VNet, Route Server และ VM
  • F5 XC namespace ที่มีอยู่ก่อนแล้ว สำหรับชั้นแอป การติดตั้งใช้งานจะ อ่าน namespace นั้นและไม่เคย สร้างหรือทำลายมัน ดังนั้น namespace ที่บรรจุเดโมอื่นที่ไม่เกี่ยวข้องจะไม่มีทางไปอยู่ในรายการ destroy ของสแตกนี้

ตัวแปรอื่น ๆ ทุกตัวมีค่าเริ่มต้นที่ใช้งานได้ และชื่อออบเจ็กต์ทุกชื่อมาจาก var.component มีสองตัวที่ตั้งใจปล่อยไว้โดยไม่มีค่าเริ่มต้น:

Terminal window
cd terraform
cp terraform.tfvars.example terraform.tfvars
ตัวแปรเหตุใดจึงไม่มีค่าเริ่มต้น
origin_ipค่าเริ่มต้นใด ๆ ก็คือเครื่องเฉพาะเครื่องหนึ่ง ค่าที่เก่าล้าสมัยจะส่งทราฟฟิกของการติดตั้งใช้งานใหม่ไปยังโฮสต์ของคนอื่นแทนที่จะล้มเหลว
lb_domainตัวกระจายโหลดจับคู่ตาม Host ดังนั้นนี่คือสิ่งที่ทุกคำขอต้องส่งมา และเป็นของผู้ที่ดำเนินการติดตั้งใช้งาน

ทั้งสองตัวมีการตรวจสอบรูปแบบ ดังนั้นการพิมพ์ผิดจะทำให้ plan ล้มเหลวแทนที่จะเป็นตัวเดโม

terraform.tfvars ถูก gitignore ไว้ และต้องคงอยู่เช่นนั้น: เพราะมันมี subscription id และ ค่าเฉพาะของวิศวกรแต่ละคน

Tenant คือการตั้งค่า ไม่ใช่สิ่งใดก็ตามที่ shell ของคุณ export อยู่

หัวข้อที่มีชื่อว่า “Tenant คือการตั้งค่า ไม่ใช่สิ่งใดก็ตามที่ shell ของคุณ export อยู่”

var.expected_xc_tenant ระบุชื่อ tenant และเป็นที่เดียวที่ระบุชื่อนั้น providers.tf ดึงค่า api_url ของผู้ให้บริการ xcsh มาจากตัวแปรนี้ ซึ่งตั้งใจให้ เขียนทับ XCSH_API_URL ใด ๆ ในสภาพแวดล้อม และ postcondition ใน terraform/main.tf จะทำให้ plan ล้มเหลวเมื่อสภาพแวดล้อมระบุ tenant ที่ต่างออกไป

อ่านค่าทั้งสองส่วนได้โดยไม่ต้องรันสิ่งใดที่เปลี่ยนสถานะ:

Terminal window
terraform output -raw xc_tenant # what the deployment targets
terraform output -raw xc_env_tenant # what your shell claims — diagnostic only
f5-sales-demo
f5-sales-demo
  1. เริ่มต้นใช้งาน การตั้งค่าแบ็กเอนด์ไม่ได้ถูก commit ไว้ ให้ใช้ของคุณเอง

    Terminal window
    terraform init -backend-config=backend.hcl
  2. Apply ครั้งแรก ขั้นนี้จะสร้าง Azure, ไซต์ CE และโทเคนลงทะเบียน และบูต CE ขึ้นมา

    Terminal window
    terraform apply
  3. Apply อีกครั้งหลังจาก CE ลงทะเบียนแล้ว ขั้นนี้ไม่ใช่ทางเลือก และเหตุผลอยู่ ด้านล่างนี้ ไม่ใช่สิ่งที่คุณต้องไปค้นพบเอง

    Terminal window
    terraform apply

จากนั้นไปที่ พิสูจน์ว่าระบบมีสุขภาพดี ก่อนแสดงให้ใครดู

การอนุมัติการลงทะเบียนเป็นแบบอัตโนมัติ และการ apply ยังเป็นสองเฟส

หัวข้อที่มีชื่อว่า “การอนุมัติการลงทะเบียนเป็นแบบอัตโนมัติ และการ apply ยังเป็นสองเฟส”

การอนุมัติการลงทะเบียนไม่จำเป็นต้องมีคนในคอนโซลอีกต่อไป: ทรัพยากร xcsh_registration_approval จะดำเนินการนี้ และโมดูลไซต์จะแก้ไขว่าจะอนุมัติ การลงทะเบียนใด

สิ่งนั้นยังไม่ทำให้การติดตั้งใช้งานเป็น apply ครั้งเดียวแบบไม่ต้องแตะต้อง และเหตุผลนั้นควร ทำความเข้าใจก่อนที่คุณจะเฝ้าดูการรันครั้งแรกแล้วสรุปว่ามันล้มเหลว:

  • ออบเจ็กต์การลงทะเบียนของ CE มีชื่อว่า r-<uuid> ไม่เคยตั้งชื่อตามไซต์ ดังนั้น ไม่มีสิ่งใดที่จะทำนายชื่อได้ในเวลา plan
  • การลงทะเบียนจะเกิดขึ้นหลังจาก VM บูตขึ้นและ vpm ลงทะเบียนแล้วเท่านั้น
  • ดังนั้น apply ครั้งแรกจะไม่วางแผนการอนุมัติใด ๆ เลย ให้ apply อีกครั้งหลังจาก CE ลงทะเบียนแล้ว แล้วการอนุมัติจะถูกสร้างขึ้น

terraform/main.tf บันทึกลำดับนี้ไว้ที่ส่วนบนของไฟล์ ซึ่งเป็นเวอร์ชัน ที่ถือเป็นแหล่งอ้างอิง — ลำดับการติดตั้งใช้งานอยู่กับโค้ดที่ทำให้มันเกิดขึ้น

SSH ของผู้ปฏิบัติงานเป็นการตัดสินใจในเวลาสร้าง

หัวข้อที่มีชื่อว่า “SSH ของผู้ปฏิบัติงานเป็นการตัดสินใจในเวลาสร้าง”

การติดตั้งใช้งานจะเขียนคีย์ของผู้ปฏิบัติงานไปยังบัญชี admin ของแอปพลายแอนซ์ ซึ่งมี login shell เป็น Site CLI คีย์นี้ถูกเขียนโดย write_files ของ cloud-init ซึ่งรันเพียงครั้งเดียวเมื่อบูตครั้งแรก

Terminal window
terraform destroy

Namespace ของแอปจะยังคงอยู่: มันถูกอ่าน ไม่เคยถูกจัดการ ดังนั้น destroy จึงไม่สามารถพา namespace ที่บรรจุเดโมอื่นที่ไม่เกี่ยวข้องไปด้วยได้ ทุกอย่างที่เหลือใน resource group จะถูกลบไป