لم يتم العثور على الملف في المتجر الموجود على الرابط: //s3-bucket/prefix/file.jpeg

تثبيت
1

أنا حاليًا في طور إعداد صورة Docker الرسمية على AWS ECS.
أثناء التشغيل على EC2، تعمل صورة Docker بشكل جيد للغاية.

ولكن بعد تشغيلها على ECS بنفس التكوين، أنتهي بصور رمزية معطوبة.

أخطاء ذات صلة:

تعذر العثور على الملف في المخزن الموجود على العنوان: //x-dev-xx-xxx-x.s3.dualstack.eu-central-1.amazonaws.com/original/1X/761c151e2d0ebedff3330dc6ec7a27050fef43f9.jpeg

و

فشل في معالجة الاستجابة المختطفة بشكل صحيح: FinalDestination::SSRFDetector::LookupFailedError: FinalDestination: فشل البحث

الملف موجود في الحاوية وحقوق الوصول هي نفسها كما في مثيل EC2.

هل يمكن لأحد أن يوجهني إلى أين يمكنني التعمق والعثور على السبب الجذري؟

شكرًا

2

هل قمت ببناء صورة باستخدام المشغل (launcher) ودفع الصورة إلى مستودع؟ وهل تقوم بتشغيلها بنفس البيئة التي يستخدمها المشغل؟

3

نعم. أستخدم متغيرات البيئة التي ينشئها الأمر run-cmd. لم أتمكن من اكتشاف خطأ حتى الآن.
للأسف، لم أتمكن من العثور على أمثلة لـ ECS لـ Discourse حتى الآن.

4

أنت على المسار الصحيح، ولكن من الصعب ترحيل الحامل وتحميل الأصول. لست متأكدًا من المشكلة.

5

لقد وجدت السبب الجذري. بسبب إعدادي لمكون Discourse AI الإضافي، قمت بإضافة منطقة خاصة (Private Zone) إلى VPC لجعل الخدمات المتنوعة متاحة داخليًا في VPC.

عند تشغيل Discourse على مثيل EC2 في حاوية Docker، تحصل الحاوية على اسم مضيف مثل 12-34-56-78-app. ومع ذلك، عند التشغيل كمهمة ECS، لا يمكنك تعيين اسم المضيف عند استخدام وضع awsvpc، ولا يمكنك تكوين نطاق البحث DNS. يؤدي هذا إلى اختلاف تحليل DNS على ECS، وفي حالتي، إضافة نطاق بحث مثل xxxx.internal.

بعد البحث، وجدت باستخدام tcpdump أن Discourse يحاول تحليل اسم النطاق المؤهل بالكامل (FQDN) الخاص به كجزء من فحوصات SSRF. إذا فشل هذا، يفشل الفحص. كخطأ لاحق، يفشل الاستدعاء إلى S3 برسالة الخطأ المضللة المذكورة أعلاه.

كان الإصلاح في حالتي هو إضافة سجل FQDN، وهو اسم مستعار لتوزيع Cloudfront الخاص بي، إلى منطقة DNS الخاصة بي.

إعجابَين (2)
6

رائع. هذا تصحيح جيد للأخطاء! ولهذا السبب هذا تثبيت غير مدعوم! لا يوجد الكثير مما يمكن تخمينه!

إعجاب واحد (1)
7

في النهاية، الأمر كالمعتاد: إذا لم ينجح الأمر، فهو دائمًا DNS :joy:

8

مرحباً @nodomain،
لقد واجهت نفس الخطأ تمامًا كما في مشاركتك أدناه. الطلب إلى صورة المستخدم الرمزية على سبيل المثال https://example.com/user_avatar/example.com/myself/96/215_2.png يستجيب بـ 500. في حالتي، لم يتم إعداد اسم النطاق example.com في نظام أسماء النطاقات العام، في مرحلة الاختبار، أقوم بانتحال اسم النطاق example.com في ملف المضيف الخاص بي محليًا. هل لن تظهر هذه المشكلة عندما يتم إعداد اسم النطاق example.com في نظام أسماء النطاقات العام؟