Settings organisieren

Normalerweise haben wir mehrere Umgebungen, in denen das Projekt (später) betrieben wird: die lokale Umgebung, eine Staging-Umgebung, Produktion usw. Jede Umgebung kann ihre eigenen spezifischen Einstellungen haben (zum Beispiel: DEBUG = True, ausführlichere Protokollierung, zusätzliche Apps usw.) . Um das zu ermöglichen, brauchen wir eine bessere Organisation der Settings.

Zusätzlich haben wir noch verschiedene Passwörter für Datenbanken, Secret-Keys und

12 Factors

12 Factors ist eine Sammlung von Empfehlungen zum Erstellen verteilter Web-Apps, die in der Cloud einfach bereitzustellen und zu skalieren sind.

Es behandelt neben Themen wie Codebase, Dependencies, Logs, auch das Thema Configuration. Eine der Hauptregeln ist, dass Konfiguration im Environment zu liegen hat, um Konfiguration von Code zu trennen. Passwörter werden also nicht hardcodiert in die Settings geschrieben, sondern als Umgebungsvariable abgelegt.

mehr Infos dazu hier: https://12factor.net/

Warning

Sensible Daten

Sensitive Daten dürfen auf gar keinen Fall in die Versionskontrolle. Diese Dateien müssen zwingend in .gitignore eingetragen werden, damit die Versionskontrolle sie ignoriert.

Auslagern von sensitiven Daten in Umgebungsvariablen

Wir gehen dabei den Weg über Environment-Variablen und das Modul django-environ. Wir könnten auch über os.environ direkt gehen, aber das ist nicht so komfortabel wie das Modul, zb. wenn es zu Key-Errorn kommt.

django-environ

django-environ is the Python package that allows you to use Twelve-factor methodology to configure your Django application with environment variables. Wir können dann eine .env-Datei erstellen, die von django-environ gelesen werden kann. Wir müssen die Umgebungsvariablen also NICHT im Betriebsystem ablegen.

Mehr zu Django Environ: https://django-environ.readthedocs.io/en/latest/

Wir installieren also:

pip install django-environ

.env Datei

Wir legen die Datei event_manager/.env an (also im Projektroot) und füllen sie mit folgendem Inhalt:

DEBUG=on
SECRET_KEY=2930923943209jalsdf023092384020239840
ALLOWED_HOSTS=127.0.0.1 localhost

In diese Datei kommen alle sensitiven Daten der aktuellen Umgebung. Passwörter für die Datenbank, Secret-Key, Port-Angaben und so weiter. Diese Datei wird nicht versioniert, dh. jeder, der das Repository importiert, benötigt ebenfalls wieder seine eigene .env-Datei. Damit man weiß, was in dieser Datei drinzustehen hat, bietet es sich an, eine env_example mit dummy-Inhalt anzulegen. An dieser Stelle noch ein Link zum Generieren eines Secret Keys: https://djecrety.ir/

environ importieren

Wir importieren das Modul in den Settings und weisen den Konfigurationskonstranten die Werte zu:

import environ

env = environ.Env(
  DEBUG=(bool, False)
  SETTINGS_MODULE=(str, "event_manager.settings.dev")
  )
environ.Env.read_env(BASE_DIR / ".env")

DEBUG = env("DEBUG")
SECRET_KEY = env("SECRET_KEY")
ALLOWED_HOSTS = env('ALLOWED_HOSTS').split()

Wir weisen hier der DEBUG-Konstante einen Default-Wert zu, nämlich False. Sollte sich diese KONSTANTE nicht in der .env-Datei befinden, wird der Defaultwert genommen. Sollte kein Defaultwert angegeben worden sein, gibt es einen Key-Error, sollte sich die KONSTANTE nicht in .env befinden.

Wir belegen auch noch SETTINGS_MODULE mit einem Defaultwert.

.env ignorieren

Wir fügen .env in die .gitignore-Datei ein, damit diese Datei nicht versioniert wird und Passwörter am Ende in einem frei zugänglichen Repository landen.

Wenn wir jetzt den runserver starten, sollte das Projekt fehlerfrei laufen.

Gehen wir also jetzt zum nächsten Schritt.

