So bedienen Sie Django-Anwendungen mit uWSGI und Nginx unter Ubuntu 16.04

Einführung

Django ist ein leistungsstarkes Webframework, mit dem Sie Ihre Python-Anwendung oder -Website auf den Markt bringen können. Django enthält einen vereinfachten Entwicklungsserver zum Testen Ihres Codes vor Ort, aber für alles, was auch nur geringfügig mit der Produktion zu tun hat, ist ein sicherer und leistungsfähigerer Webserver erforderlich.

In diesem Handbuch wird gezeigt, wie Sie einige Komponenten auf Ubuntu 16.04 installieren und konfigurieren, um Django-Anwendungen zu unterstützen und zu bedienen. Wir werden den uWSGI-Anwendungscontainerserver für die Schnittstelle mit unseren Anwendungen konfigurieren. Wir werden dann Nginx so einrichten, dass es den Proxy für uWSGI umkehrt und uns Zugriff auf seine Sicherheits- und Leistungsfunktionen gewährt, um unsere Apps bereitzustellen.

Voraussetzungen und Ziele

Um dieses Handbuch zu vervollständigen, sollten Sie eine neue Ubuntu 16.04-Serverinstanz mit einem Nicht-Root-Benutzer haben, der über die Berechtigung "+ sudo +" verfügt. Weitere Informationen zum Einrichten finden Sie in unserem initial server setup guide.

Wir werden Django in zwei verschiedenen virtuellen Umgebungen installieren. Auf diese Weise können Ihre Projekte und deren Anforderungen separat behandelt werden. Wir werden zwei Beispielprojekte erstellen, damit wir die Schritte in einer Umgebung mit mehreren Projekten ausführen können.

Sobald wir unsere Anwendungen haben, werden wir den uWSGI-Anwendungsserver installieren und konfigurieren. Dies wird als Schnittstelle zu unseren Anwendungen dienen, die Client-Anforderungen über HTTP in Python-Aufrufe übersetzen, die unsere Anwendung verarbeiten kann. Wir werden dann Nginx vor uWSGI einrichten, um die Vorteile seiner hochleistungsfähigen Verbindungsbehandlungsmechanismen und seiner einfach zu implementierenden Sicherheitsfunktionen zu nutzen.

Lass uns anfangen.

Installieren und konfigurieren Sie VirtualEnv und VirtualEnvWrapper

Wir werden unsere Django-Projekte in ihrer eigenen virtuellen Umgebung installieren, um die jeweiligen Anforderungen zu isolieren. Dazu installieren wir "+ virtualenv ", mit dem virtuelle Python-Umgebungen erstellt werden können, und " virtualenvwrapper ", mit dem der " virtualenv +" - Workflow um einige Verbesserungen der Benutzerfreundlichkeit erweitert wird.

Wir werden diese beiden Komponenten mit + pip +, dem Python-Paketmanager, installieren. Wir können dieses Dienstprogramm von den Ubuntu-Repositories installieren.

Wenn Sie Ihre Django-Projekte mit * Python 2 * erstellen, geben Sie Folgendes ein:

sudo apt-get update
sudo apt-get install python-pip

Wenn Sie * Python 3 * verwenden, geben Sie Folgendes ein:

sudo apt-get update
sudo apt-get install python3-pip

Nachdem Sie "+ pip" installiert haben, können wir "+ virtualenv" und "+ virtualenvwrapper" global installieren. Wir werden + pip auch mit` + pip` selbst auf die neueste Version upgraden.

Wenn Sie * Python 2 * verwenden, geben Sie Folgendes ein:

sudo -H pip install --upgrade pip
sudo -H pip install virtualenv virtualenvwrapper

Wenn Sie * Python 3 * verwenden, geben Sie Folgendes ein:

sudo -H pip3 install --upgrade pip
sudo -H pip3 install virtualenv virtualenvwrapper

Wenn diese Komponenten installiert sind, können wir unsere Shell jetzt mit den Informationen konfigurieren, die für die Arbeit mit dem Skript "+ virtualenvwrapper " erforderlich sind. Unsere virtuellen Umgebungen werden alle in einem Verzeichnis in unserem Home-Ordner mit dem Namen " Env " abgelegt, um einen einfachen Zugriff zu ermöglichen. Dies wird durch eine Umgebungsvariable namens " WORKON_HOME +" konfiguriert. Wir können dies zu unserem Shell-Initialisierungsskript hinzufügen und das Wrapper-Skript für die virtuelle Umgebung als Quelle verwenden.

Wenn Sie * Python 3 * und den Befehl + pip3 + verwenden, müssen Sie Ihrem Shell-Initialisierungsskript auch eine zusätzliche Zeile hinzufügen:

echo "export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3" >> ~/.bashrc

Unabhängig davon, welche Version von Python Sie verwenden, müssen Sie die folgenden Befehle ausführen:

echo "export WORKON_HOME=~/Env" >> ~/.bashrc
echo "source /usr/local/bin/virtualenvwrapper.sh" >> ~/.bashrc

Versorgen Sie nun Ihr Shell-Initialisierungsskript mit einer Quelle, damit Sie diese Funktionalität in Ihrer aktuellen Sitzung verwenden können:

source ~/.bashrc

Sie sollten jetzt ein Verzeichnis mit dem Namen "+ Env +" in Ihrem Home-Ordner haben, das Informationen zur virtuellen Umgebung enthält.

Erstellen Sie Django-Projekte

Nachdem wir unsere Tools für die virtuelle Umgebung haben, werden wir zwei virtuelle Umgebungen erstellen, jeweils Django installieren und zwei Projekte starten.

Erstellen Sie das erste Projekt

