تشخيصات طرف العميل (Customer Edge)

طرف العميل (CE) هو عقدة F5 Distributed Cloud التي يوفّرها هذا المستودع داخل Azure — terraform/modules/ce-node، والمبنية من صورة السوق volterraedgeservices/volterra-node.

تُشغّل هذه العقدة مستوى البيانات (Argo)، ومستوى التحكم (Vega)، ووكيل Envoy، وحزمة Kubernetes، وvpm، وهو الوكيل الذي يسجّل العقدة ويدير كل شيء آخر عليها.

عندما يسوء سلوك طرف العميل، يكون Site CLI هو الأداة. القرار الأول هو أي مسار وصول ينطبق، وارتكاب الخطأ فيه يضيّع الوقت بطريقة تبدو كأنها عقدة معطوبة.

أربعة مسارات وصول، وهي غير قابلة للتبادل

واجهة Debug APIلعقدة في الحالة ONLINE. قابلة للبرمجة النصية، للقراءة فقط، وتغطي 34 أمرًا.

وحدة تحكم الموقعواجهة استكشاف الأخطاء الخاصة بـ F5 لكل عقدة، عبر نفق Azure Bastion. بلا مفتاح SSH، وبلا مضيف وسيط.

SSHواجهة Site CLI الكاملة على الجهاز. تحتاج إلى مفتاح موجود من أول إقلاع ومضيف داخل شبكة VNet.

وحدة التحكم التسلسليةلعقدة لم تُسجَّل قط. المسار الوحيد عندما لا يكون للعقدة أي مسار شبكي.

تصل واجهة debug API إلى العقدة عبر مستوى التحكم في F5 Distributed Cloud. وهذا هو كل سبب أهمية هذا الفصل: لا يمكن للواجهة أن تجيب إلا بعد أن تكون العقدة قد سُجّلت وتُبلّغ عن الحالة ONLINE.

العقدة التي فشل تسجيلها — cloud-init تالف، أو رمز منتهي الصلاحية، أو عدم وجود مسار إلى register.ves.volterra.io — هي بالضبط الحالة التي تحتاج فيها إلى التشخيصات، وبالضبط الحالة التي لا يمكن للواجهة أن تخدمها.

وحدة تحكم الموقع هي ما يجدر تجربته أولاً عندما تريد واجهة استكشاف الأخطاء الخاصة بـ F5 بدلاً من أوامر محددة. وهي تطلب منك أقل قدر ممكن — بلا مفتاح، وبلا مضيف وسيط، وبلا عنوان IP عام على العقدة — لأن تحديد من يُسمح له بالاتصال يصبح قرارًا يخص Azure RBAC، وهي تجيب سواء سُجّل الموقع أم لا. تحتاج إلى Azure Bastion، الذي يقيّده هذا النشر خلف enable_bastion ولا يُنشر افتراضيًا.

SSH هو المسار الوحيد الذي يصل إلى سطح الأوامر الكامل للجهاز — تكشف واجهة debug API عن 34 أمرًا، بينما تقدم العقدة نفسها أوامر أكثر بكثير. ويقيّده أمران. يستجيب sshd على العنوان الداخلي (SLI) للعقدة فقط، لذا يحتاج إلى مضيف داخل شبكة VNet؛ ويُكتب المفتاح بواسطة cloud-init عند أول إقلاع، لأن حقل ssh_key على كائن الموقع خامل — إذ يتخطى vpm المستخدم admin ولا يطبّقه أبدًا. ولذلك فإن تمكينه على العقد العاملة يعني استبدالها.

إذًا: إذا كان الموقع في الحالة ONLINE وكانت 34 أمرًا كافية، فاستخدم واجهة debug API. وإذا أردت واجهة رسومية، أو من أجل عقدة لم تُسجَّل قط لكنها ما زالت تملك مسارًا شبكيًا، فاستخدم وحدة تحكم الموقع. وإذا كنت تحتاج إلى بقية سطح الأوامر وتستطيع الوصول إلى شبكة VNet، فاستخدم SSH. وإذا لم يكن للعقدة أي مسار شبكي عامل على الإطلاق، فوحدة التحكم التسلسلية هي الطريق الوحيد للدخول.

