Je cherche une réponse trop simplifiée à la question suivante. J'essaie d'acquérir une compréhension fondamentale du fonctionnement de Nginx avec quelque chose comme Gunicorn.
Ai-je besoin de Nginx et de quelque chose comme Gunicorn pour déployer des applications Django sur Nginx ?
Si c'est le cas, qu'est-ce qui gère réellement les demandes HTTP ?
Ps. Je ne veux pas utiliser Apache et mod_wsgi !
Simplifié à l'extrême : 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 que vous utilisez (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy), tout déploiement non trivial aura quelque chose en amont qui traitera les requêtes que votre application Django ne devrait pas traiter. Des exemples triviaux de telles requêtes sont le service de ressources statiques (images/css/js).
Il en résulte deux premiers niveaux de l'"architecture à trois niveaux" classique. Le serveur web (Nginx dans votre cas) traitera de nombreuses demandes d'images et de ressources statiques. Les requêtes qui doivent être générées dynamiquement seront ensuite transmises au serveur d'application (Gunicorn dans votre exemple). (Pour l'anecdote, le troisième des trois niveaux est la base de données).
Historiquement, chacun de ces niveaux serait hébergé sur des machines distinctes (et il y aurait très probablement plusieurs machines dans les deux premiers niveaux, c'est-à-dire : 5 serveurs web envoient des requêtes à deux serveurs d'applications qui à leur tour interrogent une seule base de données).
À l'ère moderne, nous disposons d'applications de toutes formes et de toutes tailles. Tous les projets du week-end ou les sites de petites entreprises n'ont pas besoin de la puissance de plusieurs machines et peuvent fonctionner sans problème sur une seule machine. Cela a donné naissance à de nouvelles entrées dans la gamme des solutions d'hébergement. Certaines solutions marient le serveur d'applications au serveur web (Apache httpd + mod_wsgi, Nginx + mod_uwsgi, etc). Il n'est pas rare que la base de données soit hébergée sur la même machine que l'une de ces combinaisons serveur web/application.
Dans le cas de Gunicorn, nous avons pris la décision spécifique (en copiant Unicorn de Ruby) de garder les choses séparées de Nginx tout en s'appuyant sur le comportement de proxy de Nginx. Plus précisément, si nous pouvons supposer que Gunicorn ne lira jamais de connexions directement depuis l'internet, alors nous n'avons pas à nous soucier des clients qui sont lents. Cela signifie que le modèle de traitement de Gunicorn est d'une simplicité embarrassante.
Cette séparation permet également à Gunicorn d'être écrit en Python pur, ce qui minimise les coûts de développement tout en n'ayant pas d'impact significatif sur les performances. Elle permet également aux utilisateurs d'utiliser d'autres proxies (en supposant qu'ils utilisent correctement le buffer).
En ce qui concerne votre deuxième question sur ce qui traite réellement la requête HTTP, la réponse simple est Gunicorn. La réponse complète est que Nginx et Gunicorn gèrent tous deux la requête. En fait, Nginx reçoit la requête et s'il s'agit d'une requête dynamique (généralement basée sur des modèles d'URL), il la transmet à Gunicorn, qui la traite et renvoie une réponse à Nginx, qui la retransmet ensuite au client d'origine.
En conclusion, 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 j'étudierais Gunicorn, mod_uwsgi, et peut-être CherryPy comme candidats pour le côté Django.
J'ai apprécié la simplicité de cette explication :
Nginx fera face au monde extérieur. Il servira les fichiers multimédias (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 qui exécute l'application, l'alimente et l'utilise. il a besoin de quelque chose qui exécute l'application, lui envoie des requêtes depuis le web, et renvoie des réponses.
C'est le travail de Gunicorn. Gunicorn créera un socket Unix, et servira réponses à nginx via le protocole wsgi - le socket transmet les données dans données dans les deux sens :
The outside world <-> Nginx <-> The socket <-> Gunicorn
Je cherche une réponse trop simplifiée...
Ai-je besoin à la fois de Nginx et de quelque chose comme Gunicorn pour déployer des applications Django sur Nginx ?
Dans l'affirmative, qu'est-ce qui traite les demandes HTTP ?
Réponse trop simplifiée :
OUI.
Nginx et Gunicorn.
Puisque vous déployez sur Nginx, vous avez bien sûr besoin de Nginx.
Puisque vous déployez Django, qui est un framework web, vous avez besoin de quelque chose qui fasse le lien entre le serveur web (Nginx) et le framework web (Django). Dans le monde Python, une telle chose est appelée un serveur WSGI (mais pensez-y comme un middleware), dont les exemples incluent Gunicorn et uWSGI. Lors du traitement d'une requête, Nginx transmet la requête à Gunicorn ou uWSGI, qui à son tour appelle le code de Django et renvoie la réponse.
Ce document et la réponse de Paul vous aidera à mieux l'apprendre.
Gunicorn est un gaspillage de ressources. Vous pouvez simplement passer par un proxy vers django écoutant sur un port au lieu de faire tourner gunicorn au-dessus de django et encore nginx au-dessus de tout cela. Dans les benchmarks, j'ai vu une augmentation de vitesse très perceptible. Nginx peut facilement gérer les requêtes directes vers django. Gunicorn n'est rien d'autre qu'un survol (en fait un survol plus lent) au-dessus de la route normale. Il se contente de s'asseoir, de manger vos ressources et d'essayer de prétendre qu'il alimente votre site web.
nginx met en mémoire tampon toutes les requêtes et gère lui-même les requêtes de fichiers statiques (si vous l'avez configuré de la sorte). Et il transmet tout le contenu dynamique à un autre serveur (gunicorn/django).
Gunicorn n'a pas d'autre utilité que de transmettre la requête à l'application. C'est comme une paille que l'on peut boire directement dans le verre ou boire à la paille à un rythme limité (ici la personne qui boit est django). Et nginx est le serveur qui vous apporte le verre de jus de fruit.
J'ai fait une analyse comparative et j'ai trouvé ceci - avec gunicorn : 22k req / s sans gunicorn : 34k req / s
Votre site aura besoin des req/s supplémentaires en cas de forte charge.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
1 votes
Apache et mod_wsgi est la manière la plus simple d'implémenter le pont entre votre application django et les requêtes http, qui est également très performante dans un environnement de production. Pour de nombreux développeurs, cela signifie que "Apache est meilleur que nginx" s'ils ne le savaient pas, mais comme "betamax est meilleur que VHS", hélas, c'est le dogme qui prévaut.