Wir können auf einfache Weise eine virtuelle Umgebung erstellen, indem wir einige Befehle verwenden, die uns das Skript "+ virtualenvwrapper +" zur Verfügung stellt.

Erstellen Sie Ihre erste virtuelle Umgebung mit dem Namen Ihrer ersten Site oder Ihres ersten Projekts, indem Sie Folgendes eingeben:

mkvirtualenv

Dadurch wird eine virtuelle Umgebung erstellt, Python und "+ pip " darin installiert und die Umgebung aktiviert. Ihre Eingabeaufforderung ändert sich und zeigt an, dass Sie jetzt in Ihrer neuen virtuellen Umgebung arbeiten. Es sieht ungefähr so ​​aus: ` () @: ~ $ `. Der Wert in Klammern ist der Name Ihrer virtuellen Umgebung. Jegliche über " pip +" installierte Software wird nun in der virtuellen Umgebung anstatt auf dem globalen System installiert. Dies ermöglicht es uns, unsere Pakete auf Projektbasis zu isolieren.

Unser erster Schritt wird sein, Django selbst zu installieren. Wir können dazu "+ pip" ohne "+ sudo" verwenden, da wir dies lokal in unserer virtuellen Umgebung installieren:

pip install django

Mit Django können wir unser erstes Beispielprojekt erstellen, indem wir Folgendes eingeben:

cd ~
django-admin.py startproject

Dadurch wird ein Verzeichnis mit dem Namen "++" in Ihrem Ausgangsverzeichnis erstellt. Darin befindet sich ein Verwaltungsskript, mit dem verschiedene Aspekte des Projekts behandelt werden, und ein anderes Verzeichnis mit demselben Namen, in dem der eigentliche Projektcode gespeichert ist.

Wechseln Sie in das Verzeichnis der ersten Ebene, damit Sie mit dem Einrichten der Mindestanforderungen für unser Beispielprojekt beginnen können.

cd ~/

Beginnen Sie mit der Migration der Datenbank, um die von unserem Projekt verwendete SQLite-Datenbank zu initialisieren. Sie können auf Wunsch eine alternative Datenbank für Ihre Anwendung einrichten. Dies liegt jedoch außerhalb des Geltungsbereichs dieses Handbuchs:

~//manage.py migrate

Sie sollten jetzt eine Datenbankdatei mit dem Namen "+ db.sqlite3 +" in Ihrem Projektverzeichnis haben. Jetzt können wir einen Administrator erstellen, indem wir Folgendes eingeben:

~//manage.py createsuperuser

Zu diesem Zeitpunkt sollte Ihr Projektverzeichnis (in unserem Fall "+ ~ / +") den folgenden Inhalt haben:

  • + ~ / firstsite / manage.py +: Ein Django-Projektmanagement-Skript.

  • + ~ / firstsite / firstsite / +: Das Django-Projektpaket. Dies sollte die Dateien "+ init . Py ", " settings.py ", " urls.py " und " wsgi.py +" enthalten.

  • + ~ / firstsite / db.sqlite3 +: Die SQLite-Datenbankdatei, in der Ihre Site-Informationen gespeichert werden.

Öffnen Sie als Nächstes die Einstellungsdatei für das Projekt mit Ihrem Texteditor:

nano ~///settings.py

Suchen Sie zunächst die Direktive + ALLOWED_HOSTS +. Dies definiert eine Liste der Serveradressen oder Domänennamen, die zum Herstellen einer Verbindung mit der Django-Instanz verwendet werden können. Alle eingehenden Anforderungen mit einem * Host * -Header, der nicht in dieser Liste enthalten ist, lösen eine Ausnahme aus. Django erfordert, dass Sie dies einstellen, um eine bestimmte Sicherheitslücke zu vermeiden.

Listen Sie in den eckigen Klammern die IP-Adressen oder Domänennamen auf, die Ihrem Django-Server zugeordnet sind. Jeder Artikel sollte in Anführungszeichen mit durch Komma getrennten Einträgen aufgeführt werden. Wenn Sie Anfragen für eine gesamte Domain und Subdomains wünschen, stellen Sie einen Punkt vor den Beginn des Eintrags. Im folgenden Snippet sind einige Beispiele auskommentiert, um Folgendes zu demonstrieren:

~ / firstsite / firstsite / settings.py

. . .
# The simplest case: just add the domain name(s) and IP addresses of your Django server
# ALLOWED_HOSTS = [ 'example.com', '203.0.113.5']
# To respond to 'example.com' and any subdomains, start the domain with a dot
# ALLOWED_HOSTS = ['.example.com', '203.0.113.5']
ALLOWED_HOSTS = ['', '', ]

Da wir Nginx für die Bereitstellung unserer Site einrichten, müssen wir ein Verzeichnis konfigurieren, in dem die statischen Ressourcen unserer Site gespeichert werden. Auf diese Weise kann Nginx diese direkt bedienen, was sich positiv auf die Leistung auswirkt. Wir werden Django anweisen, diese in einem Verzeichnis mit dem Namen "+ static +" im Basisverzeichnis unseres Projekts abzulegen. Fügen Sie diese Zeile am Ende der Datei hinzu, um dieses Verhalten zu konfigurieren:

~ / firstsite / firstsite / settings.py

. . .
STATIC_URL = '/static/'

Speichern und schließen Sie die Datei, wenn Sie fertig sind. Sammeln Sie nun die statischen Elemente unserer Website und platzieren Sie sie in diesem Verzeichnis, indem Sie Folgendes eingeben:

~//manage.py collectstatic

Möglicherweise werden Sie aufgefordert, "Ja" einzugeben, um die Aktion zu bestätigen und den statischen Inhalt zu erfassen. Es wird ein neues Verzeichnis mit dem Namen "+ static +" in Ihrem Projektverzeichnis geben.

