ข้ามไปยังเนื้อหา
เครือข่ายมัลติคลาวด์

เวอร์ชันซอฟต์แวร์และการสร้างใหม่

ตัวแปร Terraform สองตัวกำหนดซอฟต์แวร์ของ Customer Edge: ce_os_version สำหรับระบบปฏิบัติการ และ ce_sw_version สำหรับบิลด์ F5 Distributed Cloud ทั้งสองมีพฤติกรรมที่ตรงข้ามกับการอ่านที่เห็นได้ชัด — ฟิลด์ที่ว่างเปล่าจะให้บิลด์ล่าสุดแทนที่จะไม่มีอะไร และเวอร์ชันที่ติดตั้งได้บนโหนดหนึ่งอาจล้มเหลวบนโหนดที่เหมือนกันแต่มีดิสก์ขนาดเล็กกว่า

สิ่งที่ฟิลด์เวอร์ชันทำ ในสองระยะ

หัวข้อที่มีชื่อว่า “สิ่งที่ฟิลด์เวอร์ชันทำ ในสองระยะ”

การแยกระยะออกจากกันคือประเด็นหลักทั้งหมด หากนำมารวมกัน พฤติกรรมจะดูขัดแย้งในตัวเอง

ในการบูตครั้งแรก โหนดจะติดตั้งสิ่งที่ ce_sw_version ระบุไว้ terraform/modules/ce-node ทำการดีพลอยอิมเมจจากตลาดกลางด้วย version = "latest" ดังนั้นบิลด์ที่โหนดมาพร้อมด้วยคืออิมเมจที่จัดส่งในขณะนั้น — และสิ่งนี้เปลี่ยนแปลงไปตามเวลา ce_sw_version เลือก ปลายทาง ไม่ใช่ว่าจะมีอะไรเกิดขึ้นหรือไม่ และการปล่อยว่างไว้หมายความว่าเซิร์ฟเวอร์เป็นผู้เลือกแทนที่โหนดจะอยู่นิ่ง เช่นเดียวกันกับ ce_os_version

อย่าสันนิษฐานว่าทิศทางของการเปลี่ยนแปลงนั้นเป็นขึ้น สังเกตเมื่อ 2026-07-28 อิมเมจจัดส่งบิลด์ที่ประทับตรา 20260703-e2c462a — ใหม่กว่า crt-20250613-3382 ของฟลีตนี้ และใหม่กว่า crt-20260201-0179 ที่ผู้เช่าโฆษณาไว้ การระบุบิลด์ที่เก่ากว่าที่อิมเมจมีอยู่จะขอให้โหนดย้อนกลับ และนั่นเป็นเรื่องปกติ: ฟลีตนี้ถูกสร้างด้วยวิธีนั้นและกำลังทำงานอยู่

การปล่อยฟิลด์เวอร์ชันว่างไว้คือตัวเลือกที่เสี่ยงที่สุด ไม่ใช่ตัวเลือกที่เป็นกลาง ในขณะสร้าง เซิร์ฟเวอร์จะไม่ปล่อยฟิลด์ที่ว่างไว้ตามเดิม — มันจะเติมด้วยเวอร์ชัน ที่โฆษณาล่าสุด และติดตั้งนั้น ไซต์ที่สร้างขึ้นโดยไม่กำหนดทั้งสองฟิลด์จะกลับมาพร้อมกับการปักหมุดที่ crt-20260201-0179 และ OS 9.2026.14 ซึ่งเป็นสองเวอร์ชันที่ผู้เช่าโฆษณาไว้ และการติดตั้งก็ล้มเหลว สังเกตเมื่อ 2026-07-29

