نشر العرض التوضيحي

المتطلبات المسبقة

• Terraform بالحد الأدنى للإصدار المذكور في terraform/versions.tf — >= 1.8، من أجل الدوال المُعرَّفة من الموفر وكتلة check التي تحمي عنوان VIP.
• موفر xcsh. لا شيء يثبّت إصداراً بعينه: الملف .terraform.lock.hcl مُستثنى من git والقيد مجرد حد أدنى مفتوح، لذا فإن كل عملية init تجلب أحدث إصدار منشور. هذا مقصود لمشروع في مرحلة ما قبل الإصدار — يجب أن يفشل العرض التوضيحي عند وجود انحدار في الموفر بدلاً من البقاء على إصدار قديم يخفيه.
• بيانات اعتماد API لـ F5 XC للمستأجر المحدد في var.expected_xc_tenant، مُصدَّرة باسم XCSH_API_TOKEN (أو زوج P12/PEM). صدِّر بيانات الاعتماد فقط، ولا تصدّر عنواناً أبداً — انظر أدناه.
• بيانات اعتماد Azure بصلاحيات إنشاء مجموعة موارد وشبكة VNet وRoute Server وأجهزة افتراضية.
• مساحة أسماء موجودة مسبقاً في F5 XC لطبقة التطبيق. النشر يقرأها ولا يُنشئها أو يدمّرها أبداً، لذا لا يمكن أبداً أن تنتهي مساحة أسماء تحتوي على عروض توضيحية غير ذات صلة في قائمة الحذف الخاصة بهذه الحزمة.

dev_overrides يستبدل بصمت الموفر الذي تعتقد أنك تختبره

إذا احتوى ~/.terraformrc على كتلة dev_overrides لـ xcsh، فإن كل أمر Terraform محلي يستخدم الملف التنفيذي الموجود في ذلك المجلد ويتجاهل كلاً من قيد الإصدار وملف القفل. يكفي أن يكون البناء أقدم ببضعة أيام ليفشل برسالة Blocks of type "…" are not expected here على إعداد صالح تماماً مقابل الموفر المنشور.

أبعده عن المسار الافتراضي ولا تستخدمه إلا عندما تكون بصدد تطوير الموفر:

mv ~/.terraformrc ~/.terraformrc.provider-dev
TF_CLI_CONFIG_FILE=~/.terraformrc.provider-dev terraform plan   # when you mean it

قدّم القيمتين اللتين لا توجد لهما قيمة افتراضية

لكل متغير آخر قيمة افتراضية عملية، وكل اسم كائن مُشتق من var.component. اثنان تُركا بقصد بلا قيمة افتراضية:

cd terraform
cp terraform.tfvars.example terraform.tfvars

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

كلتاهما تُتحقق صيغتهما، لذا يؤدي خطأ إملائي إلى فشل الخطة بدلاً من فشل العرض التوضيحي.

الملف terraform.tfvars مُستثنى من git، ويجب أن يبقى كذلك: فهو يحمل معرّف اشتراك وقيماً خاصة بكل مهندس.

المستأجر إعداد، وليس ما تصدّره بيئة الطرفية لديك

يحدد var.expected_xc_tenant اسم المستأجر وهو المكان الوحيد الذي يُسمّى فيه. يستنبط providers.tf قيمة api_url لموفر xcsh منه، وهو ما يتجاوز بقصد أي XCSH_API_URL في البيئة، وتُفشل كتلة postcondition في terraform/main.tf عملية التخطيط عندما تُحدد البيئة مستأجراً مختلفاً.

اقرأ أي من الشقين دون تشغيل أي شيء يغيّر الحالة:

terraform output -raw xc_tenant       # what the deployment targets
terraform output -raw xc_env_tenant   # what your shell claims — diagnostic only

f5-sales-demo
f5-sales-demo

يوجد هذا الحاجز الوقائي لأن العرض التوضيحي نقل نفسه بصمت إلى المستأجر الخطأ

بُني العرض التوضيحي في مستأجر واحد. ثم بدأ ملف بيانات اعتماد يصدّر XCSH_API_URL لمستأجر مختلف؛ فأصدرت عمليات التطبيق اللاحقة رمزاً لذلك المستأجر، وأعادت أجهزة CE الافتراضية التسجيل هناك، وتُركت تسجيلاتها الأصلية مهجورة. وكانت كل خطة في الأثناء نظيفة، لأن لا شيء في الإعداد كان له رأي بشأن المستأجر (المشكلة 696، أُصلحت في PR 697). واستلزم التعافي تدمير الحزمة في المستأجر الخطأ وإعادة بنائها في المستأجر الصحيح.

العَرَض الذي يجب التعرّف عليه، لأنه لا يشرح نفسه: رمز صادر لمستأجر آخر يفشل مع نقطة النهاية المثبّتة برسالة 401 مجرّدة، وهو ما يُقرأ تماماً كأنه بيانات اعتماد منتهية. إذا أعادت بيانات اعتماد تعتقد أنها سليمة الرمز 401، فقارن المخرجين أعلاه قبل إصدار رمز آخر.

