سؤال لماذا أحتاج Nginx وشيء مثل Gunicorn؟


أنا أبحث عن إجابة مبسّطة جدًا على السؤال التالي. أحاول بناء فهم أساسي لكيفية عمل Nginx بجانب شيء مثل Gunicorn.

هل أحتاج إلى كل من Nginx وشيء مثل Gunicorn لنشر تطبيقات Django على Nginx؟

إذا كان الأمر كذلك ، فما الذي يعالج طلبات HTTP؟

فرع فلسطين. لا أريد استخدام Apache و mod_wsgi!


182
2017-11-15 21:16


الأصل


Apache و mod_wsgi هي الطريقة الأكثر بسيطة لتنفيذ الجسر بين تطبيق django الخاص بك وطلبات http التي هي أيضا قادرة جدا في بيئة الإنتاج. بالنسبة للعديد من المطورين ، يعني هذا أن "Apache أفضل من nginx" إذا فعلوا ذلك ولكنهم يعرفون ذلك ، ولكن "Betamax أفضل من VHS" ، للأسف ، قواعد Dogma - MagicLAMP


الأجوبة:


مبسطة بشكل مفرط: تحتاج إلى شيء ينفذ بايثون ، لكن بايثون ليست هي الأفضل في التعامل مع جميع أنواع الطلبات.

[إخلاء المسؤولية: أنا مطور Gunicorn]

أقل تبسيطًا: بغض النظر عن خادم التطبيقات الذي تستخدمه (Gunicorn أو mod_wsgi أو mod_uwsgi أو cherrypy) ، فإن أي نوع من النشر غير العادي سيكون له شيء من المنبع يمكنه التعامل مع الطلبات التي لا ينبغي أن يتعامل معها تطبيق Django. أمثلة تافهة لهذه الطلبات تخدم الأصول الثابتة (الصور / css / js).

وينتج عن ذلك مستويين أساسيين من "العمارة الثلاث" الكلاسيكية. أي خادم الويب (Nginx في حالتك) سوف يتعامل مع العديد من طلبات الصور والموارد الثابتة. سيتم إرسال الطلبات التي تحتاج إلى توليد ديناميكيًا إلى خادم التطبيقات (Gunicorn في مثالك). (جانبا ، والثالث من المستويات الثلاثة هي قاعدة البيانات)

من الناحية التاريخية ، سيتم استضافة كل من هذه المستويات على أجهزة منفصلة (وسيكون هناك على الأرجح آلات متعددة في المستويين الأوليين ، أي: 5 خوادم ويب ترسل طلبات إلى خاديمين للتطبيق والتي بدورها تستعلم عن قاعدة بيانات واحدة).

في العصر الحديث لدينا الآن تطبيقات من جميع الأشكال والأحجام. ليس كل مشروع عطلة نهاية الأسبوع أو موقع الأعمال الصغيرة في الواقع يحتاج إلى حصانا من آلات متعددة ، وسوف تعمل بسعادة كبيرة على مربع واحد. وقد أدى ذلك إلى ظهور مداخل جديدة في مجموعة حلول الاستضافة. بعض الحلول سوف تتزوج خادم التطبيق إلى خادم الويب (Apache httpd + mod_wsgi ، Nginx + mod_uwsgi ، إلخ). وليس من غير المألوف على الإطلاق استضافة قاعدة البيانات على نفس الجهاز كواحدة من مجموعات خوادم الويب / التطبيقات هذه.

الآن في حالة غونيكورن ، اتخذنا قرارًا محددًا (النسخ من روبي يونيكورن) لإبقاء الأمور منفصلة عن Nginx مع الاعتماد على سلوك وكيل Nginx. على وجه التحديد ، إذا استطعنا افتراض أن Gunicorn لن يقرأ اتصالاته من الإنترنت مباشرة ، فلا داعي للقلق بشأن العملاء البطيئين. هذا يعني أن نموذج المعالجة لـ Gunicorn بسيط للغاية.

يسمح الفصل أيضًا بكتابة غونيكورن في بايثون نقية مما يقلل من تكلفة التطوير بينما لا يؤثر بشكل كبير على الأداء. كما يسمح للمستخدمين القدرة على استخدام البروكسيات الأخرى (على افتراض أنها المخزن المؤقت بشكل صحيح).

