it-swarm-eu.dev

Wie konfigurieren Sie Django für die einfache Entwicklung und Bereitstellung?

Ich neige dazu, SQLite zu verwenden, wenn ich Django Entwickle, aber auf einem Live - Server ist Etwas öfter erforderlich ( MySQL / PostgreSQL zum Beispiel Es gibt ausnahmslos weitere Änderungen an den Django -Einstellungen: unterschiedliche Speicherorte/-intensitäten, Medienpfade usw.

Wie verwalten Sie all diese Änderungen, um die Bereitstellung zu einem einfachen, automatisierten Prozess zu machen?

109
reppimp

Update:Django-Konfigurationen wurde veröffentlicht, was wahrscheinlich für die meisten Leute eine bessere Option ist, als manuell durchzuführen.

Wenn Sie es vorziehen, Dinge manuell zu machen, gilt meine frühere Antwort weiterhin:

Ich habe mehrere Einstellungsdateien.

  • settings_local.py - Hostspezifische Konfiguration, wie Datenbankname, Dateipfade usw.
  • settings_development.py - Konfiguration, die für die Entwicklung verwendet wird, z. DEBUG = True.
  • settings_production.py - Konfiguration, die für die Produktion verwendet wird, z. SERVER_EMAIL.

Ich binde diese alle zusammen mit einer settings.py-Datei, die zuerst settings_local.py und dann eine der anderen beiden importiert. Es entscheidet, welche Einstellungen durch zwei Einstellungen in settings_local.py - DEVELOPMENT_HOSTS und PRODUCTION_HOSTS geladen werden. settings.py ruft platform.node() auf, um den Hostnamen der Maschine zu finden, auf der er läuft, und sucht dann in den Listen nach diesem Hostnamen und lädt die zweite Einstellungsdatei, je nachdem in welcher Liste der Hostname gefunden wird.

Das einzige, worüber Sie sich wirklich Sorgen machen müssen, ist, die settings_local.py-Datei mit der Host-spezifischen Konfiguration auf dem neuesten Stand zu halten. Alles andere wird automatisch erledigt.

Schauen Sie sich ein Beispiel hier an.

84
Jim

Persönlich benutze ich eine einzelne settings.py für das Projekt, ich habe es einfach nach dem Hostnamen gesucht, auf dem es steht (meine Entwicklungsmaschinen haben Hostnamen, die mit "gabriel" beginnen)

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

dann habe ich an anderen Stellen Dinge wie:

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

und so weiter. Etwas weniger lesbar, aber es funktioniert gut und erspart das gleichzeitige Jonglieren mehrerer Einstellungsdateien.

25
Gabriel Ross

Am Ende von settings.py habe ich folgendes:

try:
    from settings_local import *
except ImportError:
    pass

Auf diese Weise muss ich, wenn ich die Standardeinstellungen überschreiben möchte, einfach Settings_local.py direkt neben settings.py setzen.

22

Ich habe zwei Dateien. settings_base.py enthält allgemeine/Standardeinstellungen und wird in der Quellcodeverwaltung geprüft. Jede Implementierung verfügt über einen separaten settings.py, der am Anfang from settings_base import * ausführt und dann nach Bedarf überschreibt.

11
John Millikin

Der einfachste Weg, den ich gefunden habe, war:

1) Verwenden Sie die Standardeinstellung settings.py für die lokale Entwicklung und 2) Erstellen Sie ein production-settings.py, beginnend mit:

import os
from settings import *

Und überschreiben Sie einfach die Einstellungen, die sich in der Produktion unterscheiden:

DEBUG = False
TEMPLATE_DEBUG = DEBUG


DATABASES = {
    'default': {
           ....
    }
}
7
Andre Bossard

Etwas verwandt, für das Problem der Bereitstellung von Django selbst mit mehreren Datenbanken möchten Sie vielleicht einen Blick auf Djangostack werfen. Sie können ein vollständig kostenloses Installationsprogramm herunterladen, mit dem Sie Apache, Python, Django usw. installieren können. Im Rahmen des Installationsvorgangs können Sie auswählen, welche Datenbank Sie verwenden möchten (MySQL, SQLite, PostgreSQL). Wir verwenden die Installationsprogramme umfangreich, um Implementierungen intern zu automatisieren (sie können im unbeaufsichtigten Modus ausgeführt werden).

2
Josue