Als nächstes können wir einen Port öffnen, um auf den Django-Entwicklungsserver zuzugreifen. Wenn Sie die anfängliche Anleitung zur Serverkonfiguration befolgt haben, sollte eine UFW-Firewall aktiviert sein. Ermöglichen Sie Verbindungen zu Port 8080, indem Sie Folgendes eingeben:

sudo ufw allow 8080

Mit all dem können wir unser Projekt testen, indem wir den Entwicklungsserver vorübergehend starten. Art:

~//manage.py runserver 0.0.0.0:8080

Dadurch wird der Entwicklungsserver an Port "+ 8080 " gestartet. Besuchen Sie den Domainnamen oder die IP-Adresse Ihres Servers, gefolgt von " 8080 +" in Ihrem Browser:

http://:8080

Sie sollten eine Seite sehen, die so aussieht:

Fügen Sie "+ / admin +" am Ende der URL in der Adressleiste Ihres Browsers ein und Sie werden zur Anmeldeseite des Administrators weitergeleitet:

Melden Sie sich mit den Administratoranmeldeinformationen, die Sie mit dem Befehl "+ createduperuser +" ausgewählt haben, beim Server an. Sie haben dann Zugriff auf die Administrationsoberfläche:

Stoppen Sie nach dem Testen dieser Funktion den Entwicklungsserver, indem Sie in Ihr Terminal * CTRL-C * eingeben. Wir können jetzt mit unserem zweiten Projekt fortfahren.

Erstellen Sie das zweite Projekt

Das zweite Projekt wird genauso wie das erste erstellt. Wir werden die Erklärung in diesem Abschnitt abkürzen, da Sie dies bereits einmal ausgeführt haben.

Wechseln Sie zurück in Ihr Ausgangsverzeichnis und erstellen Sie eine zweite virtuelle Umgebung für Ihr neues Projekt. Installieren Sie Django in dieser neuen Umgebung, sobald es aktiviert ist:

cd ~
mkvirtualenv
pip install django

Die neue Umgebung wird erstellt und in geändert, wobei Ihre vorherige virtuelle Umgebung verlassen wird. Diese Django-Instanz ist völlig unabhängig von der anderen, die Sie konfiguriert haben. Auf diese Weise können Sie sie unabhängig verwalten und bei Bedarf anpassen.

Erstellen Sie das zweite Projekt und verschieben Sie es in das Projektverzeichnis:

cd ~
django-admin.py startproject
cd ~/

Initialisieren Sie die Datenbank und erstellen Sie einen Administrator:

~//manage.py migrate
~//manage.py createsuperuser

Öffnen Sie die Einstellungsdatei:

nano ~///settings.py

Setzen Sie "+ ALLOWED_HOSTS +" auf die Domäne Ihres zweiten Projekts, die IP-Adresse des Servers oder auf beide, genau wie Sie es beim ersten Projekt getan haben:

ALLOWED_HOSTS = ['', '', ]

Fügen Sie den Speicherort für die statischen Dateien wie im vorherigen Projekt hinzu:

~ / secondsite / secondsite / settings.py

. . .
STATIC_URL = '/static/'

Speichern und schließen Sie die Datei. Sammeln Sie nun die statischen Elemente in diesem Verzeichnis, indem Sie Folgendes eingeben:

~//manage.py collectstatic

Starten Sie abschließend den Entwicklungsserver, um die Site zu testen:

~//manage.py runserver 0.0.0.0:8080

Sie sollten die reguläre Site unter folgender Adresse überprüfen:

http://:8080

Melden Sie sich auch auf der Admin-Site an:

http://:8080/admin

Wenn Sie bestätigt haben, dass alles wie erwartet funktioniert, geben Sie in Ihr Terminal * STRG-C * ein, um den Entwicklungsserver zu stoppen.

Sichern aus der virtuellen Umgebung

Da wir nun mit dem Django-Teil des Handbuchs fertig sind, können wir unsere zweite virtuelle Umgebung deaktivieren:

deactivate

Wenn Sie erneut an einer Ihrer Django-Sites arbeiten müssen, sollten Sie deren jeweilige Umgebungen reaktivieren. Sie können dies mit dem Befehl + workon + tun:

workon

Or:

workon

Deaktivieren Sie erneut, wenn Sie mit der Arbeit an Ihren Websites fertig sind:

deactivate

Nun können wir mit der Konfiguration des Anwendungsservers fortfahren.

Einrichten des uWSGI-Anwendungsservers

Nachdem wir zwei Django-Projekte eingerichtet und einsatzbereit haben, können wir uWSGI konfigurieren. uWSGI ist ein Anwendungsserver, der über eine Standardschnittstelle namens WSGI mit Anwendungen kommunizieren kann. Weitere Informationen hierzu finden Sie unter https://www.digitalocean.com/community/tutorials/how-to-set-up-uwsgi-and-nginx-to-serve-python-apps-on-ubuntu-14-04 # Definitionen und Konzepte [dieser Abschnitt] unseres Handbuchs zum Einrichten von uWSGI und Nginx unter Ubuntu 14.04.

UWSGI installieren

Im Gegensatz zu der oben verlinkten Anleitung werden wir in diesem Tutorial uWSGI global installieren. Dies führt zu weniger Reibungsverlusten bei der Bearbeitung mehrerer Django-Projekte. Bevor wir uWSGI installieren können, benötigen wir die Python-Entwicklungsdateien, auf die sich die Software stützt. Wir können dies direkt aus den Ubuntu-Repositories installieren.

Wenn Sie Django mit * Python 2 * verwenden, geben Sie Folgendes ein:

