python - tutorial - ¿Cómo se configura Django para un desarrollo e implementación simple?

django windows

Question

Tiendo a usar SQLite cuando hago el desarrollo de Django , pero en un servidor en vivo a menudo se necesita algo más robusto ( MySQL / PostgreSQL , por ejemplo). Invariablemente, hay otros cambios que hacer a la configuración de Django también: diferentes ubicaciones / intensidades de registro, rutas de medios, etc.

¿Cómo gestionas todos estos cambios para que la implementación sea un proceso simple y automatizado?

Answer 1

¡Tantas respuestas complicadas!

Cada archivo settings.py viene con:

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

Utilizo ese directorio para establecer la variable DEBUG como esta (reaplace con el directorio donde está tu código de desarrollador):

DEBUG=False
if(BASE_DIR=="/path/to/my/dev/dir"):
DEBUG = True

Luego, cada vez que se mueve el archivo settings.py, DEBUG será falso y será su entorno de producción.

Cada vez que necesite configuraciones diferentes a las de su entorno de desarrollo, simplemente use:

if(DEBUG):
#Debug setting
else:
#Release setting

Answer 2

Además de los múltiples archivos de configuración mencionados por Jim, también tiendo a colocar dos configuraciones en mi archivo settings.py en la parte superior BASE_DIR y BASE_URL en la ruta del código y la URL a la base del sitio, todas las otras configuraciones se modifican para anexarse ​​a estos.

BASE_DIR = "/home/sean/myapp/" p MEDIA_ROOT = "%smedia/" % BASEDIR Ej. MEDIA_ROOT = "%smedia/" % BASEDIR

Entonces, cuando muevo el proyecto, solo tengo que editar esta configuración y no buscar todo el archivo.

También recomendaría mirar Fabric y Capistrano (herramienta Ruby, pero puede usarse para implementar aplicaciones Django) que facilitan la automatización de la implementación remota.

Answer 3

Al final de settings.py tengo lo siguiente:

try:
from settings_local import *
except ImportError:
pass

De esta forma, si quiero anular la configuración predeterminada, tengo que poner settings_local.py justo al lado de settings.py.

Answer 4

Algo relacionado, para el problema de implementar Django mismo con múltiples bases de datos, es posible que desee echar un vistazo a Djangostack . Puede descargar un instalador completamente gratuito que le permite instalar Apache, Python, Django, etc. Como parte del proceso de instalación, le permitimos seleccionar qué base de datos desea usar (MySQL, SQLite, PostgreSQL). Usamos los instaladores extensamente cuando automatizamos las implementaciones internamente (se pueden ejecutar en modo desatendido).

Answer 5

Bueno, uso esta configuración:

Al final de settings.py:

#settings.py
try:
from locale_settings import *
except ImportError:
pass

Y en locale_settings.py:

#locale_settings.py
class Settings(object):
def __init__(self):
import settings
self.settings = settings
def __getattr__(self, name):
return getattr(self.settings, name)
settings = Settings()
INSTALLED_APPS = settings.INSTALLED_APPS + (
''gunicorn'',)
# Delete duplicate settings maybe not needed, but I prefer to do it.
del settings
del Settings

Answer 6

Creo que depende del tamaño del sitio si necesita intensificar el uso de SQLite, he utilizado SQLite con éxito en varios sitios en vivo más pequeños y funciona muy bien.

Answer 7

De hecho, probablemente debería considerar tener las mismas (o casi las mismas) configuraciones para su entorno de desarrollo y producción. De lo contrario, situaciones como "Hola, funciona en mi máquina" sucederán de vez en cuando.

Por lo tanto, para automatizar su implementación y eliminar esos problemas de WOMM, solo use Docker .

Answer 8

Esta es una publicación más antigua, pero creo que si agrego esta útil library , simplificará las cosas.

Use django-configuration

Inicio rápido

pip install django-configurations

Luego, subclasifique las configuraciones incluidas. Clase de configuración en la configuración de su proyecto .py cualquier otro módulo que esté utilizando para almacenar las constantes de configuración, por ejemplo:

# mysite/settings.py
from configurations import Configuration
class Dev(Configuration):
DEBUG = True

Establezca la variable de entorno DJANGO_CONFIGURATION en el nombre de la clase que acaba de crear, por ejemplo, en ~/.bashrc :

export DJANGO_CONFIGURATION=Dev

y la variable de entorno DJANGO_SETTINGS_MODULE a la ruta de importación del módulo como de costumbre, por ejemplo, en bash:

export DJANGO_SETTINGS_MODULE=mysite.settings

Alternativamente, proporcione la opción --configuration cuando use los comandos de administración de Django a lo largo de las líneas de la opción de línea de comandos predeterminada de Django, por ejemplo:

python manage.py runserver --settings=mysite.settings --configuration=Dev