มีผลสองประการ การปล่อยว่างหมายถึง “ให้เวอร์ชันล่าสุด” ดังนั้นการดีพลอยที่ไม่ได้ปักหมุดจึงมีโอกาสมากที่สุดที่จะพบขีดจำกัดดิสก์ที่อธิบายด้านล่าง และคุณไม่สามารถแยกฟิลด์หนึ่งออกโดยปล่อยอีกฟิลด์ว่างไว้ได้ เพราะเซิร์ฟเวอร์จะเติมให้ — กำหนดทั้งสองฟิลด์อย่างตั้งใจ หรือยอมรับเวอร์ชันล่าสุดของแต่ละฟิลด์

หลังการบูตครั้งแรก ไม่มีอะไรอัปเกรดโดยอัตโนมัติ F5 Distributed Cloud โฆษณาบิลด์ที่ใหม่กว่าและรอ นั่นคือจุดที่ “โหนดอยู่ตรงที่มันลงจอด” — หลังการสร้าง ไม่ใช่ระหว่างการสร้าง

ทั้งสองระยะนั้นมองเห็นได้บนออบเจกต์ไซต์ สังเกตเมื่อ 2026-07-28 ฟลีตนี้:

volterra_software_status.available_version   crt-20260201-0179
operating_system_status.available_version    9.2026.14

ในขณะที่โหนดรัน crt-20250613-3382 และ OS 9.2024.6 บิลด์ที่ใหม่กว่ามีให้และยังไม่ได้นำมาใช้ — นี่คือสถานะคงที่ ไม่ใช่การอัปเกรดที่หยุดนิ่ง

Terraform ไม่สามารถเปลี่ยนเวอร์ชันได้ API ทำได้

หัวข้อที่มีชื่อว่า “Terraform ไม่สามารถเปลี่ยนเวอร์ชันได้ API ทำได้”

นี่คือสองข้อเท็จจริงที่แยกจากกัน และการนำมารวมกันจะให้แผนที่ผิด

Terraform ทำไม่ได้ ce_os_version และ ce_sw_version ใช้งานได้เฉพาะในช่วงเวลาสร้างเท่านั้น เปลี่ยนฟิลด์ใดฟิลด์หนึ่งและ apply แล้ว API จะปฏิเสธการอัปเดตด้วย [BAD_REQUEST] Invalid request parameters สังเกตเมื่อ 2026-07-29 บนไซต์แบบทิ้งได้ในสามทิศทาง — การปักหมุด ไปข้างหน้า สู่บิลด์ที่ใหม่กว่า การปักหมุด ไปข้างหลัง สู่บิลด์ที่เก่ากว่า และ ยกเลิกการปักหมุด โดยล้างทั้งสองฟิลด์ การไปข้างหน้าไม่ใช่กรณีพิเศษ

API ทำได้ F5 Distributed Cloud เปิดเผยการกระทำอัปเกรดเฉพาะต่อไซต์ ซึ่งเริ่มต้นการเปลี่ยนแปลงในสถานที่ — ไม่ต้องสร้างใหม่ และไม่ต้องใช้ Terraform:

Terminal window
# software build
curl -X POST -H "Authorization: APIToken $TOKEN" -H 'Content-Type: application/json' \
  --data '{"version": "<software-version>"}' \
  "$API_URL/api/config/namespaces/system/sites/<site-name>/upgrade_sw"


# operating system
curl -X POST -H "Authorization: APIToken $TOKEN" -H 'Content-Type: application/json' \
  --data '{"version": "<os-version>"}' \
  "$API_URL/api/config/namespaces/system/sites/<site-name>/upgrade_os"

สังเกตเมื่อ 2026-07-29: การเรียก software คืนค่า 200 ไซต์ย้ายไปสู่ UPGRADING โดยมี deployment_state.phase เป็น UPGRADE_IN_PROGRESS และเวอร์ชันที่ร้องขอของออบเจกต์ไซต์เปลี่ยนเป็นเวอร์ชันที่ส่งไป การละเว้นฟิลด์จะคืนค่า 400 พร้อม version empty in the request ซึ่งเป็นวิธีที่ยืนยันชื่อฟิลด์