sudo apt-get install python-dev

Wenn Sie * Python 3 * verwenden, geben Sie Folgendes ein:

sudo apt-get install python3-dev

Nachdem die Entwicklungsdateien verfügbar sind, können wir uWSGI global über "+ pip +" installieren.

Wenn Sie * Python 2 * verwenden, geben Sie Folgendes ein:

sudo -H pip install uwsgi

Wenn Sie * Python 3 * verwenden, geben Sie Folgendes ein:

sudo -H pip3 install uwsgi

Wir können diesen Anwendungsserver schnell testen, indem wir ihm die Informationen für eine unserer Sites übergeben. Zum Beispiel können wir sagen, dass es unserem ersten Projekt dienen soll, indem wir Folgendes eingeben:

uwsgi --http :8080 --home /home//Env/ --chdir /home// -w .wsgi

Hier haben wir uWSGI angewiesen, unsere virtuelle Umgebung zu verwenden, die sich in unserem Verzeichnis "+ ~ / Env " befindet, in das Verzeichnis unseres Projekts zu wechseln und die in unserem inneren Verzeichnis "+" gespeicherte Datei "+ wsgi.py " zu verwenden um die Datei bereitzustellen (unter Verwendung der Python-Modulsyntax ` firstsite.wsgi `). Zu unserer Demonstration haben wir ihn angewiesen, HTTP auf dem Port " 8080 +" bereitzustellen.

Wenn Sie in Ihrem Browser den Domainnamen oder die IP-Adresse des Servers aufrufen, gefolgt von ": 8080 +", wird Ihre Site erneut angezeigt (die statischen Elemente in der " / admin +" - Oberfläche wie CSS funktionieren noch nicht ). Wenn Sie mit dem Testen dieser Funktionalität fertig sind, geben Sie im Terminal STRG-C ein.

Konfigurationsdateien erstellen

Das Ausführen von uWSGI über die Befehlszeile ist zum Testen hilfreich, für eine tatsächliche Bereitstellung jedoch nicht besonders hilfreich. Stattdessen führen wir uWSGI im „Emperor-Modus“ aus, der es einem Master-Prozess ermöglicht, separate Anwendungen automatisch anhand einer Reihe von Konfigurationsdateien zu verwalten.

Erstellen Sie ein Verzeichnis, in dem Ihre Konfigurationsdateien gespeichert werden. Da dies ein globaler Prozess ist, erstellen wir ein Verzeichnis mit dem Namen "+ / etc / uwsgi / sites +", um unsere Konfigurationsdateien zu speichern:

sudo mkdir -p /etc/uwsgi/sites

In diesem Verzeichnis werden wir unsere Konfigurationsdateien ablegen. Für jedes von uns betreute Projekt benötigen wir eine Konfigurationsdatei. Der uWSGI-Prozess kann Konfigurationsdateien in einer Vielzahl von Formaten verarbeiten, wir werden jedoch aufgrund ihrer Einfachheit "+ .ini +" - Dateien verwenden.

Erstellen Sie eine Datei für Ihr erstes Projekt und öffnen Sie sie in Ihrem Texteditor:

sudo nano /etc/uwsgi/sites/.ini

Im Inneren müssen wir mit der Abschnittsüberschrift "+ [uwsgi] " beginnen. Alle unsere Informationen werden unter dieser Überschrift angezeigt. Wir werden auch Variablen verwenden, um die Wiederverwendbarkeit unserer Konfigurationsdatei zu verbessern. Setzen Sie nach dem Header eine Variable mit dem Namen " project " und dem Namen Ihres ersten Projekts. Fügen Sie eine Variable mit dem Namen " uid " hinzu, die Ihren " sudo +" - Benutzernamen enthält.

Wir werden auch eine Variable mit dem Namen "+ base " mit dem Pfad zum Home-Verzeichnis Ihres Benutzers hinzufügen. Dies wird aus dem Benutzernamen erstellt, den wir mit der Syntax `% (Variablenname) +` festgelegt haben. Dies wird durch den Wert der Variablen ersetzt, wenn die Konfiguration gelesen wird:

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

Als nächstes müssen wir uWSGI so konfigurieren, dass es unser Projekt korrekt handhabt. Wir müssen in das Root-Projektverzeichnis wechseln, indem wir die Option + chdir + setzen. Wir können das Ausgangsverzeichnis und den Projektnamen mit der gleichen Variablensyntax kombinieren.

In ähnlicher Weise geben wir die virtuelle Umgebung für unser Projekt an. Durch Setzen des Moduls können wir genau angeben, wie die Schnittstelle zu unserem Projekt hergestellt werden soll (durch Importieren der "Anwendung", die aus der Datei "+ wsgi.py +" in unserem inneren Projektverzeichnis aufgerufen werden kann). Die Konfiguration dieser Elemente sieht folgendermaßen aus:

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

Wir wollen einen Masterprozess mit 5 Arbeitern erstellen. Wir können dies tun, indem wir Folgendes hinzufügen:

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

master = true
processes = 5

Als nächstes müssen wir festlegen, wie uWSGI auf Verbindungen wartet. In unserem Test von uWSGI verwendeten wir HTTP und einen Netzwerkport. Da wir Nginx jedoch als Reverse-Proxy verwenden werden, haben wir bessere Optionen.

Anstatt einen Netzwerkport zu verwenden, können wir einen Unix-Socket verwenden, da alle Komponenten auf einem einzelnen Server ausgeführt werden. Dies ist sicherer und bietet eine bessere Leistung. Dieser Socket verwendet kein HTTP, sondern implementiert stattdessen das uWSGI-Protokoll "+ uwsgi ", ein schnelles Binärprotokoll für die Kommunikation mit anderen Servern. Nginx kann nativ Proxys mit dem " uwsgi +" - Protokoll erstellen, daher ist dies unsere beste Wahl.

