Comment configurer Django pour un développement et un déploiement simples?

J'ai tendance à utiliser SQLite lorsque je fais du développement Django , mais sur un serveur live, quelque chose de plus robuste est souvent nécessaire ( MySQL / PostgreSQL , par exemple). Invariablement, il y a également d'autres changements à apporter aux paramètres de Django: différents emplacements / intensités de journalisation, chemins multimédias, etc.

Comment gérez-vous tous ces changements pour faire du déploiement un processus simple et automatisé?

Mise à jour: django-configurations a été publié, ce qui est probablement une meilleure option pour la plupart des gens que de le faire manuellement.

Si vous préférez faire les choses manuellement, ma réponse précédente s'applique toujours:

J'ai plusieurs fichiers de paramètres.

• settings_local.py - configuration spécifique à l'hôte, telle que le nom de la base de données, les chemins de fichiers, etc.
• settings_development.py- configuration utilisée pour le développement, par exemple DEBUG = True.
• settings_production.py- configuration utilisée pour la production, par exemple SERVER_EMAIL.

Je les lie tous ensemble avec un settings.pyfichier qui importe d'abord settings_local.py, puis l'un des deux autres. Il décide lequel charger par deux paramètres à l'intérieur settings_local.py- DEVELOPMENT_HOSTSet PRODUCTION_HOSTS. settings.pyappelle platform.node()pour trouver le nom d'hôte de la machine sur laquelle il s'exécute, puis recherche ce nom d'hôte dans les listes et charge le deuxième fichier de paramètres en fonction de la liste dans laquelle il trouve le nom d'hôte.

De cette façon, la seule chose dont vous devez vraiment vous soucier est de garder le settings_local.pyfichier à jour avec la configuration spécifique à l'hôte, et tout le reste est géré automatiquement.

Découvrez un exemple ici .

Personnellement, j'utilise un seul settings.py pour le projet, je lui demande juste de rechercher le nom d'hôte sur lequel il se trouve (mes machines de développement ont des noms d'hôte qui commencent par "gabriel" donc j'ai juste ceci:

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

puis dans d'autres parties, j'ai des choses comme:

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/'

etc. Un peu moins lisible, mais cela fonctionne bien et évite d'avoir à jongler avec plusieurs fichiers de paramètres.

À la fin de settings.py, j'ai ce qui suit:

try:
    from settings_local import *
except ImportError:
    pass

De cette façon, si je veux remplacer les paramètres par défaut, je dois simplement placer settings_local.py juste à côté de settings.py.

J'ai deux fichiers. settings_base.pyqui contient les paramètres communs / par défaut et qui est archivé dans le contrôle de code source. Chaque déploiement a un autre settings.py, qui s'exécute from settings_base import *au début, puis remplace si nécessaire.

Le moyen le plus simple que j'ai trouvé était:

1) utilisez les paramètres par défaut.py pour le développement local et 2) créez un fichier production-settings.py commençant par:

import os
from settings import *

Et puis remplacez simplement les paramètres qui diffèrent en production:

DEBUG = False
TEMPLATE_DEBUG = DEBUG


DATABASES = {
    'default': {
           ....
    }
}

Un peu lié, pour le problème du déploiement de Django lui-même avec plusieurs bases de données, vous voudrez peut-être jeter un œil à Djangostack . Vous pouvez télécharger un programme d'installation entièrement gratuit qui vous permet d'installer Apache, Python, Django, etc. Dans le cadre du processus d'installation, nous vous permettons de sélectionner la base de données que vous souhaitez utiliser (MySQL, SQLite, PostgreSQL). Nous utilisons beaucoup les installateurs lors de l'automatisation des déploiements en interne (ils peuvent être exécutés en mode sans assistance).

J'ai mon fichier settings.py dans un répertoire externe. De cette façon, il n'est pas archivé dans le contrôle de code source ou écrasé par un déploiement. Je mets ceci dans le fichier settings.py sous mon projet Django, avec tous les paramètres par défaut:

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")

