ไฟล์การกำหนดค่า
คำสั่งสี่คำสั่งเปิดตัวแก้ไขบนไฟล์ที่ F5 เป็นเจ้าของ คำสั่งเหล่านี้ไม่อยู่ใน debug API และสองคำสั่งระบุไว้ในคำอธิบายของตัวเองว่า: “please do not use this unless F5 XC support requested”
edit-app-env-file
หัวข้อที่มีชื่อว่า “edit-app-env-file”เปิด /etc/vpm/app_env.yaml ซึ่งเป็นสภาพแวดล้อมแอปพลิเคชันในเครื่องของโหนด
execcli edit-app-env-fileคำอธิบายของอุปกรณ์จบด้วย “please do not use this unless F5 XC support requested”
ให้รับคำนั้นอย่างแท้จริง: ไฟล์นี้ถูกอ่านโดย vpm ตอนเริ่มต้น และค่าที่มีรูปแบบไม่ถูกต้องจะส่งผลกระทบต่อ
คอนเทนเนอร์แพลตฟอร์มทุกตัวบนโหนด
edit-certified-hardware
หัวข้อที่มีชื่อว่า “edit-certified-hardware”เปิดการกำหนดค่าฮาร์ดแวร์ที่ได้รับการรับรอง
execcli edit-certified-hardwareถูกระบุว่าเป็นสำหรับฝ่ายสนับสนุนเท่านั้นโดยอุปกรณ์เช่นกัน นี่คือการกำหนดค่าที่ตัดสินว่า
vpm เชื่อหรือไม่ว่ากำลังทำงานบนฮาร์ดแวร์ที่ F5 รับรอง — และการทำผิดพลาดนั้นไม่ใช่เรื่องทางทฤษฎี หากไม่มี CertifiedHardwareEndpoint ที่ถูกต้อง vpmd จะออกพร้อมข้อความ “fail to match
certified hardware” และโหนดจะไม่ลงทะเบียนเลย นั่นคือเหตุผลที่ cloud-init ของ repository นี้
ตั้งค่า endpoint อย่างชัดเจนแทนที่จะพึ่งพาค่าเริ่มต้น ดู
terraform/cloud-init/ce-node.yaml
edit-azure-client-id-secret
หัวข้อที่มีชื่อว่า “edit-azure-client-id-secret”อัปเดต Azure client id และ secret ที่ CE นี้ใช้ สำหรับกรณีที่ข้อมูลรับรองหมดอายุ
execcli edit-azure-client-id-secretเมื่อนี่คือคำตอบ CE ที่เคยทำงานได้และเริ่มล้มเหลวในการดำเนินการ Azure โดยไม่มีการเปลี่ยนแปลงการกำหนดค่าใดๆ ที่จะอธิบายได้ คือกรณีที่คำสั่งนี้มีไว้เพื่อ — ข้อมูลรับรองหมดอายุลงแทนที่จะมีอะไรเสียหาย
edit-udev-10-nic-name
หัวข้อที่มีชื่อว่า “edit-udev-10-nic-name”เปิด /etc/udev/rules.d/10-nic-names.rules ซึ่งกำหนดวิธีการตั้งชื่อ NIC
execcli edit-udev-10-nic-nameอ่านหน้าอินเทอร์เฟซก่อนแตะสิ่งนี้ การตั้งชื่อ NIC บน CE นั้นน่าประหลาดใจอยู่แล้ว:
eth0 ถูกเปลี่ยนชื่อเป็น a-i-eth0 และไม่มีที่อยู่โฮสต์ ที่อยู่ SLO อยู่บน vhost0
และว่า eth1 หรือ eth2 ตัวใดถือที่อยู่ภายในนั้นไม่สอดคล้องกันทั้งสามโหนดในการใช้งานนี้ ดู ip กฎ udev ที่สมมติการจัดเรียงที่เป็นระเบียบกว่านี้จะทำให้สถานการณ์แย่ลง