Vorwort
Im letzten Teil ging es um das Installieren von Python und der Virtuellen Umgebung auf dem Produktionsserver. Jetzt haben wir uns mehrere Umgebungen geschaffen - unsere Entwicklungsumgebung bei uns Lokal und unsere Produktionsumgebung auf dem Server. Django lädt seine Einstellungen momentan aus einer settings.py Datei. Diese Datei müssen wir nun in mehrere Dateien aufteilen, sodass wir eine Datei als Basis, eine Datei als Enwticklungsumgebung und eine Datei für die Produktionsumgebung haben. Im Nachhinein können wir dann verschiedene Dateien hinzufügen, z.B. für eine Testumgebung.
Ordner erstellen
# Nachschauen ob unsere settings.py Datei vorhanden ist
cd meine_app/meine_app/
ls -l settings.py
# Erstellen des settings - Verzeichnis, neben deiner settings.py
mkdir settings
# Da in settings.py bereits alle Einstellungen Vorhanden sind, können wir das ganze einfach umbenennen in base.py. Das ist die Basis unserer Einstellungen
# settings.py in base.py umbenennen
mv settings.py settings/base.py
# Erstellen weiterer Dateien
cd settings/
touch __init__.py development.py production.py
init.py
Diese Datei füllen wir mit folgendem Inhalt, damit je nach env unseren richtigen Einstellungen geladen werden.
# Wir importieren alles aus der base.py
from .base import *
import os
# Wenn in unserem env ENV_NAME=production gesetzt ist, werden die Produktionseinstellungen aktiv, sonst die Entwicklungseinstellungen
if os.environ.get("ENV_NAME") == 'production':
from .production import *
else:
from .development import *
Das ganze kannst du nun testen:
# Füge deinem production.py folgendes hinzu:
print("--USING PRODUCTION SETTINGS--")
# Bringe ENV_NAME=production in dein env
export ENV_NAME=production
# Beim Server start sollte nun dein print aus dem production.py angezeigt werden.
python manage.py runserver
PS: Dein settings - Modul wird im manage.py folgendermaßen aufgerufen:
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "testproj.settings")
Anpassung in development.py
# Zum debuggen, lasse dir Anzeigen ob du deine development settings benutzt
print("--- Using development Settings ---")
Hole dir einige Einstellungen aus base.py
Folgende Einstellungen musst du aus base.py entfernen und in development.py unterbringen:
# Bewege deinen SECRET_KEY von base.py in development.py
SECRET_KEY = "django-insecure-******************************************"
# Hole dir deine DEBUG & ALLOWED_HOSTS einstellungen aus base.py
DEBUG = True
ALLOWED_HOSTS = []
# Beim kopieren der Datenbank musst du BASE_DIR importieren
from .base import BASE_DIR
DATABASES = {
"default": {
"ENGINE": "django.db.backends.sqlite3",
"NAME": BASE_DIR / "db.sqlite3",
}
}
Anpassungen in production.py
Hole dir deinen SECRET_KEY mit python
python3
>>> import secrets
>>> print(secrets.token_urlsafe())
AZ-Z_-qBzjZmJuDaX40PZVS3JmcqfdOkGU2H5ErvUPg
Baue deine production.py auf:
# Zum debuggen
print("--- Using production Settings ---")
SECRET_KEY = "********************************"
# Für Produktion DEBUG Modus ausschalten
DEBUG = False
# Wenn du eine Domain über A-Record mit deinem Server verbunden hast, kannst du die Domain nutzen
ALLOWED_HOSTS = [".meineapp.de", "192.168.178.23"]
# Nutze deine Daten aus - 2. PostgreSQL für django aufsetzen.
DATABASES = {
"default": {
"ENGINE": "django.db.backends.postgresql",
"OPTIONS": {
"options": "-c search_path=meine_app_schema"
},
"NAME": "meine_app",
"USER": "mein_nutzer",
"PASSWORD": "**************",
"HOST": "localhost",
"PORT": "5432"
}
}
Füge dein production.py im .gitignore hinzu
Deine Produktionseinstellungen sollen nie in deine Codehistorie commited werden. Füge deinem .gitignore folgendes hinzu:
meine_app/meine_app/settings/production.py
Jetzt kannst du dein production.py auf deinen Server syncen
rsync -r meine_app/meine_app/settings/production.py 192.168.178.23:/srv/www/meine_repository/meine_app/meine_app/settings/production.py
Anpassung in base.py
# Du musst deinem BASE_DIR ein .parent hinzufügen, da deine Einstellungen jetzt 1 Verzeichnis tiefer liegen.
BASE_DIR = Path(__file__).resolve().parent.parent.parent
Deine .bashrc in Produktion
Füge deiner .bashrc folgendes hinzu:
# Setze dein env richtig
export ENV_NAME=producti on
# Du wirst den nutzer vor allem hier nutzen
cd /srv/www/meine_repository
# Aktiviere dir gleich dein Python
source /srv/www/meine_repository/venv/bin/activate
Datenbankmigration - python manage.py migrate
Jetzt kannst du deine Datenbank das erste mal in Produktion migrieren:
ssh [email protected]
cd meine_app/
python manage.py migrate
# So sollte der Output ausschauen:
Operations to perform:
Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
Applying contenttypes.0001_initial... OK
Applying auth.0001_initial... OK
Applying admin.0001_initial... OK
Applying admin.0002_logentry_remove_auto_add... OK
Applying admin.0003_logentry_add_action_flag_choices... OK
Applying contenttypes.0002_remove_content_type_name... OK
Applying auth.0002_alter_permission_name_max_length... OK
Applying auth.0003_alter_user_email_max_length... OK
Applying auth.0004_alter_user_username_opts... OK
Applying auth.0005_alter_user_last_login_null... OK
Applying auth.0006_require_contenttypes_0002... OK
Applying auth.0007_alter_validators_add_error_messages... OK
Applying auth.0008_alter_user_username_max_length... OK
Applying auth.0009_alter_user_last_name_max_length... OK
Applying auth.0010_alter_group_name_max_length... OK
Applying auth.0011_update_proxy_permissions... OK
Applying auth.0012_alter_user_first_name_max_length... OK
Applying sessions.0001_initial... OK
PS: Viel Spaß beim Coden,
Dein Ruben
Mein Blog# Der Settings Ordner - django in Produktion Teil 4
Vorwort
Im letzten Teil ging es um das Installieren von Python und der Virtuellen Umgebung auf dem Produktionsserver. Jetzt haben wir uns mehrere Umgebungen geschaffen - unsere Entwicklungsumgebung bei uns Lokal und unsere Produktionsumgebung auf dem Server. Django lädt seine Einstellungen momentan aus einer settings.py Datei. Diese Datei müssen wir nun in mehrere Dateien aufteilen, sodass wir eine Datei als Basis, eine Datei als Enwticklungsumgebung und eine Datei für die Produktionsumgebung haben. Im Nachhinein können wir dann verschiedene Dateien hinzufügen, z.B. für eine Testumgebung.
Ordner erstellen
# Nachschauen ob unsere settings.py Datei vorhanden ist
cd meine_app/meine_app/
ls -l settings.py
# Erstellen des settings - Verzeichnis, neben deiner settings.py
mkdir settings
# Da in settings.py bereits alle Einstellungen Vorhanden sind, können wir das ganze einfach umbenennen in base.py. Das ist die Basis unserer Einstellungen
# settings.py in base.py umbenennen
mv settings.py settings/base.py
# Erstellen weiterer Dateien
cd settings/
touch __init__.py development.py production.py
init.py
Diese Datei füllen wir mit folgendem Inhalt, damit je nach env unseren richtigen Einstellungen geladen werden.
# Wir importieren alles aus der base.py
from .base import *
import os
# Wenn in unserem env ENV_NAME=production gesetzt ist, werden die Produktionseinstellungen aktiv, sonst die Entwicklungseinstellungen
if os.environ.get("ENV_NAME") == 'production':
from .production import *
else:
from .development import *
Das ganze kannst du nun testen:
# Füge deinem production.py folgendes hinzu:
print("--USING PRODUCTION SETTINGS--")
# Bringe ENV_NAME=production in dein env
export ENV_NAME=production
# Beim Server start sollte nun dein print aus dem production.py angezeigt werden.
python manage.py runserver
PS: Dein settings - Modul wird im manage.py folgendermaßen aufgerufen:
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "testproj.settings")
Anpassung in development.py
# Zum debuggen, lasse dir Anzeigen ob du deine development settings benutzt
print("--- Using development Settings ---")
Hole dir einige Einstellungen aus base.py
Folgende Einstellungen musst du aus base.py entfernen und in development.py unterbringen:
# Bewege deinen SECRET_KEY von base.py in development.py
SECRET_KEY = "django-insecure-******************************************"
# Hole dir deine DEBUG & ALLOWED_HOSTS einstellungen aus base.py
DEBUG = True
ALLOWED_HOSTS = []
# Beim kopieren der Datenbank musst du BASE_DIR importieren
from .base import BASE_DIR
DATABASES = {
"default": {
"ENGINE": "django.db.backends.sqlite3",
"NAME": BASE_DIR / "db.sqlite3",
}
}
Anpassungen in production.py
Hole dir deinen SECRET_KEY mit python
python3
>>> import secrets
>>> print(secrets.token_urlsafe())
AZ-Z_-qBzjZmJuDaX40PZVS3JmcqfdOkGU2H5ErvUPg
Baue deine production.py auf:
# Zum debuggen
print("--- Using production Settings ---")
SECRET_KEY = "********************************"
# Für Produktion DEBUG Modus ausschalten
DEBUG = False
# Wenn du eine Domain über A-Record mit deinem Server verbunden hast, kannst du die Domain nutzen
ALLOWED_HOSTS = [".meineapp.de", "192.168.178.23"]
# Nutze deine Daten aus - 2. PostgreSQL für django aufsetzen.
DATABASES = {
"default": {
"ENGINE": "django.db.backends.postgresql",
"OPTIONS": {
"options": "-c search_path=meine_app_schema"
},
"NAME": "meine_app",
"USER": "mein_nutzer",
"PASSWORD": "**************",
"HOST": "localhost",
"PORT": "5432"
}
}
Füge dein production.py im .gitignore hinzu
Deine Produktionseinstellungen sollen nie in deine Codehistorie commited werden. Füge deinem .gitignore folgendes hinzu:
meine_app/meine_app/settings/production.py
Jetzt kannst du dein production.py auf deinen Server syncen
rsync -r meine_app/meine_app/settings/production.py 192.168.178.23:/srv/www/meine_repository/meine_app/meine_app/settings/production.py
Anpassung in base.py
# Du musst deinem BASE_DIR ein .parent hinzufügen, da deine Einstellungen jetzt 1 Verzeichnis tiefer liegen.
BASE_DIR = Path(__file__).resolve().parent.parent.parent
Deine .bashrc in Produktion
Füge deiner .bashrc folgendes hinzu:
# Setze dein env richtig
export ENV_NAME=producti on
# Du wirst den nutzer vor allem hier nutzen
cd /srv/www/meine_repository
# Aktiviere dir gleich dein Python
source /srv/www/meine_repository/venv/bin/activate
Datenbankmigration - python manage.py migrate
Jetzt kannst du deine Datenbank das erste mal in Produktion migrieren:
ssh [email protected]
cd meine_app/
python manage.py migrate
# So sollte der Output ausschauen:
Operations to perform:
Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
Applying contenttypes.0001_initial... OK
Applying auth.0001_initial... OK
Applying admin.0001_initial... OK
Applying admin.0002_logentry_remove_auto_add... OK
Applying admin.0003_logentry_add_action_flag_choices... OK
Applying contenttypes.0002_remove_content_type_name... OK
Applying auth.0002_alter_permission_name_max_length... OK
Applying auth.0003_alter_user_email_max_length... OK
Applying auth.0004_alter_user_username_opts... OK
Applying auth.0005_alter_user_last_login_null... OK
Applying auth.0006_require_contenttypes_0002... OK
Applying auth.0007_alter_validators_add_error_messages... OK
Applying auth.0008_alter_user_username_max_length... OK
Applying auth.0009_alter_user_last_name_max_length... OK
Applying auth.0010_alter_group_name_max_length... OK
Applying auth.0011_update_proxy_permissions... OK
Applying auth.0012_alter_user_first_name_max_length... OK
Applying sessions.0001_initial... OK
PS: Viel Spaß beim Coden,
Dein Ruben