التطبيق

1. التهيئة. إعداد الواجهة الخلفية غير مُضمَّن في المستودع؛ قدّم إعدادك الخاص.

   terraform init -backend-config=backend.hcl

2. التطبيق الأول. يبني هذا Azure ومواقع CE ورمز التسجيل، ويُشغّل أجهزة CE.

   terraform apply

3. طبّق مرة أخرى بعد أن تُسجّل أجهزة CE. هذا ليس اختيارياً، والسبب موضّح أدناه بدلاً من أن يكون شيئاً تكتشفه بنفسك.

   terraform apply

ثم انتقل إلى إثبات سلامته قبل عرضه على أي شخص.

موافقة التسجيل مُؤتمتة، ومع ذلك يبقى التطبيق على مرحلتين

لم تعد موافقة التسجيل تحتاج إلى شخص في وحدة التحكم: يقوم بها المورد xcsh_registration_approval، وتحدد وحدة الموقع أي تسجيل يجب الموافقة عليه.

لكن ذلك لا يجعل النشر عملية apply واحدة بلا تدخّل، والسبب يستحق الفهم قبل أن تشاهد التشغيل الأول وتستنتج أنه فشل:

• يُسمّى كائن تسجيل CE r-<uuid>. ولا يُسمّى أبداً باسم الموقع، لذا لا يمكن لأي شيء التنبؤ بالاسم في وقت التخطيط.
• لا يوجد التسجيل إلا بعد أن يُشغّل الجهاز الافتراضي ويقوم vpm بالتسجيل.
• لذلك لا يخطط التطبيق الأول لأي موافقة على الإطلاق. أعد التطبيق بعد أن تُسجّل أجهزة CE فتُنشأ الموافقات.

يوثّق terraform/main.tf هذا الترتيب في أعلى الملف، وهو النسخة المرجعية — فتسلسل النشر يعيش مع الشيفرة التي تنفّذه.

الموقع الجديد تماماً لا يكون قابلاً للوصول فوراً عبر واجهة operate API

لمدة تقارب 25 إلى 30 دقيقة بعد أن يُبلّغ موقع جديد عن حالة ONLINE، تجيب نقاط النهاية vpm/debug بصفحة BIG-IP بالرمز 503 تقول The requested URL was rejected. يبدو الأمر كأنه حجب من جدار حماية تطبيقات الويب (WAF) أو رمز مُلغى وهو ليس أياً منهما. انتظر، ثم أعد المحاولة.

يؤثر هذا على عرض توضيحي مبني حديثاً، وليس على عرض قيد التشغيل.

وصول SSH للمشغّل قرار يُتخذ وقت البناء

يكتب النشر مفتاح مشغّل إلى حساب admin على الجهاز، والذي تكون واجهة تسجيل الدخول له هي Site CLI. ويُكتب عبر write_files في cloud-init، الذي يُنفَّذ مرة واحدة عند أول تشغيل.

لا يمكن إضافته إلى أجهزة CE التي تعمل بالفعل

custom_data قابل للاستبدال فقط، لذا فإن تبنّي هذا على أجهزة CE قيد التشغيل يستبدل كل جهاز CE افتراضي. وهذا إعادة بناء للأسطول، وليس تغييراً في الإعداد. وينطبق الأمر ذاته على أي شيء آخر في قالب cloud-init — بما في ذلك تعليق، لأن custom_data هو base64encode للملف المُصاغ.

كان الأمر أسوأ في السابق: لم يكن جهاز CE المُستبدل قادراً على إعادة التسجيل أبداً، لأن تسجيل العقدة المُدمَّرة كان لا يزال يحتفظ بفهرس لوحة التحكم الفريد (tenant, cluster_name, hostname) — وكان terraform plan يُبلّغ عن “No changes” طوال المدة التي كان الأسطول فيها متوقفاً. واستلزم التعافي إعادتَي بناء كاملتين. وقد أُصلح ذلك (المشكلة 674، أُغلقت بواسطة PR 693): دورة حياة كائن الموقع مرتبطة الآن بمثيل جهاز CE الافتراضي، لذا فإن استبدال الجهاز يستبدل الموقع، وحذف الموقع يأخذ تسجيلاته معه قبل أن تُشغّل العقدة البديلة.

على أي شخص يتبنى هذا في مكان آخر أن يقرأ صفحة SSH أولاً.

إزالة النشر

terraform destroy

تبقى مساحة أسماء التطبيق: فهي مقروءة وليست مُدارة أبداً، لذا لا يمكن لأمر destroy أن يأخذ معه مساحة أسماء تحتوي على عروض توضيحية غير ذات صلة. أما كل شيء آخر في مجموعة الموارد فسيزول.