Django Tutorial Teil 11: Django in die Produktion bringen

Sobald Ihre Website fertig ist (oder fertig genug, um mit öffentlichen Tests zu beginnen), müssen Sie sie irgendwo hosten, das öffentlicher und zugänglicher ist als Ihr persönlicher Entwicklungscomputer.

Bisher haben Sie in einer Entwicklungsumgebung gearbeitet, den Django-Entwicklungswebserver verwendet, um Ihre Website für den lokalen Browser/das lokale Netzwerk freizugeben, und Ihre Website mit (unsicheren) Entwicklungseinstellungen betrieben, die Debugging und andere private Informationen offenlegen. Bevor Sie eine Website extern hosten können, müssen Sie zuerst:

• Einige Änderungen an den Projekteinstellungen vornehmen.
• Eine Umgebung für das Hosting der Django-App auswählen.
• Eine Umgebung für das Hosting statischer Dateien wählen.
• Eine produktionsfähige Infrastruktur zum Bereitstellen Ihrer Website einrichten.

Dieses Tutorial gibt einige Hinweise zu Ihren Optionen bei der Wahl eines Hosting-Anbieters, einen kurzen Überblick darüber, was Sie tun müssen, um Ihre Django-App für die Produktion bereit zu machen, und ein funktionierendes Beispiel dafür, wie die LocalLibrary-Website auf dem Railway-Cloud-Hosting-Dienst installiert wird.

Die Produktionsumgebung ist die Umgebung, die vom Servercomputer bereitgestellt wird, auf dem Ihre Website für den externen Zugriff ausgeführt wird. Die Umgebung umfasst:

• Computerhardware, auf der die Website ausgeführt wird.
• Betriebssystem (z. B. Linux, Windows).
• Laufzeit der Programmiersprache und Framework-Bibliotheken, auf denen Ihre Website basiert.
• Webserver, der Seiten und andere Inhalte bereitstellt (z. B. Nginx, Apache).
• Anwendungsserver, der „dynamische“ Anfragen zwischen Ihrer Django-Website und dem Webserver weiterleitet.
• Datenbanken, auf die Ihre Website angewiesen ist.

Der Servercomputer könnte sich auf Ihrem Gelände befinden und mit einer schnellen Verbindung mit dem Internet verbunden sein, aber es ist weit häufiger, einen Computer zu verwenden, der „in der Cloud“ gehostet wird. Das bedeutet, dass Ihr Code auf einem entfernten Computer (oder möglicherweise einem „virtuellen“ Computer) im Rechenzentrum Ihres Hosting-Unternehmens ausgeführt wird. Der entfernte Server bietet in der Regel ein garantiertes Maß an Computerressourcen (CPU, RAM, Speicher, etc.) und Internetkonnektivität zu einem bestimmten Preis.

Diese Art von aus der Ferne zugänglicher Hard- und Networking-Hardware wird als Infrastructure as a Service (IaaS) bezeichnet. Viele IaaS-Anbieter bieten Optionen für die Vorinstallation eines bestimmten Betriebssystems an, auf das Sie die anderen Komponenten Ihrer Produktionsumgebung installieren müssen. Andere Anbieter erlauben es Ihnen, vollständigere Umgebungen auszuwählen, möglicherweise einschließlich eines vollständigen Django- und Web-Server-Setups.

Andere Hosting-Anbieter unterstützen Django im Rahmen eines Platform as a Service (PaaS)-Angebots. Bei dieser Art von Hosting müssen Sie sich nicht um den größten Teil Ihrer Produktionsumgebung (Webserver, Anwendungsserver, Lastenausgleich) kümmern, da die Host-Plattform dies für Sie übernimmt — zusammen mit dem meisten, was Sie tun müssen, um Ihre Anwendung zu skalieren. Das macht das Deployment recht einfach, weil Sie sich einfach auf Ihre Webanwendung konzentrieren können und nicht auf die gesamte andere Serverinfrastruktur.

Einige Entwickler werden die erhöhte Flexibilität, die IaaS bietet, über PaaS wählen, während andere die reduzierte Wartung und einfachere Skalierung von PaaS schätzen. Wenn Sie anfangen, ist es viel einfacher, Ihre Website auf einem PaaS-System einzurichten, und genau das werden wir in diesem Tutorial tun.

Es gibt viele Hosting-Anbieter, die bekannt dafür sind, entweder aktiv Django zu unterstützen oder gut mit Django zu funktionieren, darunter: Heroku, DigitalOcean, Railway, Python Anywhere, Amazon Web Services, Azure, Google Cloud, Hetzner, und Vultr Cloud Compute — um nur einige zu nennen. Diese Anbieter bieten verschiedene Arten von Umgebungen (IaaS, PaaS) und unterschiedliche Ebenen an Computer- und Netzwerkressourcen zu unterschiedlichen Preisen.

Einige der Überlegungen bei der Wahl eines Hosts:

• Wie beschäftigt Ihre Website voraussichtlich sein wird und die Kosten für die Daten- und Rechenressourcen, die erforderlich sind, um diese Nachfrage zu decken.
• Level der Unterstützung für horizontale Skalierung (Hinzufügen von mehr Maschinen) und vertikale Skalierung (Upgrade auf leistungsfähigere Maschinen) und die Kosten dafür.
• Wo der Anbieter Rechenzentren hat und wo der Zugriff daher am schnellsten sein wird.
• Historische Verfügbarkeit und Ausfallzeiten des Hosts.
• Tools zur Verwaltung der Website — sind sie einfach zu bedienen und sicher (z. B. SFTP vs. FTP).
• Eingebaute Frameworks zur Überwachung Ihres Servers.
• Bekannte Einschränkungen. Einige Hosts blockieren absichtlich bestimmte Dienste (z. B. E-Mail). Andere bieten nur eine bestimmte Anzahl von Stunden „Live-Zeit“ in einigen Preisklassen oder bieten nur eine kleine Menge Speicherplatz.
• Zusätzliche Vorteile. Einige Anbieter bieten kostenlose Domainnamen und Unterstützung für TLS-Zertifikate, die Sie sonst bezahlen müssten.
• Ob die „kostenlose“ Stufe, auf die Sie sich verlassen, mit der Zeit abläuft und ob die Kosten für das Upgrade auf eine teurere Stufe bedeuten, dass Sie von Anfang an einen anderen Dienst hätten nutzen sollen!

Die gute Nachricht ist, wenn Sie gerade erst anfangen, dass es ziemlich viele Websites gibt, die „kostenlose“ Computerumgebungen bereitstellen, die für Bewertung und Tests gedacht sind. Dies sind in der Regel relativ beschränkte/limitierte Umgebungen und Sie müssen sich bewusst sein, dass sie nach einer gewissen Einführungszeit ablaufen können oder andere Einschränkungen haben. Sie sind jedoch großartig für das Testen von Websites mit geringem Datenverkehr in einer gehosteten Umgebung und können einen einfachen Übergang zu einer bezahlten Lösung ermöglichen, wenn Ihre Website mehr Verkehr hat. Beliebte Entscheidungen in diesem Bereich sind Vultr Cloud Compute, Python Anywhere, Amazon Web Services, Microsoft Azure, und so weiter.

Die meisten Anbieter bieten auch eine „grundlegende“ Stufe an, die für kleine Produktionswebsites gedacht ist und nützlichere Level von Rechenleistung und weniger Einschränkungen bereitstellt. Railway, Heroku, und DigitalOcean sind Beispiele für beliebte Hosting-Anbieter, die eine relativ preiswerte grundlegende Rechenstufe haben (im Bereich von 5 bis 10 USD pro Monat).

