python - mod_wsgi - ¿Cómo puedo saber si mi aplicación Django se está ejecutando en el servidor de desarrollo o no?

mod_wsgi django configuration

Question

¿Cómo puedo estar seguro de que mi aplicación se ejecuta en el servidor de desarrollo o no? Supongo que podría verificar el valor de settings.DEBUG y asumir que si DEBUG es True entonces se está ejecutando en el servidor de desarrollo, pero preferiría saber con certeza que confiar en la convención.

Answer 1

Confiar en los ajustes. BUG es la forma más elegante de AFAICS, ya que también se usa en la base de código de Django en ocasiones.

Supongo que lo que realmente quiere es una forma de establecer esa bandera automáticamente sin necesidad de actualizarla manualmente cada vez que carga el proyecto a los servidores de producción.

Para eso, compruebo la ruta de settings.py (en settings.py) para determinar en qué servidor se está ejecutando el proyecto:

if __file__ == "path to settings.py in my development machine":
    DEBUG = True
elif __file__ in [paths of production servers]:
    DEBUG = False
else:
    raise WhereTheHellIsThisServedException()

Eso sí, quizás prefieras hacer esta comprobación con las variables de entorno, como sugiere @Soviut. Pero como alguien que está desarrollando en Windows y sirviendo en Linux verificando las rutas de los archivos era más fácil que ir con variables de entorno.

Answer 2

Una diferencia entre el entorno de desarrollo y despliegue será el servidor en el que se está ejecutando. Lo que es exactamente diferente dependerá de sus entornos de desarrollo y desarrollo.

Al conocer su propio desarrollador y desplegar entornos, las variables de solicitud de HTTP se podrían usar para distinguir entre los dos. Mire variables de solicitud como request.META.HTTP_HOST , request.META.SERVER_NAME y request.META.SERVER_PORT y compárelas en los dos entornos.

Apuesto a que encontrará algo bastante obvio que es diferente y se puede usar para detectar su entorno de desarrollo. Realice la prueba en settings.py y establezca una variable que pueda usar en otro lugar.

Answer 3

settings.DEBUG podría ser True y ejecutarse bajo Apache u otro servidor que no sea de desarrollo. Todavía se ejecutará. Por lo que puedo decir, no hay nada en el entorno de tiempo de ejecución salvo para examinar el pid y compararlo con los pids en el SO que le proporcionarán esta información.

Answer 4

Me encontré con este problema hace un momento, y terminé escribiendo una solución similar a la de Aryeh Leib Taurog. Mi principal diferencia es que quiero diferenciar entre un entorno de producción y un entorno de desarrollo cuando ejecuto el servidor, pero también cuando ejecuto algunos scripts únicos para mi aplicación (que ejecuto como DJANGO_SETTINGS_MODULE = settings python [el script]). En este caso, simplemente mirando si argv [1] == runserver no es suficiente. Entonces, lo que se me ocurre es pasar un argumento extra de línea de comandos cuando ejecuto el servidor dev, y también cuando ejecuto mis scripts, y simplemente busco ese argumento en settings.py. Entonces el código se ve así:

if ''--in-development'' in sys.argv:
    ## YES! we''re in dev
    pass
else:
    ## Nope, this is prod
    pass

luego, ejecutar el servidor django se convierte

python manage.py runserver [cualquier opción que desee] --in-development

y ejecutar mis scripts es tan fácil como

DJANGO_SETTINGS_MODULE = configuración python [myscript] --in-development

Solo asegúrate de que el argumento adicional que transmites no entra en conflicto con nada django (en realidad, uso el nombre de mi aplicación como parte del argumento). Creo que esto es bastante decente, ya que me permite controlar exactamente cuándo mi servidor y mis scripts se comportarán como prod o dev, y no estoy confiando en las convenciones de los demás, aparte de las mías.

EDITAR: manage.py se queja si pasa opciones no reconocidas, por lo que debe cambiar el código en settings.py para que sea similar a

if sys.argv[0] == ''manage.py'' or ''--in-development'' in sys.argv:
    # ...
    pass

Aunque esto funciona, reconozco que no es la solución más elegante ...

Answer 5

Inspirado por la respuesta de Aryeh, el truco que ideé para mi propio uso es buscar el nombre de mi script de administración en sys.argv[0] :

USING_DEV_SERVER = "pulpdist/manage_site.py" in sys.argv[0]

(Mi caso de uso es habilitar automáticamente la autenticación nativa Django cuando ejecuto el servidor de prueba: cuando se ejecuta en Apache, incluso en servidores de desarrollo, toda la autenticación para mi proyecto actual se maneja a través de Kerberos)

Answer 6

Yo suelo:

DEV_SERVERS = [
    ''mymachine.local'',
]

DEVELOPMENT = platform.node() in DEV_SERVERS

que requiere prestar atención a lo que devuelve .node() en sus máquinas. Es importante que el valor predeterminado no sea de desarrollo para no exponer accidentalmente la información de desarrollo sensible.

También podría buscar formas más complicadas de identificar computadoras de manera única .

Answer 7

Si desea cambiar sus archivos de configuración automáticamente dependiendo del entorno de ejecución, puede usar algo que difiera en el entorno, por ejemplo

from os import environ
if environ.get(''_'', ''''): 
    print "This is dev - not Apache mod_wsgi"         

Answer 8

Puse lo siguiente en mi settings.py para distinguir entre el servidor de desarrollo estándar y la producción:

import sys
RUNNING_DEVSERVER = (len(sys.argv) > 1 and sys.argv[1] == ''runserver'')

Esto también se basa en la convención, sin embargo.

(Enmendado por el comentario de Daniel Magnusson)

Answer 9

Usualmente esto funciona:

import sys

if ''runserver'' in sys.argv:
    # you use runserver

Answer 10

server = request.META.get(''wsgi.file_wrapper'', None)
if server is not None and server.__module__ == ''django.core.servers.basehttp'':
    print(''inside dev'')

Por supuesto, wsgi.file_wrapper podría estar configurado en META, y tener una clase de un módulo llamado django.core.servers.basehttp por coincidencia extrema en otro entorno de servidor, pero espero que esto lo cubra.

Por cierto, descubrí esto haciendo una plantilla sintácticamente inválida mientras corría en el servidor de desarrollo, y busqué cosas interesantes en las secciones de Traceback y Request information , así que solo estoy editando mi respuesta para corroborar las ideas de Nate.

Answer 11

Normalmente establezco una variable llamada environment y la configuro en "DESARROLLO", "ESCENARIO" o "PRODUCCIÓN". Dentro del archivo de configuración, puedo agregar lógica básica para cambiar las configuraciones que se utilizan, según el entorno.

EDITAR: Además, puede simplemente usar esta lógica para incluir diferentes archivos settings.py que anulan la configuración básica. Por ejemplo:

if environment == "DEBUG":
    from debugsettings import *