python - examples - django templates bootstrap

Django: ¿Cómo administrar las configuraciones de desarrollo y producción?

Question

He estado desarrollando una aplicación básica. Ahora, en la etapa de implementación, ha quedado claro que necesito configuraciones tanto locales como de producción.

Sería grandioso saber lo siguiente:

• La mejor forma de lidiar con los entornos de desarrollo y producción.
• Cómo mantener aplicaciones como django-debug-toolbar solo en un entorno de desarrollo.
• Cualquier otro consejo y mejores prácticas para el desarrollo y la configuración de implementación.

Answer 1

Aquí está el enfoque que usamos:

• un módulo de settings para dividir las configuraciones en múltiples archivos para facilitar su lectura;
• un archivo .env.json para almacenar credenciales y parámetros que queremos excluir de nuestro repositorio de git, o que son específicos del entorno;
• un archivo env.py para leer el archivo .env.json

Teniendo en cuenta la siguiente estructura:

...
.env.json           # the file containing all specific credentials and parameters
.gitignore          # the .gitignore file to exclude `.env.json`
project_name/       # project dir (the one which django-admin.py creates)
  accounts/         # project''s apps
    __init__.py
    ...
  ...
  env.py            # the file to load credentials
  settings/
    __init__.py     # main settings file
    database.py     # database conf
    storage.py      # storage conf
    ...
venv                # virtualenv
...

Con .env.json como:

{
    "debug": false,
    "allowed_hosts": ["mydomain.com"],
    "django_secret_key": "my_very_long_secret_key",
    "db_password": "my_db_password",
    "db_name": "my_db_name",
    "db_user": "my_db_user",
    "db_host": "my_db_host",
}

Y project_name/env.py :

<!-- language: lang-python -->
import json
import os


def get_credentials():
    env_file_dir = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
    with open(os.path.join(env_file_dir, ''.env.json''), ''r'') as f:
        creds = json.loads(f.read())
    return creds


credentials = get_credentials()

Podemos tener la siguiente configuración:

<!-- language: lang-py -->
# project_name/settings/__init__.py
from project_name.env import credentials
from project_name.settings.database import *
from project_name.settings.storage import *
...

SECRET_KEY = credentials.get(''django_secret_key'')

DEBUG = credentials.get(''debug'')

ALLOWED_HOSTS = credentials.get(''allowed_hosts'', [])

INSTALLED_APPS = [
    ''django.contrib.admin'',
    ''django.contrib.auth'',
    ''django.contrib.contenttypes'',
    ''django.contrib.sessions'',
    ''django.contrib.messages'',
    ''django.contrib.staticfiles'',

    ...
]

if DEBUG:
    INSTALLED_APPS += [''debug_toolbar'']

...

# project_name/settings/database.py
from project_name.env import credentials

