Run Django aplicación a través de nginx + uwsgi en un subtrazado

Question

Quiero ejecutar un proyecto de prueba simple en un subdirectorio de alias en nuestro servidor de desarrollo. La configuración básica es un nginx con una ubicación que pasa todo en un subdirectorio a la aplicación wsgi.

Django, obviamente, no entiende que se ejecute en un subdirectorio de alias, que destruye por completo la generación de URL y de análisis.
No pude encontrar ninguna configuración similar a un prefijo en los documentos y mi google fu tampoco me ayudó mucho ... así que aquí estoy preguntando.

Lo único que encontré fue el FORCE_SCRIPT_NAME ajuste de los cuales al menos corrige la generación de URL. (Consulte: http://docs.webfaction.com/software/django/config.html#mounting-a-django-application-on-a-subpath)
Lamentablemente, esto no soluciona el análisis urlconf, aunque el sitio mencionado lo sugiere.

¿Es posible ejecutar una aplicación Django en un subdirectorio de alias y si es así, ¿cómo?

nginx config:

server { 
     location /fancyprojectname/static { 
       alias /srv/fancyprojectname/static; 
     } 

     location /fancyprojectname/ { 
       uwsgi_pass unix://var/run/uwsgi/app/fancyprojectname/socket; 
       include uwsgi_params; 
     } 
} 

Editar

Por lo tanto, el establecimiento de "uwsgi_param SCRIPT_NAME/fancyprojectname;" en la ubicación de nginx hace que FORCE_SCRIPT_NAME sea innecesario; por desgracia, la coincidencia de URL aún no funciona.

from django.conf.urls import patterns, include, url 

# Uncomment the next two lines to enable the admin: 
from django.contrib import admin 
admin.autodiscover() 

urlpatterns = patterns('', 
    # Uncomment the admin/doc line below to enable admin documentation: 
    # url(r'^admin/doc/', include('django.contrib.admindocs.urls')), 

    # Uncomment the next line to enable the admin: 
    url(r'^admin/', include(admin.site.urls)), 
) 

Lo que creo que lo que está sucediendo: Como la expresión regular administrador comienza con "^ admin" y la URL real es "fancyprojectname/admin /", Django puede no coincide con las direcciones URL correctamente, a pesar de que la SCRIPT_NAME es conjunto.

La solución

Por lo tanto, era de hecho un problema con SCRIPT_NAME.

El WSGI specification dice lo siguiente:

SCRIPT_NAME La parte inicial de la "ruta" de la URL de solicitud que corresponda al objeto de aplicación, por lo que la aplicación conoce su virtual "localización" . Puede ser una cadena vacía, si la aplicación corresponde a la "raíz" del servidor.

PATH_INFO El resto de la "ruta" de la URL de solicitud, que designa la "ubicación" virtual del objetivo de la solicitud dentro de la aplicación. Puede ser una cadena vacía, si la URL de la solicitud se dirige a la raíz de la aplicación y no tiene una barra diagonal.

Nginx no establece SCRIPT_NAME automáticamente, por lo que debe establecerse en cualquier caso. Luego, PATH_INFO está equivocado, porque en la configuración predeterminada Nginx establece esto en $ document_uri, que sería la URL completa.

"uwsgi_modifier1 30;" le dice a Nginx que configure UWSGI_MODIFIER_MANAGE_PATH_INFO, que a su vez le dice a UWSGI que quite el SCRIPT_NAME de PATH_INFO.

La combinación de estos valores parecen funcionar, como Django ahora puede generar y las URL de los partidos correctamente.

Answer 1

Esto es falso:

Django, obviamente, no entiende que se ejecute en un subdirectorio de alias, que destruye por completo la generación de URL y de análisis.

Django no entiende eso, y se ocupa de forma transparente. El servidor debería establecer SCRIPT_NAME: el hecho de que te encuentres utilizando FORCE_SCRIPT_NAME muestra que el problema radica en tu configuración de Nginx, en lugar de en Django.

Sospecho que el problema es el uso de location, en lugar de una directiva más adecuada. Desafortunadamente no soy un experto en Nginx/uwsgi. En Apache/mod_wsgi, que podría hacer esto:

WSGIScriptAlias /mysite /usr/local/django/mysite/apache/django.wsgi 

para contar mod_wsgi ese sitio comienza a mysite, en lugar de la raíz. Es casi seguro que hay un comando similar con nginx/uwsgi.

Answer 2

Si este bloque de ubicación Nginx funciona cuando se aloja el sitio Django en http://www.example.com/ (su dominio de base):

location/{ 
    uwsgi_pass unix:/tmp/fancyprojectname.socket; 
    include /etc/nginx/uwsgi_params; 
} 

entonces esto va a trabajar en http://www.example.com/subpath/ (un subtrazado en su dominio de base):

location /subpath { 
    uwsgi_pass unix:/tmp/fancyprojectname.socket; 
    uwsgi_param SCRIPT_NAME /subpath; # explicitly set SCRIPT_NAME to match subpath 
    uwsgi_modifier1 30; # strips SCRIPT_NAME from PATH_INFO (the url passed to Django) 
    include /etc/nginx/uwsgi_params; 
} 

... y no es necesario establecer FORCE_SCRIPT_NAME en la configuración de Django.

Referencias:

• comentarios y solución original de Strayer tal como fue anunciado en cuestión.
• https://uwsgi-docs.readthedocs.org/en/latest/Nginx.html
• https://www.python.org/dev/peps/pep-0333/ (especificación WSGI completo)