Django : Comment gérer les paramètres de développement et de production ?

Question

J'ai développé une application de base. Maintenant, au stade du déploiement, il est devenu clair que j'ai besoin de paramètres locaux et de paramètres de production.

Il serait bon de connaître les éléments suivants :

• Comment gérer au mieux les paramètres de développement et de production.
• Comment garder des applications telles que django-debug-toolbar uniquement dans un environnement de développement.
• Tout autre conseil et meilleure pratique pour les paramètres de développement et de déploiement.

Answer 1

Créer plusieurs settings*.py en extrapolant les variables qui doivent changer par environnement. Puis à la fin de votre master settings.py fichier :

try:
  from settings_dev import *
except ImportError:
  pass

Vous gardez la séparation settings_* pour chaque étape.

En haut de votre settings_dev.py ajoutez ceci :

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

Pour importer des variables que vous devez modifier.

Ce site entrée wiki a plus d'idées sur la façon de diviser vos paramètres.

Answer 2

Voici l'approche que nous utilisons :

• a settings pour diviser les paramètres en plusieurs fichiers pour plus de lisibilité ;
• a .env.json pour stocker les informations d'identification et les paramètres que nous voulons exclure de notre dépôt git, ou qui sont spécifiques à l'environnement ;
• un env.py pour lire le fichier .env.json fichier

Considérant la structure suivante :

...
.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
...

Avec .env.json comme :

{
    "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",
}

Et 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()

Nous pouvons avoir les paramètres suivants :

<!-- 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',
    }
}

les avantages de cette solution sont :

• les informations d'identification et les configurations propres à l'utilisateur pour un développement local sans modifier le dépôt git ;
• configuration spécifique à l'environnement vous pouvez avoir, par exemple, trois environnements différents avec trois systèmes différents. .env.json comme le développement, la stagging et la production ;
• les informations d'identification ne sont pas dans le référentiel

J'espère que cela vous aidera, mais faites-moi savoir si vous voyez des inconvénients à cette solution.

Answer 3

J'utilise la structure de fichier suivante :

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

Alors __init__.py est un lien (ln en unix ou mklink en Windows) vers local.py ou peut être à prod.py donc la configuration est toujours dans le project.settings est propre et organisé, et si vous voulez utiliser une configuration particulière vous pouvez utiliser la variable d'environnement DJANGO_SETTINGS_MODULE a project.settings.prod si vous devez exécuter une commande pour un environnement de production.

Dans les dossiers prod.py y local.py :

from .shared import *

DATABASE = {
    ...
}

et le shared.py conserve le caractère global sans configuration spécifique.

Answer 4

En s'appuyant sur la réponse de cs01 :

si vous avez des problèmes avec la variable d'environnement, définissez sa valeur comme une chaîne de caractères (par exemple, j'ai fait DJANGO_DEVELOPMENT="true" ).

J'ai également modifié le flux de travail du fichier cs01 comme suit :

#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 cette façon, Django n'a pas besoin de lire l'intégralité d'un fichier de paramètres avant d'exécuter le fichier de paramètres approprié. Cette solution est pratique si votre fichier de production a besoin d'éléments qui ne se trouvent que sur votre serveur de production.

Remarque : dans Python 3, les fichiers importés doivent avoir un nom de fichier . ajouté (par exemple from .settings_dev import * )

Answer 5

Utilisez settings.py pour la production. Dans le même répertoire, créez settings_dev.py pour les dérogations.

# settings_dev.py

from .settings import * 

DEBUG = False

Sur une machine de développement, exécutez votre application Django avec :

DJANGO_SETTINGS_MODULE=<your_app_name>.settings_dev python3 manage.py runserver

Sur une machine de production, exécutez comme si vous veniez d'avoir settings.py et rien d'autre.

AVANTAGES

1. settings.py (utilisé pour la production) est complètement agnostique au fait que d'autres environnements existent.
2. Pour voir la différence entre prod et dev, il suffit de regarder à un seul endroit settings_dev.py . Plus besoin de rassembler des configurations éparpillées dans settings_prod.py , settings_dev.py y settings_shared.py .
3. Si quelqu'un ajoute un paramètre à votre configuration de production après avoir résolu un problème de production, vous pouvez être sûr qu'il apparaîtra également dans votre configuration de développement (à moins qu'il ne soit explicitement remplacé). Ainsi, la divergence entre les différents fichiers de configuration sera minimisée.