Wir werden auch den Besitz und die Berechtigungen des Sockets ändern, da wir dem Webserver Schreibzugriff gewähren. Wir setzen die Option "+ vacuum +", damit die Socket-Datei automatisch bereinigt wird, wenn der Dienst beendet wird:

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

master = true
processes = 5

socket = /run/uwsgi/%(project).sock
chown-socket = %(uid):www-data
chmod-socket = 660
vacuum = true

Damit ist die uWSGI-Konfiguration unseres ersten Projekts abgeschlossen. Speichern und schließen Sie die Datei.

Das Einrichten der Datei mit Variablen hat den Vorteil, dass die Wiederverwendung unglaublich einfach ist. Kopieren Sie die Konfigurationsdatei Ihres ersten Projekts, um sie als Grundlage für Ihre zweite Konfigurationsdatei zu verwenden:

sudo cp /etc/uwsgi/sites/.ini /etc/uwsgi/sites/.ini

Öffnen Sie die zweite Konfigurationsdatei mit Ihrem Texteditor:

sudo nano /etc/uwsgi/sites/.ini

Wir müssen nur einen einzelnen Wert in dieser Datei ändern, damit es für unser zweites Projekt funktioniert. Ändern Sie die Variable "+ project +" mit dem Namen, den Sie für Ihr zweites Projekt verwendet haben:

/etc/uwsgi/sites/secondsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

master = true
processes = 5

socket = /run/uwsgi/%(project).sock
chown-socket = %(uid):www-data
chmod-socket = 660
vacuum = true

Speichern und schließen Sie die Datei, wenn Sie fertig sind. Ihr zweites Projekt sollte jetzt fertig sein.

Erstellen Sie eine systemd Unit-Datei für uWSGI

Wir haben jetzt die Konfigurationsdateien, die wir für unsere Django-Projekte benötigen, aber wir haben den Prozess noch nicht automatisiert. Als Nächstes erstellen wir eine System-Unit-Datei, um den uWSGI-Kaiserprozess zu verwalten und uWSGI beim Booten automatisch zu starten.

Wir erstellen die Unit-Datei im Verzeichnis "+ / etc / systemd / system ", in dem vom Administrator erstellte Unit-Dateien gespeichert werden. Wir rufen Ihre Datei " uwsgi.service" auf:

sudo nano /etc/systemd/system/uwsgi.service

Beginnen Sie mit dem Abschnitt "+ [Einheit] +", in dem Metadaten und Bestellinformationen angegeben werden. Hier geben wir einfach eine Beschreibung unseres Service:

/etc/systemd/system/uwsgi.service

[Unit]
Description=uWSGI Emperor service

Als nächstes werden wir den Abschnitt "+ [Service] " öffnen. Wir werden die Direktive " ExecStartPre " verwenden, um die Teile einzurichten, die wir zum Ausführen unseres Servers benötigen. Dadurch wird sichergestellt, dass das Verzeichnis " / run / uwsgi " erstellt wird und dass es unserem normalen Benutzer mit der Gruppe " www-data " als Gruppeneigentümer gehört. Beide ` mkdir ` mit dem ` -p ` Flag und dem ` chown +` Befehl kehren erfolgreich zurück, auch wenn ihre Operation nicht benötigt wird. Das wollen wir.

Für den eigentlichen Startbefehl, der in der Direktive "+ ExecStart " angegeben ist, verweisen wir auf die ausführbare Datei " uwsgi ". Wir werden es anweisen, im "Emperor-Modus" zu laufen, damit es mehrere Anwendungen mit den Dateien verwalten kann, die es in " / etc / uwsgi / sites +" findet. Wir werden auch die Teile hinzufügen, die für systemd benötigt werden, um den Prozess korrekt zu verwalten. Diese sind der uWSGI-Dokumentation here entnommen.

/etc/systemd/system/uwsgi.service

[Unit]
Description=uWSGI Emperor service

[Service]
ExecStartPre=/bin/bash -c 'mkdir -p /run/uwsgi; chown :www-data /run/uwsgi'
ExecStart=/usr/local/bin/uwsgi --emperor /etc/uwsgi/sites
Restart=always
KillSignal=SIGQUIT
Type=notify
NotifyAccess=all

Jetzt müssen wir nur noch den Abschnitt + [Install] + hinzufügen. Auf diese Weise können wir festlegen, wann der Dienst automatisch gestartet werden soll. Wir werden unseren Service an den Multi-User-Systemstatus binden. Immer wenn das System für mehrere Benutzer eingerichtet ist (normaler Betriebszustand), wird unser Service aktiviert:

/etc/systemd/system/uwsgi.service

[Unit]
Description=uWSGI Emperor service

[Service]
ExecStartPre=/bin/bash -c 'mkdir -p /run/uwsgi; chown :www-data /run/uwsgi'
ExecStart=/usr/local/bin/uwsgi --emperor /etc/uwsgi/sites
Restart=always
KillSignal=SIGQUIT
Type=notify
NotifyAccess=all

[Install]
WantedBy=multi-user.target

Wenn Sie fertig sind, speichern und schließen Sie die Datei.

Der Dienst kann zu diesem Zeitpunkt nicht erfolgreich gestartet werden, da der Benutzer "+ www-data +" verfügbar ist. Wir müssen warten, bis der uWSGI-Dienst nach der Installation von Nginx gestartet wird.

Installieren und konfigurieren Sie Nginx als Reverse Proxy

