إصدارات البرنامج وإعادة البناء

يضبط متغيران في 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.

لا تفترض أن اتجاه هذا التغيير صاعد. Observed 2026-07-28، شحنت الصورة إصداراً مُختوماً بـ 20260703-e2c462a — أحدث من crt-20250613-3382 لهذه المجموعة وأحدث من crt-20260201-0179 الذي كان المستأجر يُعلن عنه. تسمية إصدار أقدم مما تحمله الصورة يطلب من العقدة التراجع للخلف، وهذا أمر اعتيادي: أُنشئت هذه المجموعة بهذه الطريقة وهي تعمل.

ترك حقل الإصدار فارغاً هو الخيار الأكثر خطورة، لا الخيار المحايد. عند الإنشاء، لا يترك الخادم الحقل الفارغ كما هو — بل يملؤه بأحدث إصدار مُعلَن ويثبِّته. موقع أُنشئ بكلا الحقلين غير محددين عاد مثبَّتاً على crt-20260201-0179 ونظام التشغيل 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 ونظام التشغيل 9.2024.6. إصدار أحدث معروض ولم يُؤخذ — وهذه الحالة الثابتة، لا ترقية متوقفة.

لا يستطيع Terraform تغيير إصدار. الـ API يستطيع

هذان حقيقتان منفصلتان، والخلط بينهما ينتج خطة خاطئة.

Terraform لا يستطيع. ce_os_version وce_sw_version فعلياً يعملان فقط عند الإنشاء. غيِّر أياً منهما وطبِّق، فسيرفض الـ API التحديث بـ [BAD_REQUEST] Invalid request parameters. Observed 2026-07-29 على مواقع يمكن التخلص منها، في الاتجاهات الثلاثة — التثبيت للأمام على إصدار أحدث، والتثبيت للخلف على إصدار أقدم، وإلغاء التثبيت بمسح كلا الحقلين. الاتجاه الأمامي ليس حالة خاصة.

الـ API يستطيع. يكشف F5 Distributed Cloud عن إجراء ترقية مخصص لكل موقع، يبدأ التغيير في مكانه — دون إعادة بناء ودون تدخل Terraform:

# إصدار البرنامج
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"

# نظام التشغيل
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، وتغير الإصدار المطلوب في كائن الموقع إلى الإصدار الذي أُرسل. حذف الحقل يُعيد 400 مع version empty in the request، وهكذا تأكَّد اسم الحقل.

خصِّص ساعات لا دقائق، ولا تذعر من الفشل. على عقدة بقرص افتراضي، استغرقت الترقية إلى crt-20260201-0179 ما يقارب ساعة، وأبلغت عن UPGRADE_FAILED مع نتيجة Failed في منتصف الطريق، ثم اكتملت بنجاح على الإصدار الجديد. المنصة تُعيد المحاولة.

لهذا نتيجة مباشرة لمن يراقب ترقية أو يكتب نصاً برمجياً لها: نتيجة Failed هي حالة للانتظار من خلالها، لا حكماً نهائياً. معاملة أول فشل باعتباره نهائياً يُبلِّغ عن إخفاق في ترقية ستنجح.

لاحظ المجموعة في ذلك المسار: هذه المسارات تقع تحت config، لا operate. المسارات ذاتها تحت operate تُعيد 404 API Group could not be determined، وهذه رسالة توجيه لا تصريح بعدم وجود ترقية — فارق كلَّف هذا المشروع استنتاجاً خاطئاً.

الترقية عبر الـ API تُخرج Terraform عن المزامنة

المتغيرات المثبَّتة لا تزال تقول ما كانت تقوله دائماً، لذا يعمل الموقع الحي الآن على إصدار لا تُسمِّيه الإعدادات. لن يُوفِّقه Terraform — لا يستطيع، إذ يُرفض التحديث — لذا عاملِ ترقية الـ API باعتبارها خطوة متعمدة خارج سيطرة Terraform، وحدِّث القيم المثبَّتة لتطابقها عند إعادة البناء التالية.

ادعاءان سابقان في هذه الصفحة، تم سحبهما

قالت هذه الصفحة سابقاً إن نقل CE إلى إصدار مختلف يعني إعادة إنشاء الموقع، وأن تحديثاً مرفوضاً “يمسح الحقل على الخادم رغم ذلك” مما يجعل Terraform يقترح تغييراً فاشلاً إلى الأبد. لم يصمد أيٌّ منهما أمام الاختبار: ترقية الـ API أعلاه تبدأ تغيير الإصدار في مكانه دون إعادة إنشاء أي شيء، وبعد كل من التحديثات الثلاثة المرفوضة بقيت مواصفات الموقع دون تغيير وظل الموقع ONLINE. الاختلاف الموصوف في مشكلة الموفر xcsh#1387 لوحظ على موقع كان قد رُقِّي تلقائياً متجاوزاً قيمته المثبَّتة، لذا قد يحتاج تلك الحالة الابتدائية المتباينة؛ ولم يُعَد إنتاجه على موقع تطابقت مواصفاته مع قيمته المثبَّتة.

إذا أعدتَ البناء بدلاً من الترقية، تسري جميع تبعات استبدال CE.

جميع تبعات استبدال CE تسري

مفاتيح SSH جديدة للمضيف، وعناوين داخلية مُعاد تعيينها، وتسجيل جديد، وفقدان كل ما كان موجوداً فقط على العقدة. يعمل cloud-init مرة أخرى على الـ VM الجديدة، لذا يبقى وصول SSH المُهيَّأ بهذه الطريقة — لكنه يعمل فقط عند الإقلاع الأول، لذا يختفي أي شيء أُضيف إلى العقدة القديمة يدوياً.

اقرأ SSH حول تبعات مفتاح المضيف والعناوين قبل جدولة هذا.

