इसे छोड़कर कंटेंट पर जाएं
मल्टी-क्लाउड नेटवर्किंग

सॉफ़्टवेयर संस्करण और पुनर्निर्माण

दो Terraform चर एक Customer Edge का सॉफ़्टवेयर सेट करते हैं: ऑपरेटिंग सिस्टम के लिए ce_os_version और F5 Distributed Cloud बिल्ड के लिए ce_sw_version। दोनों इस तरह से व्यवहार करते हैं जो स्पष्ट पठन के विपरीत है — एक खाली फ़ील्ड आपको कुछ नहीं बल्कि सबसे नया बिल्ड देती है, और एक संस्करण जो एक नोड पर इंस्टॉल होता है, वह उसी के समान लेकिन छोटी डिस्क वाले नोड पर विफल हो सकता है।

संस्करण फ़ील्ड क्या करते हैं, दो चरणों में

Section titled “संस्करण फ़ील्ड क्या करते हैं, दो चरणों में”

चरणों को अलग करना ही पूरा विषय है। मिलाने पर, व्यवहार स्व-विरोधाभासी लगता है।

पहले बूट पर, एक नोड वह इंस्टॉल करता है जो ce_sw_version नाम देता है। terraform/modules/ce-node मार्केटप्लेस इमेज को version = "latest" के साथ डिप्लॉय करता है, इसलिए एक नोड जो बिल्ड लेकर आता है वह वही है जो उस इमेज में वर्तमान में शिप होती है — और वह समय के साथ बदलती है। ce_sw_version गंतव्य चुनता है, न कि यह कि कुछ होता है या नहीं, और इसे खाली छोड़ने का अर्थ है कि सर्वर चुनता है, न कि नोड वहीं रहता है। यही बात ce_os_version के लिए भी लागू होती है।

यह न मानें कि उस परिवर्तन की दिशा ऊपर की ओर है। Observed 2026-07-28, इमेज ने एक बिल्ड शिप किया जिस पर 20260703-e2c462a की मुहर लगी थी — इस फ्लीट के crt-20250613-3382 से नया और उस crt-20260201-0179 से भी नया जो टेनेंट विज्ञापित कर रहा था। इमेज जो ले जाती है उससे पुराना बिल्ड नाम देना नोड को पीछे की ओर ले जाने के लिए कहता है, और यह सामान्य है: यह फ्लीट इसी तरह बनाया गया था और चल रहा है।

संस्करण फ़ील्ड को खाली छोड़ना तटस्थ नहीं बल्कि सबसे जोखिम भरा विकल्प है। निर्माण के समय सर्वर खाली फ़ील्ड को अकेला नहीं छोड़ता — वह उसे सबसे नए विज्ञापित संस्करण से भर देता है और उसे इंस्टॉल करता है। दोनों फ़ील्ड को अनसेट करके बनाई गई एक साइट crt-20260201-0179 और OS 9.2026.14 पर पिन होकर वापस आई, वे दो संस्करण जो टेनेंट विज्ञापित कर रहा था, और फिर इंस्टॉल विफल हो गया। Observed 2026-07-29।

इसके दो परिणाम हैं। खाली का अर्थ है “मुझे सबसे नया दो”, इसलिए एक अनपिन्ड डिप्लॉयमेंट वह है जिसके नीचे वर्णित डिस्क सीमा से मिलने की सबसे अधिक संभावना है। और आप एक फ़ील्ड को दूसरे को खाली छोड़कर अलग नहीं कर सकते, क्योंकि सर्वर उसे भर देता है — दोनों को जानबूझकर सेट करें, या प्रत्येक का सबसे नया स्वीकार करें।

पहले बूट के बाद, कुछ भी अपने आप अपग्रेड नहीं होता। F5 Distributed Cloud एक नया बिल्ड विज्ञापित करता है और प्रतीक्षा करता है। यहीं पर “नोड वहीं रहता है जहाँ वह उतरा” लागू होता है — निर्माण के दौरान नहीं बल्कि उसके बाद।

दोनों चरण साइट ऑब्जेक्ट पर दिखाई देते हैं। Observed 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 बदल सकता है

Section titled “Terraform संस्करण नहीं बदल सकता। API बदल सकता है”

ये दो अलग-अलग तथ्य हैं, और इन्हें मिलाने से गलत योजना बनती है।

Terraform नहीं बदल सकता। ce_os_version और ce_sw_version प्रभावी रूप से केवल निर्माण-समय के हैं। किसी को भी बदलें और apply करें, और API अपडेट को [BAD_REQUEST] Invalid request parameters के साथ अस्वीकार कर देता है। Observed 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"

Observed 2026-07-29: सॉफ़्टवेयर कॉल ने 200 लौटाया, साइट UPGRADING में चली गई जिसमें deployment_state.phase UPGRADE_IN_PROGRESS था, और साइट ऑब्जेक्ट का अनुरोधित संस्करण पोस्ट किए गए संस्करण में बदल गया। फ़ील्ड को छोड़ने पर version empty in the request के साथ 400 लौटाता है, जिससे फ़ील्ड नाम की पुष्टि हुई।

घंटों का बजट रखें, मिनटों का नहीं, और विफलता पर घबराएँ नहीं। एक डिफ़ॉल्ट-डिस्क नोड पर crt-20260201-0179 तक अपग्रेड लगभग एक घंटे तक चला, बीच में UPGRADE_FAILED रिपोर्ट किया जिसमें result Failed था, और फिर नए बिल्ड पर सफलतापूर्वक पूर्ण हुआ। प्लेटफ़ॉर्म पुनः प्रयास करता है।

