Ansible-role-nginx-config: الافتراضيات المفقودة لـ nginx_main_template. *

أتفق تماماalexsegura. خيار تحديد معلمات مفردة على التراكم. كان التطوير في الدور أبطأ قليلاً مما كنت أرغب مؤخرًا ، لكن الأمور يجب أن تبدأ في الانتعاش مرة أخرى في الشهرين المقبلين. ومع ذلك ، لا تتردد في تقديم PR إذا كنت ترغب في ذلك 😄

شكرا لرسالتك.
نعم ، يمكنني المساهمة في طلب سحب 🙂

المشكلة التي أراها هنا وهناك في هذا الدور ، هي أن الإعدادات الافتراضية مضمنة.
لذلك إذا تغيرت الإعدادات الافتراضية ، عليك أن تتذكر تغييرها في كل من defaults/main.yml ، وفي القوالب.

https://github.com/nginxinc/ansible-role-nginx/blob/a92d424bdb5dc51b143c702754bed761e919a576/tasks/conf/upload-config.yml#L8 -L14

أفترض أن السبب هو أنه عند استخدام الإملاءات الافتراضية ، يتم استبدالها. هناك إعداد hash_behavior ولكنه عالمي على ما أعتقد.

هل تعرف طريقة لاسترداد المتغيرات الافتراضية "التي لم يتم لمسها" لدور ما؟
شيء من هذا القبيل role_defaults['var_name'] ؟

alexsegura لا أعرف طريقة رائعة لإنجاز هذا السلوك. من الناحية المثالية ، قد ترغب في إعداد حيث يمكن للدور نشر تكوين مفيد دون استخدام أي من القيم الموجودة في defaults/main.yml .

الفكرة الرئيسية التي يتبادر إلى الذهن هي استخدام vars/main.yml لترميز بعض القيم الافتراضية ثم القيام بشيء مثل | default(var_main_upload_src) ، لكنني لست متأكدًا من أن هذا هو أفضل مسار للمضي قدمًا.

ربما تكون الطريقة الوحيدة للقيام بذلك هي في القالب نفسه باستخدام المرشح الافتراضي.

حسنًا ، يعد هذا حلاً جيدًا للمعلمات المتعلقة بالقالب (وإذا نظرت إلى ملفات القوالب ، يتم استخدام الفلتر الافتراضي بالفعل في مكانين). ومن المسلم به أن ذلك من شأنه معالجة القضية الأصلية. ستكون مهمة تستغرق وقتًا طويلاً ولكنها قابلة للتنفيذ.

ومع ذلك ، يبقى السؤال حول ما هو أفضل نهج للمتغيرات غير المتعلقة بالقالب ، وأكثر من ذلك ، هل هناك أفضل نهج؟

مما أراه هنا وهناك ، فإن أفضل نهج للتخلف هو تجنب استخدام الإملاءات ، على سبيل المثال

nginx_main_template_user: www-data

بدلا من

nginx_main_template:
  user: www-data

هذا من شأنه أن يعالج المشكلة جزئيًا ، وفي البداية كانت هذه هي الطريقة التي تم بها تنظيم الدور. ولكن عندما بدأت في تقديم خيارات قوالب أكثر تعقيدًا (مثل كتل مواقع متعددة) ، بدأت القواميس والقوائم في جعلها أكثر منطقية.

أو يمكنك استخدام قواميس منفصلة للتكوين الافتراضي وتكوين المستخدم ودمجها مع مرشح combine . لقد كنت أستخدم دورًا لنشر تدفق الهواء حيث يتم استخدام هذه الطريقة:
airflow_config: "{{ airflow_defaults_config | combine(airflow_user_config, recursive=True) }}"
أعتقد أن هذا سيزيل أيضًا الحاجة إلى وجود إعدادات افتراضية مشفرة في القوالب؟

يمكن التحقق من الدور الذي أشير إليه هنا .

حسنًا ، هذا نهج مثير للاهتمام ، ويمكنني أن أرى أنه يعمل. ربما يكون من المفيد إنشاء PoC صغير باستخدام أحد القواميس الأصغر (أفكر في قوالب main أو stream ) لمعرفة مدى نجاحها عمليًا.

لقد جربت هذا بالفعل للقالب الرئيسي وكان يعمل كما هو متوقع. ومع ذلك ، نظرًا لأنني سرت في المسار الأقل جهدًا ، فقد قمت بدمج قواميسين nginx_default_main_template من الإعدادات الافتراضية و nginx_user_main_template من قواعد اللعبة للمستخدمين في nginx_main_template .
سيؤدي هذا إلى إدخال تغيير فاصل لذا سأقوم بإعادة تشكيل الدور لاستخدام القاموس المدمج تحت اسم جديد وإرسال العلاقات العامة.

يعد قالب http أكثر صعوبة نظرًا لوجود قواميس مستخدم متعددة يمكن دمجها. يمكن أن تكون المراسي والأسماء المستعارة جنبًا إلى جنب مع عامل الدمج بديلاً ولكن بعد ذلك يكون المستخدم مسؤولاً عن إجراء الدمج.
سأقضي بعض الوقت في تلك الجبهة أيضًا.

راجع للشغل: هل هناك سبب لاختيار استخدام قاموس بدلاً من قائمة لتحديد قوالب http متعددة؟ مما وجدته ، لا يتم استخدام المفتاح أبدًا.

راجع للشغل: هل هناك سبب لاختيار استخدام قاموس بدلاً من قائمة لتحديد قوالب http متعددة؟ مما وجدته ، لا يتم استخدام المفتاح أبدًا.

لا ليس بالفعل كذلك. بعد فوات الأوان ، أعتقد أنه قد يحسن إمكانية القراءة للحصول على مفتاح لكل قالب HTTP تحدده ، لكنني لا أعارض تغييره إلى قائمة إذا كان ذلك يجعل الأمور أسهل.

واجهت مشكلة مماثلة وبعد ذلك في هذه المشكلة. أود أن أقدم منظورًا بديلاً:

يجب عدم ترميز القيم الافتراضية للتكوين على الإطلاق ، وتركها للبرنامج الجاري تثبيته.

كما أوضحتalexsegura بالفعل ، فإن المشكلة تكمن في أنك بحاجة إلى الحفاظ على القيم متزامنة ، وهو الأمر الذي لن يكون الحال دائمًا بطبيعته (البشر معرضون للخطأ).

إذا كنت تشعر أنه يجب عليك توفير تكوين افتراضي ، أقترح الاحتفاظ بالأقسام الفرعية في dirs منفصلة ، ودمجها في أدنى مستوى إذا حدد المستخدم قيمة ، ثم دمجها في التكوين.

ولكن حتى هذا ، imo ، ليس ضمن نطاق الدور - يجب نسخ التكوين إلى الهدف ، وعدم التأكد من أن قيمه على ما يرام ؛ على الأكثر ، سأعطي خطأ إذا تعذر بدء البرنامج بسبب خطأ في التكوين (أو استخدم وظيفة التحقق من صحة البرنامج ، إذا كانت متوفرة).

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

أي تقدم في هذه القضية؟

لا. لا تزال هناك خطط للعودة إلى هذا في المستقبل "القريب" ، ولكن هناك مهمتان أخريان لها الأولوية.