วางแผนเป็นชั่วโมง ไม่ใช่นาที และอย่าตื่นตระหนกกับความล้มเหลว บนโหนดที่มีดิสก์เริ่มต้น การอัปเกรดเป็น crt-20260201-0179 ใช้เวลาประมาณหนึ่งชั่วโมง รายงาน UPGRADE_FAILED พร้อม result Failed ในระหว่างทาง แล้วจึง เสร็จสิ้นสำเร็จ บนบิลด์ใหม่ แพลตฟอร์มลองใหม่อีกครั้ง

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

สังเกตกลุ่มในเส้นทางนั้น: สิ่งเหล่านี้อยู่ภายใต้ config ไม่ใช่ operate เส้นทางเดียวกันภายใต้ operate จะคืนค่า 404 API Group could not be determined ซึ่งเป็นข้อความเส้นทางและไม่ใช่คำบอกว่าไม่มีการอัปเกรด — ความแตกต่างนี้ทำให้โปรเจกต์นี้ได้ข้อสรุปที่ผิด

หากคุณสร้างใหม่แทนที่จะอัปเกรด ผลกระทบทุกประการของการแทนที่ CE จะมีผล

บิลด์ที่ปักหมุดอาจล้มเหลวในการติดตั้ง และไซต์จะติดขัด

หัวข้อที่มีชื่อว่า “บิลด์ที่ปักหมุดอาจล้มเหลวในการติดตั้ง และไซต์จะติดขัด”

การยอมรับหมุดไม่ได้หมายความว่าติดตั้งสำเร็จ บน Customer Edge Azure Secure Mesh v2 แบบโหนดเดียวที่สร้างใหม่และปักหมุดที่ crt-20260201-0179 ออบเจกต์ไซต์รายงานเวอร์ชันที่ปักหมุดทันที — และการติดตั้งก็ล้มเหลว:

site_state        PROVISIONING
phase             UPGRADE_FAILED
result            Failed
last_installed    (empty)
message           stage: 10, app: voucher obj: voucher objKind: DaemonSet failed ...
                  required replicas: 1, current replicas: 0

สังเกตเมื่อ 2026-07-28 และทำซ้ำสองครั้งในวันที่ 2026-07-29 หมุด ระบบปฏิบัติการ ติดตั้งตามปกติในการรันเดียวกัน (9.2024.6 เป็น 9.2026.14, UPGRADE_COMPLETED); เฉพาะการติดตั้งซอฟต์แวร์เท่านั้นที่ล้มเหลว ไซต์ไม่เคยถึง ONLINE และ last_installed_version ยังคงว่างเปล่า ดังนั้นจึงไม่มีการย้อนกลับสู่บิลด์ที่ทำงานได้ — ไม่มีการติดตั้งสำเร็จก่อนหน้านี้ให้ย้อนกลับ

ความล้มเหลวในขณะสร้างไม่เหมือนกับความล้มเหลวระหว่างการอัปเกรด ทั้งสองมีพฤติกรรมต่างกัน และความแตกต่างนั้นสำคัญเมื่อคุณตัดสินใจว่าจะเข้าแทรกแซงหรือไม่:

ในขณะสร้างระหว่างการอัปเกรด API
ลองใหม่จนสำเร็จหรือไม่?ไม่ — คงอยู่ที่ Failed นานกว่า 20 นาที สองครั้งใช่ — กู้คืนและเสร็จสิ้น
โหนดจบลงที่ไหน?PROVISIONING ไม่มีอะไรติดตั้งONLINE บนบิลด์ที่ทำงานได้
ปลอดภัยที่จะปล่อยทิ้งไว้หรือไม่?ไม่ มันติดขัดใช่ มันกู้คืนหรือคงบิลด์เก่าไว้