इसका उन लोगों के लिए सीधा परिणाम है जो अपग्रेड देख रहे हैं, या स्क्रिप्ट कर रहे हैं: एक Failed परिणाम एक ऐसी स्थिति है जिसका इंतजार करना है, कोई फैसला नहीं। पहले को अंतिम मानने से एक ऐसे अपग्रेड के लिए विफलता रिपोर्ट होती है जो सफल होने वाला है।

उस पथ में समूह पर ध्यान दें: ये config के अंतर्गत रहते हैं, operate के नहीं। operate के अंतर्गत समान पथ 404 API Group could not be determined लौटाते हैं, जो एक रूटिंग संदेश है और यह बयान नहीं कि कोई अपग्रेड मौजूद नहीं है — एक अंतर जिसने इस प्रोजेक्ट को एक गलत निष्कर्ष पर पहुँचाया।

यदि आप अपग्रेड के बजाय पुनर्निर्माण करते हैं, तो CE को बदलने के सभी परिणाम लागू होते हैं।

एक पिन किया हुआ बिल्ड इंस्टॉल होने में विफल हो सकता है, और साइट तब अटकी रहती है

Section titled “एक पिन किया हुआ बिल्ड इंस्टॉल होने में विफल हो सकता है, और साइट तब अटकी रहती है”

पिन को स्वीकार करना उसे इंस्टॉल करने के समान नहीं है। crt-20260201-0179 पर पिन किए गए एक नव-निर्मित सिंगल-नोड Azure Secure Mesh v2 Customer Edge पर, साइट ऑब्जेक्ट ने तुरंत पिन किया हुआ संस्करण रिपोर्ट किया — और फिर इंस्टॉल विफल हो गया:

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

Observed 2026-07-28, और 2026-07-29 को दो बार पुनः उत्पन्न किया गया। ऑपरेटिंग सिस्टम पिन उसी रन में सामान्य रूप से इंस्टॉल हुआ (9.2024.6 से 9.2026.14, UPGRADE_COMPLETED); केवल सॉफ़्टवेयर इंस्टॉल विफल हुआ। साइट कभी ONLINE तक नहीं पहुँची और last_installed_version खाली रही, इसलिए कुछ भी किसी काम करने वाले बिल्ड पर वापस रोलबैक नहीं हुआ — वापस रोल करने के लिए कोई पहले की सफल इंस्टॉल नहीं थी।

निर्माण के समय विफलता अपग्रेड के दौरान विफलता जैसी नहीं है। दोनों अलग तरह से व्यवहार करते हैं और यह अंतर तब मायने रखता है जब आप तय कर रहे हों कि हस्तक्षेप करना है या नहीं:

निर्माण के समयAPI अपग्रेड के दौरान
क्या यह सफलता तक पुनः प्रयास करता है?नहीं — 20 मिनट से अधिक समय तक दो बार Failed रहाहाँ — ठीक हुआ और पूर्ण हुआ
नोड कहाँ समाप्त होता है?PROVISIONING, कुछ भी इंस्टॉल नहींएक काम करने वाले बिल्ड पर ONLINE
क्या इसे छोड़ना सुरक्षित है?नहीं, यह अटका हुआ हैहाँ, यह ठीक हो जाता है या पुराना बिल्ड रखता है

इसलिए निर्माण-समय की विफलता के लिए बड़ी डिस्क के साथ पुनर्निर्माण की आवश्यकता है, जबकि Failed रिपोर्ट करने वाले अपग्रेड को कुछ निष्कर्ष निकालने से पहले कुछ समय के लिए अकेला छोड़ देना चाहिए।

कारण डिस्क है, संस्करण नहीं। सॉफ़्टवेयर × OS × डिस्क आकार का एक मैट्रिक्स, प्रति संयोजन एक डिस्पोज़ेबल सिंगल-नोड Azure Secure Mesh v2 साइट और सभी एक ही मार्केटप्लेस इमेज से, इसे अलग करता है। Observed 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 विफल स्थिति में नोड पर 3.5 G खाली के साथ 29 G है)। 33 GB साफ़ इंस्टॉल होता है। इसलिए डिफ़ॉल्ट लगभग दो गीगाबाइट कम है, बहुत बड़े मार्जिन से नहीं।

इसे फ्लीट पर लागू करने से पहले किसी डिस्पोज़ेबल साइट पर संस्करण परिवर्तन का परीक्षण करें: एक फ्लीट जो इस तरह विफल होता है, PROVISIONING में अटका रहता है और पुनर्निर्माण ही एकमात्र निकास है।

दस्तावेज़ीकरण किस बिल्ड का वर्णन करता है

Section titled “दस्तावेज़ीकरण किस बिल्ड का वर्णन करता है”

इस साइट पर कमांड संदर्भ crt-20250613-3382 का वर्णन करता है, वह बिल्ड जो यह फ्लीट चलाता है। जो कमांड केवल नए बिल्ड पर मौजूद हैं, वे sitecli/command-classification.json में not_on_this_build के अंतर्गत दर्ज हैं और अलग से प्रलेखित हैं, नए बिल्ड पर कमांड के रूप में, ताकि वहाँ कुछ भी यहाँ चलाने योग्य न पढ़े। देखें ऑन-बॉक्स कमांड भी।