Settings-Datei für jede Umgebung

Jede Umgebung, in der das Projekt betrieben wird, hat andere Einstellung: eine andere Datenbank, ein anderer Logger usw. Im Produktivbetrieb sollte zum Beispiel die django-Debugbar nicht in den MIDDLEWARE stehen. Die TEMPLATES-Liste hingegen wird u.U. auch im Produktivbetrieb die gleiche sein, wie im lokalen Betrieb.

Wir sehen also: es gibt Konfigurationen in den settings.py, die für alle Umgebungen gelten, und manche nur für spezielle.

Unsere Gliederung der Settings wird also so sein, dass es eine Base-Settings gibt, von der alle anderen Settings erben und die überschreiben oder anreichern kann.

Settings organisieren

ein Verzeichnis für die Settings

Wir legen ein neues Verzeichnis an: event_manager/event_manager/settings, in welches die Settings für die verschiedenen Umgebungen gespeichert werden. Die alte settings.py nennen wir um in settings_old.py, da wir diese nicht mehr benötigen.

Settings-Dateien

In das event_manager/event_manager/settings-Verzeichnis speichern wir zwei neue Dateien: base.py und dev.py. Wenn später noch eine weitere Umgebung dazukommt, kann diese hier angelegt werden.

event_manager
    ├───event_manager
         ├───settings
               ├─base.py
               ├─dev.py

Inhalt der base.py

Diese Inhalte sind die Einstellungen, die in allen Umgebungen benötigt werden. Alle sensiblen Inhalte kommen über die Umgebungsvariablen. So sieht sie zur Zeit aus:

from pathlib import Path
import environ


# Build paths inside the project like this: BASE_DIR / 'subdir'.
BASE_DIR = Path(__file__).resolve().parent.parent.parent

env = environ.Env(DEBUG=(bool, False))
environ.Env.read_env(BASE_DIR / ".env")

DEBUG = env("DEBUG")
SECRET_KEY = env("SECRET_KEY")
LOG_LEVEL = env("LOG_LEVEL")

INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "django.contrib.admindocs",
    "crispy_forms",
]

INSTALLED_APPS.extend(["events", "user"])

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.contrib.messages.middleware.MessageMiddleware",
    "django.middleware.clickjacking.XFrameOptionsMiddleware",
]

ROOT_URLCONF = "event_manager.urls"

TEMPLATES = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "DIRS": [BASE_DIR / "event_manager" / "templates"],
        "APP_DIRS": True,
        "OPTIONS": {
            "context_processors": [
                "django.template.context_processors.debug",
                "django.template.context_processors.request",
                "django.contrib.auth.context_processors.auth",
                "django.contrib.messages.context_processors.messages",
            ],
        },
    },
]

WSGI_APPLICATION = "event_manager.wsgi.application"


AUTH_PASSWORD_VALIDATORS = [
    {
        "NAME": "django.contrib.auth.password_validation.UserAttributeSimilarityValidator",
    },
    {
        "NAME": "django.contrib.auth.password_validation.MinimumLengthValidator",
    },
    {
        "NAME": "django.contrib.auth.password_validation.CommonPasswordValidator",
    },
    {
        "NAME": "django.contrib.auth.password_validation.NumericPasswordValidator",
    },
]

# https://docs.djangoproject.com/en/3.2/topics/i18n/
LANGUAGE_CODE = "de"

TIME_ZONE = "Europe/Berlin"
USE_I18N = True
USE_L10N = True
USE_TZ = True

# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/3.2/howto/static-files/

CRISPY_TEMPLATE_PACK = "bootstrap4"
STATIC_URL = "/static/"
STATICFILES_DIRS = [BASE_DIR / "static"]
STATIC_ROOT = BASE_DIR / "staticfiles"

# Default primary key field type
# https://docs.djangoproject.com/en/3.2/ref/settings/#default-auto-field
DEFAULT_AUTO_FIELD = "django.db.models.BigAutoField"
AUTH_USER_MODEL = "user.User"

Inhalt der dev.py

Diese Datei importiert alle Einstellungen der base.py, überschreibt aber bei Bedarf diejenigen Einstellungen, die im Entwicklungsbetrieb anderes sein müssen. So sieht sie zur Zeit aus:

