execstart - Ejecución de Django con Gunicorn-Best Practice

restart gunicorn

Question

Hay 3 formas de ejecutar una aplicación django con gunicorn:

1. Estándar gunicorn + wsgi ( ref django doc )

   gunicorn project.wsgi:application

2. Uso de la integración django gunicorn (ref gunicorn doc y django doc ):

   python manage.py run_gunicorn

3. Usando el comando gunicorn_django (ref gunicorn doc )

   gunicorn_django [OPTIONS] [SETTINGS_PATH]

La documentación de Django sugiere usar 1., que ni siquiera está listado como una opción en la documentación de Gunicorn.

¿Existe alguna práctica recomendada sobre la mejor manera de ejecutar una aplicación django con gunicorn, y cuáles son las ventajas / desventajas previsibles de estas diferentes soluciones?

Echando un vistazo al código de gunicorn, parece que prácticamente todos hacen lo mismo: 2. parece estar creando una aplicación wsgi utilizando los elementos internos de django, y 3. utiliza 2.

Si ese es el caso, ni siquiera entendería cuál es la razón para no usar simplemente "1". todo el tiempo, especialmente desde que un archivo wsgi.py se ha creado automáticamente desde django 1.4; Si eso es cierto, tal vez simplemente debería sugerirse una mejora de la documentación ...

Además, la mejor práctica para la configuración de Gunicorn con django sería genial. Usando 1., ¿tiene sentido establecer algunos valores predeterminados en el archivo wsgi y evitar configuraciones adicionales?

Referencias:

1. ¿Debo usar la integración django-gunicorn o wsgi? solo concierne a las opciones 1. y 3., no hay ninguna pista para la configuración y la respuesta no tiene fundamento
2. Implementar Django con gunicorn y nginx proporciona información más amplia pero no está estrictamente relacionado ni responde a esta pregunta
3. Django Gunicorn wsgi sobre la versión "4", que está lanzando gunicorn -c configfile y configfile apuntará a django_settings a django
4. Django WSGI y Gunicorn son un poco confusos :) mezclando 1. y 3. Por supuesto que wsgi.py se usa solo con 1.

Answer 1

Después de revisar yo diría que la mejor manera es usar gunicorn + wsgi

$ gunicorn project.wsgi:application

Ahora está confirmado en gunicorn docs: si ejecuta Django 1.4 o una versión más reciente, se recomienda simplemente ejecutar su aplicación con la interfaz WSGI usando el comando gunicorn y django como se vinculó anteriormente .

También evita agregar gunicorn como aplicación instalada, lo que significa que no es un requisito instalar gunicorn para probar su aplicación, lo que podría ser útil de vez en cuando.

Acerca de la configuración

El archivo de configuración de Django que se va a usar se puede pasar a través de una variable ENV o se puede personalizar en el archivo wsgi.py A veces creo varios archivos wsgi.py si tengo varias configuraciones (por ejemplo, varios sitios web) que tienen que ejecutarse desde el mismo proyecto. Consulte Django Doc para obtener más información.

Una solución de una sola línea que no requiere ningún archivo nuevo del comentario de Carl :

DJANGO_SETTINGS_MODULE=project.settings.prod gunicorn project.wsgi:application

suena como una forma mejor (aunque probablemente termine escribiéndolo en algunos comandos de shell para que sea más fácil de "recordar").

La configuración de Gunicorn se puede pasar como -c settings_file , pero estoy explorando otras formas e intentaré actualizar esta respuesta si encuentro alguna. Usar variables de entorno parece un trabajo duro, pero solo para casos limitados

En particular, sería bueno obtener / compartir algunas configuraciones entre django y gunicorn; La documentación de Gunicorn dice:

Actualmente, solo las aplicaciones Paster tienen acceso a configuraciones específicas del marco. Si tiene ideas para proporcionar configuraciones a las aplicaciones WSGI o para obtener información de settings.py de Django, puede abrir un problema para informarnos.

( Actualización : no he encontrado ninguna forma más inteligente, pero después de todo, las variables env son suficientes para mis casos más comunes).

Answer 2

Encontró una solución que funciona tanto para manage.py (en la máquina local) como con gunicorn

crear un archivo que tiene todas las cosas evniroment

# mysite/settings/set_env.py

import os

_environment = os.getenv(''environment'', None)
if _environment == "production":
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings.production")
elif _environment == "development":
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings.development")
else:
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings.local")

e importe este archivo en sus archivos manage.py y wsgi.py, sin necesidad de cambiar nada más en la ejecución de gunicorn

Answer 3

Supongo que usar run_gunicorn es el camino a seguir, también es la forma más simple de usarlo.

Es básicamente el mismo que usign gunicorn project.wsgi:application pero necesita que gunicorn se agregue a INSTALLED_APPS para que django reconozca el comando run_gunicorn , por lo que probablemente no sea la forma predeterminada ...

El uso de gunicorn_django está más o menos en desuso, como también se indica en la documentación aquí ...