تحقق من حالة الموقع أولاً — وتحقق من أنك تسأل المستأجر الصحيح

طلب واحد يخبرك بالمسار الذي أنت عليه:

curl -sS -H "Authorization: APIToken $XCSH_API_TOKEN" \
  "$XCSH_API_URL/api/config/namespaces/system/sites/<site>" \
  | jq -r '.spec.site_state'

ONLINE تعني أن واجهة debug API ستعمل. وأي شيء آخر يعني وحدة تحكم الموقع أو وحدة التحكم التسلسلية.

الموقع الذي لا وجود له لديه تفسير ثانٍ يسبق «أنه لم يُسجَّل قط»: وهو أنك موجَّه إلى المستأجر الخاطئ. يعيش هذا النشر في f5-sales-demo (https://<XC_TENANT>.console.ves.volterra.io)، وهو مثبَّت بواسطة var.expected_xc_tenant — والأمر cd terraform && terraform output -raw xc_tenant يوضّح ذلك دون المساس بأي شيء. أما بيانات الاعتماد المُصدرة لمستأجر آخر فتعيد 401 مجردًا، وهو ما يُقرأ كرمز منتهي الصلاحية.

قواعد السلامة

هذه القواعد تنطبق على كل أمر في كل صفحة أدناه.

• للقراءة فقط إلا إذا كنت متأكدًا. سطح الأوامر مقسوم إلى طبقتي امتياز، وطبقة Exec إما تُعدّل العقدة أو تقرأ علامة حالة. لا شيء في هذه الصفحات يُنفّذ أمر Exec، وكذلك لا يفعل ذلك إطار الالتقاط.
• لا تفترض أبدًا أن أمرًا آمن انطلاقًا من اسمه. فـ ip-link-set يُقرأ كأنه استعلام لكنه يُعطّل واجهة شبكة. وsystemctl-restart-crio يعيد تشغيل زمن تشغيل الحاويات أسفل مستوى بيانات حيّ.
• فضّل الأمر الأضيق الذي يجيب على السؤال. فـ health و diagnosis يلخّصان العقدة بتكلفة زهيدة؛ أما flow-l فيُفرغ كل تدفّق حيّ، بينما flow-l-match يجيب على السؤال نفسه بشأن اتصال واحد.
• طرف العميل يخدم حركة مرور حيّة. هذه بيئات عرض توضيحي مشتركة. افترض أن أحدهم يقدّم عرضًا من الموقع الذي تُصحّحه.

ما هو موثّق هنا

كل أمر يمكن الوصول إليه عبر واجهة debug API على إصدار البرنامج الذي يشغّله هذا المستأجر، مع مخرجات مُلتقطة من عقدة حيّة بدلاً من نسخها من مكان آخر.

يسرد مرجع الأوامر جميعها مع فئتها وطبقة الامتياز وطريقة النقل؛ أما سير العمل فيسلسلها في التتابعات التي تستخدمها فعليًا عندما يحدث خطأ ما.

أما الأجزاء المتاحة على الجهاز فقط من Site CLI — configure، وconfigure-network، وfactory-reset، وupgrade، وقرابة ستين أمر ExecCLI إضافيًا — فهي غير مشمولة، لأن مخرجاتها لم تُلتقط من عقدة حيّة بالطريقة التي التُقطت بها كل صفحة أدناه.

لكنها، مع ذلك، لم تعد بعيدة المنال. فالسكربت scripts/sitecli_ssh_harvest.py يشغّل قائمة الإكمال الخاصة بالجهاز عبر SSH ويسجّل الوصف الذي يقدّمه الجهاز لكل أمر، بحيث يمكن قياس هذا السطح بدلاً من تخمينه. وتنفيذه ممنوع افتراضيًا — فهو يُعدّد كل شيء ولا يُنفّذ سوى قائمة سماح — لأن صياغة الأوامر غير المتحقَّق منها، وآثار الأوامر غير المتحقَّق منها، هي الخلل الذي يوجد هذا التوثيق لتجنّب تكراره.