Para permitir que Django use su configuración, ahora debe modificar su script manage.py o wsgi.py para usar las versiones de configuración de django de las funciones de inicio apropiadas, por ejemplo, un manage.py típico usando django-configurations se vería así:

#!/usr/bin/env python
import os
import sys
if __name__ == "__main__":
os.environ.setdefault(''DJANGO_SETTINGS_MODULE'', ''mysite.settings'')
os.environ.setdefault(''DJANGO_CONFIGURATION'', ''Dev'')
from configurations.management import execute_from_command_line
execute_from_command_line(sys.argv)

Observe que en la línea 10 no usamos la herramienta común django.core.management.execute_from_command_line sino que configurations.management.execute_from_command_line .

Lo mismo se aplica a su archivo wsgi.py , por ejemplo:

import os
os.environ.setdefault(''DJANGO_SETTINGS_MODULE'', ''mysite.settings'')
os.environ.setdefault(''DJANGO_CONFIGURATION'', ''Dev'')
from configurations.wsgi import get_wsgi_application
application = get_wsgi_application()

Aquí no usamos la función predeterminada django.core.wsgi.get_wsgi_application , sino que configurations.wsgi.get_wsgi_application .

¡Eso es! Ahora puede usar su proyecto con manage.py y su servidor WSGI favorito habilitado.

Answer 9

La forma más simple que encontré fue:

1) use la configuración predeterminada .py para desarrollo local y 2) cree una producción- settings.py comenzando con:

import os
from settings import *

Y luego anule las configuraciones que difieren en producción:

DEBUG = False
TEMPLATE_DEBUG = DEBUG
DATABASES = {
''default'': {
....
}
}

Answer 10

Personalmente, utilizo un solo settings.py para el proyecto, solo hago que busque el nombre de host en el que se encuentra (mis máquinas de desarrollo tienen nombres de host que comienzan con "gabriel", así que solo tengo esto:

import socket
if socket.gethostname().startswith(''gabriel''):
LIVEHOST = False
else:
LIVEHOST = True

luego en otras partes tengo cosas como:

if LIVEHOST:
DEBUG = False
PREPEND_WWW = True
MEDIA_URL = ''http://static1.grsites.com/''
else:
DEBUG = True
PREPEND_WWW = False
MEDIA_URL = ''http://localhost:8000/static/''

y así. Un poco menos legible, pero funciona bien y ahorra tener que hacer malabares con múltiples archivos de configuración.

Answer 11

Tengo dos archivos. settings_base.py que contiene settings_base.py comunes / predeterminadas, y que está registrado en el control de fuente. Cada implementación tiene un settings.py separado, que se ejecuta from settings_base import * al principio y luego sobrescribe según sea necesario.

Answer 12

Tengo mi archivo settings.py en un directorio externo. De esta forma, no se verifica en el control de fuente, o se sobrescribe con una implementación. Lo puse en el archivo settings.py en mi proyecto Django, junto con la configuración predeterminada:

import sys
import os.path
def _load_settings(path):
print "Loading configuration from %s" % (path)
if os.path.exists(path):
settings = {}
# execfile can''t modify globals directly, so we will load them manually
execfile(path, globals(), settings)
for setting in settings:
globals()[setting] = settings[setting]
_load_settings("/usr/local/conf/local_settings.py")

Nota: Esto es muy peligroso si no puede confiar en local_settings.py.

Answer 13

Yo uso el medio ambiente:

if os.environ.get(''WEB_MODE'', None) == ''production'' :
from settings_production import *
else :
from settings_dev import *

Creo que este es un enfoque mucho mejor, porque finalmente necesita ajustes especiales para su entorno de prueba, y puede agregarlo fácilmente a esta condición.

Answer 14

Actualización: se ha lanzado django-configurations que probablemente sea una mejor opción para la mayoría de las personas que hacerlo manualmente.

Si prefiere hacer las cosas manualmente, mi respuesta anterior sigue siendo válida:

Tengo varios archivos de configuración.

• settings_local.py - configuración específica del host, como nombre de la base de datos, rutas de archivos, etc.
• settings_development.py - configuración utilizada para el desarrollo, por ejemplo, DEBUG = True .
• settings_production.py - configuración utilizada para producción, p. ej. SERVER_EMAIL .

Ato todo esto junto con un archivo settings.py que primero importa settings_local.py , y luego uno de los otros dos. Decide qué cargar con dos configuraciones dentro de settings_local.py - DEVELOPMENT_HOSTS y PRODUCTION_HOSTS . settings.py llama a platform.node() para encontrar el nombre de host de la máquina en la que se está ejecutando, y luego busca ese nombre de host en las listas, y carga el segundo archivo de configuraciones dependiendo de la lista en la que encuentre el nombre de host.

De esta forma, lo único que realmente debe preocuparse es mantener el archivo settings_local.py actualizado con la configuración específica del host, y todo lo demás se maneja automáticamente.

Mira un ejemplo here .