Die mit django-admin und manage.py erstellte Django-Skeleton-Website ist so konfiguriert, dass die Entwicklung einfacher ist. Viele der Django-Projekteinstellungen (wie in settings.py angegeben) sollten für die Produktion anders sein, entweder aus Sicherheits- oder Leistungsgründen.

Die kritischen Einstellungen, die Sie überprüfen müssen, sind:

• DEBUG. Dies sollte in der Produktion auf False gesetzt werden (DEBUG = False). Dies verhindert, dass sensible/vertrauliche Debug-Trace- und Variableninformationen angezeigt werden.
• SECRET_KEY. Dies ist ein großer, zufälliger Wert, der zum Beispiel für CSRF-Schutz verwendet wird. Es ist wichtig, dass der in der Produktion verwendete Schlüssel nicht in der Versionskontrolle ist oder außerhalb des Produktionsservers zugänglich ist.

Die Django-Dokumente schlagen vor, dass geheime Informationen am besten aus einer Umgebungsvariable geladen oder aus einer dateibasierten, nur für den Server zugänglichen Datei gelesen werden sollten. Lassen Sie uns die LocalLibrary-Anwendung so ändern, dass wir unsere SECRET_KEY- und DEBUG-Variablen aus Umgebungsvariablen lesen, falls sie definiert sind, und auf Werte zurückfallen, die in einer .env-Datei im Root definiert sind, und schließlich auf die im Konfigurationsfile definierten Standardwerte. Dies ist sehr flexibel, da es jede von der Hosting-Umgebung unterstützte Konfiguration erlaubt.

Zum Lesen von Umgebungswerten aus einer Datei verwenden wir python-dotenv. Dies ist eine Bibliothek zum Lesen von Schlüssel-Wert-Paaren aus einer Datei und deren Verwendung als Umgebungsvariablen, aber nur, wenn die entsprechende Umgebungsvariable nicht definiert ist.

Installieren Sie die Bibliothek in Ihrer virtuellen Umgebung wie gezeigt (und aktualisieren Sie auch Ihre requirements.txt-Datei):

pip3 install python-dotenv

Öffnen Sie dann /locallibrary/settings.py und fügen Sie den folgenden Code nach BASE_DIR ein, aber vor der Sicherheitswarnung: # SECURITY WARNING: keep the secret key used in production secret!

# Support env variables from .env file if defined
import os
from dotenv import load_dotenv
env_path = load_dotenv(os.path.join(BASE_DIR, '.env'))
load_dotenv(env_path)

Dies lädt die .env-Datei aus dem Root der Webanwendung. Variablen, die in der Datei als KEY=VALUE definiert sind, werden importiert, wenn der Schlüssel in os.environ.get('<KEY>', '<DEFAULT VALUE>') verwendet wird, falls definiert.

Deaktivieren Sie als nächstes die ursprüngliche SECRET_KEY-Konfiguration und fügen Sie die neuen Zeilen wie unten gezeigt hinzu. Während der Entwicklung wird keine Umgebungsvariable für den Schlüssel angegeben, sodass der Standardwert verwendet wird (es sollte egal sein, welchen Schlüssel Sie hier verwenden, oder ob der Schlüssel „veröffentlicht“ wird, denn Sie werden ihn in der Produktion nicht verwenden).

# SECURITY WARNING: keep the secret key used in production secret!
# SECRET_KEY = 'django-insecure-&psk#na5l=p3q8_a+-$4w1f^lt3lx1c@d*p4x$ymm_rn7pwb87'
import os
SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY', 'django-insecure-&psk#na5l=p3q8_a+-$4w1f^lt3lx1c@d*p4x$ymm_rn7pwb87')

Kommentieren Sie dann die bestehende DEBUG-Einstellung aus und fügen Sie die neue Zeile wie unten gezeigt hinzu.

# SECURITY WARNING: don't run with debug turned on in production!
# DEBUG = True
DEBUG = os.environ.get('DJANGO_DEBUG', '') != 'False'

Der Wert von DEBUG ist standardmäßig True, wird jedoch nur dann False, wenn der Wert der DJANGO_DEBUG-Umgebungsvariable auf False gesetzt wird oder DJANGO_DEBUG=False in der .env-Datei gesetzt wird. Bitte beachten Sie, dass Umgebungsvariablen Zeichenfolgen und keine Python-Typen sind. Daher müssen wir Zeichenfolgen vergleichen. Die einzige Möglichkeit, die DEBUG-Variable auf False zu setzen, besteht darin, sie tatsächlich auf die Zeichenfolge False zu setzen.

Sie können die Umgebungsvariable auf "False" unter Linux durch Eingabe des folgenden Befehls einstellen:

export DJANGO_DEBUG=False

Eine vollständige Checkliste der Einstellungen, die Sie ändern möchten, finden Sie in der Deployment-Checkliste (Django-Dokumentation). Eine Anzahl dieser Einstellungen kann auch mit dem folgenden Terminalbefehl aufgelistet werden:

python3 manage.py check --deploy

Gunicorn ist ein reiner Python-HTTP-Server, der üblicherweise für das Anbinden von Django-WSGI-Anwendungen verwendet wird.

Obwohl wir Gunicorn nicht benötigen, um unsere LocalLibrary-Anwendung während der Entwicklung bereitzustellen, werden wir es lokal installieren, damit es Teil unserer requirements wird, wenn die Anwendung bereitgestellt wird.

Stellen Sie zuerst sicher, dass Sie sich in der Python-Virtual-Umgebung befinden, die bei Einrichtung der Entwicklungsumgebung erstellt wurde (verwenden Sie den Befehl workon [name-of-virtual-environment]). Installieren Sie anschließend Gunicorn lokal in der Befehlszeile mit pip:

pip3 install gunicorn

SQLite, die Standard-Django-Datenbank, die Sie für die Entwicklung verwendet haben, ist eine vernünftige Wahl für kleine bis mittelgroße Websites. Leider kann sie auf einigen beliebten Hosting-Diensten wie Heroku nicht verwendet werden, da diese keinen dauerhaften Datenspeicher in der Anwendungsumgebung bereitstellen (eine Anforderung von SQLite). Während dies uns für die bereitgestellten Beispielbereitstellungen nicht betrifft, zeigen wir Ihnen einen anderen Ansatz, der auf Railway, Heroku und einigen anderen Diensten funktioniert.

Der Ansatz besteht darin, eine Datenbank zu verwenden, die in einem eigenen Prozess irgendwo im Internet läuft und auf die die Django-Bibliotheksanwendung über eine Adresse zugreift, die als Umgebungsvariable übergeben wird. In diesem Fall verwenden wir eine Postgres-Datenbank, die ebenfalls auf Railway gehostet wird, aber Sie könnten jeden beliebigen Datenbank-Hostingdienst verwenden, den Sie möchten.

Die Datenbankverbindungsinformationen werden an Django über eine Umgebungsvariable namens DATABASE_URL übergeben. Anstatt diese Informationen fest in Django zu codieren, verwenden wir das Paket dj-database-url, um die DATABASE_URL-Umgebungsvariable zu analysieren und automatisch in das von Django gewünschte Konfigurationsformat zu konvertieren. Zusätzlich zur Installation des dj-database-url Pakets müssen wir auch psycopg2 installieren, da Django dies benötigt, um mit Postgres-Datenbanken zu interagieren.

dj-database-url

dj-database-url wird verwendet, um die Django-Datenbankkonfiguration aus einer Umgebungsvariable zu extrahieren.

Installieren Sie es lokal, damit es Teil unserer requirements wird, um auf dem Bereitstellungsserver eingerichtet zu werden:

pip3 install dj-database-url

settings.py

Öffnen Sie /locallibrary/settings.py und kopieren Sie die folgende Konfiguration ans Ende der Datei:

