Caddy أمام Nginx للتطبيق عبر Docker Compose

الدعم تثبيت
,
1

لقد قمت بترقية أحد خوادم منتديات Discourse الخاصة بي، وذلك للسماح بفتح منفذ UDP 443 بدلاً من TCP فقط في جدار الحماية الخاص بلوحة تحكم IONOS Cloud (أنا من المملكة المتحدة).

لا أستخدم شبكة توصيل المحتوى (CDN) لأن هذا المنتدى المحدد لا يضم عدداً كبيراً من المستخدمين، لكنه يحتوي على العديد من الفئات.

واجهت بعض الصعوبات في ضمان عمل التصفية الجغرافية للعناوين IP عبر nginx بشكل صحيح، وأداء المنتدى جيد الآن دون أي مشاكل في /logs.

لقد قمت بإعداد تدوير سجلات البروكسي باستخدام Docker Compose، وأقدّر حقيقة أن Caddy يقوم بإخفاء تلقائي للحقول الحساسة في سجلات البروكسي، وهو أمر لم ألاحظه حقاً مع Nginx من قبل. على الرغم من أنني أتذكر فقط استخدام سجلات البروكسي مرتين خلال العامين اللذين استخدمت فيه Discourse في بيئة الإنتاج.

أتمنى معرفة مدى الاهتمام الذي قد يثار إذا نشرت دليلاً يشرح الأوامر التي نفذتها، وما حدث عند تشغيلها، للانتقال من دليل تثبيت Docker للمبتدئين إلى المنتدى الحالي الأكثر توافقاً مع الأجهزة المحمولة - يمكنني تضمين أوامر للصيانة المستقبلية، أي ترقية Caddy إلى إصدار أحدث، لكنني لم أجرب هذه الأوامر على خادم VPS الخاص بي في IONOS L بعد.

2

للعلم، يوجد هذا الطلب: Add Caddy web server template as nginx alternative - Pull Request #952 - discourse/discourse_docker - GitHub

3

شكرًا لك، لم أكن قد رأيت طلب الدمج (PR) هذا. الأمر مثير للاهتمام - إعدادي مختلف قليلاً في أنني أبقيت على خادم الويب Nginx الخاص بـ Discourse كما هو، وأقوم بتشغيل Caddy بشكل منفصل في Docker Compose أمامه، وذلك بشكل أساسي لتوفير HTTP/3 على الحافة.

هناك تغيير صغير على جانب Discourse: أضفت نقطة ربط دائمة في ملف app.yml بحيث يستخدم Nginx قيمة X-Forwarded-For الخاصة بـ Caddy لتحديد عنوان IP الحقيقي للعميل عند وصول الطلبات عبر المقبض Unix. كنت بحاجة في البداية إلى حل بديل باستخدام X-Real-IP في Caddy، ولكن بعد إضافة الإصلاح على جانب Nginx، تمكنت من إزالة ذلك والتحقق من أن Discourse لا يزال يسجل عنوان IP الصحيح للعميل.

كما قمت بتعطيل QUIC 0-RTT/البيانات المبكرة صراحةً في تكوين Caddy مع الإبقاء على تمكين HTTP/3، لتجنب حالة الحافة الإضافية المتعلقة بالبيانات المبكرة.

يتمكين نهجي أيضًا من تسجيل الوصول إلى HTTP في Caddy على مستوى الموقع، مما يمنحني التخفي الافتراضي للرؤوس الحساسة للمصادقة في Caddy. أقوم بتدوير سجلات json-file الناتجة في Docker عند حجم 25 ميجابايت × 3. لاحظت أن طلب الدمج (PR) الحالي يحتوي على كتلة تدوير السجلات في الخيارات العامة لـ Caddy، وهو ما تصفه وثائق Caddy بأنه تكوين للسجلات التشغيلية بدلاً من سجلات الوصول إلى HTTP.

لذا، فهو ليس تثبيتًا قياسيًا غير مستوعب تمامًا، ولكنه أيضًا نهج مختلف عن استبدال Nginx بـ Caddy بالكامل.

سألقي نظرة فاحصة على طلب الدمج (PR) هذا. في الوقت الحالي، أنا مهتم بشكل أساسي بمعرفة ما إذا كان هناك اهتمام كافٍ بهذا النهج لجعل دليل خطوة بخطوة يستحق الجهد، بدلاً من البدء في إنشاء واحد على الفور.

4

مجرد تصحيح/توضيح لما قلته أعلاه.

عندما وصفت النتيجة في البداية على أنها:

منتدى أكثر ملاءمة للأجهزة المحمولة، كان جزءًا مما لاحظته أن الرحلة ذهابًا وإيابًا الأولية عند فتح تطبيق الويب التقدمي (PWA) في متصفح iOS Safari كانت تبدو بطيئة جدًا في السابق.

ومع ذلك، أعتذر الآن عن تضمين هذا البيان في ردي اللاحق:

كان تعطيل 0-RTT شيئًا حاولته أثناء تشخيص مشكلة عنوان IP للعميل، لكنه لا يبدو ضروريًا. استمرت كلتا خطأي PostgreSQL المتعلقتين بـ unix: بينما كان 0rtt off مكونًا بالفعل.

كان التغيير الذي يبدو أنه حل هذه الأخطاء بدلاً من ذلك هو الخطاف المستمر في app.yml الذي يعدل nginx بحيث يستخدم قيمة X-Forwarded-For من Caddy كعنوان IP الحقيقي للعميل عندما تصل الطلبات عبر المقبس Unix.

لذلك، أزلت الآن إعداد 0rtt off واستعدلت السلوك الافتراضي لـ Caddy. لا يزال HTTP/3 يعمل، ويستمر عنوان IP الصحيح للعميل في المرور إلى Discourse.

لذا، إذا كان هناك اهتمام كافٍ في النهاية لأقوم بوضع دليل خطوة بخطوة، فلن أتضمن تعطيل QUIC 0-RTT كجزء مطلوب من التكوين.

5

يمكنك أيضًا القيام بذلك باستخدام Nginx الأساسي: https://quic.nginx.org/

6

شكرًا لك - لقد قمت بفحص nginx المضمن حاليًا داخل حاوية app الخاصة بـ Discourse، وأنت على حق في أنه يمكنه توفير HTTP/3 مباشرةً:

nginx 1.26.3-3+deb13u7
OpenSSL 3.5.6
--with-http_v3_module

لذلك، فإن استخدام HTTP/3 مباشرةً من nginx الموجود في Discourse بديل حقيقي بالفعل.

إحدى الأسباب التي قد تجعلني أفضل Caddy لهذا الإعداد الخاص هي ميزة 0-RTT. بعد تصحيح ما ذكرته أعلاه، أعيدت تفعيل سلوك QUIC 0-RTT الافتراضي في Caddy، ولاحظت تحسنًا ملحوظًا في تجربة التحميل التي كنت أحاول تحسينها في PWA على Safari لنظام iOS.

وفقًا لما يمكنني استنتاجه من وثائق nginx، لا يمكن لإصدارات nginx السابقة لـ 1.29.1 تفعيل 0-RTT عند بناؤها مع OpenSSL، بغض النظر عن إعداد ssl_early_data، لذا فإن nginx 1.26.3 الموجود حاليًا في حاوية Discourse الخاصة بي يمكنه دعم HTTP/3 ولكنه لا يدعم هذا التحسين المحدد.

لذلك، أنا مهتم بمقارنة النهجين بدلاً من افتراض أن Caddy ضروري فقط من أجل HTTP/3.