إصدار مثبَّت قد يفشل في التثبيت، ويصبح الموقع عالقاً

قبول القيمة المثبَّتة لا يعني تثبيتها. على 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

Observed 2026-07-28، وأُعيد إنتاجه مرتين في 2026-07-29. ثبَّت القيد المثبَّت لـنظام التشغيل بصورة طبيعية في الجلسة ذاتها (من 9.2024.6 إلى 9.2026.14، UPGRADE_COMPLETED)؛ فشل تثبيت البرنامج فقط. لم يبلغ الموقع حالة ONLINE وظل last_installed_version فارغاً، لذا لم يُعَد شيء إلى إصدار عامل — لم يكن ثمة تثبيت سابق ناجح للتراجع إليه.

الفشل عند الإنشاء ليس كالفشل خلال الترقية. يتصرف كلاهما بشكل مختلف، والفارق مهم حين تقرر ما إذا كنت ستتدخل:

	عند الإنشاء	خلال ترقية الـ API
هل يُعيد المحاولة ليصل للنجاح؟	لا — ظل على Failed أكثر من 20 دقيقة، مرتين	نعم — تعافى واكتمل
أين تنتهي العقدة؟	PROVISIONING، لا شيء مثبَّت	ONLINE على إصدار عامل
هل من الآمن تركه؟	لا، إنه عالق	نعم، يتعافى أو يحتفظ بالإصدار القديم

لذا يحتاج الفشل عند الإنشاء إعادة بناء بقرص أكبر، في حين يجب ترك الترقية التي تُبلِّغ عن Failed لفترة قبل أن تستنتج أي شيء.

السبب هو القرص، لا الإصدار. مصفوفة من البرنامج × نظام التشغيل × حجم القرص، موقع Azure Secure Mesh v2 أحادي العقدة قابل للتخلص منه لكل تركيبة وجميعها من صورة السوق ذاتها، يُعزل السبب. Observed 2026-07-29:

البرنامج	نظام التشغيل 9.2024.6 (ما تشحنه الصورة)	نظام التشغيل 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 يثبَّت بنظافة. إذن الافتراضي ينقصه نحو غيغابايتين فحسب، لا بهامش واسع.

لا تضبط الحد الأدنى المقاس

33 GB هو أصغر حجم لوحظ أنه يعمل — لهذا الزوج من الإصدارات، على هذه الصورة، اليوم. إصدار بحجم أكبر قليلاً من البيانات سيفشل مرة أخرى عند 33 GB دون أي تغيير في الإعدادات ودون سبب واضح، تماماً كما يفعل الافتراضي الآن. اختَر هامشاً أعلى من الحد الأدنى: الأحجام المتحقق منها هنا هي 33 و36 و40 و48 و64 GB، وتكلفة الأكبر منها بضعة غيغابايتات من القرص المُدار.

اختبر تغيير الإصدار على موقع قابل للتخلص منه قبل تطبيقه على مجموعة بغض النظر: مجموعة تفشل بهذه الطريقة تظل عالقة في PROVISIONING مع إعادة الإنشاء كمخرج وحيد.

لا تحجم القرص استناداً إلى أرقام F5 السابقة للترقية

يطلب الفحص الموثَّق السابق للترقية من F5 مساحة حرة تساوي 20 GB مضافاً إليها 15% من السعة. هذا الفحص يحكم ترقيات واجهة وحدة التحكم وينص صراحةً على أنه لا ينطبق على الترقيات المُبادَرة عبر الـ API، لذا لا يصف هذا الفشل. بتطبيقه هنا يتنبأ بأن قرص 48 GB سيفشل؛ 48 GB يثبَّت بنظافة. حدِّد الحجم استناداً إلى النتائج المقاسة أعلاه، لا إلى تلك الصيغة.

تفسير قدَّمته هذه الصفحة سابقاً، تم سحبه

اقترحت نسخة سابقة من هذه الصفحة أن التثبيت فشل لأن الإصدار المطلوب كان أقدم من الإصدار الموجود في الصورة — أي أن العقدة طُلب منها التراجع للخلف. هذا خاطئ. أُنشئت هذه المجموعة من الصورة ذاتها مع قيمة مثبَّتة أقدم بـثلاثة عشر شهراً وثبَّتت بصورة طبيعية، وcrt-20260201-0179 يثبَّت أيضاً حين تُترك قيمة نظام التشغيل عند إصدار الصورة ذاته. اتجاه السفر ليس المتغير.

الإصدار الذي يصفه التوثيق

يصف مرجع الأوامر على هذا الموقع crt-20250613-3382، الإصدار الذي تعمل عليه هذه المجموعة. الأوامر الموجودة فقط على الإصدارات الأحدث مسجَّلة في sitecli/command-classification.json تحت not_on_this_build وموثَّقة بشكل منفصل، كما في الأوامر على الإصدارات الأحدث، لذا لا شيء هناك يبدو قابلاً للتشغيل هنا. انظر أيضاً الأوامر داخل الصندوق.

الوصول إلى إصدار أحدث مسألة محسومة، وليست إعادة بناء

سُجِّل هذا هنا سابقاً باعتباره مسألة غير محسومة، مع تقرير عن فشل الإصدار الأحدث على مواقع Azure Secure Mesh v2 أحادية العقدة مقابل ملاحظة مضادة عن موقع يعمل عليه. كلاهما مُفسَّر الآن: الإصدار الأحدث يثبَّت على تلك البنية، والفشل كان حد القرص المذكور أعلاه لا الإصدار.

إذن ثمة مساران ولا يستلزم أيٌّ منهما إعادة بناء لذاتها — أنشئ عقدة بقرص كبير بما يكفي، أو رقِّ عقدة موجودة عبر الـ API. Observed 2026-07-29.