Can Django può correre solo su Gunicorn (no Apache o nginx)?

Question

Ho provato praticamente tutti i tutorial di django + nginx sul Web e non riesco a visualizzare sullo schermo un file di immagine. È sempre la vecchia storia - 404 PAGE NOT FOUND. La pagina web si carica bene ma django.png nella mia cartella /static/ no. Non sono sicuro se si tratta di un problema in settings.py o con nginx.

Sono così frustrato con esso che mi rifiuto di guardare un altro "Come ottenere tutorial nginx/django". Se distribuisco un sito Web nel prossimo futuro, Gunicorn è sufficiente per eseguire un sito Django e servire file statici contemporaneamente senza utilizzare Apache o nginx? In primo luogo, c'è un grande vantaggio nell'avere un proxy inverso?

Answer 1

Sì. Gunicorn può anche servire la tua staticità.

Se tutto il resto fallisce, lascia Django fanno per voi Per fare questo, basta aggiungere un altro modello di URL, come segue (anche se, fare questo come ultima risorsa prima di frustrazione.):

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

Mentre django serve statico è meglio che non servirlo affatto, vale la pena di delegarlo ai server ottimizzati per lo stesso tipo di nginx.

Si consiglia di eseguire nginx su una porta diversa per iniziare e modificare l'impostazione di STD_URL django per includere la porta (dopo aver confermato che la porta serve le statistiche). - Fare questo è semplice come fare un simlink a MEDIA_ROOT dalla cartella nginx.

E se si utilizza comunque nginx, è anche utile eseguire il proxy di tutte le richieste che lo utilizzano e solo passare la richiesta di django al gunicorn. Tutto ciò richiede l'aggiunta di un file conf che nomini di conseguenza nginx.

Posso vedere come può essere fonte di confusione per chi sta iniziando e sta provando a fare tutto (richieste proxy, servire statico, configurare nginx) in una volta. Provalo uno per uno. Prendi i media dal gunicorn; Quindi servitelo da nginx e poi eventualmente anche il proxy nginx. Ma fai tutto prima di avere la tua app in produzione. Questo approccio, ho visto aumenta la comprensione e diminuisce la frustrazione.

Answer 2

Se si utilizzano già servizi Web Amazon, è possibile utilizzare i bucket s3 per ospitare il contenuto statico e distribuire l'app su ec2 utilizzando gunicorn (o qualsiasi altra cosa si desideri). In questo modo, non devi preoccuparti di configurare il tuo file server statico.

documentazione

Answer 3

Il Gunicorn osserva che senza un proxy di buffering client lenti, il lavoratore di default è suscettibile di un attacco denial of service: http://gunicorn.org/deploy.html

Anche se ci sono molti proxy HTTP disponibili, vi consigliamo vivamente che si utilizza nginx. Se si sceglie un altro server proxy, è necessario impostare in modo che esegua il buffering dei client lenti quando si utilizzano i lavoratori Gunicorn predefiniti. Senza questo buffering Gunicorn sarà facilmente vulnerabile agli attacchi denial-of-service . È possibile utilizzare slowloris per verificare se il proprio proxy si comporta correttamente.

Questo potrebbe non essere il caso quando si utilizza uno dei lavoratori asincroni come gevent o tornado.

Answer 4

Ho realizzato utilizzando un middleware Werkzeug.Non è bello, non performante come l'utilizzo di un server nginx, ma non il lavoro:

Set STATIC_ROOT su settings.py

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

che dire Werkzeug per servire i file da questa cartella

# 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'), 
}) 

Quando DEBUG = True, Django serve i file. Quando DEBUG = False, Werkzeug serve i file dalla cartella raccolta staticamente. È necessario eseguire collectstatic sul server che utilizza DEBUG = False affinché funzioni.

Obs: per qualche motivo, Werkzeug fornisce 500 per file non trovati, non 404. È strano, ma funziona comunque. Se sai perché, per favore commenta.

Answer 5

mi consiglia di utilizzare Nginx di fronte per diversi motivi:

• manutenzione o la pagina di errore interno del server possono essere facilmente implementate quando gunicorn è giù. Ciò significa che avrai sempre qualcosa da rispondere se il tuo server delle applicazioni non è in esecuzione.
• Come suggerisce Gunicorn doc, gli attacchi http come DOS non vengono rilevati.
• In seguito è possibile implementare la propria strategia di bilanciamento del carico. Questo diventerà più importante per l'ingegneria di rilascio man mano che il progetto si ridimensiona. Personalmente, ho trovato AWS ELB un po 'inaffidabile e ci sto pensando.

Aggiornamento:

Inoltre, si prega di vedere una risposta ben scritto da uno sviluppatore Gunicorn:

Why do I need Nginx and something like Gunicorn?