غير مرجح. إنه نوع الشيء الذي ستقوم به مرة واحدة بالضبط، وستقوم به عندما تكون بالفعل في خضم التعامل مع app.yml.
سأرى ما إذا كان بإمكاني تقديم طلب سحب (PR) لإضافته إلى standalone.yml، مع ذلك.
ومع وضع هذا في مكانه، يصبح الأمر أبسط بكثير!
4 إعجابات
شكرا جزيلا على هذا، لقد كنت أقوم بتعديل templates/web.letsencrypt.ssl.template.yml محليًا ولكن هذا يجعل حياتي أسهل بكثير!
إعجاب واحد (1)
هل نحتاج إلى تضمين اسم المضيف (الأصلي) في هذا، أم الأسماء البديلة فقط؟
فقط الأسماء المستعارة. اسم المضيف هو اسم المضيف.
إعجاب واحد (1)
إذن هكذا إذن؟
env:
DISCOURSE_HOSTNAME: domain.com
DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org
إعجاب واحد (1)
أتصارع فلسفياً مع معنى ‘الاسم المستعار’، وأدرجت كلا العنوانين اللذين أريد أن يؤديا إلى موقعي: nzarchitecure.net.nz و www.nzarchitecture.net.nz دون أي آثار سلبية واضحة (وبافتراض عدم وجود فائدة أيضًا).
إعجاب واحد (1)
هل يمكن تعديل standalone.yml بواسطة إعدادات المسؤول ضمن نسخة Discourse قيد التشغيل أو تكليفها بقراءتها؟
إذا كان الأمر كذلك، فسيكون ذلك مفيدًا جدًا للمستخدمين الجدد وأولئك الذين يتطلعون إلى ترحيل النطاقات أو إضافة أسماء مستعارة - مما يقلل من الصداع الذي يجب البحث عنه واستكشاف الأخطاء وإصلاحها.
لا. سيكون من السيئ جدًا أن تتمكن الوظائف التي تعمل في الحاوية من تغيير أشياء مثل app.yml. في الواقع، من ممارسات الأمان الجيدة وضع أشياء مثل مفاتيح S3 في ملف yml بحيث تكون مخفية عن واجهة Discourse.
مرة أخرى، من النادر جدًا إجراء تغييرات مثل تلك التي تحتاج إلى إعادة توجيه النطاقات، وهي تتطلب أشياء أخرى، مثل إعدادات DNS. الوقت المناسب للقيام بذلك هو عند إعداد Discourse، وعند إعداد Discourse، فإنك تعبث بملف yml.
إعجاب واحد (1)