Vraag Waarom heb ik Nginx en zoiets als Gunicorn nodig?


Ik ben op zoek naar een al te vereenvoudigd antwoord op de volgende vraag. Ik probeer een fundamenteel begrip op te bouwen van hoe Nginx werkt, samen met iets als Gunicorn.

Heb ik zowel Nginx als zoiets als Gunicorn nodig om Django-apps op Nginx te implementeren?

Zo ja, wat behandelt de HTTP-verzoeken dan eigenlijk?

Ps. Ik wil Apache en mod_wsgi niet gebruiken!


182
2017-11-15 21:16


oorsprong


Apache en mod_wsgi zijn de eenvoudigste manier om de brug te slaan tussen uw django-applicatie en http-verzoeken die ook zeer capabel zijn in een productieomgeving. Voor veel ontwikkelaars betekent dit 'Apache is beter dan nginx' als ze het wisten, maar als 'betamax is beter dan VHS', helaas, Dogma-regels - MagicLAMP


antwoorden:


Overdreven vereenvoudigd: je hebt iets nodig dat Python uitvoert, maar Python is niet de beste in het verwerken van alle soorten verzoeken.

[disclaimer: ik ben een Gunicorn-ontwikkelaar]

Minder vereenvoudigd: ongeacht welke app-server u gebruikt (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy) elke niet-triviale implementatie zal iets stroomopwaarts hebben dat de verzoeken behandelt die uw Django-app niet zou moeten verwerken. Triviale voorbeelden van dergelijke verzoeken zijn het dienen van statische activa (images / css / js).

Dit resulteert in twee eerste lagen van de klassieke "three tier architecture". Dat wil zeggen, de webserver (Nginx in uw geval) zal veel aanvragen voor afbeeldingen en statische bronnen afhandelen. Aanvragen die dynamisch moeten worden gegenereerd, worden vervolgens doorgegeven aan de toepassingenserver (Gunicorn in uw voorbeeld). (Terzijde, de derde van de drie lagen is de database)

Historisch gezien zou elk van deze lagen worden gehost op verschillende machines (en er zouden hoogstwaarschijnlijk meerdere machines zijn in de eerste twee lagen, dat wil zeggen: 5 webservers verzenden verzoeken naar twee app-servers die op hun beurt een enkele database bevragen).

In het moderne tijdperk hebben we nu toepassingen in alle soorten en maten. Niet elk project in het weekend of een bedrijf met kleine bedrijven heeft eigenlijk het vermogen van meerdere machines nodig en zal heel gelukkig op een enkele doos draaien. Dit heeft geleid tot nieuwe inzendingen in de reeks hostingoplossingen. Sommige oplossingen trouwen de app-server met de webserver (Apache httpd + mod_wsgi, Nginx + mod_uwsgi, enz.). En het is helemaal niet ongebruikelijk om de database op dezelfde machine te hosten als een van deze web / app-servercombinaties.

Nu, in het geval van Gunicorn, hebben we een specifieke beslissing genomen (kopie van Ruby's Unicorn) om dingen gescheiden te houden van Nginx terwijl ze vertrouwen op het proxiërende gedrag van Nginx. In het bijzonder, als we kunnen aannemen dat Gunicorn nooit rechtstreeks verbindingen van internet zal lezen, hoeven we ons geen zorgen te maken over trage clients. Dit betekent dat het verwerkingsmodel voor Gunicorn beschamend eenvoudig is.

Door de scheiding kan Gunicorn ook in pure Python worden geschreven, waardoor de ontwikkelkosten tot een minimum worden beperkt en de prestaties niet significant worden beïnvloed. Het biedt gebruikers ook de mogelijkheid om andere proxies te gebruiken (ervan uitgaande dat ze correct bufferen).

Wat betreft uw tweede vraag over wat het HTTP-verzoek daadwerkelijk behandelt, is het eenvoudige antwoord Gunicorn. Het complete antwoord is dat Nginx en Gunicorn het verzoek afhandelen. In principe zal Nginx het verzoek ontvangen en als het een dynamisch verzoek is (meestal gebaseerd op URL-patronen), dan zal het dat verzoek doorgeven aan Gunicorn, dat het zal verwerken, en dan een reactie terugsturen naar Nginx, die vervolgens het antwoord terugstuurt naar het origineel cliënt.

Dus tot slot, ja. Je hebt zowel Nginx als Gunicorn (of iets dergelijks) nodig voor een goede Django-inzet. Als je specifiek op zoek bent naar Django met Nginx, dan zou ik Gunicorn, mod_uwsgi en misschien CherryPy onderzoeken als kandidaten voor de Django-kant van de dingen.


267
2017-11-15 21:49



Bedankt dat je de tijd hebt genomen om zo'n gedetailleerd antwoord te schrijven! Elke aanbevolen lezing van deze "3-tier-architectuur"? - a.m.
Geweldig antwoord, maar ik begrijp het probleem niet met trage clients. - Mads Skjern
@MadsSkjern Ik gok het hier, maar als je aanneemt dat alle clients snel zijn, dan kun je een vaste pool van werkprocessen gebruiken, en niet hoeven te coderen voor het geval dat veel of alle geblokkeerd zijn in afwachting van een klant. - Jonathan Hartley
@ A.m. en.wikipedia.org/wiki/Multitier_architecture - Jonathan Hartley
mijn django-app dient alleen json geen statische inhoud kan ik gewoon gaan met gunicorn en geen nginx - Sar009


Ik vond deze uitleg leuk in zijn eenvoud:

Nginx zal de buitenwereld onder ogen zien. Het dient mediabestanden (afbeeldingen,   CSS, enz.) Rechtstreeks vanuit het bestandssysteem. Het kan echter niet praten   rechtstreeks naar Django-applicaties; het heeft iets nodig dat het   toepassing, feedaanvragen van het web en antwoorden terugsturen.

Dat is de taak van Gunicorn. Gunicorn zal een Unix-socket maken en serveren   reacties op nginx via het wsgi-protocol - de socket geeft de gegevens door   beide richtingen:

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

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


20
2017-12-13 07:52



Het hoeven geen sockets te zijn, voor het geval anderen zich afvragen. - akshay


Ik ben op zoek naar een overdreven vereenvoudigd antwoord ...

Heb ik zowel Nginx als zoiets als Gunicorn nodig om Django-apps op Nginx te implementeren?

Zo ja, wat behandelt de HTTP-verzoeken dan eigenlijk?

Al te vereenvoudigd antwoord:

JA.

Zowel Nginx als Gunicorn.

Omdat je op Nginx werkt, heb je natuurlijk Nginx nodig.

Omdat je Django, een webraamwerk, inzet, heb je iets nodig dat het gesprek tussen de webserver (Nginx) en het webraamwerk (Django) overbrugt. In de Python-wereld wordt zoiets een WSGI-server genoemd (maar denk dat het een soort middleware is), waarvan Gunicorn en uWSGI voorbeelden zijn. Bij het afhandelen van een verzoek, stemt Nginx het verzoek in met Gunicorn of uWSGI, die op zijn beurt de Django-code oproept en het antwoord retourneert.

Dit document en het antwoord van Paulus zal je helpen om het beter te leren.


0
2017-10-26 21:42