# Update database configuration from $DATABASE_URL environment variable (if defined)
import dj_database_url

if 'DATABASE_URL' in os.environ:
    DATABASES['default'] = dj_database_url.config(
        conn_max_age=500,
        conn_health_checks=True,
    )

Django wird nun die Datenbankkonfiguration in DATABASE_URL verwenden, wenn die Umgebungsvariable gesetzt ist; andernfalls wird die SQLite-Standarddatenbank verwendet. Der Wert conn_max_age=500 macht die Verbindung persistent, was viel effizienter ist, als die Verbindung bei jedem Anforderungsvorgang neu zu erstellen (dies ist optional und kann bei Bedarf entfernt werden).

psycopg2

Django benötigt psycopg2, um mit Postgres-Datenbanken zu arbeiten. Installieren Sie es lokal, damit es Teil unserer requirements für Railway wird, um auf dem Remote-Server eingerichtet zu werden:

pip3 install psycopg2-binary

Beachten Sie, dass Django standardmäßig die SQLite-Datenbank während der Entwicklung verwenden wird, es sei denn, DATABASE_URL ist gesetzt. Sie können vollständig auf Postgres umschalten und dieselbe gehostete Datenbank für Entwicklung und Produktion verwenden, indem Sie dieselbe Umgebungsvariable in Ihrer Entwicklungsumgebung festlegen (Railway macht es einfach, dieselbe Umgebung für Produktion und Entwicklung zu verwenden). Alternativ können Sie auch eine selbst gehostete Postgres-Datenbank auf Ihrem lokalen Computer installieren und verwenden.

Während der Entwicklung verwenden wir Django und den Django-Entwicklungswebserver, um sowohl unsere dynamischen HTML- als auch unsere statischen Dateien (CSS, JavaScript, etc.) bereitzustellen. Dies ist für statische Dateien ineffizient, weil die Anfragen durch Django gehen müssen, obwohl Django nichts damit macht. Obwohl dies während der Entwicklung keine Rolle spielt, hätte es erhebliche Leistungsprobleme, wenn wir denselben Ansatz in der Produktion verwenden würden.

In der Produktionsumgebung trennen wir typischerweise die statischen Dateien von der Django-Webanwendung, was es einfacher macht, sie direkt vom Webserver oder einem Content Delivery Network (CDN) bereitzustellen.

Die wichtigen Einstellungsvariablen sind:

• STATIC_URL: Dies ist die Basis-URL-Position, von der aus statische Dateien bereitgestellt werden, zum Beispiel auf einem CDN.
• STATIC_ROOT: Dies ist der absolute Pfad zu einem Verzeichnis, in dem Djangos collectstatic-Tool alle statischen Dateien sammelt, die in unseren Templates referenziert werden. Sobald gesammelt, können sie dann als Gruppe zu dem Ort hochgeladen werden, wo die Dateien gehostet werden sollen.
• STATICFILES_DIRS: Dies listet zusätzliche Verzeichnisse auf, in denen Djangos collectstatic-Tool nach statischen Dateien suchen soll.

Django-Templates beziehen sich auf Standorte statischer Dateien relativ zu einem static-Tag (Sie können dies im Basistemplate sehen, das in Django-Tutorial Teil 5: Erstellen unserer Homepage definiert ist), welches wiederum mit der STATIC_URL-Einstellung korrespondiert. Statische Dateien können also auf jedem Host hochgeladen werden und Sie können Ihre Anwendung aktualisieren, um sie unter dieser Einstellung zu finden.

Das collectstatic-Tool wird verwendet, um statische Dateien in dem durch die STATIC_ROOT-Projekteinstellung definierten Ordner zu sammeln. Es wird mit dem folgenden Befehl aufgerufen:

python3 manage.py collectstatic

Für dieses Tutorial kann collectstatic vor dem Hochladen der Anwendung aufgerufen werden und kopiert alle statischen Dateien in der Anwendung an den Ort, der durch STATIC_ROOT definiert ist. Whitenoise findet die Dateien aus dem standardmäßig definierten STATIC_ROOT-Standort und liefert sie an der Basis-URL, die durch STATIC_URL definiert ist.

settings.py

Öffnen Sie /locallibrary/settings.py und kopieren Sie die folgende Konfiguration ans Ende der Datei. Der BASE_DIR sollte bereits in Ihrer Datei definiert sein (die STATIC_URL könnte bereits in der Datei definiert gewesen sein, als sie erstellt wurde. Während es keinen Schaden anrichten würde, könnten Sie die doppelte frühere Referenz auch löschen).

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

# The absolute path to the directory where collectstatic will collect static files for deployment.
STATIC_ROOT = BASE_DIR / 'staticfiles'

# The URL to use when referring to static files (where they will be served from)
STATIC_URL = '/static/'

Wir werden die Datei-Dienste tatsächlich mit einer Bibliothek namens WhiteNoise bereitstellen, die wir im nächsten Abschnitt installieren und konfigurieren werden.

Es gibt viele Möglichkeiten, statische Dateien in der Produktion bereitzustellen (wir haben die entsprechenden Django-Einstellungen in den vorherigen Abschnitten gesehen). Das WhiteNoise-Projekt bietet einen der einfachsten Methoden, um statische Assets direkt von Gunicorn in der Produktion bereitzustellen.

In der WhiteNoise Dokumentation finden Sie eine Erklärung, wie es funktioniert und warum die Implementierung eine relativ effiziente Methode zum Bereitstellen dieser Dateien ist.

Die Schritte, um WhiteNoise für das Projekt einzurichten, sind hier angezeigt (und unten reproduziert):

Installieren Sie whitenoise

Installieren Sie whitenoise lokal mit dem folgenden Befehl:

pip3 install whitenoise

settings.py

Um WhiteNoise in Ihre Django-Anwendung zu installieren, öffnen Sie /locallibrary/settings.py, finden Sie die MIDDLEWARE-Einstellung und fügen Sie das WhiteNoiseMiddleware nahe dem Anfang der Liste, direkt unter dem SecurityMiddleware, hinzu:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'whitenoise.middleware.WhiteNoiseMiddleware',
    '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',
]

Optional können Sie die Größe der bereitgestellten statischen Dateien reduzieren (das ist effizienter). Fügen Sie einfach Folgendes am Ende von /locallibrary/settings.py hinzu:

# Static file serving.
# https://whitenoise.readthedocs.io/en/stable/django.html#add-compression-and-caching-support
STORAGES = {
    # ...
    "staticfiles": {
        "BACKEND": "whitenoise.storage.CompressedManifestStaticFilesStorage",
    },
}

Sie müssen nichts Weiteres tun, um WhiteNoise zu konfigurieren, da es standardmäßig Ihre Projekteinstellungen für STATIC_ROOT und STATIC_URL verwendet.

Die Python-Abhängigkeiten Ihrer Webanwendung sollten in einer Datei requirements.txt im Root Ihres Repositorys gespeichert werden. Viele Hosting-Dienste installieren automatisch Abhängigkeiten aus dieser Datei (in anderen müssen Sie dies selbst tun). Sie können diese Datei mit pip auf der Kommandozeile erstellen (führen Sie das Folgende im Root des Repos aus):

pip3 freeze > requirements.txt

Nachdem Sie all die verschiedenen Abhängigkeiten oben installiert haben, sollte Ihre requirements.txt Datei mindestens diese Einträge enthalten (obwohl die Versionsnummern unterschiedlich sein können). Bitte löschen Sie alle anderen nicht aufgelisteten Abhängigkeiten, es sei denn, Sie haben sie für diese Anwendung ausdrücklich hinzugefügt.

