ملخص
بعد إعادة تشغيل حاوية روتينية (إعادة تشغيل المضيف / docker restart)، يفشل nginx في البدء داخل حاوية app مع ظهور الخطأ التالي:
nginx: [emerg] unknown directive "brotli_static" in /etc/nginx/conf.d/discourse.conf:172
يؤدي هذا إلى تعطيل الموقع بالكامل (بدون أي بديل — حيث لا يربط nginx أبدًا بالموانئ 80/443) حتى يتم إصلاحه يدويًا.
البيئة
- الصورة الأساسية:
discourse/base:2.0.20260812-0036 - nginx:
1.26.3-3+deb13u7(حزمة Debian 13/trixie، وليدة مخصصة) - حزم
libnginx-mod-http-brotli-staticو-filterبإصدار 1.0.0~rc-6 مثبتة، وتوجد روابط رمزية في/etc/nginx/mods-enabled/*.conf(بأسطرload_moduleالصحيحة) وتشير إلى ملفات.soصالحة.
السبب الجذري
ملف /etc/nginx/nginx.conf (المملوك لحزمة nginx-common وغير معدّل) لا يحتوي على أمر include /etc/nginx/modules-enabled/*.conf;، لذا لا يتم تحميل وحدات Brotli المثبتة أبدًا — بينما لا يزال ملف discourse.conf (المولّد بواسطة قوالب Discourse) يُصدر brotli_static on; بافتراض أنها محمّلة.
لماذا لا يفشل فورًا؟
يتم إعادة تحليل الإعداد فقط عندما يعيد nginx الفعلي البدء (أو إعادة التشغيل). يمكن لحاوية مُعاد بناؤها حديثًا أن تعمل بشكل سليم لعدة أيام أو أسابيع حتى يحدث شيء يعيد تشغيل nginx (إعادة تشغيل المضيف، docker restart، نفاد الذاكرة، إلخ)، عندئذٍ يبدأ في الدخول في حلقة انهيار صامتة (بمعدل ~1 مرة/ثانية) دون أي استرداد تلقائي.
الحل المؤقت
أضف include /etc/nginx/modules-enabled/*.conf; كسطر أول في /etc/nginx/nginx.conf (سياق رئيسي، قبل events {}). تم تأكيد أن هذا يُعيد نجاح nginx -t والعمل العادي.
الطلب
هل يمكن للصورة الأساسية أن تقوم إما (أ) بإضافة هذا الأمر include إلى ملف nginx.conf الخاص بها، أو (ب) إزالة brotli_static/brotli من قالب discourse.conf المُشغّل إذا لم تعد حزمة nginx الخاصة بالتوزيع تدعم Brotli بشكل افتراضي؟