لم أستطع معرفة سبب توقف تثبيتنا عن تقديم الأصول من شبكة توصيل المحتوى (CDN) في أحدث تحديث. نحن نستخدم Cloudfront، وكان يعمل بشكل جيد لتقديم كل من التحميلات والأصول، لكن يبدو أنه في أحدث تحديث، يتم تقديم الأصول من الخادم بدلاً من ذلك.
المشكلة الأخرى التي نواجهها هي أنه عند تمرير المتغير DISCOURSE_CDN_URL، يبدأ Discourse في طلب أصول غير مُولَّدة أو مُحمَّلة بواسطة مهمة s3:upload_assets (مثل أوراق الأنماط مثلاً). هذا يؤدي إلى تعطل الموقع بالكامل وظهور صفحة بيضاء. يذكر هذا المنشور شيئاً مشابهاً.
لقد قمت بإزالة DISCOURSE_CDN_URL الذي كان مضبوطًا على نفس قيمة DISCOURSE_S3_CDN_URL لأن ذلك كان يتسبب في تعطل الموقع (كان يحاول سحب أصول غير موجودة على S3).
عند النظر إلى الموقع الذي كنت أواجه فيه مشاكل، يبدو أنني نسيت إضافة https:// إلى عنوان URL الخاص بشبكة CDN التي كنت أستخدمها. لست متأكدًا من كيفية عمله في أي وقت، أو إذا لم يعمل أبدًا، كيف لم ألاحظ ذلك عند إضافة القيمة المعطلة.
@eatcodetravel، بالطبع يجب عليك إخفاء كلمات مرور SMTP ومفاتيح S3، لكنني أعتقد أنك ستحتاج إلى مشاركة قيم CDN على الأقل حتى يتمكن أي شخص من التخمين ما قد يكون المشكلة.
نعم، كان عليّ إزالة DISCOURSE_CDN_URL، حيث بدأ يطلب أصولًا لا يتم تحميلها إلى S3 بواسطة مهمة rake s3:upload_assets، مما يؤدي إلى تعطل الموقع بالكامل. ربما كان هذا هو الجزء الذي تغير، وقد نحتاج إلى تحديث rake s3:upload_assets ليعمل بشكل صحيح مرة أخرى.
نعم، يمكن استخدام عنوان URL لنفس شبكة تسليم المحتوى (CDN) لكل من DISCOURSE_CDN_URL و DISCOURSE_S3_CDN_URL، لكن ذلك يتطلب كثيرًا من تسجيل الدخول إلى شبكة تسليم المحتوى لاستخدام المصدر الصحيح لكل أصل بناءً على عنوان URL. على سبيل المثال، تأتي ملفات CSS من التطبيق، بينما تأتي ملفات JavaScript من S3، وهذا مجرد حالة واحدة، فلدينا عشرات الحالات.
لذلك، يتوقع منك تعيين كلا العنوانين، حيث يعمل DISCOURSE_CDN_URL كـ “وكيل” لتطبيق الويب الخاص بك، بينما يعمل DISCOURSE_S3_CDN_URL كوكيل لحزمة تخزين الكائنات الخاصة بك.
حسناً، هل هذا شيء تغير مؤخراً؟ لست متأكداً مما إذا كان كلاود فرونت يدعم العمل كوكيل عكسي لتطبيقنا بدلاً من سلة S3. أرى أنك تستخدم كلاود فرونت في ميتا، هل هناك أي إجراء خاص تقوم به لتشغيله، أم أن ديسكوس يتولى الأمر بالكامل؟
إذا قمت بفحص هذه الصفحة، ستلاحظ أننا نستخدم رابطين مختلفين لـ Cloudfront، لذا نطبق ما ذكرته أعلاه: توزيعين، أحدهما لشبكة CDN العادية والآخر لـ S3.
المشكلة المذكورة في عنوان المنشور الأصلي هي أن ملفات CSS تأتي من التطبيق بينما تأتي ملفات JS من S3. تحتاج إلى شبكة CDN تدرك مصدر كل أصل (asset) ويمكنها الوصول إلى المكان المطلوب، أو استخدام شبكتي CDN. وهذا هو السبب في وجود إعدادين مختلفين في النهاية.
رغم أن هذا يبدو منطقياً تماماً الآن بعد أن فهمت الأمر، إلا أنني لست متأكداً من أنه موثق. وقد تواجه مشاكل (على الأقل واجهتُ أنا ذلك!)، حيث تتطلب مهمة rake لنقل التحميلات إلى S3 وجود s3_cdn. وهذا يفسر سبب محاولتي عدة مرات لنقل الأشياء إلى S3 ثم التخلي عن الفكرة.
أعتقد أنه سيكون من الجيد وجود تحذير يقول شيئاً مثل: “يا رجل، لا يمكنك امتلاك CDN للأصول دون وجود CDN للوسائط.” في مكان ما.
حسناً، الآن فهمت ما تقصده، لم أكن أعرف أن هذا مطلوب. هل لي أن أسأل لماذا يجب أن يأتي CSS من التطبيق؟ لماذا لا يمكننا رفعه عبر مهمة rake s3:upload_assets؟
سأقوم ببعض البحث حول كيفية تحقيق ذلك على Cloudfront وسأضع نتائجي/العقبات التي أواجهها هنا.
حسنًا، ربما أشرح هذا بشكل سيء. يمكنك ذلك. لكن الأمر معقد كما تظهر مواضيعك وموضوعك الحالي.
الموقع الخاص بـ @eatcodetravel يعمل حاليًا مع تعيين S3_CDN فقط، لكنك تدخل في حالة غريبة حيث يتم تقديم CSS (الذي يعيق العرض) من خادمك بينما لا يتم تقديم الصور في المنشورات، وهو أمر غير منطقي.
لأن هناك ميزة “إدارة > تخصيص”. يمكن للأشخاص تغيير CSS من لوحة الإدارة. كما يتم تقديم مقتطفات JS المخصصة الموجودة في السمات من التطبيق حسب علمي.
تمكنت في النهاية من حل هذه المشكلة من خلال توفير توزيع Cloudfront ثانٍ يشير إلى خادم الويب، مع الاحتفاظ بالتوزيع الآخر فقط لـ S3. شكرًا لك @Falco على الملاحظات، لكنني أوافق على أن هذا يحتاج إلى توثيق بشكل أفضل قليلاً.
s”؟