Django==5.0.2
dj-database-url==2.1.0
gunicorn==21.2.0
psycopg2-binary==2.9.9
wheel==0.38.1
whitenoise==6.6.0
python-dotenv==1.0.1

Viele Hosting-Dienste erlauben es Ihnen, Projekte aus einem lokalen Repository oder von cloud-basierten Versionskontrollplattformen zu importieren und/oder zu synchronisieren. Dies kann das Deployment und iterative Entwicklung deutlich erleichtern.

Sie sollten bereits GitHub zur Speicherung des Local-Library-Quellcodes verwenden (dies wurde in Source Code Management mit Git und GitHub als Teil der Einrichtung Ihrer Entwicklungsumgebung eingerichtet.

Dies ist ein guter Zeitpunkt, um ein Backup Ihres "Vanilla"-Projekts zu machen — während einige der Änderungen, die wir in den folgenden Abschnitten vornehmen, nützlich für das Deployment auf jedem Hosting-Dienst sein könnten (oder für die Entwicklung), könnten andere es nicht sein. Vorausgesetzt, Sie haben bereits alle bisher vorgenommenen Änderungen in der main-Branche auf GitHub gesichert, können Sie einen neuen Branch erstellen, um Ihre Änderungen wie folgt zu sichern:

# Fetch the latest main branch
git checkout main
git pull origin main

# Create branch vanilla_deployment from the current branch (main)
git checkout -b vanilla_deployment

# Push the new branch to GitHub
git push origin vanilla_deployment

# Switch back to main
git checkout main

# Make any further changes in a new branch
git checkout -b my_changes_for_deployment # Create a new branch

Dieser Abschnitt bietet eine praktische Demonstration, wie LocalLibrary auf PythonAnywhere gehostet werden kann.

Wir wählen PythonAnywhere aus mehreren Gründen:

• PythonAnywhere bietet einen wirklich kostenlosen Einsteigerplan, obwohl mit einigen Einschränkungen. Die Tatsache, dass es für alle Entwickler erschwinglich ist, ist für MDN wirklich wichtig!

  Hinweis: Dieses Tutorial wurde auf Heroku, Railway und jetzt PythonAnywhere gehostet und migriert, als die zuvor kostenlosen Pläne eingestellt wurden. Wir haben PythonAnywhere ausgewählt, weil wir denken, dass dieser Plan wahrscheinlich kostenlos bleiben wird. Wir haben das Railway-Beispiel auch beibehalten, das nicht kostenlos ist, zum Vergleich und weil es uns ermöglicht, Funktionen wie die Integration mit Postgres-Datenbanken, die auf einem anderen Dienst laufen, einfacher zu demonstrieren.

• PythonAnywhere kümmert sich um die Infrastruktur, sodass Sie es nicht müssen. Sich nicht um Server, Load-Balancer, Reverse-Proxy usw. kümmern zu müssen, erleichtert den Einstieg erheblich.

• Die Fähigkeiten und Konzepte, die Sie bei der Verwendung von PythonAnywhere lernen, sind übertragbar.

• Der Service und die Planbeschränkungen beeinträchtigen uns nicht besonders, wenn wir PythonAnywhere für das Tutorial verwenden. Zum Beispiel:

  • Der Einsteigerplan erlaubt nur eine Web-App unter <your-username>.pythonanywhere.com, eingeschränkten ausgehenden Internetzugriff von Ihren Apps, niedrigen CPU/Bandbreitenverbrauch, keine IPython/Jupyter-Notebook-Unterstützung, keine kostenlose Postgres-Datenbank. Aber es gibt genug Platz für unsere Basis-Site, um zu laufen!
  • Eigene Domains werden nicht unterstützt (zum Zeitpunkt des Schreibens).
  • Die Umgebung wird heruntergefahren, wenn sie nicht verwendet wird, daher kann es zu Verzögerungen beim Neustart kommen. Sie können sie für immer betreiben, aber Sie müssen die Site alle drei Monate besuchen und die Webanwendung erneuern.
  • Es gibt kostenlosen Support für eine separate MySQL-Datenbank, aber nicht für Postgres. In dieser Demonstration verwenden wir einfach die von Django in der gehosteten Ubuntu-Umgebung erstellte Standard-SQLite-Datenbank.

PythonAnywhere eignet sich für das Hosting dieser Demonstration und kann bei Bedarf auf größere Projekte skaliert werden. Sie sollten sich die Zeit nehmen herauszufinden, ob es für Ihre eigene Website geeignet ist.

PythonAnywhere bietet ein vollständig webbasiertes Interface zum Hochladen, Bearbeiten und sonstigen Arbeiten mit Ihrer Anwendung.

Über das Interface können Sie eine Bash-Konsole in einer Ubuntu-Linux-Umgebung starten, in der Sie Ihre Anwendung erstellen können. In dieser Demonstration werden wir die Konsole verwenden, um unser lokales Bibliotheks-GitHub-Repository zu klonen und eine Python-Umgebung zu erstellen, in der wir die Webanwendung ausführen können.

Der kostenlose Plan bietet keine separate Unterstützung für Postgres. Während wir einen anderen Hosting-Dienst für unsere Datenbank verwenden könnten, verwenden wir einfach die Standard-SQLite-Datenbank, die von Django in der gehosteten Ubuntu-Umgebung erstellt wurde (es gibt mehr als genug Platz, um die Bibliotheksfunktionen zu demonstrieren).

Sobald die Anwendung läuft, kann sie durch das Setzen von Umgebungsvariablen über die Bash-Konsole für die Produktion konfiguriert werden.

Das ist alles, was Sie an Übersicht benötigen, um loszulegen.

Um PythonAnywhere zu nutzen, müssen Sie zunächst ein Konto erstellen:

• Gehen Sie zur Seite mit den Plänen und Preisen von PythonAnywhere und wählen Sie die Schaltfläche Create a Beginner account.
• Erstellen Sie ein Konto mit Ihrem Benutzernamen, E-Mail und Passwort, bestätigen Sie die Nutzungsbedingungen und wählen Sie dann Register.
• Sie werden dann eingeloggt und zum PythonAnywhere-Dashboard umgeleitet: https://www.pythonanywhere.com/user/<your_user_name>/.

Als nächstes werden wir ein Bash-Prompt öffnen, eine virtuelle Umgebung einrichten und den lokalen Bibliotheksquellcode von GitHub abrufen. Wir konfigurieren auch die Standarddatenbank und sammeln statische Dateien, damit sie von PythonAnywhere bereitgestellt werden können.

1. Öffnen Sie zuerst den Bereich „Consoles“ (Konsolensteuerung), indem Sie in der oberen Anwendungsleiste auf Consoles (Konsolen) klicken.

2. Wählen Sie dann den Bash-Link, um eine neue Konsole zu erstellen und zu starten:

   

   Beachten Sie, dass jede erstellte Konsole für die spätere Wiederverwendung gespeichert wird, zusammen mit der gesamten Verlaufshistorie. Der grüne Pfeil oben zeigt an, dass dieses Konto eine Konsole hat, die wir stattdessen hätten öffnen können.

3. Geben Sie in der Konsole den folgenden Befehl ein, um eine Python 3.10-virtuelle Umgebung namens "env_local_library" für die Installation der lokalen Bibliotheksabhängigkeiten zu erstellen.

   bash

   mkvirtualenv --python=python3.10 env_local_library
   

   Dies ist genau der gleiche Prozess, der unter Einrichtung einer Django-Entwicklungsumgebung behandelt wird. Wir hätten die Umgebung beliebig benennen können, und wir können sie deaktivieren und mit den unten stehenden Befehlen reaktivieren:

   bash

   deactivate
   workon env_local_library
   

4. Holen Sie sich als nächstes den Bibliotheksquellcode von GitHub. PythonAnywhere erwartet, dass Sie Anwendungen in einem nach Ihrer Site-URL benannten Ordner installieren.

   Hinweis: Da wir das kostenlose Konto verwenden, können Sie Ihren Account nur <your_pythonanywhere_username>.pythonanywhere.com nennen (zum Beispiel, wenn Ihr Benutzername „Odtsetseg“ ist, müssen Sie die lokale Bibliotheksquelle in einen Ordner namens odtsetseg.pythonanywhere.com legen).

   Geben Sie den folgenden Befehl ein, um Ihren Bibliotheksquellcode in einen entsprechend benannten Ordner zu klonen (Sie müssen die Benutzernamenwerte durch Ihren eigenen Namen ersetzen):

   bash

   git clone https://github.com/<github_username>/django-locallibrary-tutorial.git <your_pythonanywhere_username>.pythonanywhere.com
   
   # Navigate into the new folder
   cd <your_pythonanywhere_username>.pythonanywhere.com
   

5. Installieren Sie die Bibliotheksabhängigkeiten mit der requirements.txt Datei:

   bash

   pip3 install -r requirements.txt
   

6. Erstellen und konfigurieren Sie eine SQLite-Datenbank auf dem Host-Computer (genau wie wir es während der Entwicklung getan haben).

   bash

   python manage.py migrate
   

   Hinweis: Für das Railway-Beispiel werden wir eine Postgres-Datenbank konfigurieren und eine Verbindung herstellen, indem wir die DATABASE_URL Umgebungsvariable setzen. Es ist wichtig, dass migrate nach der Konfiguration der zu verwendenden Datenbank aufgerufen wird.

7. Sammeln Sie alle statischen Dateien an einem Ort, an dem diese in der Produktion bereitgestellt werden können:

   bash

   python manage.py collectstatic --no-input
   

8. Erstellen Sie einen Superuser für den Zugriff auf die Website (wie im Abschnitt Django-Admin-Seite behandelt):

   bash

   python manage.py createsuperuser
   

   Notieren Sie sich die Details, da Sie diese benötigen, um Ihre Website zu testen.

Nachdem Sie den lokalen Bibliotheksquellcode abgerufen und die Abhängigkeiten in einer virtuellen Umgebung installiert haben, müssen wir PythonAnywhere mitteilen, wie es sie finden und als Web-App verwenden kann.

1. Navigieren Sie zum Web Bereich der Site und klicken Sie auf den Link Add a new web app (Eine neue Webanwendung hinzufügen):

   

   Der Create new web app Wizard wird dann geöffnet, um Sie durch die Konfiguration der Haupteigenschaften der Web-App zu führen.

2. Wählen Sie Next, um die Konfiguration des Domainnamens der Web-App zu überspringen. Das kostenlose Konto erstellt die Domain basierend auf Ihrem Benutzernamen: <user_name>.pythonanywhere.com.

   

3. Wählen Sie im Bildschirm Select a Python Web framework Manual configuration.

   

   Manuelle Konfiguration gibt uns die vollständige Kontrolle darüber, wie die Umgebung konfiguriert ist. Dies spielt momentan keine große Rolle, aber es würde, wenn wir mehrere Sites hosten würden, möglicherweise mit unterschiedlichen Versionen von Python und/oder Django.

4. Wählen Sie im Bildschirm Select a Python version 3.10

   

   Im Allgemeinen sollten Sie die neueste von der von Ihnen verwendeten Django-Version zulässige Python-Version auswählen.

5. Wählen Sie auf dem Bildschirm Manual configuration Next (der Bildschirm erklärt nur einige der Konfigurationsoptionen)

   

   Die Web-App wird erstellt und im Webbereich wie gezeigt angezeigt. Der Bildschirm hat eine Reload-Schaltfläche, die Sie verwenden können, um die Webanwendung zu aktualisieren, nachdem Sie weitere Änderungen vorgenommen haben. Wie auf dem Bildschirm erwähnt, müssen Sie die Schaltfläche Run until 3 months from today klicken, um die Website für weitere drei Monate am Leben zu halten (und fortlaufend).

   

6. Scrollen Sie im "Code"-Abschnitt des Web-Tabs nach unten und wählen Sie den Link zur WSGI-Konfigurationsdatei. Diese wird einen Namen in der Form /var/www/<user_name>_pythonanywhere_com_wsgi.py haben.

   

   Ersetzen Sie den Inhalt in der Datei durch den folgenden Text (aktualisieren Sie zuerst „hamishwillee“ mit Ihrem eigenen Benutzernamen), und klicken Sie dann auf die Schaltfläche Save.

   python

   import os
   import sys
   
   path = '/home/hamishwillee/hamishwillee.pythonanywhere.com'
   if path not in sys.path:
       sys.path.append(path)
   
   os.environ['DJANGO_SETTINGS_MODULE'] = 'locallibrary.settings'
   
   from django.core.wsgi import get_wsgi_application
   application = get_wsgi_application()
   

   Beachten Sie, dass die Rolle der WSGI-Datei darin besteht, dem Gunicorn-Server den Zugriff auf die Local-Library-Anwendung zu ermöglichen. PythonAnywhere erwartet, dass sich diese Datei an diesem Ort befindet, weshalb die bereits im Projekt vorhandene WSGI-Datei nicht verwendet werden kann.

7. Scrollen Sie im „Virtualenv“-Abschnitt des Web-Tabs nach unten. Wählen Sie den Link Enter the path to a virtual env, if desired und geben Sie den Pfad der in den vorangegangenen Schritten erstellten virtuellen Umgebung ein. Wenn Sie es "env_local_library" genannt haben, wie vorgeschlagen, lautet der Pfad: /home/<user_name>/.virtualenvs/env_local_library

   

8. Scrollen Sie im „Static files“-Abschnitt des Web-Tabs nach unten.

   

   Wählen Sie den Link Enter URL und geben Sie \static_files\ ein. Dies ist das STATIC_URL in den Anwendungseinstellungen und spiegelt den Ort wider, an den Dateien kopiert wurden, als wir collectstatic im vorherigen Abschnitt ausgeführt haben.

9. Klicken Sie oben im Web-Tab auf die Schaltfläche Reload, um die Site neu zu starten. Klicken Sie dann auf den Site-URL-Link, um die Live-Site zu starten:

Wenn die Site geöffnet wird, sehen Sie an diesem Punkt einen Fehler-Debug-Bildschirm wie unten gezeigt. Dies ist ein Django-Sicherheitsfehler, der ausgelöst wird, weil unser Quellcode nicht auf einem „erlaubten“ Host läuft.

Öffnen Sie /locallibrary/settings.py in Ihrem GitHub-Projekt und ändern Sie die ALLOWED_HOSTS-Einstellung, um Ihre PythonAnywhere-Site-URL einzuschließen:

## For example, for a site URL at 'hamishwillee.pythonanywhere.com'
## (replace the string below with your own site URL):
ALLOWED_HOSTS = ['hamishwillee.pythonanywhere.com', '127.0.0.1']

# During development, you can instead set just the base URL
# (you might decide to change the site a few times).
# ALLOWED_HOSTS = ['.pythonanywhere.com','127.0.0.1']

Da die Anwendung CSRF-Schutz verwendet, müssen Sie auch den Schlüssel CSRF_TRUSTED_ORIGINS setzen. Öffnen Sie /locallibrary/settings.py und fügen Sie eine Zeile wie unten hinzu:

## For example, for a site URL is at 'web-production-3640.up.railway.app'
## (replace the string below with your own site URL):
CSRF_TRUSTED_ORIGINS = ['https://hamishwillee.pythonanywhere.com']

# During development/for this tutorial you can instead set just the base URL
# CSRF_TRUSTED_ORIGINS = ['https://*.pythonanywhere.com']

Speichern Sie diese Einstellungen und committen Sie sie in Ihr GitHub-Repo.

Sie müssen dann die Version Ihres Projekts auf PythonAnywhere aktualisieren. Angenommen, Sie verwenden Ihr Bash-Prompt im Ordner <user_name>.pythonanywhere.com, und Sie haben die Änderungen in den Main-Branch gepushed, dann könnten Sie sie im Bash-Prompt mit dem folgenden Befehl importieren:

git pull origin main

Verwenden Sie die Restart-Schaltfläche auf dem Web-Tab, um die Anwendung neu zu starten. Wenn Sie Ihre gehostete Site aktualisieren, sollte sie nun offen sein und die Startseite der Site anzeigen.

Sie sollten sich mit dem oben erstellten Superuser-Konto anmelden können, Autoren, Genres, Bücher usw. erstellen, genauso wie Sie es auf Ihrem lokalen Computer getan haben.

Im Abschnitt Ihre Website bereit für die Veröffentlichung machen haben wir die Anwendung so modifiziert, dass sie mit Hilfe von Umgebungsvariablen oder Variablen in einer .env-Datei in Produktion konfiguriert werden kann.

Konkret haben wir die Bibliothek so eingerichtet, dass Sie DJANGO_DEBUG=False setzen können, um die Debug-Verfolgung, die dem Benutzer bei einem Fehler angezeigt wird, zu reduzieren.

• DJANGO_SECRET_KEY auf einen geheimen Wert in Produktion setzen.
• DATABASE_URL falls Ihre Anwendung eine gehostete Datenbank verwendet (wir tun dies in diesem Beispiel nicht).

Der Weg, auf dem Umgebungsvariablen festgelegt werden, hängt vom Hosting-Dienst ab. Für PythonAnywhere müssen Sie sie aus einer Umgebungsdatei lesen. Das haben wir bereits eingerichtet, also müssen wir nur die Datei erstellen.

Die Schritte sind:

1. Öffnen Sie ein Bash-Prompt auf PythonAnywhere.

2. Navigieren Sie zu Ihrem Anwendungsverzeichnis (ersetzen Sie <user-name> durch Ihren eigenen Account):

   bash

   cd ~/<user-name>.pythonanywhere.com
   

3. Setzen Sie die Umgebungsvariablen, indem Sie sie als Schlüssel-Wert-Paar in die .env-Datei schreiben. Zum Beispiel, um DJANGO_DEBUG in der Bash-Konsole auf False zu setzen, geben Sie den folgenden Befehl ein:

   bash

   echo "DJANGO_DEBUG=False" >> .env
   

4. Starten Sie die Anwendung neu.

Sie können testen, ob der Vorgang funktioniert hat, indem Sie versuchen, einen Datensatz zu öffnen, der nicht existiert (zum Beispiel ein Genre erstellen und dann die Nummer in der URL-Leiste inkrementieren, um einen Datensatz zu öffnen, der noch nicht erstellt wurde). Wenn die Umgebungsvariable geladen wurde, erhalten Sie eine „Nicht gefunden“-Nachricht anstelle einer detaillierten Debug-Verfolgung.

Dieser Abschnitt bietet eine praktische Demonstration, wie LocalLibrary auf Railway installiert wird.

Railway ist aus mehreren Gründen eine attraktive Hosting-Option:

• Railway kümmert sich um den größten Teil der Infrastruktur, so dass Sie sich darum nicht kümmern müssen. Wenn man sich nicht um Server, Lastenausgleich, Reverse-Proxies und so weiter kümmern muss, ist es viel einfacher, loszulegen.
• Railway hat einen Fokus auf die Entwicklererfahrung für Entwicklung und Deployment, was zu einer schnelleren und sanfteren Lernkurve führt als viele andere Alternativen.
• Die Fähigkeiten und Konzepte, die Sie bei der Verwendung von Railway lernen, sind übertragbar. Während Railway einige hervorragende neue Funktionen hat, verwenden andere beliebte Hosting-Dienste viele der gleichen Ideen und Ansätze.
• Railway-Dokumentation ist klar und vollständig.
• Der Dienst scheint sehr zuverlässig zu sein, und wenn Sie ihn lieben, ist die Preisgestaltung vorhersehbar, und das Skalieren Ihrer App ist sehr einfach.

Sie sollten sich die Zeit nehmen herauszufinden, ob Railway für Ihre eigene Website geeignet ist.

Webanwendungen werden jeweils in ihrem eigenen isolierten und unabhängigen virtualisierten Container ausgeführt. Um Ihre Anwendung auszuführen, muss Railway in der Lage sein, die entsprechende Umgebung und Abhängigkeiten einzurichten und auch zu verstehen, wie sie gestartet wird. Diese Informationen stellen wir für Django-Apps in einer Reihe von Textdateien zur Verfügung:

• runtime.txt: gibt die zu verwendende Programmiersprache und Version an.
• requirements.txt: listet die Python-Abhängigkeiten auf, die für Ihre Site benötigt werden, einschließlich Django.
• Procfile: Eine Liste von Prozessen, die ausgeführt werden müssen, um die Webanwendung zu starten. Bei Django wird dies in der Regel der Gunicorn-Webanwendungsserver sein (mit einem .wsgi-Skript).
• wsgi.py: WSGI Konfiguration, um unsere Django-Anwendung in der Railway-Umgebung aufzurufen.

Sobald die Anwendung ausgeführt wird, kann sie sich mit Informationen, die in Umgebungsvariablen bereitgestellt werden, konfigurieren. Zum Beispiel kann eine Anwendung, die eine Datenbank verwendet, die Adresse mit der Variablen DATABASE_URL abrufen. Der Datenbankdienst selbst kann von Railway oder einem anderen Anbieter gehostet werden.

Entwickler interagieren mit Railway über die Railway-Site und mit einem speziellen Command Line Interface (CLI)-Tool. Das CLI erlaubt es Ihnen, ein lokales GitHub-Repository mit einem Railway-Projekt zu verknüpfen, das Repository von der lokalen Zweigstelle auf die Live-Site hochzuladen, die Protokolle des laufenden Prozesses zu inspizieren, Konfigurationsvariablen zu setzen und abzurufen, und vieles mehr. Eines der nützlichsten Features ist, dass Sie mit dem CLI-Tool Ihr lokales Projekt mit den gleichen Umgebungsvariablen wie das Live-Projekt ausführen können.

Um unsere Anwendung auf Railway zu bringen, müssen wir unsere Django-Webanwendung in ein Git-Repository legen, die oben genannten Dateien hinzufügen, eine Datenbankverbindung integrieren und Änderungen vornehmen, um statische Dateien korrekt zu handhaben. Sobald wir das alles gemacht haben, können wir ein Railway-Konto einrichten, den Railway-Client holen und unsere Website installieren.

Das ist alles, was wir überblicksmäßig brauchen, um loszulegen.

In diesem Abschnitt erklären wir die Änderungen, die Sie an unserer LocalLibrary-Anwendung vornehmen müssen, um sie auf Railway zum Laufen zu bringen. Wir müssen wirklich nur eine Procfile und runtime.txt Datei erstellen, weil fast alles andere bereits vorhanden ist.

Beachachten Sie, dass diese Änderungen Sie nicht daran hindern, die bereits gelernten lokalen Tests und Arbeitsabläufe zu verwenden.

Procfile

Eine Procfile ist der „Einstiegspunkt“ der Webanwendung. Es listet die Befehle auf, die von Railway ausgeführt werden sollen, um Ihre Site zu starten.

Erstellen Sie die Datei Procfile (ohne Dateierweiterung) im Root Ihres GitHub-Repos und kopieren/fügen Sie den folgenden Text ein:

web: python manage.py migrate && python manage.py collectstatic --no-input && gunicorn locallibrary.wsgi

Das Präfix web: gibt Railway an, dass dies ein Webprozess ist und HTTP-Verkehr gesendet werden kann. Wir rufen dann den Django-Migrationsbefehl python manage.py migrate auf, um die Datenbanktabellen einzurichten. Dann rufen wir den Django-Befehl python manage.py collectstatic auf, um statische Dateien im Ordner zu sammeln, der von der STATIC_ROOT-Projekteinstellung definiert wird (siehe den Abschnitt Bereitstellung statischer Dateien in der Produktion unten). Schließlich starten wir den gunicorn-Prozess, einen beliebten Webanwendungsserver, dem wir Konfigurationsinformationen im Modul locallibrary.wsgi (erstellt mit unserem Anwendungsskelett: /locallibrary/wsgi.py) übergeben.

Sie werden feststellen, dass wir das Projekt bereits so eingerichtet haben, dass es gunicorn umfasst und die Bereitstellung statischer Dateien unterstützt!

Mit dem Procfile können Sie auch Arbeitsprozesse starten oder andere nicht interaktive Aufgaben ausführen, bevor das Release bereitgestellt wird.

Runtime

Die runtime.txt-Datei gibt, wenn definiert, Railway an, welche Version von Python verwendet werden soll. Erstellen Sie die Datei im Root des Repos und fügen Sie den folgenden Text hinzu:

python-3.10.2

Testen und spe

ichern Sie die Änderungen in GitHub

Bevor Sie weitergehen, testen Sie die Site erneut lokal und überprüfen Sie, ob sie durch keine der oben vorgenommenen Änderungen kaputtgegangen ist. Starten Sie den Entwicklungs-Webserver wie gewohnt und überprüfen Sie dann, ob die Site in Ihrem Browser noch wie erwartet funktioniert.

python3 manage.py runserver

Lassen Sie uns als Nächstes die Änderungen zu GitHub pushen. Geben Sie im Terminal (nachdem Sie zu unserem lokalen Repository navigiert haben) die folgenden Befehle ein:

git checkout -b railway_changes
git add -A
git commit -m "Added files and changes required for deployment"
git push origin railway_changes

Erstellen Sie dann in GitHub einen Pull-Request und führen Sie ihn zusammen.

Jetzt sollten wir bereit sein, LocalLibrary auf Railway bereitzustellen.

Um Railway zu verwenden, müssen Sie zunächst ein Konto erstellen:

• Gehen Sie zu railway.com und klicken Sie auf den Login-Link in der oberen Werkzeugleiste der Site.
• Wählen Sie GitHub im Popup aus, um sich mit Ihren GitHub-Anmeldeinformationen anzumelden.
• Sie müssen möglicherweise zu Ihrer E-Mail gehen und Ihr Konto verifizieren.
• Sie werden dann im Railway.com-Dashboard eingeloggt: https://railway.com/dashboard.

Als Nächstes werden wir Railway einrichten, um unsere Bibliothek von GitHub bereitzustellen. Wählen Sie zuerst die Option Dashboard aus dem oberen Menü der Site und klicken Sie dann auf die Schaltfläche New Project:

Railway zeigt eine Liste von Optionen für das neue Projekt an, darunter die Option, ein Projekt von einer Vorlage bereitzustellen, die zuerst in Ihrem GitHub-Konto erstellt wurde, sowie eine Anzahl von Datenbanken. Wählen Sie Deploy from GitHub repo.

Alle Projekte in den GitHub-Repos, die Sie während der Einrichtung mit Railway geteilt haben, werden angezeigt. Wählen Sie Ihr GitHub-Repository für die lokale Bibliothek: <user-name>/django-locallibrary-tutorial.

Bestätigen Sie Ihre Bereitstellung, indem Sie Deploy Now auswählen.

Railway wird Ihr Projekt laden und bereitstellen, und den Fortschritt auf der Registerkarte „Bereitstellungen“ anzeigen. Wenn die Bereitstellung erfolgreich abgeschlossen ist, sehen Sie einen Bildschirm wie den untenstehenden.

Sie können auf die Site-URL (oben hervorgehoben) klicken, um die Site in einem Browser zu öffnen (sie wird jedoch immer noch nicht funktionieren, weil die Einrichtung noch nicht abgeschlossen ist).

Wenn die Site geöffnet wird, zu diesem Zeitpunkt werden Sie ein Fehler-Debug-Bildschirm wie unten gezeigt sehen. Dies ist ein Django-Sicherheitsfehler, der ausgelöst wird, weil unser Quellcode nicht auf einem "erlaubten" Host läuft.

Öffnen Sie /locallibrary/settings.py in Ihrem GitHub-Projekt und ändern Sie die ALLOWED_HOSTS-Einstellung, um Ihre Railway-Site-URL einzuschließen:

## For example, for a site URL at 'web-production-3640.up.railway.app'
## (replace the string below with your own site URL):
ALLOWED_HOSTS = ['web-production-3640.up.railway.app', '127.0.0.1']

# During development, you can instead set just the base URL
# (you might decide to change the site a few times).
# ALLOWED_HOSTS = ['.railway.com','127.0.0.1']

Da die Anwendung CSRF-Schutz verwendet, müssen Sie auch den Schlüssel CSRF_TRUSTED_ORIGINS setzen. Öffnen Sie /locallibrary/settings.py und fügen Sie eine Zeile wie unten hinzu:

## For example, for a site URL is at 'web-production-3640.up.railway.app'
## (replace the string below with your own site URL):
CSRF_TRUSTED_ORIGINS = ['https://web-production-3640.up.railway.app']

# During development/for this tutorial you can instead set just the base URL
# CSRF_TRUSTED_ORIGINS = ['https://*.railway.app']

Speichern Sie dann Ihre Einstellungen und committen Sie sie in Ihr GitHub-Repo (Railway wird Ihre Anwendung automatisch aktualisieren und erneut bereitstellen).

Als Nächstes müssen wir eine Postgres-Datenbank erstellen und sie mit der Django-Anwendung verbinden, die wir gerade bereitgestellt haben. (Wenn Sie die Site jetzt öffnen, erhalten Sie einen neuen Fehler, weil die Datenbank nicht zugänglich ist). Wir erstellen die Datenbank als Teil des Anwendungsprojekts, obwohl Sie die Datenbank in ihrem eigenen separaten Projekt erstellen können.

Auf Railway wählen Sie die Option Dashboard im oberen Menü der Site und dann Ihr Anwendungsprojekt aus. Zu diesem Zeitpunkt enthält es nur einen Service für Ihre Anwendung (dies kann ausgewählt werden, um Variablen und andere Details des Dienstes festzulegen). Die Schaltfläche Settings (Einstellungen) kann zum Ändern der Projekteinstellungen verwendet werden. Wählen Sie die Schaltfläche „New“, um der Projekt einen neuen Dienst hinzuzufügen.

Wählen Sie „Database“, wenn Sie nach dem Typ des hinzuzufügenden Dienstes gefragt werden:

Wählen Sie dann „Add PostgreSQL“ (PostgreSQL hinzufügen), um die Datenbank hinzuzufügen.

Railway wird dann einen Dienst mit einer leeren Datenbank im selben Projekt bereitstellen. Nach Abschluss werden nun sowohl der Anwendungs- als auch der Datenbankdienst in der Projektansicht angezeigt.

Wählen Sie den Webdienst und dann die Registerkarte Variables (Variablen). Wählen Sie New Variable (Neue Variable) und dann im Feld Variable name (Variablenname), wählen Sie Add reference (Referenz hinzufügen). Scrollen Sie herunter und wählen Sie DATABASE_URL (dies ist der Name der Variablen, die wir eingerichtet haben, damit die LocalLibrary eine Umgebungsvariable liest).

Wählen Sie dann Add (Hinzufügen), um die Variablenreferenz hinzuzufügen, und schließlich Deploy (dies wird in einem Popup angezeigt). Beachten Sie, dass Sie auch die Postgres-Datenbank öffnen, dann die Registerkarte Variablen und die Variable kopieren könnten.

Wenn Sie das Projekt jetzt öffnen, sollte es genau wie lokal angezeigt werden. Beachten Sie jedoch, dass es noch keinen Weg gibt, die Bibliothek mit Daten zu füllen, weil wir noch kein Superuser-Konto erstellt haben. Das werden wir mit dem CLI Tool auf unserem lokalen Computer tun.

Laden Sie den Railway-Client herunter und installieren Sie ihn für Ihr lokales Betriebssystem, indem Sie den Anweisungen hier folgen.

Nachdem der Client installiert ist, können Sie Befehle ausführen. Einige der wichtigeren Operationen beinhalten das Bereitstellen des aktuellen Verzeichnisses Ihres Computers auf einem verbundenen Railway-Projekt (ohne es auf GitHub hochladen zu müssen), und Ihr Django-Projekt lokal mit den gleichen Einstellungen zu betreiben wie auf dem Produktionsserver. Wir zeigen diese in den nächsten Abschnitten.

Sie können eine Liste aller möglichen Befehle erhalten, indem Sie Folgendes in ein Terminal eingeben.

railway help

Um einen Superuser zu erstellen, müssen wir den Django-Befehl createsuperuser gegen die Produktionsdatenbank aufrufen (dies ist die gleiche Operation, die wir lokal in Django-Tutorial Teil 4: Django-Admin-Seite > Erstellen eines Superusers ausgeführt haben). Railway bietet keinen direkten Terminalzugriff auf den Server, und wir können diesen Befehl nicht zum Procfile hinzufügen, weil er interaktiv ist.

Was wir tun können, ist, diesen Befehl lokal auf unserem Django-Projekt auszuführen, wenn es mit der Produktionsdatenbank verbunden ist. Der Railway-Client macht dies einfach, da er einen Mechanismus bereitstellt, um Befehle lokal mit den gleichen Umgebungsvariablen wie auf dem Produktionsserver auszuführen, einschließlich der Datenbankverbindungszeichenfolge.

Öffnen Sie zuerst ein Terminal oder eine Eingabeaufforderung in einem Git-Klon Ihres Local-Library-Projekts. Melden Sie sich dann mit dem Befehl login oder login --browserless an Ihrem Browserkonto an (folgen Sie allen resultierenden Eingabeaufforderungen und Anweisungen des Clients oder der Website, um die Anmeldung abzuschließen):

railway login

Nachdem Sie sich angemeldet haben, verknüpfen Sie Ihr aktuelles Local-Library-Verzeichnis mit dem zugehörigen Railway-Projekt mit dem folgenden Befehl. Beachten Sie, dass Sie bei der Aufforderung ein bestimmtes Projekt auswählen/eingeben müssen:

railway link

Nachdem das lokale Verzeichnis und das Projekt verknüpft sind, können Sie das lokale Django-Projekt mit den Produktionseinrichtungseinstellungen ausführen. Stellen Sie zuerst sicher, dass Ihre normale Django-Entwicklungsumgebung bereit ist. Rufen Sie dann den folgenden Befehl auf und geben Sie wie erforderlich Name, E-Mail-Adresse und Passwort ein:

railway run python manage.py createsuperuser

Sie sollten jetzt in der Lage sein, den Adminbereich Ihrer Website (https://[your-url].railway.app/admin/) zu öffnen und die Datenbank genauso zu füllen, wie es in Django-Tutorial Teil 4: Django-Admin-Seite) gezeigt wurde.

Der letzte Schritt ist, die Site sicher zu machen. Insbesondere müssen wir das Debug-Protokoll ausschalten und einen geheimen CSRF-Schlüssel einstellen. Die Arbeit, die benötigten Werte aus Umgebungsvariablen zu lesen, wurde im Abschnitt Ihre Website bereit zum Veröffentlichen machen erledigt (siehe DJANGO_DEBUG und DJANGO_SECRET_KEY).

Öffnen Sie den Informationsbildschirm für das Projekt und wählen Sie die Registerkarte Variables (Variablen). Dies sollte bereits die DATABASE_URL enthalten, wie unten gezeigt.

Es gibt viele Möglichkeiten, einen kryptographisch sicheren Schlüssel zu generieren. Eine einfache Möglichkeit ist, den folgenden Python-Befehl auf Ihrem Entwicklungscomputer auszuführen:

python -c "import secrets; print(secrets.token_urlsafe())"

Wählen Sie den New Variable-Button und geben Sie den Schlüssel DJANGO_SECRET_KEY mit Ihrem geheimen Wert ein (dann Add anwählen). Geben Sie dann den Schlüssel DJANGO_DEBUG mit dem Wert False ein. Die letzte Gruppe der Variablen sollte so aussehen:

Der Railway-Client stellt den Befehl logs bereit, um das Ende der Protokolle anzuzeigen (ein vollständigeres Protokoll ist auf der Site für jedes Projekt verfügbar):

railway logs

Wenn Sie mehr Informationen benötigen, als dies bereitstellen kann, müssen Sie sich in das Django-Logging einarbeiten.

Das ist das Ende dieses Tutorials über das Einrichten von Django-Apps in der Produktion und auch die Serie von Tutorials über die Arbeit mit Django. Wir hoffen, Sie haben es nützlich gefunden. Sie können eine vollständig durchgearbeitete Version des Quellcodes hier auf GitHub ansehen.

Der nächste Schritt ist, unsere letzten Artikel zu lesen und dann die Bewertungsaufgabe abzuschließen.

• Deploying Django (Django-Dokumentation)

  • Deployment-Checkliste (Django-Dokumentation)
  • Bereitstellung statischer Dateien (Django-Dokumentation)
  • Wie man mit WSGI bereitstellt (Django-Dokumentation)
  • Wie man Django mit Apache und mod_wsgi verwendet (Django-Dokumentation)
  • Wie man Django mit Gunicorn verwendet (Django-Dokumentation)

• Railway-Dokumentation

  • CLI

• DigitalOcean

  • Wie man Django-Anwendungen mit uWSGI und Nginx auf Ubuntu 16.04 bereitstellt
  • Weitere DigitalOcean Django Community-Dokumente

• Heroku-Dokumentation (ähnliche Einrichtungskonzepte)

  • Konfiguration von Django-Apps für Heroku (Heroku-Dokumentation)
  • Erste Schritte auf Heroku mit Django (Heroku-Dokumentation)
  • Django und statische Ressourcen (Heroku-Dokumentation)
  • Nebenläufigkeit und Datenbankverbindungen in Django (Heroku-Dokumentation)
  • Wie Heroku funktioniert (Heroku-Dokumentation)
  • Dynos und der Dyno-Manager (Heroku-Dokumentation)
  • Konfiguration und Konfigurationsvariablen (Heroku-Dokumentation)
  • Einschränkungen (Heroku-Dokumentation)
  • Bereitstellen von Python-Anwendungen mit Gunicorn (Heroku-Dokumentation)
  • Arbeiten mit Django (Heroku-Dokumentation)

• Zurück
• Übersicht: Django Webframework (Python)
• Weiter