Pourquoi ai-je besoin de Nginx et de quelque chose comme Gunicorn?

Je cherche une réponse trop simplifiée à la question suivante. J'essaie de développer une compréhension fondamentale du fonctionnement de Nginx aux côtés de quelque chose comme Gunicorn.

Ai-je besoin de Nginx et de quelque chose comme Gunicorn pour déployer des applications Django sur Nginx?

Si oui, qu'est-ce qui gère réellement les requêtes HTTP?

Ps. Je ne veux pas utiliser Apache et mod_wsgi!

Trop simplifié: Vous avez besoin de quelque chose qui exécute Python, mais Python n'est pas le meilleur pour traiter tous les types de demandes.

[disclaimer: je suis un développeur de Gunicorn]

Moins simplifié: quel que soit le serveur d'application utilisé (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy), tout type de déploiement non trivial aura quelque chose en amont qui gérera les demandes que votre application Django ne devrait pas traiter. Des exemples triviaux de telles demandes servent des actifs statiques (images / css / js).

Il en résulte deux premiers niveaux de la "architecture à trois niveaux" classique. En d'autres termes, le serveur Web (Nginx dans votre cas) traitera de nombreuses demandes d'images et de ressources statiques. Les demandes devant être générées dynamiquement seront ensuite transmises au serveur d'applications (Gunicorn dans votre exemple). (En passant, le troisième des trois niveaux est la base de données)

Historiquement, chacun de ces niveaux était hébergé sur des machines distinctes (et il y aurait probablement plusieurs machines dans les deux premiers niveaux, c.-à-d.: 5 serveurs Web envoient des demandes à deux serveurs d'applications, qui interrogent à leur tour une seule base de données).

À l'ère moderne, nous avons maintenant des applications de toutes formes et de toutes tailles. Ce ne sont pas tous les projets de week-end ou les sites de petites entreprises qui ont réellement besoin de la puissance de plusieurs machines et qui fonctionnent sans problème sur une seule boîte. Cela a engendré de nouvelles entrées dans la gamme de solutions d'hébergement. Certaines solutions vont associer le serveur d'applications au serveur Web (Apache httpd + mod_wsgi, Nginx + mod_uwsgi, etc.). Et il n’est pas du tout inhabituel d’héberger la base de données sur le même ordinateur que l’une de ces combinaisons serveur Web / application.

Maintenant, dans le cas de Gunicorn, nous avons pris une décision spécifique (copie de la Licorne de Ruby) de séparer les éléments de Nginx tout en nous appuyant sur le comportement de proxy de Nginx. Plus précisément, si nous pouvons supposer que Gunicorn ne lira jamais les connexions directement à partir d’Internet, nous n’avons pas à nous inquiéter des clients lents. Cela signifie que le modèle de traitement pour Gunicorn est d'une simplicité embarrassante.

La séparation permet également à Gunicorn d’être écrit en Python pur, ce qui minimise les coûts de développement sans affecter de manière significative les performances. Cela permet également aux utilisateurs d’utiliser d’autres proxies (en supposant qu’ils tamponnent correctement).

En ce qui concerne votre deuxième question sur ce qui gère réellement la requête HTTP, la réponse simple est Gunicorn. La réponse complète est que Nginx et Gunicorn gèrent la demande. Fondamentalement, Nginx recevra la demande. S'il s'agit d'une demande dynamique (généralement basée sur des modèles d'URL), elle donnera cette demande à Gunicorn, qui la traitera, puis renverra une réponse à Nginx qui la renverra ensuite à l'original. client.

Donc en terminant, oui. Vous avez besoin à la fois de Nginx et de Gunicorn (ou quelque chose de similaire) pour un déploiement correct de Django. Si vous cherchez spécifiquement à héberger Django avec Nginx, alors je me renseignerais sur Gunicorn, mod_uwsgi et peut-être CherryPy en tant que candidats pour le côté Django.

J'ai aimé cette explication dans sa simplicité:

Nginx fera face au monde extérieur. Il servira les fichiers multimédia (images, CSS, etc.) directement à partir du système de fichiers. Cependant, il ne peut pas parler directement aux applications Django; il a besoin de quelque chose pour exécuter l'application, l'alimenter à partir du Web et renvoyer les réponses.

C'est le travail de Gunicorn. Gunicorn créera une socket Unix et transmettra les réponses à nginx via le protocole wsgi - la socket transmet les données dans les deux sens:

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

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

Je cherche une réponse trop simpliste ...

Ai-je besoin de Nginx et de quelque chose comme Gunicorn pour déployer des applications Django sur Nginx?

Si oui, qu'est-ce qui gère réellement les requêtes HTTP?

Réponse trop simplifiée:

OUI.

Nginx et Gunicorn.

Puisque vous déployez sur Nginx, vous avez évidemment besoin de Nginx.

Puisque vous déployez Django, qui est un framework Web, vous avez besoin de quelque chose qui jette un pont entre le serveur Web (Nginx) et le framework Web (Django). Dans le monde Python, une telle chose s'appelle un serveur WSGI (mais le pense comme un middleware), dont Gunicorn et uWSGI sont des exemples. Lors du traitement d'une requête, Nginx envoie un proxy à Gunicorn ou à uWSGI, qui appelle à son tour le code Django et renvoie la réponse.

Ce document et la réponse de Paul vous aideront à mieux l’apprendre.

Gunicorn est un gaspillage de ressources. Vous pouvez simplement transmettre par proxy à django écoutant sur un port au lieu d’exécuter gunicorn sur le dessus de django et encore nginx sur le dessus. Dans les repères, j'ai vu une augmentation de vitesse très notable. Nginx peut facilement gérer les demandes directes à Django. Gunicorn n'est rien d'autre qu'un survol (en fait un survol plus lent) au-dessus de la route normale. Il ne fait qu'asseoir et mange vos ressources et essaie de prétendre dynamiser votre site Web.

nginx met en mémoire tampon toutes les demandes et gère les demandes de fichiers statiques par lui-même (si vous l'avez configuré comme cela). Et envoie le contenu dynamique à un autre serveur (gunicorn / django).

Gunicorn n'a pas d'autre utilité que de simplement transmettre la demande à l'application. C'est comme une paille que vous pouvez boire directement dans un verre ou boire de la paille à un rythme limité (ici, la personne qui boit est un django). Et nginx est le serveur qui vous a apporté le verre de jus.

J'ai comparé et trouvé ceci - avec gunicorn: 22k req / s sans gunicorn: 34k req / s

Votre site aura besoin des req / s supplémentaires en forte charge.