CDN كامل للموقع باستخدام AWS CloudFront

تثبيت
1

أهلاً بالجميع. لقد قمت مؤخرًا بإعداد تثبيت Discourse الخاص بي باستخدام AWS CloudFront (CF) لتسريع الموقع بالكامل - وإلغاء تحميل SSL باستخدام شهادات AWS في CF. لاحظ أن هذا التثبيت ينحرف عن الدليل الرسمي فيما يتعلق بتكوين CDN و SSL - لذلك قد يكون ذلك مثيرًا للجدل ويؤدي إلى مشاكل دعم مستقبلية. لذا كن حذرًا… هناك تنانين هنا. أنا أشارك التكوين الذي نجح معي هنا:

  1. قم بإعداد Discourse للاستماع على المنفذ 80 فقط وتعطيل Let’s Encrypt عن طريق التعليق على الأسطر المشار إليها في app.yml:

    2021-11-03 16_06_24-Window
    2021-11-03 16_06_24-Window729×262 12.2 KB

  2. قم بإعداد Discourse للانتباه إلى رأس CF، cloudfront-forwarded-proto، بدلاً من x-forwarded-proto (الذي لا يمرره CF - والغريب أنه لا يمكن تكوينه لتمريره إلى المصدر… يا له من جنون! :angry:)

    2021-11-03 16_09_08-Window
    2021-11-03 16_09_08-Window858×217 7.99 KB

  3. قم بإعداد توزيع CF الخاص بك مع اسم مستعار لاسم المضيف العام المقصود الخاص بك (مثل forum.example.com) باستخدام شهادة AWS ACM (التي قمت بإنشائها).

  4. قم بإعداد مصدر CF باستخدام عنوان IP العام المرن للخادم EC2 الذي يستضيف Discourse (مثل ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com). قم بتكوينه لـ http فقط (أي المنفذ 80 فقط - لا يوجد 443). لا تحتاج إلى إعداد المصدر الخاص بك باسم مضيف رائع في DNS مثل forum-origin.example.com. اسم المضيف أو عنوان IP الخاص بـ EC2 يعملان بشكل جيد.

  5. قم بإعداد “سلوكيات” CF لمسارات الطلبات المختلفة. المفتاح هنا هو تكوين سلوك التخزين المؤقت للأشياء التي هي موارد ثابتة بشكل واضح؛ وتكوين عدم التخزين المؤقت لكل شيء آخر (أي يتم تمرير هذه الطلبات كما هي إلى المصدر دون تخزين مؤقت). شيء رئيسي آخر هنا هو أن قاعدة المرور الأخيرة (“الافتراضية”) تستخدم “سياسة طلب مصدر” مخصصة تمرر جميع رؤوس الطلبات الأصلية إلى المصدر بالإضافة إلى رأس CF cloudfront-forwarded-proto. قم أيضًا بتكوين عمليات إعادة توجيه http إلى https في سلوكياتك - بحيث يتم إجبار جميع طلبات المستخدم النهائي على أن تكون https بواسطة CF.

    2021-11-03 16_15_54-Window
    2021-11-03 16_15_54-Window1783×415 53.6 KB

  6. لا تقم بتكوين “DISCOURSE_CDN_URL”

  7. قم بتمكين “فرض https”

  8. لا تقم بتكوين “عنوان URL أساسي للاستقصاء الطويل” - اتركه فارغًا. على الرغم من جميع التحذيرات الشديدة بشأن كون هذا مزعجًا عند تمريره عبر وكيل، إلا أنه يعمل بشكل جيد بالنسبة لي حتى الآن. ربما يكون وقت الاستبقاء الافتراضي لـ CF طويلاً بما يكفي لمنعه من إسقاط الاتصال.

أعتقد أن هذا كل شيء… :thinking:

النتيجة النهائية هي أن جميع الطلبات، http/المستندات، وجميع الموارد الثابتة الداعمة، وجميع استدعاءات ajax، وما إلى ذلك، يتم خدمتها جميعًا على نفس اسم النطاق (مثل forum.example.com). يتم تحديد سلوك التخزين المؤقت (وسلوك المرور) بواسطة “سلوكياتك” المكونة في CF. ويتم تشفير جميع الاتصالات باستخدام شهادات AWS ACM المنتهية على حافة CF - ثم يتم إرسال حركة المرور غير المشفرة/http مرة أخرى إلى خادم المصدر.

أجرؤ على القول بأن هذا قد يكون أنظف مما لدى meta.discourse.org حاليًا :shushing_face:.

7 إعجابات
2

مرحباً @jaffadog

أنا في سيناريو مشابه ولكن في الموقع الكامل مع شبكة توصيل محتوى مختلفة. في تجربتك، هل اختبرت تكوين DISCOURSE_CDN_URL بعنوان URL الخاص بنطاق موقع الويب؟ على سبيل المثال، في وضع شبكة توصيل المحتوى الكاملة، إذا كان عنوان URL الخاص بموقعك هو https://foo.bar.com؛ فيجب أن يكون عنوان URL لشبكة توصيل المحتوى هو https://foo.bar.com أيضًا. إذا تركنا DISCOURSE_CDN_URL فارغًا، فستبدأ عناوين URL لأصول موقع الويب بمسار نسبي. على سبيل المثال، كما في المقتطف أدناه،

      <link rel="preload" href="/extra-locales/admin?v=8f522e122c802d1ed66dfa7fecafbb35" as="script">
<script defer src="/extra-locales/admin?v=8f522e122c802d1ed66dfa7fecafbb35"></script>

هذا يبدو غير أنيق في موقع إنتاجي، على الرغم من أن كلا عنواني URL يقومان بطلب إلى https://foo.bar.com.