Ich habe meine Datei settings.py in einem externen Verzeichnis. Auf diese Weise wird es nicht in der Quellcodeverwaltung überprüft oder von einer Bereitstellung überschrieben. Ich habe dies in die Datei settings.py unter meinem Django-Projekt mit allen Standardeinstellungen eingefügt:

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

Hinweis: Dies ist sehr gefährlich, wenn Sie local_settings.py nicht vertrauen können.  

1
Chase Seibert

Nun, ich verwende diese Konfiguration:

Am Ende von settings.py:

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

Und in 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
1
sacabuche

Zusätzlich zu den von Jim erwähnten mehreren Einstellungsdateien neige ich auch dazu, zwei Einstellungen in meine Datei "settings.py" oben zu übernehmen. BASE_DIR und BASE_URL setzen den Pfad des Codes und die URL zur Basis der Site sowie alle anderen Einstellungen werden modifiziert, um sich an diese anzuhängen.

BASE_DIR = "/home/sean/myapp/" z.B. MEDIA_ROOT = "%smedia/" % BASEDIR

Beim Verschieben des Projekts muss ich also nur diese Einstellungen bearbeiten und nicht die gesamte Datei durchsuchen.

Ich würde auch empfehlen, Fabric und Capistrano (Ruby-Tool, aber es kann zum Bereitstellen von Django-Anwendungen verwendet werden), die die Automatisierung der Remote-Bereitstellung erleichtern.

1
Sean O Donnell

Dies ist ein älterer Beitrag, aber ich denke, wenn ich diesen nützlichen library hinzufüge, werden die Dinge vereinfacht.

Verwenden Sie Django-Konfiguration

Schnellstart

pip install Django-configurations

Ordnen Sie dann die enthaltenen Konfigurationen der Unterklasse zu. Konfigurationsklasse in den settings.py Ihres Projekts oder in einem anderen Modul, das Sie zum Speichern der Einstellungskonstanten verwenden, z.

# mysite/settings.py

from configurations import Configuration

class Dev(Configuration):
    DEBUG = True

Setzen Sie die Umgebungsvariable Django_CONFIGURATION Auf den Namen der soeben erstellten Klasse, z. in ~/.bashrc:

export Django_CONFIGURATION=Dev

und die Umgebungsvariable Django_SETTINGS_MODULE zum Modulimportpfad wie üblich, z. in bash:

export Django_SETTINGS_MODULE=mysite.settings

Alternativ Geben Sie die Option --configuration An, wenn Sie Django Verwaltungsbefehle gemäß Djangos Standardbefehlszeilenoption --settings Verwenden, z :

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

Um Django zu aktivieren, um Ihre Konfiguration zu verwenden, müssen Sie jetzt Ihr manage.py oder wsgi.py Skript zur Verwendung von Django-Konfigurationsversionen der entsprechenden Starterfunktionen, zB ein typisches manage.py mit Django-Konfigurationen würde so aussehen:

#!/usr/bin/env python

import os
import sys

if __== "__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)

Beachten Sie, dass in Zeile 10 nicht das allgemeine Tool Django.core.management.execute_from_command_line, Sondern configurations.management.execute_from_command_line Verwendet wird.

Gleiches gilt für Ihre wsgi.py -Datei, z.

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

Hier verwenden wir nicht die Standardfunktion Django.core.wsgi.get_wsgi_application, Sondern configurations.wsgi.get_wsgi_application.

Das ist es! Sie können Ihr Projekt jetzt mit manage.py und Ihrem bevorzugten WSGI-fähigen Server verwenden.

0
Little Phild

Ich denke, es hängt von der Größe der Site ab, ob Sie SQLite verwenden müssen. Ich habe SQLite erfolgreich auf mehreren kleineren Live-Sites verwendet, und es läuft großartig.

0
Ycros

Ich benutze die Umgebung:

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

Ich glaube, dass dies ein viel besserer Ansatz ist, da Sie eventuell spezielle Einstellungen für Ihre Testumgebung benötigen, und Sie können dies problemlos hinzufügen.

0
slashmili

So viele komplizierte Antworten!

Jede settings.py-Datei enthält:

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

Ich verwende dieses Verzeichnis, um die DEBUG -Variable so zu setzen (setze die Adresse, an der sich der Dev-Code befindet)

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

Jedes Mal, wenn die Datei settings.py verschoben wird, ist DEBUG False und Ihre Produktionsumgebung.

Jedes Mal, wenn Sie andere Einstellungen benötigen als in Ihrer Entwicklungsumgebung, verwenden Sie einfach:

if(DEBUG):
    #Debug setting
else:
    #Release setting
0
JM Desrosiers