¿Puede Django correr solo con Gunicorn (sin Apache o nginx)?

Question

He probado casi todos los tutoriales de django + nginx en la web y no puedo obtener un archivo de imagen para mostrar en la pantalla. Siempre es la vieja historia - PAGINA NO ENCONTRADA. La página web carga bien pero django.png en mi carpeta /static/ no. No estoy seguro si es un problema en settings.py o con nginx.

Estoy tan frustrado que me niego a mirar otro "Cómo obtener el tutorial nginx/django". Si despliego un sitio web en un futuro cercano, Gunicorn bastará para ejecutar un sitio de Django y servir archivos estáticos simultáneamente sin utilizar Apache o nginx. ¿Hay un gran beneficio de tener un proxy inverso en primer lugar?

Answer 1

Sí. Gunicorn puede servir tu estática también.

Si todo lo demás falla, y mucho Django lo haga por usted Para ello, sólo hay que añadir otro patrón de URL, de la siguiente manera (aunque, hacer esto como último recurso antes de la frustración.):

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

Si bien django serving static es mejor que no servirlo en absoluto, vale la pena delegar eso a los servidores optimizados para el mismo tipo de nginx.

Recomendaría ejecutar nginx en un puerto diferente para empezar, y cambiar la configuración django STATIC_URL para incluir el puerto (después de haber confirmado que el puerto atiende la estática). - Hacer esto es tan simple como hacer un enlace a MEDIA_ROOT desde la carpeta nginx.

Y si está usando nginx de todos modos, también es bueno realizar un proxy de todas las solicitudes que lo usan y solo pasar la solicitud django al gunicornio. Todo esto requiere es la adición de un archivo conf que le dice a nginx en consecuencia.

Veo cómo puede ser confuso para aquellos que están comenzando e intentando hacer todo (solicitudes de proxy, servir estáticos, configurar nginx) a la vez. Pruébalo uno por uno. Obtener los medios del gunicornio; Luego preséntala desde nginx y luego eventualmente tendrás el proxy nginx también. Pero haz todo esto antes de que tengas tu aplicación en producción. Este enfoque, he visto aumenta la comprensión y disminuye la frustración.

Answer 2

Si ya está utilizando Amazon web services, puede usar s3 buckets para alojar su contenido estático y desplegar su aplicación en ec2 usando gunicorn (o lo que quiera). De esta forma, no tiene que preocuparse por configurar su propio servidor de archivos estático.

documentación

Answer 3

El Gunicorn señala que sin un proxy tampón clientes lentos, el trabajador por defecto es susceptible a un ataque de denegación de servicio: http://gunicorn.org/deploy.html

Aunque hay muchos servidores proxy HTTP disponibles, se recomienda encarecidamente que utilice Nginx. Si elige otro servidor proxy, necesita , asegúrese de que almacena temporalmente los clientes lentos cuando usa trabajadores predeterminados de Gunicorn . Sin este almacenamiento en búfer, Gunicorn será fácilmente susceptible a ataques de denegación de servicio . Puede usar slowloris para verificar si su proxy se comporta correctamente.

Este podría no ser el caso cuando se utiliza uno de los trabajadores de asincronización como gevent o tornado.

Answer 4

He hecho utilizando un middleware Werkzeug.¿No es hermosa, ni performant como el uso de un servidor Nginx, pero cumple su cometido:

Conjunto STATIC_ROOT en settings.py

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

Que decir Werkzeug para servir archivos de esta carpeta

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

Cuando DEBUG = True, Django sirve los archivos. Cuando DEBUG = False, Werkzeug sirve archivos de la carpeta estática recopilada. Debe ejecutar collectstatic en el servidor que usa DEBUG = False para que esto funcione.

Obs: Por alguna razón, Werkzeug da 500 para archivos no encontrados, no 404. Es extraño, pero todavía funciona. Si sabes por qué, por favor comenta.

Answer 5

recomiendo el uso de Nginx delante por varias razones:

• mantenimiento o la página de error interno del servidor se pueden implementar fácilmente cuando gunicorn está abajo. Eso significa que siempre tendrá algo que responder si su servidor de aplicaciones no se está ejecutando.
• Como sugiere Gunicorn doc, no se detectan ataques HTTP como DOS.
• Es posible que desee implementar su propia estrategia de equilibrio de carga más adelante. Esto se volverá más importante para la ingeniería de lanzamiento a medida que su proyecto escala. Personalmente, encontré AWS ELB un poco poco fiable y estoy pensando en ello.

actualización:

También, por favor ver una respuesta bien escrito por un desarrollador Gunicorn:

Why do I need Nginx and something like Gunicorn?