Nachdem uWSGI konfiguriert und einsatzbereit ist, können wir jetzt Nginx als unseren Reverse-Proxy installieren und konfigurieren. Dies kann von Ubuntus Standard-Repositorys heruntergeladen werden:

sudo apt-get install nginx

Sobald Nginx installiert ist, können wir für jedes unserer Projekte eine Serverblock-Konfigurationsdatei erstellen. Beginnen Sie mit dem ersten Projekt, indem Sie eine Serverblock-Konfigurationsdatei erstellen:

sudo nano /etc/nginx/sites-available/

Im Inneren können wir unseren Serverblock starten, indem wir die Portnummer und den Domainnamen angeben, auf die unser erstes Projekt zugreifen soll. Der + Servername + Block muss mit einem der Domainnamen des Servers oder seiner IP-Adresse übereinstimmen, oder es kann stattdessen die Standard-Nginx-Seite verwendet werden. Wir gehen davon aus, dass Sie für jede Domain einen Domainnamen haben:

/ etc / nginx / sites-available / firstsite

server {
   listen 80;
   server_name .com www..com;
}

Als Nächstes können wir Nginx anweisen, sich keine Sorgen zu machen, wenn kein Favicon gefunden wird. Wir verweisen außerdem auf den Speicherort unseres statischen Dateiverzeichnisses, in dem wir die statischen Elemente unserer Website gesammelt haben:

/ etc / nginx / sites-available / firstsite

server {
   listen 80;
   server_name .com www..com;

   location = /favicon.ico { access_log off; log_not_found off; }
   location /static/ {
       root /home//;
   }
}

Als Nächstes können wir einen Catch-All-Location-Block erstellen, der alle zusätzlichen Abfragen direkt an unsere Anwendung weiterleitet. Wir werden die + uwsgi + - Parameter in + / etc / nginx / uwsgi_params + aufnehmen und den Datenverkehr an den Socket übergeben, den der uWSGI-Server eingerichtet hat:

/ etc / nginx / sites-available / firstsite

server {
   listen 80;
   server_name .com www..com;

   location = /favicon.ico { access_log off; log_not_found off; }
   location /static/ {
       root /home//;
   }

   location / {
       include         uwsgi_params;
       uwsgi_pass      unix:/run/uwsgi/.sock;
   }
}

Damit ist unser erster Serverblock fertig.

Wir werden dies als Grundlage für die Nginx-Konfigurationsdatei unseres zweiten Projekts verwenden. Kopieren Sie es jetzt:

sudo cp /etc/nginx/sites-available/ /etc/nginx/sites-available/

Öffnen Sie die neue Datei in Ihrem Texteditor:

sudo nano /etc/nginx/sites-available/

Hier müssen Sie einen Verweis auf "" durch einen Verweis auf "" ersetzen. Sie müssen auch "+ Servername +" ändern, damit Ihr zweites Projekt auf einen anderen Domainnamen reagiert, oder den Port ändern, wenn Sie nicht mehr als einen Domainnamen oder eine IP-Adresse haben. Wenn Sie fertig sind, sieht es ungefähr so ​​aus:

/ etc / nginx / sites-available / secondsite

server {
   listen 80;
   server_name .com www..com;

   location = /favicon.ico { access_log off; log_not_found off; }
   location /static/ {
       root /home//;
   }

   location / {
       include         uwsgi_params;
       uwsgi_pass      unix:/run/uwsgi/.sock;
   }
}

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Verknüpfen Sie anschließend Ihre beiden neuen Konfigurationsdateien mit dem Verzeichnis "+ sites-enabled +" von Nginx, um sie zu aktivieren:

sudo ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled
sudo ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled

Überprüfen Sie die Konfigurationssyntax, indem Sie Folgendes eingeben:

sudo nginx -t

Wenn keine Syntaxfehler erkannt werden, können Sie den Nginx-Dienst neu starten, um die neue Konfiguration zu laden:

sudo systemctl restart nginx

Wenn Sie sich an früher erinnern, haben wir den uWSGI-Server nie gestartet. Tun Sie das jetzt, indem Sie Folgendes eingeben:

sudo systemctl start uwsgi

Löschen wir die UFW-Regel für den Port "+ 8080 +" und erlauben stattdessen den Zugriff auf unseren Nginx-Server:

sudo ufw delete allow 8080
sudo ufw allow 'Nginx Full'

Sie sollten nun in der Lage sein, Ihre beiden Projekte zu erreichen, indem Sie zu ihren jeweiligen Domain-Namen gehen. Sowohl die öffentliche als auch die Verwaltungsschnittstelle sollten wie erwartet funktionieren.

Wenn dies gut funktioniert, können Sie beide Dienste so konfigurieren, dass sie beim Booten automatisch gestartet werden, indem Sie Folgendes eingeben:

sudo systemctl enable nginx
sudo systemctl enable uwsgi

Note

Fehlerbehebung bei Nginx und uWSGI

Wenn Sie nicht auf Ihre Anwendung zugreifen können, müssen Sie eine Fehlerbehebung für Ihre Installation durchführen.

Nginx zeigt die Standardseite anstelle der Django-Anwendung an

Wenn Nginx die Standardseite anzeigt, anstatt auf Ihre Anwendung zu verweisen, bedeutet dies normalerweise, dass Sie in der Datei "+ / etc / nginx / sites-available / " das Zeichen " Servername +" anpassen müssen, um auf die IP-Adresse Ihres Servers zu verweisen Domain Name.

Nginx verwendet "+ Servername ", um zu bestimmen, welcher Serverblock zur Beantwortung von Anfragen verwendet werden soll. Wenn Sie die Standard-Nginx-Seite sehen, ist dies ein Zeichen dafür, dass Nginx die Anfrage nicht explizit einem Serverblock zuordnen konnte. Daher wird auf den Standardblock zurückgegriffen, der in ` / etc / nginx / sites-available / definiert ist. Standard + `.