from event_manager.settings.base import *

# für Debug-Toolbar
INTERNAL_IPS = ("127.0.0.1",)

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": BASE_DIR / "db.sqlite3",
    }
}

MIDDLEWARE.extend(["debug_toolbar.middleware.DebugToolbarMiddleware"])

INSTALLED_APPS.extend(
    [
        "debug_toolbar",
    ]
)


DEBUG_TOOLBAR_CONFIG = {
    "INTERCEPT_REDIRECTS": False,
}

Die settings_old.py können wir nun löschen, wenn wir alles übertragen haben.

Best Practice: Settings-Dateien versionieren

Das aktuelle Setup ermögtlicht uns, dass auch jeder User eine eigene Settings Datei haben könnte, also zb. tom.py für den User tom. Trotzdem ist es ratsam, diese privaten, lokalen dev-Settings nicht von der Versionierung auszuschließen. Miskonfigurationen oder bad-pratices können so schneller auffallen.

Bekanntmachen des settings-Folders

Django weiß von unserer neuen Struktur natürlich nichts. Per default wird nach einer Datei settings.py im Projektverzeichnis gesucht. Das müssen wir ändern.

Settings-Modul in Env eintragen

in unsere .evn-Datei legen wir alle Settings, die wir für unseren lokalen Betrieb haben möchte. So auch das Settings-File. Im folgenden Beispiel sagen wir, dass unsere Settings-Datei die event_manager.settings.dev.py sein soll. Auf einem Live-System würde man hier auf die event_manager.settings.prod.py verweisen (die wir noch nicht angelegt haben).

DEBUG=on
SECRET_KEY=2930923943209jalsdf023092384020239840
SETTINGS_MODULE=event_manager.settings.dev
ALLOWED_HOSTS=127.0.0.1 localhost

manage.py

Wir öffnen die Datei event_manager/manage.py und fügen folgenden Inhalt ein:

# andere Imports

# environ importieren
import environ

# Settings Modul aus den Environments holen
env = environ.Env(DEBUG=(bool, False))
environ.Env.read_env()
settings_module = env('SETTINGS_MODULE')


def main():

    # diese Zeile ändern
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", settings_module)
    # anderer Code

wsgi.py

When the WSGI server loads your application, Django needs to import the settings module — that’s where your entire application is defined.

Django uses the DJANGO_SETTINGS_MODULE environment variable to locate the appropriate settings module. It must contain the dotted path to the settings module. You can use a different value for development and production; it all depends on how you organize your settings.

import os

# environ importieren
import environ

# Settings aus den Umgebungsvariablen laden
env = environ.Env(DEBUG=(bool, False))
environ.Env.read_env()
settings_module = env('SETTINGS_MODULE')

from django.core.wsgi import get_wsgi_application

# diese Zeile ändern
os.environ.setdefault("DJANGO_SETTINGS_MODULE", settings_module)

Wenn jetzt der Runserver gestartet wird, sollte alles funktionieren. Wenn wir in der Django-Debugtoolbar auf Einstellungen gehen, sehen wir, dass die Settings-Datei wie gewünscht unsere event_manager.settings.dev ist.

Auf der shell kann man sich die Settings so angucken:

>>> from django.conf import settings
>>> settings.__dict__

Wir müssen an mehreren Stellen environ importieren und die Settings laden. Dies verstößt gegen das DRY-Prinzip. Wir schreiben uns in der Datei event_manager/event_manager/utils.py eine Helper-Funktion, die dies einmal erledigt.

import os
from pathlib import Path
import environ

BASE_DIR = Path(__file__).resolve().parent.parent


def getenv():
    """read .env-File from BASE_DIR and create environ instance"""
    environ.Env.read_env(os.path.join(BASE_DIR, ".env"))

    return environ.Env(
        DEBUG=(bool, False),
        SETTINGS_MODULE=(str, "event_manager.settings.dev"),
    )

Wir brauchen diese Funktion jetzt nur noch zu importieren und nutzen Zum Beispiel in der event_manager/event_manager/settings/base.py

from ..utils import getenv
# anderer code

env = getenv()