Comment gérer les paramètres locaux et les paramètres de production dans Django ?

Question

Quelle est la méthode recommandée pour gérer les paramètres pour le développement local et le serveur de production ? Certains d'entre eux (comme les constantes, etc.) peuvent être modifiés/accédés dans les deux, mais d'autres (comme les chemins vers les fichiers statiques) doivent rester différents, et ne doivent donc pas être écrasés à chaque fois que le nouveau code est déployé.

Actuellement, j'ajoute toutes les constantes à settings.py . Mais à chaque fois que je modifie une constante localement, je dois la copier sur le serveur de production et éditer le fichier pour les changements spécifiques à la production... :(

Edit : il semble qu'il n'y ait pas de réponse standard à cette question, j'ai accepté la méthode la plus populaire.

Answer 1

Deux boules de Django : Meilleures pratiques pour Django 1.5 suggère d'utiliser un contrôle de version pour vos fichiers de paramètres et de stocker les fichiers dans un répertoire séparé :

project/
    app1/
    app2/
    project/
        __init__.py
        settings/
            __init__.py
            base.py
            local.py
            production.py
    manage.py

En base.py contient les paramètres courants (tels que MEDIA_ROOT ou ADMIN), tandis que le fichier local.py y production.py ont des paramètres spécifiques au site :

Dans le fichier de base settings/base.py :

INSTALLED_APPS = (
    # common apps...
)

Dans le fichier des paramètres de développement local settings/local.py :

from project.settings.base import *

DEBUG = True
INSTALLED_APPS += (
    'debug_toolbar', # and other apps for local development
)

Dans le fichier des paramètres de production settings/production.py :

from project.settings.base import *

DEBUG = False
INSTALLED_APPS += (
    # other apps for production site
)

Ensuite, lorsque vous exécutez django, vous ajoutez le fichier --settings option :

# Running django for local development
$ ./manage.py runserver 0:8000 --settings=project.settings.local

# Running django shell on the production site
$ ./manage.py shell --settings=project.settings.production

Les auteurs du livre ont également mis en place un modèle de présentation de projet sur Github.

Answer 2

En settings.py :

try:
    from local_settings import *
except ImportError as e:
    pass

Vous pouvez remplacer ce qui est nécessaire dans local_settings.py il devrait rester en dehors de votre contrôle de version. Mais puisque vous parlez de copie, je suppose que vous n'en utilisez aucune ;)

Answer 3

Au lieu de settings.py utiliser ce modèle :

.
└── settings/
    ├── __init__.py  <= not versioned
    ├── common.py
    ├── dev.py
    └── prod.py

common.py est l'endroit où se trouve la majeure partie de votre configuration.

prod.py importe tout de common et surcharge tout ce qu'il doit surcharger :

from __future__ import absolute_import # optional, but I like it
from .common import *

# Production overrides
DEBUG = False
#...

De même, dev.py importe tout de common.py et surcharge tout ce qu'il doit surcharger.

Enfin, __init__.py est l'endroit où vous décidez des paramètres à charger, et c'est également l'endroit où vous stockez les secrets (ce fichier ne doit donc pas être versionné) :

from __future__ import absolute_import
from .prod import *  # or .dev if you want dev

##### DJANGO SECRETS
SECRET_KEY = '(3gd6shenud@&57...'
DATABASES['default']['PASSWORD'] = 'f9kGH...'

##### OTHER SECRETS
AWS_SECRET_ACCESS_KEY = "h50fH..."

Cette solution me plaît :

1. Tout est dans votre système de version, sauf les secrets
2. La plupart des configurations sont regroupées en un seul endroit : common.py .
3. Les éléments spécifiques à la production y sont insérés prod.py les éléments spécifiques au développement sont placés dans dev.py . C'est simple.
4. Vous pouvez remplacer des éléments de common.py en prod.py o dev.py et vous pouvez ignorer tout ce qui se trouve dans __init__.py .
5. C'est du python pur et dur. Pas de hacks de réimportation.

Answer 4

J'utilise une version légèrement modifiée des paramètres de type "if DEBUG" publiés par Harper Shelby. Évidemment, en fonction de l'environnement (win/linux/etc.), le code peut avoir besoin d'être légèrement modifié.

Dans le passé, j'utilisais le "if DEBUG", mais j'ai constaté que j'avais parfois besoin de faire des tests avec DEUBG fixé à False. Ce que je voulais vraiment, c'était distinguer si l'environnement était de production ou de développement, ce qui me donnait la liberté de choisir le niveau DEBUG.

PRODUCTION_SERVERS = ['WEBSERVER1','WEBSERVER2',]
if os.environ['COMPUTERNAME'] in PRODUCTION_SERVERS:
    PRODUCTION = True
else:
    PRODUCTION = False

DEBUG = not PRODUCTION
TEMPLATE_DEBUG = DEBUG

# ...

if PRODUCTION:
    DATABASE_HOST = '192.168.1.1'
else:
    DATABASE_HOST = 'localhost'

Je considère toujours cette méthode de paramétrage comme un travail en cours. Je n'ai pas vu de moyen unique de gérer les paramètres de Django qui couvre toutes les bases et en même temps n'est pas un casse-tête total à installer (je ne suis pas d'accord avec les méthodes de 5x les fichiers de paramètres).

Answer 5

J'utilise un settings_local.py et un settings_production.py. Après avoir essayé plusieurs options, je me suis rendu compte qu'il est facile de perdre du temps avec des solutions complexes alors qu'il est facile et rapide d'avoir simplement deux fichiers de configuration.

Lorsque vous utilisez mod_python/mod_wsgi pour votre projet Django, vous devez le faire pointer vers votre fichier de configuration. Si vous le faites pointer vers app/settings_local.py sur votre serveur local et app/settings_production.py sur votre serveur de production, alors la vie devient facile. Il suffit d'éditer le fichier de configuration approprié et de redémarrer le serveur (le serveur de développement de Django redémarre automatiquement).