Das "+ Servername +" im Serverblock Ihres Projekts muss genauer sein als das im Standardserverblock, der ausgewählt werden soll.

Nginx zeigt einen 502 Bad Gateway Error anstelle der Django-Anwendung an

Ein 502-Fehler weist darauf hin, dass Nginx die Anforderung nicht erfolgreich übermitteln kann. Eine Vielzahl von Konfigurationsproblemen äußert sich in einem 502-Fehler. Für eine ordnungsgemäße Fehlerbehebung sind daher weitere Informationen erforderlich.

Weitere Informationen finden Sie in den Fehlerprotokollen von Nginx. In der Regel erfahren Sie, welche Bedingungen während des Proxy-Vorgangs zu Problemen geführt haben. Folgen Sie den Nginx-Fehlerprotokollen, indem Sie Folgendes eingeben:

sudo tail -F /var/log/nginx/error.log

Stellen Sie jetzt eine weitere Anfrage in Ihrem Browser, um einen neuen Fehler zu generieren (versuchen Sie, die Seite zu aktualisieren). Sie sollten eine neue Fehlermeldung im Protokoll sehen. Wenn Sie sich die Meldung ansehen, kann dies Ihnen helfen, das Problem einzugrenzen.

Möglicherweise wird die folgende Meldung angezeigt:

  • connect () to unix: /run/uwsgi/firstsite.sock fehlgeschlagen (2: Keine solche Datei oder Verzeichnis) *