DATABASES = {
    ''default'': {
        ''ENGINE'': ''django.db.backends.postgresql_psycopg2'',
        ''NAME'': credentials.get(''db_name'', ''''),
        ''USER'': credentials.get(''db_user'', ''''),
        ''HOST'': credentials.get(''db_host'', ''''),
        ''PASSWORD'': credentials.get(''db_password'', ''''),
        ''PORT'': ''5432'',
    }
}

los beneficios de esta solución son:

• credenciales y configuraciones específicas del usuario para el desarrollo local sin modificar el repositorio de git;
• configuración específica del entorno , puede tener, por ejemplo, tres entornos diferentes con tres .env.json diferentes, como dev, stagging y producción;
• las credenciales no están en el repositorio

Espero que esto ayude, solo avíseme si ve alguna advertencia con esta solución.

Answer 2

Cree múltiples settings*.py archivos, extrapolando las variables que necesitan cambiar por entorno. Luego, al final de su archivo master settings.py :

try:
  from settings_dev import *
except ImportError:
  pass

Mantiene los archivos de settings_* separados para cada etapa.

En la parte superior de su archivo settings_dev.py , agregue esto:

import sys
globals().update(vars(sys.modules[''settings'']))

Para importar variables que necesita modificar.

Esta code.djangoproject.com/wiki/SplitSettings tiene más ideas sobre cómo dividir tu configuración.

Answer 3

De forma predeterminada, use la configuración de producción, pero cree un archivo llamado settings_dev.py en la misma carpeta que su archivo settings.py . Agregue modificaciones allí, como DEBUG=True .

En la computadora que se usará para el desarrollo, agréguela a su archivo ~/.bashrc :

export DJANGO_DEVELOPMENT=true

En la parte inferior de su archivo settings.py , agregue lo siguiente.

# Override production variables if DJANGO_DEVELOPMENT env variable is set
if os.environ.get(''DJANGO_DEVELOPMENT'') is not None:
    from settings_dev import * 

(Tenga en cuenta que la importación * generalmente debe evitarse en Python, pero esta es una circunstancia única)

Por defecto, los servidores de producción no anularán nada. ¡Hecho!

En comparación con las otras respuestas, esta es más simple porque no requiere la actualización de PYTHONPATH o la configuración de DJANGO_SETTINGS_MODULE que solo le permite trabajar en un proyecto django a la vez.

Answer 4

Esta es mi solución, con diferentes entornos para dev, test y prod

import socket

[...]

DEV_PC = ''PC059''
host_name = socket.gethostname()

if host_name == DEV_PC:
   #do something
   pass
elif [...]

Answer 5

Esto parece haber sido respondido, sin embargo, un método que utilizo combinado con el control de versión es el siguiente:

Configure un archivo env.py en el mismo directorio que las configuraciones en mi entorno de desarrollo local que también agrego a .gitignore:

env.py:

#!usr/bin/python

DJANGO_ENV = True
ALLOWED_HOSTS = [''127.0.0.1'', ''dev.mywebsite.com'']

.gitignore:

mywebsite/env.py

settings.py:

if os.path.exists(os.getcwd() + ''/env.py''):
    #env.py is excluded using the .gitignore file - when moving to production we can automatically set debug mode to off:
    from env import *
else:
    DJANGO_ENV = False

DEBUG = DJANGO_ENV

Me parece que esto funciona y es mucho más elegante: con env.py es fácil ver nuestras variables de entorno local y podemos manejar todo esto sin múltiples archivos settings.py o similares. Este método permite utilizar todo tipo de variables de entorno locales que no desearíamos configurar en nuestro servidor de producción. Utilizando .gitignore a través del control de versión, también mantenemos todo perfectamente integrado.

Answer 6

Normalmente tengo un archivo de configuración por entorno y un archivo de configuración compartido:

/myproject/
  settings.production.py
  settings.development.py
  shared_settings.py

Cada uno de mis archivos de entorno tiene:

try:
    from shared_settings import *
except ImportError:
    pass

Esto me permite anular las configuraciones compartidas si es necesario (agregando las modificaciones debajo de esa estrofa).

Luego selecciono los archivos de configuración que usaré al vincularlo a settings.py:

ln -s settings.development.py settings.py

Answer 7

Si desea mantener 1 archivo de configuración y su sistema operativo de desarrollo es diferente de su sistema operativo de producción, puede poner esto en la parte inferior de su settings.py:

from sys import platform
if platform == "linux" or platform == "linux2":
    # linux
    # some special setting here for when I''m on my prod server
elif platform == "darwin":
    # OS X
    # some special setting here for when I''m developing on my mac
elif platform == "win32":
    # Windows...
    # some special setting here for when I''m developing on my pc

Leer más: ¿Cómo reviso el sistema operativo en Python?

Answer 8

Utilizo las impresionantes configuraciones django , y todas las configuraciones se almacenan en mi settings.py :

from configurations import Configuration

class Base(Configuration):
    # all the base settings here...
    BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
    ...

class Develop(Base):
    # development settings here...
    DEBUG = True 
    ...

class Production(Base):
    # production settings here...
    DEBUG = False

Para configurar el proyecto Django, simplemente seguí los documentos .

Answer 9

Yo uso la estructura de archivo folloring:

project/
   ...
   settings/
   settings/common.py
   settings/local.py
   settings/prod.py
   settings/__init__.py -> local.py

Entonces __init__.py es un enlace (ln en Unix o mklink en Windows) a local.py o puede ser a prod.py para que la configuración esté todavía en el project.settings módulo de project.settings está limpio y organizado, y si desea usar un configuración particular puede usar la variable de entorno DJANGO_SETTINGS_MODULE para project.settings.prod si necesita ejecutar un comando para el entorno de producción.

En los archivos prod.py y local.py :

from .shared import *

DATABASE = {
    ...
}

y el archivo shared.py mantiene como global sin configuraciones específicas.

Answer 10

construyendo la respuesta de cs01:

si tiene problemas con la variable de entorno, establezca su valor en una cadena (por ejemplo, yo hice DJANGO_DEVELOPMENT="true" ).

También cambié el flujo de trabajo de archivos de cs01 de la siguiente manera:

#settings.py
import os
if os.environ.get(''DJANGO_DEVELOPMENT'') is not None:
    from settings_dev import * 
else:
    from settings_production import *
#settings_dev.py
development settings go here
#settings_production.py
production settings go here

De esta forma, Django no tiene que leer todo el archivo de configuración antes de ejecutar el archivo de configuración apropiado. Esta solución es útil si su archivo de producción necesita elementos que solo están en su servidor de producción.

Nota: en Python 3, los archivos importados deben tener un . anexado (por ejemplo, from .settings_dev import * )

Answer 11

Mi forma favorita de hacerlo es usar la variable de entorno DJANGO_SETTINGS_MODULE y usar dos (o más) archivos de configuración, por ejemplo, production_settings.py test_settings.py .

A continuación, puede utilizar un script de arranque o un administrador de procesos para cargar la configuración correcta (configurando el entorno). Si está utilizando un virtualenv, incluso podría piratearlo en el guión de activación de virtualenv.

Puede aprovechar la variable PYTHONPATH para almacenar los ajustes en una ubicación completamente diferente (por ejemplo, en un servidor de producción, almacenarlos en /etc/ tiene sentido) - esto permite una implementación más sencilla ya que separa completamente la configuración de los archivos de la aplicación (que es una cosa buena).

Configurando DJANGO_SETTINGS_MODULE usando un Administrador de Procesos

Si no le gusta escribir un script de arranque que establezca el entorno (¡y hay muy buenas razones para sentirse así!), Le recomendaría usar un administrador de procesos:

• Supervisor permite pasar variables de entorno a los procesos gestionados utilizando la clave de configuración de environment un programa .
• Honcho (un equivalente puro de Python de Ruby''s Foreman) le permite definir variables de entorno en un archivo de "entorno" ( .env ) .

Hack bin/activate para establecer DJANGO_SETTINGS_MODULE

Si usa un virtualenv, agregue esto a su secuencia de comandos bin/activate :

DJANGO_SETTINGS_MODULE="production_settings"
export DJANGO_SETTINGS_MODULE

Y en tu servidor de prueba:

DJANGO_SETTINGS_MODULE="test_settings"
export DJANGO_SETTINGS_MODULE