Kann Django alleine auf Gunicorn laufen (kein Apache oder Nginx)?

Question

Ich habe gerade über versucht, jeden django + nginx Tutorial auf dem Netz, und ich kann nicht eine Bilddatei auf dem Bildschirm angezeigt bekommen. Es ist immer die alte Geschichte - 404 Seite nicht gefunden. Die Web-Seite geladen wird gut, aber django.png in meinem /static/ Ordner nicht. Nicht sicher, ob es ein Problem in settings.py oder mit nginx ist.

Ich bin so frustriert es, dass ich an einem anderen suchen verweigern „Wie nginx/django Tutorial bekommen“. Wenn ich in naher Zukunft eine Website bereitstellen werde, wird Gunicorn ausreichen, um eine Django-Site zu betreiben und statische Dateien gleichzeitig zu bedienen, ohne Apache oder nginx zu benutzen? Hat es einen großen Vorteil, überhaupt einen Reverse-Proxy zu haben?

Answer 1

Ja. Gunicorn kann auch deinem Statik dienen.

Wenn alle Stricke reißen, lassen django es für Sie tun Um das zu tun, müssen Sie nur eine andere URL-Muster hinzufügen, wie folgt (obwohl, tun dies als letztes Mittel vor Frustration.):

urlpatterns = patterns('', 
    # ... the rest of your URLconf goes here ... 
) + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT) 

Während django serving static besser ist als gar nicht, es lohnt sich, das auf die für nginx optimierten Server zu delegieren.

Ich würde empfehlen, nginx auf einem anderen Port läuft mit, zu starten und die django STATIC_URL Einstellung zu ändern, den Hafen schließen (Nachdem Sie bestätigt haben, dass der Port die Statik dient). - Dies ist so einfach wie ein Simlink zum MEDIA_ROOT aus dem Nginx-Ordner.

Und wenn Sie sowieso nginx verwenden, ist es auch gut, alle Anfragen mit Proxy zu übernehmen und nur die Django-Anfrage an das Gunicorn zu übergeben. All dies erfordert das Hinzufügen einer conf Datei, die nginx entsprechend informiert.

Ich kann sehen, wie es für diejenigen, die starten und versuchen, alles zu tun (Proxy-Anfragen, statisch zu dienen, konfigurieren nginx) sofort verwirrend sein kann. Probieren Sie es nacheinander aus. Hol die Medien aus dem Gunicorn; Dann serviere es von Nginx und dann schließlich auch den Nginx-Proxy. Aber machen Sie das alles, bevor Sie Ihre App in Produktion haben. Dieser Ansatz, den ich gesehen habe, erhöht das Verständnis und verringert die Frustration.

Answer 2

Wenn Sie bereits Amazon Web Services verwenden, können Sie s3 Eimer benutzen, um Ihre statische Inhalte zu hosten und verteilen Ihre Anwendung EC2 gunicorn (oder was auch immer Sie möchten). Auf diese Weise müssen Sie sich keine Gedanken darüber machen, Ihren eigenen statischen Dateiserver einzurichten.

Answer 3

Die Gunicorn Dokumentation stellt fest, dass ohne einen Proxy-Pufferung langsam Kunden, die Standard-Arbeiter zu einem Denial-of-Service-Angriff anfällig ist: http://gunicorn.org/deploy.html

Obwohl es viele HTTP-Proxies zur Verfügung stehen, wir dringend empfohlen, dass Sie verwenden Nginx. Wenn Sie einen anderen Proxy-Server müssen Sie wählen, um stellen Sie sicher, dass es langsam Kunden puffert, wenn Sie die Standard Gunicorn Arbeiter verwenden. Ohne diese Pufferung ist Gunicorn leicht anfällig für Denial-of-Service-Attacken auf . Sie können slowloris verwenden, um zu überprüfen, ob sich Ihr Proxy ordnungsgemäß verhält.

Dies ist möglicherweise nicht der Fall, wenn einer der asynchronen Worker wie gevent oder tornado verwendet wird.

Answer 4

habe ich mit einer Werkzeug Middleware gemacht.Ist das nicht schön, noch performant wie ein nginx-Server verwenden, aber es erfüllt seinen Zweck:

Set STATIC_ROOT auf settings.py

# project/settings.py 
import os 
BASE_DIR = os.path.dirname(os.path.dirname(__file__))) 
STATIC_ROOT = BASE_DIR+'/static-collected' 

als Werkzeug sagen Dateien aus diesem Ordner dienen

# project/wsgi.py 
import os 
BASE_DIR = os.path.dirname(os.path.dirname(__file__)) 

(...) 
from django.core.wsgi import get_wsgi_application 
application = get_wsgi_application() 
(...) 

import os 
from werkzeug.wsgi import SharedDataMiddleware 
print 'Installing WSGI static files server middleware' 
application = SharedDataMiddleware(application, { 
    '/static': os.path.join(BASE_DIR, 'static-collected'), 
}) 

Wenn DEBUG = True ist, dienen Django die Dateien. Wenn DEBUG = False, liefert Werkzeug Dateien aus dem statisch gesammelten Ordner. Sie müssen Collectstatic auf dem Server ausführen, der DEBUG = False verwendet, damit das funktioniert.

Obs: Aus irgendeinem Grund gibt Werkzeug 500 für nicht gefundene Dateien, nicht 404. Es ist seltsam, aber immer noch funktioniert. Wenn Sie wissen warum, bitte Kommentar.

Answer 5

Ich empfehle Nginx vor aus mehreren Gründen mit:

• Wartung oder interne Serverfehlerseite kann einfach implementiert werden, wenn gunicorn unten ist. Das bedeutet, dass Sie immer etwas zu reagieren haben, wenn Ihr Anwendungsserver nicht läuft.
• Wie Gunicorn doc schlägt, http-Angriffe wie DOS werden nicht erkannt.
• Möglicherweise möchten Sie später eine eigene Lastenausgleichsstrategie implementieren. Dies wird für das Release-Engineering wichtiger, wenn Ihr Projekt skaliert wird. Persönlich habe ich AWS ELB ein bisschen unzuverlässig gefunden und ich denke darüber nach.

Update:

Lesen Sie bitte auch eine gut schriftliche Antwort von einem Gunicorn Entwickler:

Why do I need Nginx and something like Gunicorn?