بالنسبة إلى سؤالك الثاني حول ما يعالج طلب HTTP ، فإن الإجابة البسيطة هي Gunicorn. الجواب الكامل هو كل من Nginx و Gunicorn التعامل مع الطلب. بشكل أساسي ، ستتلقى Nginx الطلب وإذا كان طلبًا ديناميكيًا (يعتمد بشكل عام على أنماط عنوان URL) ، فسيعطي ذلك الطلب إلى Gunicorn ، والذي سيعالجه ، ثم يعيد الرد إلى Nginx الذي يعيد توجيه الاستجابة إلى النسخة الأصلية عميل.

إذن ، في الختام ، نعم. أنت في حاجة إلى كل من Nginx و Gunicorn (أو شيء مماثل) لنشر Django المناسب. إذا كنت تبحث على وجه التحديد لاستضافة Django مع Nginx ، فحينئذٍ سأحقق في Gunicorn ، mod_uwsgi ، وربما CherryPy كمرشحين لجانب Django من الأشياء.


268
2017-11-15 21:49



شكرا لأخذ الوقت الكافي لكتابة إجابة مفصلة! أي قراءة الموصى بها على هذا "بنية الطبقة 3"؟ - a.m.
إجابة رائعة ، لكنني لا أفهم المشكلة مع العملاء البطيئين. - Mads Skjern
MadsSkjern أنا أخمن هنا ، ولكن إذا كنت تفترض أن جميع العملاء يتعاملون بسرعة ، فيمكنك استخدام مجموعة ثابتة من العمليات الخاصة بالعمال ، وليس من الضروري أن نرمز إلى الحالة التي يتم فيها حظر العديد منها أو كلها في انتظار العميل. - Jonathan Hartley
@صباحا. en.wikipedia.org/wiki/Multitier_architecture - Jonathan Hartley
بلدي التطبيق django يخدم فقط json أي محتوى ثابت يمكن أن اذهب فقط مع gunicorn وليس nginx - Sar009


اعجبت بهذا الشرح ببساطته:

ستواجه Nginx العالم الخارجي. سيخدم ملفات الوسائط (الصور ،   CSS ، وما إلى ذلك) مباشرة من نظام الملفات. ومع ذلك ، لا يمكن الحديث   مباشرة إلى تطبيقات Django ؛ انها تحتاج الى شيء من شأنه ان يدير   والتغذية التي تطلبها من الويب وعرض الردود.

هذا هو عمل (جانيكورن) سوف Gunicorn إنشاء مقبس يونيكس ، وخدم   الردود على nginx عبر بروتوكول wsgi - يمرر المحول البيانات في   كلا الاتجاهين:

The outside world <-> Nginx <-> The socket <-> Gunicorn

https://gist.github.com/Atem18/4696071


20
2017-12-13 07:52



لا يجب أن تكون مآخذ ، فقط في حالة يتساءل الآخرون. - akshay


أنا أبحث عن إجابة مبسّطة جدًا ...

هل أحتاج إلى كل من Nginx وشيء مثل Gunicorn لنشر تطبيقات Django على Nginx؟

إذا كان الأمر كذلك ، فما الذي يعالج طلبات HTTP؟

الإجابة المبسطة للغاية:

نعم فعلا.

كل من Nginx و Gunicorn.

نظرًا لأنك تقوم بالتوزيع على Nginx ، فإنك بالطبع بحاجة إلى Nginx.

نظرًا لأنك تقوم بنشر Django ، وهو إطار ويب ، فإنك تحتاج إلى شيء يربط بين خادم الويب (Nginx) وإطار الويب (Django). في عالم بايثون ، يُطلق على هذا الشيء اسم خادم WSGI (لكن أعتقد أنه مثل وسط) ، ومن الأمثلة على ذلك Gunicorn و uWSGI. عند التعامل مع طلب ما ، تقوم شركة Nginx بتوكيل الطلب إلى Gunicorn أو UWSGI ، والذي بدوره يستدعي رمز Django ويعيد الاستجابة.

هذا المستند وسوف يساعدك الجواب بول على تعلمها بشكل أفضل.


0
2017-10-26 21:42