In diesem Artikel werde ich den Ablauf der tatsächlichen Bereitstellung (= Veröffentlichung auf einem Webserver) einer mit Django erstellten Webanwendung in einer Produktionsumgebung vorstellen.
python manage.py runserver wird davon ausgegangen, dass Sie den Vorgang auf localhost: 8000 bereits problemlos abgeschlossen haben.Von hier aus erklären wir, wie die erstellte Webanwendung tatsächlich in die Produktionsumgebung gestellt und veröffentlicht wird.
Dieses Mal möchten wir die Verzeichnisdateien wie folgt ablegen. (Hinweis: Einige irrelevante Teile werden diesmal weggelassen.)
/
├─var
│ └─www
│ └─html #Apache-Dokumentstamm
├─etc
│ └─httpd
│ ├─conf
│ │ └─httpd.conf #Apache-Konfigurationsdatei
│ └─conf.d
│ └─django.conf #Zusätzliche Konfigurationsdatei zum Ausführen von Django
└─home
└─ec2-user #Hier ist das erste Verzeichnis, in dem ssh eine Verbindung zur Instanz herstellt
└─Django
├─env #Virtuelle Umgebung zum Ausführen von Django-Apps
└─project #Django-Projekt
│ manage.py
├─static
├─project
│ │ settings.py
│ │ local_settings.py
│ └─ wsgi.py
└─app
├─templates
└─static
Dieses Mal werde ich die Django-App über das Remote-Repository von Github auf den Server bringen. Erstellen Sie zunächst ein Remote-Repository auf der Github-Website. Verwenden Sie danach den folgenden Befehl direkt unter dem Django-Projekt, um ein lokales Repository zu erstellen, das mit dem erstellten Remote-Repository verknüpft ist.
$ git init
$ git remote add origin [Remote-Repository-Adresse]
Folgendes müssen Sie tun, bevor Sie den Inhalt Ihres lokalen Repositorys remote übertragen können.
Die Django-App verfügt über Einstellungen, die zwischen der lokalen Umgebung und der Remote-Umgebung geändert werden müssen. In project / settings.py gibt es beispielsweise eine Variable namens DEBUG.
(local)project/settings.py
# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True
Wenn dies der Fall ist, wird im Falle eines http-Fehlers die detaillierte Fehlerposition im Browser angezeigt. Wenn dies jedoch in der Produktionsumgebung aktiviert ist, werden detaillierte Informationen auf dem Server an Dritte weitergegeben, sodass dies nicht gut ist. Daher wird empfohlen, in der Produktionsumgebung False beizubehalten.
Außerdem gibt es in project / settings.py eine Variable namens SECRET_KEY.
(local)project/settings.py
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'pej^q2ql$$#bzg#crh6k_9(p=%p)&6x(kwh@nos&=!$ej&60fh' #example
Dies gibt den privaten Schlüssel an, der für die Verschlüsselung und das Hashing verwendet wird, sodass er nicht außerhalb des Projekts verfügbar gemacht werden sollte. Mit anderen Worten, übertragen Sie die Konfigurationsdatei mit diesem Wert nicht in ein Remote-Repository auf Github.
Deshalb,
Fügen Sie die Informationen in eine andere Datei als die normale Datei project / settings.py ein und schließen Sie sie von der Git-Verwaltung aus.
Erstellen Sie in der Projektdatei eine neue Datei mit dem Namen local_settings.py und geben Sie die Einstellungen ein, die Sie nicht mit git verwalten möchten.
(local)project/local_settings.py
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'pej^q2ql$$#bzg#crh6k_9(p=%p)&6x(kwh@nos&=!$ej&60fh' #example
# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True
Löschen Sie anschließend die in local_settings.py beschriebenen Informationen aus der Datei project / settings.py. Fügen Sie dann oben die folgende Zeile hinzu, um die Informationen in local_settings.py zu lesen.
from .local_settings import *
Die Konfigurationsdatei ist jetzt perfekt. Lassen Sie uns dann das erstellte git local_settings.py verwalten.
(local)project/settings.py
$ vi .gitignore
#Schreib das Folgende
local_settings.py
Jetzt, da Sie bereit sind zu pushen, laden wir den Quellcode in ein Remote-Repository hoch.
$ git push origin master
Python, das standardmäßig in Amazon Linux enthalten ist, besteht aus 2 Serien, daher müssen Sie 3 Serien manuell installieren. Installieren Sie dieses Mal Python 3.6 und das entsprechende Entwicklungstool mit dem Befehl yum.
$ sudo yum install python36 python36-devel
Auf diese Weise wird Python der 3er-Serie auf den Server gestellt.
Beachten Sie, dass das Standardsystem 2 verwendet wird, wenn Sie nur den Befehl python drücken. Der Befehl zur Verwendung der gerade installierten 3er-Serie ist der Befehl python3.
$ python -V
Python 2.7.16
$ python3 -V
Python 3.6.8
Dieses Mal werde ich die Django-App im Ordner / home / ec2-user / Django / ablegen. Erstellen Sie daher in diesem Django-Ordner eine dritte virtuelle Python-Umgebung mit dem Namen env.
$ cd /home/ec2-user/Django/
$ python3 -m venv env
Sie haben jetzt eine virtuelle Umgebung erstellt. Gehen Sie in diese Umgebung und verwenden Sie pip, um Django und mod_wsgi zu installieren.
$ source env/bin/activate
$ pip install django mod_wsgi
Wenn Sie andere Framework-Bibliotheken in Ihrer Django-App verwenden (z. B. Django Rest Fremework), müssen Sie diese ebenfalls installieren. Im Folgenden wird davon ausgegangen, dass Sie in dieser virtuellen Umgebung arbeiten.
Bringen Sie die Django-App aus dem in 1 vorbereiteten Github-Remote-Repository. Klonen Sie das Remote-Repository im Ordner / home / ec2-user / Django /.
$ git clone [Remote-Repository-Adresse]
Sie haben die App nun erfolgreich auf Ihren Server gebracht. Da jedoch eine Einstellung in local_settings.py früher gespeichert ist, werde ich local_settings.py manuell auf dem Server erstellen.
$ vi /project/project/local_settings.py
#Schreib das Folgende
SECRET_KEY = 'pej^q2ql$$#bzg#crh6k_9(p=%p)&6x(kwh@nos&=!$ej&60fh' #Machen Sie den gleichen Wert wie local
DEBUG = False #Da es sich um eine Produktionsumgebung handelt, setzen Sie sie auf False.
Überprüfen wir nun mit "python manage.py runserver", ob Django in der Umgebung des Servers ordnungsgemäß funktioniert. Wenn Sie zu diesem Zeitpunkt problemlos starten können, überspringen Sie 4 und fahren Sie mit 5 fort. Zu diesem Zeitpunkt wird möglicherweise ein SQLite3-Versionsfehler angezeigt.
$ python manage.py runserver
(Kürzung)
django.core.exceptions.ImproperlyConfigured: SQLite 3.8.3 or later is required (found 3.7.17).
In diesem Fall müssen Sie sqlite3 mit 3.8.3 oder höher installieren. Es gab Informationen, dass es mit "yum" nicht funktionieren würde, also entschied ich mich, stetig mit "wget" zu arbeiten. (Quelle: [django] SQLite-Versionsfehler)
#Holen Sie sich die neue Version von sqlite3 source
$ wget https://www.sqlite.org/2019/sqlite-autoconf-3300100.tar.gz
$ tar xzf ./sqlite-autoconf-3300100.tar.gz
$ rm -f ./sqlite-autoconf-3300100.tar.gz
#Erstellen und installieren
$ cd ./sqlite-autoconf-3300100/
$ ./configure --prefix=/usr/local
$ make
$ sudo make install
Referenz: Was tun, wenn beim Starten des Entwicklungsservers in Django 2.2 ein SQLite3-Fehler auftritt
Überprüfen Sie, ob die Installation erfolgreich war.
#Bestätigung des Installationsziels
$ sudo find /usr/ -name sqlite3
/usr/lib64/python2.6/sqlite3
/usr/lib64/python3.6/sqlite3
/usr/lib64/python2.7/sqlite3
/usr/bin/sqlite3
/usr/local/bin/sqlite3
#Versionsbestätigung
$ /usr/bin/sqlite3 --version
3.30.0 2019-10-10 20:19:45 18db032d058f1436ce3dea84081f4ee5a0f2259ad97301d43c426bc7f3df1b0b
Ich habe erfolgreich sqlite3 mit 3.8.3 oder höher erhalten. Benennen Sie das alte SQLite um → Erstellen Sie einen symbolischen Link für das neue SQLite, sodass der Befehl sqlite3 die neue Version verwendet.
$ sudo mv /usr/bin/sqlite3 /usr/bin/sqlite3_old
$ sudo ln -s /usr/local/bin/sqlite3 /usr/bin/sqlite3
Übergeben Sie außerdem den Pfad, um die neu installierte Version von sqlite3 zur gemeinsam genutzten Bibliothek hinzuzufügen.
$ vi /etc/ld.so.conf.d/sqlite3-x86_64.conf
#Schreib das Folgende
/usr/local/lib
Es gibt auch eine Möglichkeit, die Umgebungsvariable LD_LIBRARY_PATH zu aktualisieren, um den Pfad an die gemeinsam genutzte Bibliothek zu übergeben. Selbst wenn die Einstellung LD_LIBRARY_PATH an einer fehlerhaften Stelle definiert ist, wird sie nicht wiedergegeben. Also habe ich leise den Pfad in ld.so.conf.d definiert. Referenz: Es wird möglicherweise nicht wiedergegeben, auch wenn LD_LIBRARY_PATH festgelegt ist
(Artikel, auf die oben verwiesen wurde hat die Einstellung LD_LIBRARY_PATH in ~ / .bashrc geschrieben, dies hat jedoch nicht funktioniert.)
Sobald Sie überprüft haben, dass Django erfolgreich auf Ihrem Server gestartet werden kann, ist es Zeit, sich darauf vorzubereiten, es auf Apache zu veröffentlichen.
Verwenden Sie zuerst den Befehl find, um den Pfad zu überprüfen, in dem sich das zuvor eingegebene mod_wsgi befindet.
$ find -name 'mod_*.so'
./env/lib/python3.6/site-packages/mod_wsgi/server/mod_wsgi-py36.cpython-36m-x86_64-linux-gnu.so
Diese mod_wsgi-py36.cpython-36m-x86_64-linux-gnu.so ist der Hauptteil von mod_wsgi. Notieren Sie sich den Pfad, den Sie gerade für die spätere Verwendung überprüft haben.
Fügen Sie als Nächstes die Einstellungen zu Apache hinzu. Erstellen Sie mit dem folgenden Befehl eine neue Konfigurationsdatei, die mod_wsgi beschreibt.
$ sudo vi /etc/httpd/conf.d/django.conf
Dadurch wird vi gestartet und Sie können die Datei bearbeiten. Geben Sie hier die folgenden Einstellungen ein.
/etc/httpd/conf.d/django.conf
LoadModule wsgi_module /home/ec2-user/Django/env/lib64/python3.6/site-packages/mod_wsgi/server/mod_wsgi-py36.cpython-36m-x86_64-linux-gnu.so
WSGIScriptAlias / /home/ec2-user/Django/project/project/wsgi.py
WSGIPythonPath /home/ec2-user/Django/env/lib/python3.6/site-packages
WSGIPythonHome /home/ec2-user/Django/env
<Directory /home/ec2-user/Django/project/project>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
Die Einstellung hat folgende Bedeutung.
--LoadModule: Der Speicherort der mod_wsgi-Body-Datei. --WSGIScriptAlias: Einstellung für die Übertragung zum zweiten wsgi-Skript, wenn auf die erste URL zugegriffen wird. Hier wird die Anfrage, die an das Stammverzeichnis von Apache gesendet wurde, im Django-Projekt auf wsgi.py übersprungen. --WSGIPythonPath: Der Pfad, der während der Ausführung an Python übergeben werden soll. --WSGIPythonHome: Python-Ausgangsverzeichnis für Apache. --Directory ~ Below: Gewährt Apache-Berechtigungen für das angegebene Verzeichnis.
Referenz: Offizielles Dokument Verwendung von Django mit Apache und mod_wsgi
Starten Sie Apache nach dem Ausfüllen neu.
$ sudo service httpd restart
Wenn Sie über Ihren Browser auf Ihre Website zugreifen und das mit Django erstellte Projekt erfolgreich angezeigt wird, sind Sie erfolgreich!
Ich denke jedoch, dass sich mein derzeit im Browser angezeigtes Projekt in einem Zustand befindet, in dem CSS und JS nicht funktionieren / Bilder nicht angezeigt werden. Dies ist auf die unterschiedliche Behandlung statischer Dateien zwischen der Entwicklungsumgebung und der Produktionsumgebung zurückzuführen.
Im Allgemeinen sollten statische Dateien bei der Entwicklung einer App mit Django häufig in statischen Ordnern in jeder Anwendung gespeichert werden.
project
│ manage.py
├─project
│ │ settings.py
│ │ local_settings.py
│ └─ wsgi.py
├─app1
│ ├─templates
│ └─static #Statische Datei, die von App1 verwendet wird
└─app2
├─templates
└─static #Statische Datei, die von App2 verwendet wird
In der Produktionsumgebung (= DEBUG ist in der Einstellung False) werden jedoch alle statischen Dateien an einem Ort (im Allgemeinen direkt unter dem Projekt) gesammelt und vom Webserver (Apache) verwendet. Daher wird nicht erkannt, wann statisch für jede Anwendung wie zum Zeitpunkt der Entwicklung verteilt wird. Referenz: Offizielles Dokument Statische Dateien bereitstellen Umgang mit statischen Dateien in Django
Django verfügt über einen Mechanismus, mit dem Sie dies mit einem einzigen Befehl tun können, ohne manuell ein statisches Dateiverzeichnis für Ihre Produktionsumgebung erstellen zu müssen. Von hier aus können Sie damit Einstellungen zum Sammeln statischer Dateien direkt unter dem Projekt hinzufügen.
Stellen Sie sicher, dass Sie die folgenden Einstellungen in project / settings.py haben:
project/settings.py
# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/2.2/howto/static-files/
STATIC_URL = '/static/'
Diese Einstellung sollte standardmäßig vorhanden sein. Die Bedeutung von jedem ist wie folgt.
--BASE_DIR: Pfad des Projektdokumentstamms (= oberstes Projektverzeichnis). --STATIC_URL: URL für die Verteilung statischer Dateien.
Sobald dies bestätigt ist, fügen Sie die folgenden Einstellungen zu settings.py hinzu.
project/settings.py
STATIC_ROOT = os.path.join(BASE_DIR, 'static')
STATIC_ROOT ist eine Einstellung, in der statische Dateien für die Produktionsumgebung erfasst werden. Hier lautet die Einstellung "Erstellen Sie einen Ordner namens static direkt unter dem Projekt".
Wenn Sie dies tun können, sind Sie bereit zu gehen. Verwenden Sie Befehle, um die statischen Dateien zu sammeln, die für jede Anwendung am Speicherort von STATIC_ROOT verteilt sind. Gehen Sie direkt unter das Projekt (wo manage.py ausgeführt werden kann) und führen Sie den folgenden Befehl aus.
$ python manage.py collectstatic
Durch Ausführen dieses Befehls wird automatisch eine statische Datei direkt unter dem Projekt generiert und alle von der Anwendung verwendeten statischen Dateien werden darin gespeichert.
project
│ manage.py
├─static #Neues Verzeichnis
├─project
│ │ settings.py
│ │ local_settings.py
│ └─ wsgi.py
├─app1
│ ├─templates
│ └─static
└─app2
├─templates
└─static
Lassen Sie Apache als Nächstes das Verzeichnis der statischen Dateien erkennen, die an einem Ort gesammelt wurden. Fügen Sie der Datei /etc/httpd/conf.d/django.conf die folgenden Einstellungen hinzu.
/etc/httpd/conf.d/django.conf
Alias /static/ /home/ec2-user/Django/project/static/
<Directory /home/ec2-user/Django/project/static>
Require all granted
</Directory>
Die Bedeutung von jedem ist wie folgt.
--Alias: Wenn auf die erste URL zugegriffen wird, wird sie in das zweite Verzeichnis übertragen. Wenn auf (Domänenname) / static (STATIC_ROOT in settings.py festgelegt) zugegriffen wird, wird hier die statische Datei für die zuvor mit dem Befehl collect static erstellte Produktionsumgebung übersprungen.
--Verzeichnis und darunter: Gewähren Sie statischen Dateien für Produktionsumgebungen Apache-Berechtigungen.
Starten Sie Apache neu, sobald Sie bereit sind.
$ sudo service httpd restart
Wenn Sie über Ihren Browser auf Ihre Domain zugreifen und Ihre Website mit statischen Dateien anzeigen können, ist dies ein großer Erfolg!
Recommended Posts