Dies zeigt an, dass Nginx die Socket-Datei am angegebenen Speicherort nicht finden konnte. Sie sollten den in den Dateien "+ firstsite " und " secondsite " in " / etc / nginx / sites-available " definierten Ort " uwsgi_pass " mit dem tatsächlichen Ort der Dateien " firstsite.sock " und "" vergleichen secondsite.sock + Socket-Dateien im Verzeichnis + / run / uwsgi + `.

Überprüfen Sie, ob die Socket-Dateien im Verzeichnis "+ / run / uwsgi +" vorhanden sind, indem Sie Folgendes eingeben:

sudo ls /run/uwsgi

Wenn sich in + / run / uwsgi + keine Socket-Dateien befinden, bedeutet dies im Allgemeinen, dass der + uwsgi + - Prozess diese nicht erstellen konnte. Überprüfen Sie den Status des Prozesses "+ uwsgi +", um festzustellen, ob er gestartet werden konnte:

sudo systemctl status uwsgi

Wenn der Befehl "+ systemctl status +" angibt, dass ein Fehler aufgetreten ist, oder wenn Sie die Socket-Dateien nicht im Verzeichnis finden, bedeutet dies, dass uWSGI nicht ordnungsgemäß gestartet werden konnte. Überprüfen Sie die uWSGI-Prozessprotokolle, indem Sie Folgendes eingeben:

sudo journalctl -u uwsgi

Sehen Sie sich die Meldungen in den Protokollen an, um herauszufinden, wo uWSGI auf Probleme gestoßen ist. Es gibt viele Gründe, auf die Sie möglicherweise gestoßen sind. Wenn uWSGI die Socket-Datei jedoch nicht erstellen konnte, liegt dies häufig an einem der folgenden Gründe:

  • Die Projektdateien gehören dem Benutzer "+ root " anstelle eines " sudo +" - Benutzers

  • Die Zeile "+ ExecStartPre " in der Datei " /etc/systemd/system/uwsgi.service +" enthält nicht den richtigen Befehl zum Erstellen des Verzeichnisses und zum Zuweisen des Eigentums

  • Der Pfad "+ uwsgi_pass " in den Site-Konfigurationsdateien im Verzeichnis " / etc / nginx / sites-available +" ist nicht auf den richtigen Socket-Speicherort ausgerichtet

  • Die in den Dateien "+ .ini " im Verzeichnis " / etc / uwsgi / sites +" definierte uWSGI-Konfiguration ist falsch. Überprüfen Sie die folgenden Punkte:

  • Die Anweisung + chdir + zeigt nach der Interpolation auf das Hauptprojektverzeichnis.

  • Die Direktive "+ home +" zeigt nach der Interpolation auf das Verzeichnis der virtuellen Umgebung.

  • Die Direktive "+ module " verwendet die Python-Modul-Importsyntax, um die Datei " wsgi.py +" aus dem inneren Projektverzeichnis zu laden.

  • Die Anweisung "+ socket " verweist auf eine Datei in der Datei " / run / uwsgi " (die durch die Zeile " ExecStartPre +" in der oben genannten Servicedatei erstellt werden sollte).

Wenn Sie Änderungen an der Datei "+ /etc/systemd/system/uwsgi.service +" vornehmen, laden Sie den Dämon erneut, um die Dienstdefinition erneut zu lesen, und starten Sie den uWSGI-Prozess erneut, indem Sie Folgendes eingeben:

sudo systemctl daemon-reload
sudo systemctl restart uwsgi

Das Beheben dieser Probleme sollte es Nginx ermöglichen, die Socket-Datei korrekt zu finden.

  • connect () to unix: /run/uwsgi/firstsite.sock fehlgeschlagen (13: Berechtigung verweigert) *

Dies weist darauf hin, dass Nginx aufgrund von Berechtigungsproblemen keine Verbindung zum uWSGI-Socket herstellen konnte. In der Regel geschieht dies, wenn der Socket in einer eingeschränkten Umgebung erstellt wird oder wenn die Berechtigungen falsch waren. Während der uWSGI-Prozess die Socket-Datei erstellen kann, kann Nginx nicht darauf zugreifen.

Dies kann vorkommen, wenn an einer beliebigen Stelle zwischen dem Stammverzeichnis (+ / +) der Socket-Datei eingeschränkte Berechtigungen bestehen. Sie können die Berechtigungen und Besitzwerte der Socket-Datei und der übergeordneten Verzeichnisse anzeigen, indem Sie den absoluten Pfad zu unserer Socket-Datei an den Befehl "+ namei +" übergeben:

namei -nom /run/uwsgi/firstsite.sock
Outputf: /run/uwsgi/firstsite.sock
drwxr-xr-x root  root     /
drwxr-xr-x root  root     run
drwxr-xr-x sammy www-data uwsgi
srw-rw---- sammy www-data firstsite.sock

Die Ausgabe zeigt die Berechtigungen der einzelnen Verzeichniskomponenten an. Anhand der Berechtigungen (erste Spalte), des Eigentümers (zweite Spalte) und des Gruppeneigentümers (dritte Spalte) können wir herausfinden, welche Art von Zugriff auf die Socket-Datei zulässig ist.

Im obigen Beispiel verfügt jedes der Verzeichnisse, die zur Socket-Datei führen, über Lese- und Ausführungsberechtigungen für die ganze Welt (die Berechtigungsspalte für die Verzeichnisse endet mit + r-x + anstelle von + --- +). Die Gruppe "+ www-data" hat Gruppeneigentum über den Socket selbst. Mit diesen Einstellungen sollte der Nginx-Prozess erfolgreich auf den Socket zugreifen können.

Wenn eines der Verzeichnisse, die zum Socket führen, nicht der Gruppe "+ www-data +" gehört oder keine Berechtigung zum Lesen und Ausführen in der Welt hat, kann Nginx nicht auf den Socket zugreifen. Normalerweise bedeutet dies, dass die Konfigurationsdateien einen Fehler aufweisen.

Wenn die Verzeichnispfade die Berechtigungen oder den Besitz zu stark einschränken, lesen Sie die Datei "+ /etc/systemd/system/uwsgi.service ". Die Anweisung " ExecStartPre " erstellt das Verzeichnis " / run / uwsgi " und weist der Gruppe " www-data +" den Gruppeneigentum zu. Wenn die Befehle hier nicht korrekt sind, sind die Verzeichnispfade möglicherweise zu restriktiv.

Wenn der Zugriff auf die Socket-Datei selbst für den Nginx-Prozess nicht möglich ist, sind möglicherweise die Einstellungen in den "+ .ini " - Dateien in " / etc / uwsgi / sites " falsch. Überprüfen Sie die Werte von " chown-socket " und " chmod-socket +", um sicherzustellen, dass dem Webprozess die Berechtigung zum Zugriff auf die Dateien erteilt wurde.

Weitere Fehlerbehebung

Zur weiteren Fehlerbehebung können die Protokolle helfen, die Ursachen einzugrenzen. Überprüfen Sie sie nacheinander und suchen Sie nach Meldungen, die auf Problembereiche hinweisen.

Die folgenden Protokolle können hilfreich sein:

  • Überprüfen Sie die Nginx-Prozessprotokolle, indem Sie Folgendes eingeben: + sudo journalctl -u nginx +

  • Überprüfen Sie die Nginx-Zugriffsprotokolle, indem Sie Folgendes eingeben: + sudo less / var / log / nginx / access.log +

  • Überprüfen Sie die Nginx-Fehlerprotokolle, indem Sie Folgendes eingeben: + sudo less / var / log / nginx / error.log +

  • Überprüfen Sie die uWSGI-Anwendungsprotokolle, indem Sie Folgendes eingeben: + sudo journalctl -u uwsgi +

Während Sie Ihre Konfiguration oder Anwendung aktualisieren, müssen Sie wahrscheinlich die Prozesse neu starten, um sich an Ihre Änderungen anzupassen.

Wenn Sie Ihre Django-Anwendung aktualisieren, können Sie den uWSGI-Prozess neu starten, um die Änderungen zu übernehmen, indem Sie Folgendes eingeben:

sudo systemctl restart uwsgi

Wenn Sie die Service-Datei + uwsgi + systemd ändern, laden Sie den Daemon neu und starten Sie den Prozess neu, indem Sie Folgendes eingeben:

sudo systemctl daemon-reload
sudo systemctl restart uwsgi

Wenn Sie die Nginx-Serverblockkonfiguration ändern, testen Sie die Konfiguration und dann Nginx, indem Sie Folgendes eingeben:

sudo nginx -t && sudo systemctl restart nginx

Diese Befehle sind hilfreich, um Änderungen beim Anpassen Ihrer Konfiguration zu übernehmen.

Fazit

In diesem Handbuch haben wir zwei Django-Projekte in jeweils eigenen virtuellen Umgebungen eingerichtet. Wir haben uWSGI so konfiguriert, dass jedes Projekt unabhängig von der jeweils konfigurierten virtuellen Umgebung bereitgestellt wird. Anschließend haben wir Nginx so eingerichtet, dass es als Reverse-Proxy für die Verarbeitung von Clientverbindungen fungiert und je nach Clientanforderung das richtige Projekt bereitstellt.

Django vereinfacht das Erstellen von Projekten und Anwendungen, indem es viele der gemeinsamen Elemente bereitstellt, sodass Sie sich auf die einzigartigen Elemente konzentrieren können. Indem Sie die in diesem Artikel beschriebene allgemeine Toolkette nutzen, können Sie die von Ihnen erstellten Anwendungen problemlos von einem einzelnen Server aus bereitstellen.