Wie verwaltet man lokale vs. Produktionseinstellungen in Django?

Question

Wie sollten die Einstellungen für die lokale Entwicklung und den Produktionsserver gehandhabt werden? Einige von ihnen (wie z. B. Konstanten usw.) können in beiden geändert/zugelassen werden, aber einige von ihnen (wie Pfade zu statischen Dateien) müssen unterschiedlich bleiben und sollten daher nicht jedes Mal überschrieben werden, wenn der neue Code bereitgestellt wird.

Derzeit füge ich alle Konstanten zu settings.py . Aber jedes Mal, wenn ich eine Konstante lokal ändere, muss ich sie auf den Produktionsserver kopieren und die Datei für produktionsspezifische Änderungen bearbeiten... :(

Edit: Da es anscheinend keine Standardantwort auf diese Frage gibt, habe ich die am weitesten verbreitete Methode übernommen.

Answer 1

Ich verwende eine settings_local.py und eine settings_production.py. Nachdem ich verschiedene Optionen ausprobiert habe, habe ich festgestellt, dass es einfach ist, Zeit mit komplexen Lösungen zu verschwenden, wenn sich zwei Einstellungsdateien einfach und schnell anfühlen.

Wenn Sie mod_python/mod_wsgi für Ihr Django-Projekt verwenden, müssen Sie es auf Ihre Einstellungsdatei verweisen. Wenn Sie auf app/settings_local.py auf Ihrem lokalen Server und auf app/settings_production.py auf Ihrem Produktionsserver verweisen, wird das Leben einfach. Bearbeiten Sie einfach die entsprechende Einstellungsdatei und starten Sie den Server neu (der Django-Entwicklungsserver wird automatisch neu gestartet).

Answer 2

Ich verwalte meine Konfigurationen mit Hilfe von django-split-settings .

Es handelt sich um einen direkten Ersatz für die Standardeinstellungen. Sie ist einfach, aber konfigurierbar. Und eine Überarbeitung Ihrer bestehenden Einstellungen ist nicht erforderlich.

Hier ist ein kleines Beispiel (Datei example/settings/__init__.py ):

from split_settings.tools import optional, include
import os

if os.environ['DJANGO_SETTINGS_MODULE'] == 'example.settings':
    include(
        'components/default.py',
        'components/database.py',
        # This file may be missing:
        optional('local_settings.py'),

        scope=globals()
    )

Das war's.

Update

Ich schrieb eine Blog-Beitrag über die Verwaltung django die Einstellungen mit django-split-sttings . Schauen Sie mal!

Answer 3

Denken Sie daran, dass settings.py eine Live-Code-Datei ist. Unter der Annahme, dass Sie DEBUG in der Produktion nicht eingestellt haben (was eine bewährte Praxis ist), können Sie etwas tun wie:

if DEBUG:
    STATIC_PATH = /path/to/dev/files
else:
    STATIC_PATH = /path/to/production/files

Ziemlich einfach, aber Sie könnten theoretisch jede beliebige Komplexitätsstufe erreichen, die nur auf dem Wert von DEBUG basiert - oder jeder anderen Variablen oder Codeprüfung, die Sie verwenden möchten.

Answer 4

Das Problem bei den meisten dieser Lösungen ist, dass Sie entweder Ihre lokalen Einstellungen anwenden müssen vor die üblichen, oder nach sie.

Es ist also nicht möglich, Dinge außer Kraft zu setzen wie

• die env-spezifischen Einstellungen definieren die Adressen für den Memcached-Pool, und in der Haupteinstellungsdatei wird dieser Wert zur Konfiguration des Cache-Backends verwendet
• die env-spezifischen Einstellungen fügen Anwendungen/Middleware zum Standard hinzu oder entfernen sie

zur gleichen Zeit.

Eine Lösung kann durch die Verwendung von Konfigurationsdateien im "ini"-Stil mit der Klasse ConfigParser implementiert werden. Sie unterstützt mehrere Dateien, Lazy-String-Interpolation, Standardwerte und eine Menge anderer Goodies. Sobald eine Anzahl von Dateien geladen wurde, können weitere Dateien geladen werden, deren Werte die vorherigen überschreiben, falls vorhanden.

Sie laden eine oder mehrere Konfigurationsdateien, abhängig von der Rechneradresse, den Umgebungsvariablen und sogar den Werten in zuvor geladenen Konfigurationsdateien. Dann verwenden Sie einfach die geparsten Werte, um die Einstellungen auszufüllen.

Eine Strategie, die ich erfolgreich angewandt habe, war:

• Einen Standard laden defaults.ini fichier
• Überprüfen Sie den Rechnernamen und laden Sie alle Dateien, die mit dem umgekehrten FQDN übereinstimmen, von der kürzesten bis zur längsten Übereinstimmung (ich lud also net.ini entonces net.domain.ini entonces net.domain.webserver01.ini , wobei jede einzelne möglicherweise die Werte der vorherigen überschreibt). Dies gilt auch für die Rechner der Entwickler, so dass jeder seinen bevorzugten Datenbanktreiber usw. für die lokale Entwicklung einrichten kann.
• Prüfen Sie, ob ein "Clustername" deklariert ist, und laden Sie in diesem Fall cluster.cluster_name.ini die Dinge wie Datenbank- und Cache-IPs definieren kann

Als Beispiel dafür, was Sie damit erreichen können, können Sie einen "Subdomain"-Wert pro env definieren, der dann in den Standardeinstellungen verwendet wird (als hostname: %(subdomain).whatever.net ), um alle notwendigen Hostnamen und Cookies zu definieren, die Django benötigt, um zu funktionieren.

Dies ist die trockenste Lösung, die ich finden konnte, denn die meisten (bestehenden) Dateien hatten nur 3 oder 4 Einstellungen. Darüber hinaus musste ich die Kundenkonfiguration verwalten, also gab es einen zusätzlichen Satz von Konfigurationsdateien (mit Dingen wie Datenbanknamen, Benutzern und Passwörtern, zugewiesener Subdomain usw.), eine oder mehrere pro Kunde.

Man kann dies so niedrig oder so hoch wie nötig skalieren, man gibt einfach in der Konfigurationsdatei die Schlüssel an, die man pro Umgebung konfigurieren möchte, und sobald eine neue Konfiguration benötigt wird, setzt man den vorherigen Wert in die Standardkonfiguration und überschreibt ihn, wo nötig.

Dieses System hat sich als zuverlässig erwiesen und funktioniert gut mit der Versionskontrolle. Es wurde lange Zeit für die Verwaltung von zwei separaten Clustern von Anwendungen (15 oder mehr separate Instanzen der Django-Site pro Maschine) mit mehr als 50 Kunden verwendet, wobei die Cluster je nach Laune des Systemadministrators ihre Größe und Mitglieder änderten...

Answer 5

1 - Erstellen Sie einen neuen Ordner in Ihrer Anwendung und benennen Sie ihn nach Einstellungen.

2 - Erstellen Sie nun eine neue __init__.py Datei und schreiben Sie darin

from .base import *

try:
    from .local import *
except:
    pass

try:
    from .production import *
except:
    pass

3 - Erstellen Sie drei neue Dateien im Ordner "Einstellungen". local.py y production.py y base.py .

4 - Innen base.py kopieren Sie den gesamten Inhalt der vorherigen settings.py und benennen Sie ihn in einen anderen Namen um, z.B. old_settings.py .

5 - Ändern Sie in der Datei base.py den Pfad BASE_DIR so, dass er auf den neuen Pfad der Einstellungen zeigt

Alter Weg-> BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

Neuer Pfad -> BASE_DIR = os.path.dirname(os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

Auf diese Weise kann das Projekt strukturiert und zwischen Produktion und lokaler Entwicklung verwaltet werden.