Remarque: Ceci est très dangereux si vous ne pouvez pas faire confiance à local_settings.py.

En plus des multiples fichiers de paramètres mentionnés par Jim, j'ai également tendance à placer deux paramètres dans mon fichier settings.py en haut BASE_DIRet à BASE_URLdéfinir le chemin du code et l'URL vers la base du site, tous les autres paramètres sont modifiés pour s'y ajouter.

BASE_DIR = "/home/sean/myapp/" par exemple MEDIA_ROOT = "%smedia/" % BASEDIR

Ainsi, lors du déplacement du projet, je n'ai qu'à modifier ces paramètres et non à rechercher l'ensemble du fichier.

Je recommanderais également de regarder fabric et Capistrano (outil Ruby, mais il peut être utilisé pour déployer des applications Django) qui facilitent l'automatisation du déploiement à distance.

Eh bien, j'utilise cette configuration:

À la fin de settings.py:

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

Et dans 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

Tant de réponses compliquées!

Chaque fichier settings.py est livré avec:

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

J'utilise ce répertoire pour définir la variable DEBUG comme ceci (remplacez-le avec le directoy où se trouve votre code de développement):

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

Ensuite, chaque fois que le fichier settings.py est déplacé, DEBUG sera False et c'est votre environnement de production.

Chaque fois que vous avez besoin de paramètres différents de ceux de votre environnement de développement, utilisez simplement:

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

Je pense que cela dépend de la taille du site pour savoir si vous devez abandonner l'utilisation de SQLite, j'ai utilisé avec succès SQLite sur plusieurs sites en direct plus petits et il fonctionne très bien.

J'utilise l'environnement:

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

Je pense que c'est une bien meilleure approche, car vous aurez éventuellement besoin de paramètres spéciaux pour votre environnement de test, et vous pouvez facilement l'ajouter à cette condition.

C'est un article plus ancien, mais je pense que si j'ajoute cela utile, librarycela simplifiera les choses.

Utilisez django-configuration

Démarrage rapide

pip install django-configurations

Ensuite, sous-classez la classe configurations.Configuration incluse dans le fichier settings.py de votre projet ou dans tout autre module que vous utilisez pour stocker les constantes de paramètres, par exemple:

# mysite/settings.py

from configurations import Configuration

class Dev(Configuration):
    DEBUG = True

Définissez la DJANGO_CONFIGURATIONvariable d'environnement sur le nom de la classe que vous venez de créer, par exemple dans ~/.bashrc:

export DJANGO_CONFIGURATION=Dev

et la DJANGO_SETTINGS_MODULEvariable d'environnement vers le chemin d'importation du module comme d'habitude, par exemple dans bash:

export DJANGO_SETTINGS_MODULE=mysite.settings

Vous pouvez également fournir l' --configurationoption lors de l'utilisation des commandes de gestion Django le long des lignes de l' --settingsoption de ligne de commande par défaut de Django, par exemple:

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

Pour permettre à Django d'utiliser votre configuration, vous devez maintenant modifier votre script manage.py ou wsgi.py pour utiliser les versions de django-configurations des fonctions de démarrage appropriées, par exemple un manage.py typique utilisant django-configurations ressemblerait à ceci:

#!/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)

Remarquez à la ligne 10 que nous n'utilisons pas l'outil commun django.core.management.execute_from_command_linemais à la place configurations.management.execute_from_command_line.

La même chose s'applique à votre fichier wsgi.py , par exemple:

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

Ici, nous n'utilisons pas la django.core.wsgi.get_wsgi_applicationfonction par défaut mais à la place configurations.wsgi.get_wsgi_application.

C'est tout! Vous pouvez maintenant utiliser votre projet avec manage.py et votre serveur compatible WSGI préféré.

En fait, vous devriez probablement envisager d'avoir les mêmes (ou presque les mêmes) configurations pour votre environnement de développement et de production. Sinon, des situations comme "Hé, ça marche sur ma machine" se produiront de temps en temps.

Donc, pour automatiser votre déploiement et éliminer ces problèmes WOMM, utilisez simplement Docker .