لديّ سؤال يتعلق بتقنية شبكة توصيل المحتوى (CDN).
هل من الصحيح أن شبكة CDN يمكنها فقط تخزين الملفات الموجودة في موقعي ولا يمكنها تخزين الملفات المرتبطة مباشرة (hotlinked) من موقع آخر؟
أقوم بتخزين ملفات الكتالوج (ملفات mps والصور) على خادم آخر وأقوم بربطها مباشرة في موقع Discourse الخاص بي. هل من الصحيح أن هذه الملفات لن يتم تخزينها مؤقتًا بواسطة شبكة CDN؟ وهل توجد طريقة لتخزين الملفات المرتبطة مباشرة مؤقتًا أيضًا؟
ما لم تخبر discourse بعدم القيام بذلك، فستقوم بسحب تلك الصور عن بُعد إلى مخزن الصور الخاص بها. يفترض ما يلي أنك قمت بإيقاف هذه الميزة.
يجب أن تضع هذا الموقع خلف شبكة توصيل المحتوى (CDN) ثم تشارك عنوان URL الخاص بـ CDN مع discourse.
إذا وضعت شبكة توصيل المحتوى (CDN) أمام موقع الصور الخاص بك ولكنك شاركت عنوان URL الأصلي مع discourse، فيمكنك استخدام ميزة مدمجة لاستبدال عنوان URL الأصلي بعنوان URL الخاص بـ CDN.
هل فهمي صحيح أنه إذا قمت بتفعيل ميزة CDN في Discourse وتعطيل حفظ المصدر في Discourse، فإن خدمة CDN ستنشئ ذاكرة تخزين مؤقت لهذه الملفات الخارجية، وستقوم Discourse باستبدال جميع الروابط بالملفات المرتبطة مباشرة من موقع آخر؟
أشك في إمكانية إنشاء ذاكرة تخزين مؤقت للملفات الخارجية المرتبطة مباشرة من مواقع أخرى. هل يمكن لأي شخص تأكيد ذلك؟
معلومة للإعلام - لقد نشرت موضوعًا جديدًا حول كيفية إعداد تسريع CDN للموقع الكامل (وإنهاء SSL) باستخدام AWS Cloudfront هنا (الرابط أدناه). هناك مخاطر هنا، لذا تحرك بحذر.
هل ما زال هذا مطلوبًا عندما يحدث الخطأ Reason: CORS header ‘Access-Control-Allow-Origin’ missing؟
لا يمكنني العثور على أي شيء يستخدم هذا المتغير في Github:
تعديل: لا يزال تعليق الإعدادات يقول إنه مطلوب، وهو يعمل بعد ذلك. لذلك سأقبل الأمر 
في الوقت الحالي من عام 2023، هل لا تزال القواعد الأربع المذكورة أدناه بحاجة إلى اتباعها بدقة؟ على سبيل المثال، إذا كنت سأستخدم Akamai، المصمم لجعل اسم النطاق الرئيسي مع تسريع شبكة توصيل المحتوى الخاصة به. هل لدى أي شخص تكوين مُقطّر للقواعد المذكورة أدناه، مثل هل يجب أن يستمر طلب ناقل الرسائل و الاستقصاء الطويل إلى المصدر؟ أين يجب أن تذهب هذه الإعدادات؟ يبدو أن عنوان URL الأساسي للاستقصاء الطويل قد تمت إزالته من لوحة تحكم المسؤول؟
هناك بعض الإعدادات المتقدمة التي تسمح لك بتقديم طلبات Message Bus من مجال مختلف. ومع ذلك، فهي معقدة للغاية.
لذلك، يجب تعيين “عنوان URL الأساسي للاستطلاع الطويل” من خلال وحدة تحكم Rails. نظرًا لأنه تمت إزالته من لوحة تحكم المسؤول. يجب أن أكون قد فاتني السبب المنشور في أي مكان من قبل لماذا تمت إزالته إذا كان الإعداد لا يزال مطلوبًا لتمكين الموقع من العمل بشكل جيد في وضع شبكة توصيل المحتوى للموقع بالكامل.
وبالمثل، يجب تعيين DISCOURSE_ENABLE_CORS: true في app.yml.
يجب عليك تعيينه باستخدام متغير بيئة (DISCOURSE_LONG_POLLING_BASE_URL) في ملف app.yml الخاص بك. إنه مخفي لأن قلة قليلة من الأشخاص يحتاجون إلى تعيينه ويفترض أنه إذا كنت تفعل ذلك فأنت تعرف ما تفعله.
شكراً، @pfaffman! كان يجب أن أعرف أن كل هذه المتغيرات المكتوبة بأحرف كبيرة يجب أن توضع في app.yml.
إذن، ما هي حالات استخدام ناقل الرسائل التي ستدخل حيز التنفيذ؟ على سبيل المثال، الرد على منشور يسبب إشعارًا وما إلى ذلك؟ سأقوم باختبار حالات الاستخدام للتأكد مما إذا كان ناقل الرسائل في موقعي يعمل كما هو متوقع بدون تعيين DISCOURSE_LONG_POLLING_BASE_URL.
مرحباً،
هل تم إزالة “عنوان URL الأساسي للاستطلاع الطويل” من لوحة تحكم المسؤول؟ أو هل يمكن إجراء هذا الإعداد من خلال وحدة تحكم Rails؟
long_polling_base_url هو إعداد موقع مخفي، ولكن يمكن تعيينه من وحدة تحكم rails إذا لم تكن تستخدم متغير بيئة في app.yml الخاص بك:
هذه القائمة بالتأكيد تعطي رؤى أعمق حول Discourse.
لقد قمت بإعداد شبكة توصيل المحتوى (CDN) مع موقعي الإلكتروني، وقد وصلت إلى ذاكرة التخزين المؤقت للحافة، ومع ذلك لم أواجه مشكلة في ناقل الرسائل (message-bus) مع رؤوس الاستجابة الخاصة به، ولكن لا يزال الأمر لا يبدو قوياً. لم يتم تعيين إعدادات CORS أيضاً.
Cache-Control: must-revalidate, private, max-age=0
مرحباً،
لقد طرحت سؤالي في موضوع آخر Full Site CDN Using AWS CloudFront - #2 by Hyan. لقد قمت بنفس الإعداد وتركت #DISCOURSE_CDN_URL: https://discourse-cdn.example.com دون تغيير. هل يمكنني تعيين هذا إلى نفس عنوان URL للموقع؟ على سبيل المثال، http://forum.example.com. بخلاف ذلك، ستكون هناك أصول URL في مسار نسبي بدون اسم نطاق.
أقدر ذلك إذا أعطاني @sam أو @pfaffman تلميحاً.
لا أوصي باستخدام Cloudflare كشبكة توصيل محتوى (CDN). يستخدمها بعض الأشخاص. ربما يمكنهم المساعدة.
تحرير: أوه، آسف. هذه “شبكة توصيل محتوى للموقع بالكامل…” ربما لا ينبغي لي المساهمة هنا.
لا، أنا أستخدم Akamai CDN، الذي يدعم تخزين المحتوى الديناميكي مؤقتًا.
من المنشور الأول في هذا الموضوع، يبدو أنه يجب عليّ تعيين DISCOURSE_CDN_URL كـ CDN غير كامل للموقع، على الرغم من أن عنوان URL هو نفسه عنوان URL للموقع. أنا فقط لست متأكدًا مما إذا كان تعيينه يتسبب في تعطل موقعي ونتائج أخرى لا رجعة فيها، وفي النهاية اضطررت إلى إعادة تثبيت البرنامج من البداية. في هذا المنشور https://meta.discourse.org/t/full-site-cdn-using-aws-cloudfront/208161، لم يقم المؤلف بتعيينه ويترك DISCOURSE_CDN_URL دون تغيير، ولا يتطلب عنوان URL منفصلاً لخدمة message-bus/long-polling. أستخدم هذا الحل وموقعي يعمل بشكل جيد حتى الآن. العيب الوحيد لهذا الحل هو وجود العديد من عناوين URL النسبية (لا يوجد عنوان URL أساسي، حيث أن قيمة DISCOURSE_CDN_URL فارغة) في مصدر الصفحة، مما يجعله يبدو وكأنه ليس موقعًا على مستوى الإنتاج.
متابعة لأسئلتي، وجدت منشورًا مشابهًا لما أسأل عنه في هذا المنشور CloudFront not caching static files - #4 by Falco
أقدر إجابة @Falco، في إعداد CDN للموقع بالكامل هذا، هل يمكنني تعيين DISCOURSE_CDN_URL بنفس قيمة DISCOURSE_HOSTNAME؟ حيث أفترض أن إعداد CDN للموقع بالكامل يعني أن CDN تسرع عنوان URL الخاص باسم المضيف مما يجعل DISCOURSE_CDN_URL بنفس قيمة DISCOURSE_HOSTNAME. ولكن لا توجد وثائق لائقة حول هذا في meta.
مرحباً، هل يوجد قالب للأرنب؟
لا تحتاج إلى قالب لذلك، فقط قم بتكوين bunny للسحب من موقع discourse الخاص بك وقم بتعيين DISCOURSE_CDN_URL إلى نقطة نهاية cdn التي يوفرها bunny في app.yml
أحاول استخدام “تسريع شبكة توصيل المحتوى” (CDN acceleration) مع عنوان IP الخاص بخادم VPS الخاص بي مع Bunny DNS. إنه يعمل، ولكن جميع المستخدمين لديهم نفس عنوان IP.
لقد وجدت الإعداد للتو، ويسمى “X-Real-Ip”.