ดังนั้นความล้มเหลวในขณะสร้างต้องการการสร้างใหม่ด้วยดิสก์ขนาดใหญ่ขึ้น ในขณะที่การอัปเกรดที่รายงาน Failed ควรปล่อยทิ้งไว้สักพักก่อนที่คุณจะสรุปอะไร

สาเหตุคือดิสก์ ไม่ใช่เวอร์ชัน เมทริกซ์ของซอฟต์แวร์ × OS × ขนาดดิสก์ โดยมีไซต์ Azure Secure Mesh v2 แบบโหนดเดียวแบบทิ้งได้หนึ่งไซต์ต่อการรวมกัน และทั้งหมดจากอิมเมจตลาดกลางเดียวกัน ช่วยแยกแยะได้ สังเกตเมื่อ 2026-07-29:

ซอฟต์แวร์OS 9.2024.6 (สิ่งที่อิมเมจจัดส่ง)OS 9.2026.14
crt-20250613-3382ติดตั้งได้ติดตั้งได้
crt-20260201-0179ติดตั้งได้ล้มเหลว บนดิสก์เริ่มต้นเท่านั้น

ไม่มีเวอร์ชันใดล้มเหลวเพียงลำพัง มีเฉพาะคู่เท่านั้นที่ล้มเหลว และเฉพาะบนดิสก์เริ่มต้นของอิมเมจ — คู่เดียวกันติดตั้งได้บน 33 GB และทุกขนาดที่ใหญ่กว่าที่ทดสอบ ดังนั้นบิลด์ที่ใหม่กว่าไม่ได้ไม่รองรับที่นี่ และระบบปฏิบัติการที่ใหม่กว่าก็เช่นกัน แต่เมื่อใช้ร่วมกันพวกมันต้องการดิสก์มากกว่าที่โหนดเริ่มต้นมีอยู่เล็กน้อย

terraform/modules/ce-node ไม่กำหนด disk_size_gb ดังนั้น Customer Edge ทุกตัวจะได้รับค่าเริ่มต้นของอิมเมจ — ขนาดเดียวที่คู่นี้ล้มเหลว หากต้องการรันคู่นี้ ให้ขยายดิสก์

ขอบอยู่ที่ส่วนที่น่าประหลาดใจ และนั่นเป็นเหตุผลที่นี่ดูเหมือนปัญหาเวอร์ชันนานมาก ค่าเริ่มต้นคือ 31 GiB (คำสั่ง health รายงาน size_gb: 31 และ /var คือ 29 G โดยมีพื้นที่ว่าง 3.5 G บนโหนดในสถานะที่ล้มเหลว) 33 GB ติดตั้งได้สะอาด ดังนั้นค่าเริ่มต้นขาดอยู่ประมาณสองกิกะไบต์ ไม่ใช่ขาดมาก

ทดสอบการเปลี่ยนเวอร์ชันบนไซต์แบบทิ้งได้ก่อนที่จะนำไปใช้กับฟลีตไม่ว่าในกรณีใด: ฟลีตที่ล้มเหลวด้วยวิธีนี้จะติดขัดใน PROVISIONING โดยมีการสร้างใหม่เป็นทางออกเดียวเท่านั้น

บิลด์ใดที่เอกสารอธิบาย

หัวข้อที่มีชื่อว่า “บิลด์ใดที่เอกสารอธิบาย”

การอ้างอิงคำสั่งบนไซต์นี้อธิบาย crt-20250613-3382 ซึ่งเป็นบิลด์ที่ฟลีตนี้รัน คำสั่งที่มีเฉพาะบนบิลด์ที่ใหม่กว่าจะถูกบันทึกไว้ใน sitecli/command-classification.json ภายใต้ not_on_this_build และบันทึกแยกต่างหาก ดังเช่น คำสั่งบนบิลด์ที่ใหม่กว่า ดังนั้นไม่มีอะไรในนั้นที่อ่านว่าสามารถรันได้ที่นี่ ดูเพิ่มเติมที่ คำสั่งบนกล่อง