Erstellen einer Django- und Gunicorn-Anwendung mit Docker auf Ubuntu

Django ist ein High-Level-Open-Source-Python-Web-Framework, das Ihnen hilft, Ihre Python-Anwendung schnell zu erstellen. Es fördert eine schnelle Entwicklung und ein klares, pragmatisches Design, indem es dem Model-Template-Views-Architekturmuster folgt. Standardmäßig bringt das Framework die notwendigen modernen Anwendungskomponenten wie Benutzerauthentifizierung, Caching-Framework, objektrelationalen Mapper, URL-Dispatcher, Template-System und eine anpassbare Verwaltungsoberfläche mit.

Gunicorn ‘Green Unicorn’ ist ein Python-WSGI-HTTP-Server für UNIX-Systeme. Der Gunicorn-Server ist mit verschiedenen Web-Frameworks kompatibel, bietet eine hervorragende Leistung und schont die Serverressourcen. Docker ist eine Open-Source-Container-Plattform, die es schon seit einiger Zeit gibt und die die Anwendungsentwicklung schnell, effizient und vorhersehbar macht.

In diesem Tutorial werden Sie Fähigkeiten in der Entwicklung und Bereitstellung skalierbarer, containerisierter Django-Web-Apps erwerben. Wir werden eine Django-Polls-App verwenden, die gemäß den Einführungsanleitungen für den Einstieg in Django erstellt wurde. Zum Zeitpunkt der Erstellung dieses Tutorials haben wir es auf Django 3.2, unterstützt von Python 3.6 oder neuer, aufgebaut. Wir werden die App als Container mit Docker bereitstellen und sie mit dem Gunicorn-Server ausführen. Natürlich müssen Sie vor der Bereitstellung der Django-App in einem Container einige Änderungen am Projektcode vornehmen, um Dinge wie die Protokollierung in Standard-Ausgabeströme und die Arbeit mit Umgebungsvariablen zu handhaben. Statische Dateien wie CSS- und JavaScript-Bilder können in Object-Storage-Dienste ausgelagert werden, um eine einfache Verwaltung der Dateien von einem einzigen Ort aus in einer Multi-Container-Umgebung zu ermöglichen.

Wir zeigen Ihnen, wie Sie diese Änderungen auf der Grundlage der gut beschriebenen Twelve-Factor-Methodik zur Erstellung skalierbarer Webanwendungen implementieren. Sobald Sie die Änderungen abgeschlossen haben, erstellen Sie ein Docker-Image der Anwendung und stellen die containerisierte App mit Docker bereit. Wir empfehlen Ihnen, den im Tutorial beschriebenen Schritten zu folgen, um ein vollständiges Verständnis des Tutorials zu erlangen.

Voraussetzungen

Da es sich um ein praktisches Tutorial handelt, empfehlen wir Ihnen, die folgende Einrichtung vorzunehmen, um dem Tutorial folgen zu können:

• Ein Ubuntu 20.04-Server. Sie können den Schritten 1 bis 4 dieser Schritt-für-Schritt-Anleitung zur Einrichtung Ihres Ubuntu-Servers auf CloudSigma folgen.

• Stellen Sie sicher, dass Sie einen Benutzer mit sudo-Rechten auf beiden Knoten hinzufügen, die wir zur Ausführung der Befehle verwenden werden, wie im obigen Tutorial beschrieben.

• Installieren Sie Docker auf dem Server. Sie können den Schritten 1, 2 und 3 unserer Anleitung zur Installation und zum Betrieb von Docker folgen. Denken Sie daran, den oben erstellten Sudo-Benutzer zur Docker-Gruppe hinzuzufügen.

• Ein kompatibler Object-Storage-Speicherplatz. Django unterstützt mehrere Speicherdienste, wie in der django-storages-Dokumentation aufgelistet. Sie können einen Dienst Ihrer Wahl wählen und der Dokumentation folgen, um ihn einzurichten. Für dieses Tutorial verwenden wir MinIO, einen S3-kompatiblen Cloud-Speicherdienst.

• Eine SQL-Datenbankinstanz. Django unterstützt mehrere SQL-Datenbanken, die Sie frei wählen können. Für dieses Tutorial verwenden wir PostgreSQL. Die PostgreSQL-Datenbank wird nicht in einem Container bereitgestellt. Wir werden einen separaten Ubuntu-Server einrichten, um die PostgreSQL-Instanz zu hosten, um sowohl unser Multi-Container-Setup als auch die Datenpersistenz zu gewährleisten. Sie können eine weitere Ubuntu 20.04-Instanz erstellen und dieser Anleitung folgen, um eine PostgreSQL-Datenbankinstanz auf Ubuntu einzurichten. Denken Sie daran, eine Rolle in der PostgreSQL-Datenbank für Ihren Sudo-Benutzer hinzuzufügen, wie in den Schritten 2 und 3 erklärt. Diese Rolle ermöglicht es Ihnen, sich von den anderen Servern, auf denen Ihre Container gehostet werden, mit der Datenbank zu verbinden.

Gemäß diesen Voraussetzungen sollten Sie über zwei Ubuntu-Server-Instanzen verfügen. Auf einer Instanz wird Ihr Docker-Container ausgeführt, auf der anderen Instanz die PostgreSQL-Instanz. Fangen wir an!

Schritt 1: Konfigurieren der PostgreSQL-Datenbankinstanz

In diesem Abschnitt werden wir die Postgres-Konfigurationen auf dem Ubuntu-Server ändern, auf dem die Postgres-Instanz läuft. Dies ermöglicht Verbindungen von einer externen IP-Adresse. Sobald die Verbindung hergestellt ist, können wir eine Datenbank und eine Benutzerrolle erstellen, die speziell für die von uns bereitgestellte Django Polls-App bestimmt sind.

First, if you had set up your environment as per the Prerequisites, you should have a role in your PostgreSQL database for your sudo user. Next, we need to set a password for this role. While on the server running PostgreSQL, log into the Postgres terminal with the following command:

Once on the Postgres terminal, issue the \password command to alter the password of a user. The syntax for the \passwordcommand is \password <username>. For our case, the command:

Enter the password and confirm it. Save this password somewhere safe as you will use it to authenticate from the other Ubuntu server later on. After that, type exit and hit Enter to exit the Postgres terminal.

If you had enabled firewall (ufw) on the PostgreSQL server instance, you will need to allow traffic to the Postgres default port 5432. You may restrict the traffic to only originate from a specific IP address of your other Ubuntu server that will run the Docker container. Execute the following command to add the ufw rule, replacing your IP address where highlighted:

This will ensure that only your server can connect to the PostgreSQL instance. While that allows traffic through the firewall, you also need to modify the PostgreSQL configuration files to allow connection from the remote IP address. By default, the configuration only allows connection from localhost. The configuration files for PostgreSQL are found at the /etc/postgresql/12/main directory. 12, in this case, is the version of PostgreSQL we installed for this tutorial. You may have installed a different version. Thus, you may change it into the directory /etc/postgresql/ and list contents to find the version number of the PostgreSQL you installed.

Use nano to modify the configuration file:

Find this line below, and uncomment it, set it to allow connections from all IPs:

Save and close the file. Then, you have to edit the pg_hba.conf file too, it’s in the same directory as the postgresql.conf. The pg_hba.conf allows you to define from which computers you can connect to the PostgreSQL instance as well as the method of authentication. Open the file with nano:

Please read the comments in this file to understand the keywords. The section we are looking for is this:

Our focus will be on the second line, you want it to look like the line below after uncommenting:

Please replace the highlighted part with your Ubuntu server IP address to allow it to connect to the PostgreSQL instance. Save the file once you are ready. Restart the PostgreSQL database for the changes to take effect:

Our other Ubuntu server with the specified IP address should be able to connect to the Postgres Instance.

Step 2: Connecting to the PostgreSQL Server Instance and Creating a Database and User

In this step, we will try to ensure that the Ubuntu instance serving our Docker container can connect to the other server running the PostgreSQL instance. Log into the Ubuntu instance that has Docker and install the postgresql-client package inside the Ubuntu host machine (not inside the container yet).

As a norm, first update the apt package and then install the package with the following commands:

Das oben installierte Paket hilft Ihnen beim Erstellen einer Datenbank und eines Benutzers für Ihre Anwendung. Als Nächstes müssen wir uns mit der PostgreSQL-Instanz verbinden, indem wir Verbindungsparameter an den PostgreSQL-Client übergeben.

Die Verbindungsparameter folgen dieser Syntax:

In diesem Befehl ist der username der Benutzer/die Rolle, den/die Sie Ihrer PostgreSQL-Datenbank hinzugefügt haben. host die IP-Adresse der Ubuntu-Instanz, auf der Ihre PostgreSQL-Datenbank ausgeführt wird. port der Standardport, auf dem Postgres auf eingehende Verbindungen lauscht, d. h. 5432. Anstelle der database, verwenden wir die Standarddatenbank namens postgres die mit der PostgreSQL-Installation geliefert wird. Ersetzen Sie Ihre Werte in den hervorgehobenen Teilen entsprechend und drücken Sie die Eingabetaste. Wenn Sie dazu aufgefordert werden, geben Sie das von Ihnen festgelegte Passwort ein. Dadurch werden Sie in der Postgres-Eingabeaufforderung angemeldet, in der Sie die Datenbank verwalten können.

Sie haben sich erfolgreich mit der PostgreSQL-Instanz verbunden. Sie können nun eine Datenbank für die Django-Polls-App erstellen. Nennen wir sie django_polls:

Stellen Sie sicher, dass Ihre Anweisung mit einem Semikolon endet, um Fehler zu vermeiden. Wechseln Sie dann in die django_polls-Datenbank mit dem Befehl:

Erstellen Sie als Nächstes einen für dieses Projekt spezifischen Datenbankbenutzer. Nennen wir den Benutzer django_user:

Wählen Sie ein sicheres Passwort für Ihren Benutzer. Sobald dies erledigt ist, müssen wir die Verbindungsparameter für den soeben erstellten Benutzer ändern. Dies hilft, Datenbankoperationen zu beschleunigen, indem sichergestellt wird, dass die korrekten Werte nicht bei jedem Verbindungsaufbau abgefragt und festgelegt werden.

Legen Sie die Standardkodierung, die Django erwartet, auf UTF-8 fest:

Legen Sie als Nächstes das Standard-Transaktionsisolationsschema auf „ read committed“ fest, was das Lesen von nicht abgeschlossenen Transaktionen blockiert:

Legen Sie Ihre Zeitzone fest. Um das Tutorial universell zu halten, verwenden wir UTC:

Schließlich gewähren Sie dem neuen Benutzer administrative Berechtigungen für die Datenbank:

Verlassen Sie die PostgreSQL-Eingabeaufforderung, wenn Sie bereit sind:

Das ist alles für diesen Schritt. Sobald Sie Ihre Django-App richtig konfiguriert haben, sollte sie in der Lage sein, Ihre Datenbank zu verwalten.

Schritt 3: Abrufen der App aus einem Git-Repository und Definieren von Abhängigkeiten

In diesem Schritt werden wir das Repository der Django-polls-App klonen. Dieses Repository enthält den Code für Djangos „Schreiben Sie Ihre erste Django-App“-Tutorial.

Melden Sie sich auf dem Ubuntu-Server an, auf dem Docker läuft, erstellen Sie ein Verzeichnis namens django_project und navigieren Sie hinein:

Klonen Sie dann das Repository mit dem folgenden Befehl in das Verzeichnis:

Navigieren Sie in das Verzeichnis und listen Sie den Inhalt auf:

Listen Sie den Inhalt des Verzeichnisses auf:

Beachten Sie die folgenden Elemente:

• manage.py: Diese Datei ist der Einstieg in das Befehlszeilenprogramm, das Django zur Verwaltung Ihrer App bereitstellt.

• mysite: ein Verzeichnis mit dem Django-Projektbereich und den Code-Einstellungen.

• polls: ein Verzeichnis, das den polls Anwendungscode enthält.

• templates: enthält benutzerdefinierte Vorlagendateien für die Admin-Seiten.

Um mehr darüber zu erfahren, wie wir das Projekt tatsächlich erstellt haben, werfen Sie bitte einen Blick auf das „Schreiben Sie Ihre erste Django-App“ aus der offiziellen Dokumentation. Innerhalb des django-polls-Verzeichnis wollen wir unsere Python-Abhängigkeiten in einer Textdatei definieren. Wir nennen sie requirements.txt. Öffnen Sie die Datei mit Ihrem bevorzugten Editor:

Fügen Sie die folgenden Zeilen in die Datei ein, um die Abhängigkeiten zu deklarieren:

In dieser Datei haben wir Python-Abhängigkeiten mit ihren genauen Versionen definiert, die beim Erstellen der App installiert werden sollen. Einige davon sind Django, django-storages für die Interaktion mit Object-Storage-Buckets, der psycopg2-Adapter für PostgreSQL, gunicorn-WSGI-Server und andere zusätzliche Abhängigkeiten. Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Schritt 4: Konfigurieren von Umgebungsvariablen für eine Django-App

Die twelve-factor app-Methodik empfiehlt, fest codierte Konfigurationen aus der Codebasis Ihrer Anwendung zu extrahieren. Auf diese Weise erhalten Sie die Freiheit, das Verhalten der Anwendung zur Laufzeit durch Ändern von Umgebungsvariablen zu ändern, ohne die Codebasis anzurühren. Docker funktioniert mit diesem Setup, daher werden wir die Einstellungsdatei so ändern, dass sie mit Umgebungsvariablen funktioniert. Kubernetes funktioniert ebenfalls mit diesem Konfigurations-Setup. Wir werden ein weiteres Tutorial zur Bereitstellung mit Kubernetes auf dem CloudSigma blog.

Die settings.py ist die Hauptkonfigurationsdatei für ein Django-Projekt. Es ist ein Python-Modul, das native Datenstrukturen zur Konfiguration der Anwendung verwendet. Für unsere Anwendung befindet sich die Datei am Speicherort django-polls/mysite/settings.py. Die meisten ihrer Werte sind fest codiert. Dies würde erfordern, dass Sie die Konfigurationsdatei in der Codebasis ändern, wenn Sie das Verhalten der Anwendung ändern. Das wollen wir ändern. Glücklicherweise bietet Python die getenv-Funktion im os-Modul an. Wir können sie verwenden, um Django so zu konfigurieren, dass Konfigurationsparameter stattdessen aus lokalen Umgebungsvariablen gelesen werden.

Fahren wir fort, indem wir die Datei django-polls/mysite/settings.py ändern, um die fest codierten Werte der Variablen zu ersetzen, die wir möglicherweise zur Laufzeit mit einem Aufruf von os.getenv aktualisieren möchten. Diese Funktion liest den Wert, der im angegebenen Namen der Umgebungsvariablen festgelegt ist. Optional können Sie einen zweiten Parameter angeben, der ein Standardwert ist, der verwendet wird, wenn die Umgebungsvariable nicht gesetzt ist.

Hier ist ein Beispiel:

In der obigen Zeile weisen wir Django an, den geheimen Schlüssel aus der Umgebungsvariablen abzurufen. Wir geben keinen Fallback-Wert an, da wir den Schlüssel extern bereitstellen werden. Wenn er nicht existiert, sollte der Start der Anwendung fehlschlagen. Während wir den geheimen Schlüssel extern bereitstellen, möchten wir auch sicherstellen, dass alle unsere containerisierten Kopien der App denselben Schlüssel auf den verschiedenen Servern verwenden. Dies vermeidet potenzielle Probleme, die entstehen, wenn die verschiedenen Kopien der App unterschiedliche Schlüssel verwenden.

Hier ist ein weiteres Beispiel mit einer Standardoption:

In dieser Zeile definieren wir eine Umgebungsvariable DEBUG, die gelesen werden soll. Wenn sie jedoch nicht gesetzt ist, haben wir einen zweiten Parameter angegeben, der an die DEBUG-Einstellungsvariable übergeben wird. DEBUG ist auf False gesetzt, um sicherzustellen, dass keine sensiblen Informationen an das Frontend übergeben werden, falls ein Problem mit der Anwendung auftritt. Wenn wir uns jedoch im Entwicklungsmodus befinden, möchten wir, dass sie auf True gesetzt ist, damit wir die Fehlerinformationen sehen können, was uns die Behebung von Fehlern erleichtert.

Da Sie nun wissen, wie wichtig Umgebungsvariablen sind, öffnen Sie die Datei django_project/django-polls/settings.py in Ihrem Editor. Importieren Sie zuerst das os-Modul, indem Sie diese Zeile am Anfang der settings.py-Datei hinzufügen:

Suchen Sie dann nach diesen Variablen und aktualisieren Sie sie wie folgt:

In der ALLOWED_HOSTS-Einstellung geben wir an, dass sie den Wert aus der Umgebungsvariable DJANGO_ALLOWED_HOSTS beziehen und diesen in eine Python-Liste aufteilen soll, wobei ein Komma ( ,) als Trennzeichen verwendet wird. Wenn die Variable fehlt, wird ALLOWED_HOSTS auf gesetzt.127.0.0.1.

Scrollen Sie als Nächstes durch die Datei und suchen Sie den Bereich DATABASES. Konfigurieren Sie diesen so, dass er ebenfalls aus Umgebungsvariablen liest:

Beachten Sie, dass wir das Modul json.loads hinzugefügt haben. Sie sollten auch einen Import des Moduls am Anfang der settings.py-Datei hinzufügen:

Die Funktion json.loads deserialisiert ein JSON-Objekt, das an DATABASES['default']['OPTIONS'] aus der Umgebungsvariable DB_OPTIONS übergeben wird. Die Angabe dieser Option ermöglicht es uns, eine beliebige Datenstruktur zu übergeben, um die Datenbankkonfiguration zu definieren. Eine Datenbank-Engine enthält eine Reihe von gültigen Optionen, die auf sie anwendbar sind. Die JSON-Option gibt uns die Flexibilität, ein JSON-Objekt mit den entsprechenden Parametern für die Datenbank-Engine zu kodieren, die wir gerade verwenden.

Der Wert DATABASES['default']['NAME'] gibt den Datenbanknamen in dem von uns eingerichteten relationalen Datenbankmanagementsystem an. Wenn Sie eine SQLite-Datenbank verwenden, sollten Sie den Pfad zur Datenbankdatei angeben.

Beachten Sie, dass Python mehrere Methoden bietet, um externe Umgebungsvariablen auszulesen. Wir haben nur eine davon verwendet. Es steht Ihnen frei, andere Methoden zu recherchieren und zu verwenden. In diesem Schritt haben Sie gelernt, wie Sie mit externen Umgebungsvariablen arbeiten. Dies gibt Ihnen die Flexibilität, die Variablen zu ändern und das Verhalten der in Containern ausgeführten App anzupassen. Im nächsten Schritt lernen Sie, wie Sie mit Objektspeicherdiensten arbeiten.

Schritt 5: Arbeiten mit externen Objektspeicherdiensten

Ein wesentlicher Vorteil der Containerisierung Ihrer Anwendung besteht darin, sie portabel zu machen, um bei steigendem Datenverkehr problemlos mehrere Kopien der App bereitzustellen. Dies schafft Raum für Skalierung. Dies bringt jedoch das Problem mit sich, Versionen von statischen Dateien und Assets über verschiedene Container hinweg zu verwalten. Dank der Fortschritte in der Cloud-Technologie können Sie diese gemeinsam genutzten statischen Elemente auf einen externen Speicher auslagern. Anschließend können Sie die Dateien über ein Netzwerk für alle Ihre laufenden Container zugänglich machen. Anstatt zu versuchen, die Dateien über die verschiedenen laufenden Container hinweg zu synchronisieren, haben Sie einen zentralen Ort, an dem Sie sie verwalten können.

Das Konzept, das wir oben zu erklären versuchen, ist die Nutzung von Cloud-Objektspeicherdiensten oder Simple Storage Services (S3). Django verfügt über ein Paket namens django-storages, das Ihnen die Arbeit mit Remote-Speicher-Backends ermöglicht. Django-storages funktioniert mit den meisten S3-kompatiblen Objektspeicherdiensten wie unter anderem FTP, SFTP, Amazons AWS S3, Google Cloud Storage, Dropbox und Azure Storage. In diesem Tutorial verwenden wir MinIO. Sie können gerne auch andere S3-kompatible Objektspeicherdienste. MinIOMinIO bietet hochleistungsfähigen, S3-kompatiblen Objektspeicher. Mit MinIO können Sie eine S3-kompatible Dateninfrastruktur in jeder Cloud aufbauen.

Wir zeigen Ihnen, wie Sie einen MinIO-Speicherdienst auf der CloudSigma-Plattform einrichten. Bitte befolgen Sie diese Schritte:

• Beginnen Sie damit, ein Konto auf CloudSigma zu erstellen. Wenn Sie bei der Erstellung des MinIO-Speichers auf Probleme stoßen, wenden Sie sich bitte an den kostenlosen 24/7-Live-Chat-Support von CloudSigma, und man wird Ihnen helfen.

• Fügen Sie Ihre Rechnungsinformationen hinzu.

• Fordern Sie als Nächstes Ihren öffentlich zugänglichen Bucket von hier an: https://blog.cloudsigma.com/xxxx. Sie müssen sich an den Live-Chat-Support wenden, um Ihre Kontozugangsdaten zu erhalten.

• Sobald Ihre MinIO-Objektspeicherumgebung erstellt wurde, erhalten Sie Zugangsdaten und weitere Anweisungen für den Zugriff darauf. Die Zugangsdaten sollten Ihre MINI_ACCESS_KEY, MINIO_SECRET_KEY, und MINIO_URL enthalten. Sie werden diese Schlüssel in den folgenden Anweisungen verwenden.

Lassen Sie uns einige weitere Änderungen an der mysite/settings.py-Datei vornehmen, die wir im vorherigen Schritt geändert haben. Fügen Sie in der Datei die storages-App zu Djangos Liste der INSTALLED_APPS:

Die storages-App wird über django-storages installiert, wie in der requirements.txt definiert. Scrollen Sie ganz nach unten in der Datei und ersetzen Sie die STATIC_URL-Variable durch das folgende Code-Snippet:

Beachten Sie, dass einige der Konfigurationsvariablen fest codiert sind:

• STATICFILES_STORAGE: definiert das Speicher-Backend, das Django zur Verarbeitung statischer Dateien verwendet. In unserem Leitfaden verwenden wir MinIO-Speicher, aber Sie können jedes beliebige S3-kompatible Backend verwenden, wie in der Dokumentation zu Django Storages erklärt.

• AWS_S3_OBJECT_PARAMETERS: definiert die Cache-Control-Header.

• AWS_LOCATION: Wir verwenden dies, um ein Verzeichnis innerhalb des Speicher-Buckets festzulegen, in dem alle statischen Dateien gespeichert werden. Es steht Ihnen frei, einen anderen Namen zu wählen.

• AWS_DEFAULT_ACL: legt die Zugriffskontrollliste (ACL) für statische Dateien fest. Wenn Sie den Wert auf ‘ public-Read’ setzen, werden die Dateien für alle öffentlichen Benutzer zugänglich gemacht.

• STATIC_URL: Django verwendet die in dieser Variable festgelegte Basis-URL, um URLs für statische Dateien zu generieren. Die Basis-URL wird in diesem Fall durch die Kombination der Endpunkt-URL und des Unterverzeichnisses für statische Dateien gebildet.

• STATIC_ROOT: definiert, wo statische Dateien lokal gesammelt werden sollen, bevor sie in den Remote-Objektspeicher kopiert werden.

Wir haben auch einige extern definierte Umgebungsvariablen, um Flexibilität und Portabilität zu gewährleisten:

• AWS_STORAGE_BUCKET_NAME: definiert den Namen des Storage-Buckets, in den Django die Assets hochlädt.

• AWS_S3_ENDPOINT_URL: definiert die Endpunkt-URL, die für den Zugriff auf den Object-Storage-Dienst verwendet wird. Dies ist die URL, die dem Server zugewiesen ist, auf dem Ihr MinIO-Dienst gehostet wird.

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

Sobald Sie diese Einstellungen vorgenommen und die deklarierten Python-Abhängigkeiten installiert haben, können Sie jederzeit den Django-Befehl manage.py collectstatic ausführen, um die statischen Dateien Ihres Projekts zusammenzustellen und sie in das Remote-Object-Storage-Backend hochzuladen:

Wir haben jedoch die env-Datei noch nicht mit Konfigurationen eingerichtet, daher wird es wahrscheinlich fehlschlagen.

Wenn Sie den Befehl ausführen, dauert es je nach Größe und Ihrer Internetgeschwindigkeit einen Moment, um Ihre Assets in den MinIO Cloud Storage zu kopieren.

Das ist alles für diesen Schritt. Sehen wir uns an, wie wir das Senden von Django-Protokollen an die Docker-Engine handhaben können, damit Sie sie im nächsten Schritt mit dem Befehl docker logs anzeigen können.

Schritt 6: Einrichten der Protokollierung in einer Django-App

Im Debug-Modus, wenn die Option DEBUG auf True gesetzt ist, protokolliert Django Informationen in der Standardausgabe und im Standardfehler. Die Protokollinformationen werden normalerweise in dem Terminal angezeigt, von dem aus Sie den Entwicklungs-HTTP-Server gestartet haben.

In der Produktionsumgebung verwenden Sie wahrscheinlich einen anderen HTTP-Server, und die Option DEBUG ist auf False gesetzt. Django verwendet in diesem Fall eine andere Protokollierungsmethode. Django sendet Protokolle mit der Priorität ERROR oder CRITICAL an ein von Ihnen definiertes administratives E-Mail-Konto. Dies funktioniert in vielen Situationen hervorragend.

In containerisierten und Kubernetes-Setups wird die Protokollierung in der Standardausgabe und im Standardfehler dringend empfohlen. Protokollmeldungen werden in einem einzigen Verzeichnis im Dateisystem des Nodes gesammelt und sind über die Befehle kubectl und docker leicht zugänglich. Mit einer zentralen Protokollierungsstelle im Dateisystem des Nodes kann das Betriebsteam problemlos Prozesse auf jedem Node ausführen, um Protokolle zu überwachen und weiterzuleiten. Daher müssen wir unsere Anwendung so konfigurieren, dass sie Protokolle in dieses Standard-Setup schreibt.

Sie werden sich freuen zu hören, dass Django das hochgradig anpassbare Modul logging aus der Python-Standardbibliothek nutzt. Dies ermöglicht es Ihnen, ein Dictionary zu definieren, das an logging.config.dictConfig übergeben wird, um die gewünschten Ausgaben und Formatierungen zu definieren. Hier ist ein schöner Artikel über Django Logging, The Right Way, der Ihnen helfen kann, Techniken zur Django-Protokollierung zu meistern.

Öffnen Sie die Datei django-polls/mysite/settings.py  in Ihrem Editor. Fügen Sie oben in der Datei einen Import für die Python-Bibliothek logging.config hinzu:

Bisher sollte Ihr Import-Bereich in settings.py mit allen hinzugefügten Importen so aussehen:

Die Bibliothek logging.config nimmt ein Dictionary mit einer neuen Protokollierungskonfiguration über die Funktion dictConfig entgegen, um das Standard-Protokollierungsverhalten von Django zu überschreiben.

Scrollen Sie ans Ende der Datei und fügen Sie das folgende Code-Snippet für die Protokollierungskonfiguration hinzu:

LOGGING_CONFIG ist auf None gesetzt, um die von Django definierten Standard-Logging-Konfigurationen zu deaktivieren/zu löschen. LOGLEVEL wird durch die Umgebungsvariable DJANGO_LOGLEVEL gesetzt. Wenn diese jedoch nicht existiert, möchten wir, dass sie auf „ info’.

Das logging.config-Modul, das wir oben importiert haben, stellt eine Funktion dictConfig bereit, die zum Festlegen eines neuen Konfigurations-Dictionarys verwendet wird. Das Dictionary definiert die Textformatierung über den Schlüssel formatters. Die Ausgabe wird mit dem Schlüssel handlers festgelegt, und schließlich definiert der Schlüssel loggers, welche Nachricht an welchen Handler gesendet werden soll.

Sobald Sie diese Einstellungen definiert haben, Docker stellt die Logs über den Befehl docker logs bereit. Ähnlich verhält es sich in einem anderen Tutorial, das wir für Kubernetes erstellen werden: Dort können Sie die Logs mit dem Befehl kubectl logs anzeigen. Beginnen wir nun im nächsten Schritt mit dem Containerisierungsprozess.

Schritt 7: Definieren des Anwendungs-Dockerfiles

In diesem Schritt definieren wir die Konfiguration zum Starten des Container-Images, auf dem die Django-App ausgeführt wird, die vom Gunicorn-WSGI-Server bereitgestellt wird. Wir definieren die Laufzeitumgebung für die Erstellung eines Container-Images, installieren die Anwendung und ihre Abhängigkeiten und nehmen einige abschließende Konfigurationen vor.

• Das Parent-Image für eine Django-App

Die Entscheidung für das Basis-Image, auf dem Ihr Container aufbauen soll, ist die allererste Entscheidung, die Sie bei containerisierten Deployments treffen müssen. Natürlich haben Sie die Möglichkeit, Ihre Container-Images von SCRATCH (d. h. einem leeren Dateisystem) aufzubauen oder sie auf einem vorhandenen Container-Image basieren zu lassen. Da wir das Rad nicht neu erfinden wollen, werden wir unser Image auf einem Basis-Image aufbauen. Es gibt viele Open-Source-Container-Images, die im offiziellen Container-Image-Repository von Docker verfügbar sind. Sofern Sie Ihr Image nicht von Grund auf neu erstellen, wird dringend empfohlen, ein Image aus dem offiziellen Hub von Docker zu verwenden. Das liegt daran, dass Docker überprüft, ob die Images den Best Practices entsprechen, und sicherstellt, dass regelmäßige Updates und Sicherheitspatches bereitgestellt werden.

Da Django ein Python-Framework ist, nutzen wir ein Image mit einer Standard-Python-Umgebung, in der die benötigten Tools und Bibliotheken bereits vorinstalliert sind. Auf der offiziellen Seite für Python-Images auf Docker Hub finden Sie ein Python-basiertes Image für verschiedene Python-Versionen.

In unseren verschiedenen Docker-basierten Tutorials werden Sie feststellen, dass wir Images verwenden, die auf Alpine Linux basieren. Alpine Linux bietet eine robuste, aber schlanke Betriebssystemumgebung für die Ausführung von containerisierten Anwendungen. Obwohl das Dateisystem klein ist, ist es erweiterbar und verfügt über ein vollständiges Paketverwaltungssystem mit der Möglichkeit, Funktionen hinzuzufügen.

Bei der Auswahl eines Basis-Images auf dem Docker Hub werden Sie feststellen, dass für jedes Image mehrere Tags verfügbar sind. Für Python haben wir 3-alpine, was auf das neueste Python 3-Image der neuesten Alpine-Version verweist. Das bedeutet: Falls Ihr Projekt mit einer älteren Image-Version arbeitet, kann es zu Fehlern kommen, wenn die Maintainer des Docker-Images ein Update durchführen. Um solche Szenarien in Zukunft zu vermeiden, wird immer empfohlen, die spezifischsten Tags für das Image zu wählen, das Sie verwenden möchten.

In diesem Tutorial verwenden wir das 3.8.12-alpine3.15 -Image als Basis-Image für unsere Django-Anwendung. Dieses spezifische Tag wird in der Dockerfile unter Verwendung der FROM-Anweisung angegeben. Das Dockerfile befindet sich im Hauptprojektverzeichnis: django_project.

Navigieren Sie zunächst aus dem Verzeichnis Django-polls zurück in das Verzeichnis django_project:

Sobald Sie sich im Verzeichnis befinden, öffnen Sie mit Ihrem bevorzugten Editor eine Datei namens Dockerfile :

Fügen Sie als Nächstes die folgende Zeile ein, um die Basis Ihres Images festzulegen:

Das FROM -Schlüsselwort definiert den Ausgangspunkt eines benutzerdefinierten Docker-Images. Sobald dies definiert ist, können wir weitere Anweisungen zum Einrichten der Anwendungen hinzufügen. Diese Anweisungen installieren die erforderlichen Abhängigkeiten, kopieren die Anwendungsdateien und richten die Laufzeitumgebung ein.

Fügen Sie das folgende Code-Snippet in das Dockerfile ein:

In diesem Code-Snippet weisen wir Docker an, die Datei requirements.txt  nach /app/requirements.txt zu kopieren, um sicherzustellen, dass die Abhängigkeiten der Anwendung im Dateisystem des Images verfügbar sind. Die Anforderungen umfassen alle Python-Pakete, die zur Ausführung der Anwendung erforderlich sind. Die Abhängigkeiten werden zuerst kopiert, damit Docker die Image-Ebene zwischenspeichern kann. Das liegt daran, dass Docker jeden Schritt im Dockerfile zwischenspeichert. Der erste Build des Images dauert in der Regel länger. Docker lädt die Abhängigkeiten herunter und speichert sie dann im Cache. Wenn sich die Datei requirements.txt nicht ändert, baut Docker aus dem Cache auf, was nachfolgende Builds beschleunigt.

Der nächste Schritt enthält die Anweisung RUN, die eine Liste von Linux-Befehlen ausführt, die mit dem Linux-Operator && verkettet sind. Die Befehle bewirken Folgendes:

• Verwenden Sie das Paketverwaltungstool apk von Alpine, um PostgreSQL-Entwicklungsdateien und grundlegende Build-Abhängigkeiten zu installieren.

• Erstellen Sie eine virtuelle Python-Umgebung.

• Installieren Sie die Python-Abhängigkeiten wie in der Datei requirements.txt definiert unter Verwendung von pip.

• Kompilieren Sie die erforderlichen Laufzeitpakete, indem Sie die Anforderungen der installierten Python-Pakete analysieren.

• Entfernen Sie alle Build-Abhängigkeiten, die nicht mehr benötigt werden.

Der Grund für die Verkettung der Befehle im Schritt RUN besteht darin, die Image-Ebenen zu reduzieren. Docker erstellt jedes Mal eine neue Image-Ebene auf dem vorhandenen Dateisystem, wenn es auf ADD, COPY oder RUN-Anweisung im Dockerfile. Das Komprimieren von Befehlen, wo anwendbar, minimiert die Anzahl der erstellten Image-Layer.

Elemente, die zu Image-Layern hinzugefügt wurden, können in einem nachfolgenden Layer nicht mehr entfernt werden. Sie müssen Anweisungen zum Löschen unerwünschter Elemente deklarieren, bevor Sie zur nächsten Anweisung übergehen. Dies ist notwendig, um die Image-Größe zu reduzieren. Sie sollten bemerken, dass wir den apk del-Befehl am Ende der RUN-Anweisung hinzugefügt haben. Dies wurde getan, um die Build-Abhängigkeiten zu entfernen, nachdem wir sie zum Erstellen der Pakete der App verwendet hatten.

Als Nächstes haben wir eine weitere ADD-Anweisung, mit der wir den Anwendungscode in das Verzeichnis /app kopieren. Danach verwenden wir die WORKDIR-Anweisung, um das Arbeitsverzeichnis des Images auf das Verzeichnis /app -Verzeichnis festlegen, welches nun den Code der Anwendung enthält.

Als Nächstes haben wir die ENV-Anweisungen, mit denen wir zwei Umgebungsvariablen festlegen, die das Image den laufenden Containern zur Verfügung stellt. Zuerst setzen wir die Variable VIRTUAL_ENV auf /env. Zweitens setzen wir die Variable PATH so, dass sie das Verzeichnis /env/bin enthält. In diesen beiden Zeilen binden wir das Skript /env/bin/activate ein, womit wir eine virtuelle Umgebung in einer Linux-Umgebung aktivieren. Sie können mehr über die Arbeit mit virtuellen Umgebungen in Python auf anderen Betriebssystemen lesen. Die letzte Anweisung ist der EXPOSE-Befehl, der den Port festlegt, 8000 auf dem der Container zur Laufzeit lauschen wird.

Mittlerweile ist Ihr Dockerfile fast vollständig, abgesehen von dem Standardbefehl, der beim Starten der Container ausgeführt wird. Lassen Sie uns diesen im nächsten Abschnitt definieren.

• Den Standardbefehl des Docker-Images verstehen

Beim Starten eines Docker-Containers können Sie einen auszuführenden Befehl angeben. Wenn Sie jedoch keinen Befehl angeben, bestimmt der Standardbefehl des Docker-Images, was beim Starten des Containers passiert. Wir verwenden die Anweisungen ENTRYPOINT oder CMD einzeln oder zusammen, um einen Standardbefehl im Dockerfile zu definieren.

Wenn Sie sich dafür entscheiden, sowohl ENTRYPOINT als auch CMD, legen Sie in der ENTRYPOINT-Anweisung die ausführbare Datei fest, die vom Container ausgeführt wird. In der CMD-Anweisung definieren Sie die Standardargumentliste für den ausführbaren Befehl. Sie können die Standardargumentliste überschreiben, indem Sie beim Starten des Containers alternative Argumente in der Befehlszeile im folgenden Format anhängen:

Dieses Format verhindert, dass Entwickler den ENTRYPOINT-Befehl leicht überschreiben können. Der ENTRYPOINT-Befehl ist so definiert, dass er ein Skript aufruft, das die Umgebung einrichtet und basierend auf der bereitgestellten Argumentliste verschiedene Aktionen ausführt.

Sie können die ENTRYPOINT-Anweisung allein verwenden, um die ausführbare Datei des Containers zu konfigurieren. Dieses Format erlaubt jedoch nicht die Definition einer Standardargumentliste. Sie können Argumente angeben, wenn Sie den Container mit dem Befehl docker run ausführen.

Wenn Sie sich dafür entscheiden, nur CMD zu verwenden, interpretiert Docker dies als Standardbefehl und Standardargumentliste, die Sie zur Laufzeit überschreiben können. Weitere Informationen finden Sie in den offiziellen Dockerfile-Referenzdokumenten.

Sehen wir uns an, wie wir die gelernten Informationen über Standardbefehle auf unser Container-Beispiel anwenden können. Wir möchten die Anwendung standardmäßig mit dem gunicorn-Server bereitstellen. Obwohl die an den gunicorn-Server übergebene Argumentliste zur Laufzeit nicht konfigurierbar sein muss, möchten wir die Flexibilität haben, andere Befehle für Zwecke wie das Debugging oder die Verwaltung von Konfigurationen (Initialisieren der Datenbank, Sammeln statischer Assets usw.) auszuführen. Wie Sie sehen, liegt es in unserem besten Interesse, CMD zu verwenden, um einen Standardbefehl zu definieren, der es uns ermöglicht, ihn bei Bedarf zu überschreiben.

Hier sind einige Syntaxen, die Sie verwenden können, um den Befehl CMD zu definieren:

• CMD ["command", "argument 1", "argument 2", . . . ,"argument n"]: Das exec-Format (empfohlenes Format) nimmt einen Befehl und eine Liste von Argumenten entgegen. Es führt den Befehl direkt ohne Shell-Verarbeitung aus.
• CMD command "argument 1" "argument 2" . . . "Argument n": Das Shell-Format definiert einen Befehl und eine Liste von Argumenten. Es übergibt die Liste der Befehle zur Verarbeitung an die Shell. Dies kann nützlich sein, wenn Sie Umgebungsvariablen in einem Befehl ersetzen möchten, ist jedoch nicht völlig vorhersehbar.
• CMD ["Argument 1", "Argument 2", . . . ,"Argument n"]: Das Argumentlistenformat definiert nur die Standard-Argumentliste und wird zusammen mit einer ENTRYPOINT -Anweisung.

Wir werden das exec-Format verwenden, um unsere endgültige Anweisung im Dockerfile zu definieren. Fügen Sie die folgende Zeile am Ende Ihres Dockerfile:

Sie können das Dockerfile jetzt speichern und schließen..

Wenn Sie Container mit diesem Image starten, führen diese gunicorn aus, gebunden an den Localhost-Port 8000 mit 3 Workern, und rufen die application-Funktion in der wsgi.py-Datei im mysite -Verzeichnis auf. Sie können einen anderen Befehl angeben, um den Standardbefehl zur Laufzeit zu überschreiben und stattdessen einen anderen Prozess als Gunicorn auszuführen. Vielleicht möchten Sie mehr erfahren über Gunicorn-Worker.

Ihr Dockerfile ist nun bereit und Sie können docker build verwenden, um das App-Image zu erstellen. Sie können docker run verwenden, um den Container auf Ihrem lokalen Entwicklungsrechner zu starten.

• Erstellen des Docker-Images

Der Befehl docker build sucht standardmäßig nach einem Dockerfile im aktuellen Verzeichnis, um seine Bauanweisungen zu finden. Er sendet auch den Build-„Kontext“ an den Docker-Daemon. Ein Build-Kontext ist eine Reihe von Dateien, die während des Build-Prozesses verfügbar sein sollten. Standardmäßig ist das aktuelle Verzeichnis, in dem Sie den Befehl docker build ausführen, als Build-Kontext festgelegt.

Führen Sie in demselben Verzeichnis, das Ihr Dockerfile enthält, den folgenden Befehl aus: docker build. Geben Sie ein Image und ein Tag mit dem Flag -t an und legen Sie das aktuelle Verzeichnis als Build-Kontext fest, indem Sie den Punkt ( .) am Ende des Befehls verwenden:

In diesem Befehl haben wir das Image django-polls und das Tag v1. Beachten Sie den Punkt am Ende des Befehls, mit dem wir das aktuelle Verzeichnis als Build-Kontext angeben.

Wenn der Befehl docker build abgeschlossen ist, sollten Sie eine Ausgabe ähnlich der folgenden sehen:

Ihr Docker-Image ist nun bereit. Wenn wir nicht einige der Konfigurationen in externe Umgebungsvariablen ausgelagert hätten, könnten Sie Ihren Container ganz einfach mit dem Befehl docker run ausführen. Da wir jedoch die externen Umgebungsvariablen, die wir in der Datei settings.py eingerichtet haben, nicht konfiguriert haben, wird der Start fehlschlagen. Lassen Sie uns das im nächsten Schritt abschließen.

Schritt 8: Einrichten der Laufzeitumgebung und Testen der App

Wir nähern uns dem Ende dieses Tutorials. In diesem Schritt werden wir die Umgebungsvariablen in der Datei env konfigurieren. Mit den Variablen der Datei env können wir das Datenbankschema erstellen, die statischen Dateien generieren und in den externen Objektspeicherdienst hochladen und schließlich die App testen.

Docker bietet verschiedene Methoden, mit denen Sie dem Container Umgebungsvariablen bereitstellen können. In unserem Fall möchten wir eine Liste von Umgebungsvariablen über eine Datei bereitstellen. Daher verwenden wir die Methode --env-file-Methode.

Erstellen Sie mit Ihrem bevorzugten Editor eine Datei namens env im Verzeichnis django_project:

Fügen Sie die folgende Liste von Variablen ein:

Die Variablen in der Liste sind diejenigen, die du in den vorherigen Schritten definiert hast:

• DJANGO_SECRET_KEY: Generiere einen eindeutigen, unvorhersehbaren Wert, wie in den Django-Docs erklärt. Du kannst diesen Befehl verwenden, um eine zufällige Zeichenfolge zu generieren und sie der Variablen zuzuweisen:

• DEBUG: Wir haben diesen Wert auf True, aber für ein Produktions-Deployment denke daran, ihn auf False zu setzen, indem du ihn leer lässt.

• DJANGO_LOGLEVEL: Wir haben dies auf info, du kannst es gerne an deine Bedürfnisse anpassen.

• DJANGO_ALLOWED_HOSTS: Setze diesen Wert auf die IP-Adresse des Ubuntu-Servers, auf dem deine Docker-Container laufen. Optional kannst du ihn auf * setzen, eine Wildcard, die im Entwicklungsmodus mit allen Hosts übereinstimmt.

• DB_DATABASE: Wenn du einen anderen Datenbanknamen verwendet hast, trage ihn hier entsprechend ein.

• DB_USERNAME: Setze dies auf den Benutzernamen, den du für deine Datenbank gewählt hast.

• DB_PASSWORD: Setze dies auf das Passwort, das du für deine Datenbank gewählt hast.

• DB_HOST: Setze dies auf den Host, auf dem deine Datenbankinstanz läuft, wie du es in Schritt Eins.

• eingerichtet hast.: Setze dies auf den Port deiner Datenbank.

• STATIC_MINIO_BUCKET_NAME: Setze dies auf den Bucket-Namen, den du in deinem MinIO Cloud Storage-Konto erstellt hast.

Speichere und schließe die Datei, wenn du mit der Bearbeitung fertig bist.

Die Umgebungskonfigurationen sind nun bereit. Wir müssen den Container ausführen und Argumente übergeben, um den Standard-CMD-Befehl zu überschreiben und das Datenbankschema mit den Befehlen manage.py makemigrations und manage.py migrate zu erstellen.

Hier ist der Befehl:

In diesem Befehl führen wir das Container-Image django-polls:v1 aus und verwenden das Flag –env-file, um die Umgebungsvariablendatei zu übergeben. Wir überschreiben auch den Standard-CMD-Befehl mit sh -c "python manage.py makemigrations && python manage.py migrate" Wenn dieser Befehl ausgeführt wird, um den Container zu starten, erstellt er das Datenbankschema wie im Anwendungscode definiert.

Wenn dies erfolgreich war, solltest du eine Ausgabe ähnlich der folgenden sehen:

Die Ausgabe zeigt an, dass das Datenbankschema erfolgreich erstellt wurde.

Der nächste Schritt besteht darin, einen administrativen Benutzer für die Django-App zu erstellen. Wir werden den Container starten und eine interaktive Shell darin mit dem folgenden Befehl öffnen:

Der Befehl startet den Container mit einer Shell-Eingabeaufforderung, über die du mit der Python-Shell interagieren kannst. Lass uns einen Benutzer erstellen:

Folge den Anweisungen, um einen Benutzernamen, eine E-Mail-Adresse und ein Passwort einzugeben, bestätige das Passwort und drücke die Eingabetaste, um den Benutzer zu erstellen. Verlasse die Shell und beende den Container, indem du STRG+D.

Als Nächstes müssen wir den Container erneut ausführen und den Standardbefehl mit dem Django-Befehl collectstatic überschreiben, um die statischen Dateien für die App zu generieren und sie in deinen MinIO Cloud Storage-Dienst hochzuladen:

Wenn der Vorgang abgeschlossen ist, solltest du eine ähnliche Ausgabe wie unten sehen, die anzeigt, dass sich dein Container erfolgreich mit dem MinIO-Speicherdienst verbunden und die statischen Dateien hochgeladen hat:

Unser Storage-Bucket sieht nun so aus, mit den von Django erstellten Verzeichnissen:

Schließlich können wir die App nun mit folgendem Befehl ausführen:

Hier ist die Ausgabe:

Wenn Sie den obigen Befehl ausführen, wird der Standard-CMD-Befehl in Ihrem Image ausgeführt und der Port freigegeben 8000 wie definiert. Jetzt wird Ubuntu auf Port 80 auf den Port 8000 des django-polls:v1 Containers abgebildet.

Wir können die Anwendung nun im Browser testen. Rufen Sie die öffentliche IP-Adresse Ihres Servers im Browser auf: http://your_server_public_ip.

Es ist ein 404 Page Not Found Fehler zu erwarten, da wir gemäß dem Django-Tutorial keine Route für den Pfad / definiert haben:

Wir haben die Variable DEBUG auf True gesetzt, weshalb wir diese Fehlerseite mit vielen wichtigen Informationen sehen. Lassen Sie uns die Variable DEBUG deaktivieren. Zuerst müssen Sie den laufenden Container mit STRG+C stoppen. Öffnen Sie dann die Datei env:

Suchen Sie als Nächstes die Variable DEBUG und entfernen Sie deren Wert oder lassen Sie sie leer. Wir lassen sie leer, da die Funktion getenv den Wert False als String interpretiert und somit true zurückgibt:

Speichern Sie die Datei und führen Sie den Container erneut mit dem Befehl aus:

Wenn Sie diese Adresse http://your_server_public_ip in Ihrem Browser aufrufen, sollten Sie die Standard-404-Seite sehen:

Sie haben gesehen, wie Sie das Laufzeitverhalten Ihrer Django-App mithilfe von Umgebungsvariablen manipulieren können, ohne den Quellcode zu ändern.

Navigieren Sie zu http://your_server_public_ip/polls, um die Polls-Startseite zu sehen:

Wir haben noch keine Umfragen, da wir die App gerade erst bereitgestellt haben.

Navigieren Sie zur Admin-Oberfläche: http://your_server_public_ip/admin, um das Admin-Anmeldefenster anzuzeigen:

Geben Sie die Anmeldedaten ein, die Sie mit dem Befehl createsuperuser festgelegt haben, um sich anzumelden. Sie sollten sich nun auf der Administrationsseite befinden:

Beachten Sie, dass alle statischen Dateien von dem externen Speicherdienst bereitgestellt werden, den wir eingerichtet haben. Sie können einen Rechtsklick in Ihrem Browserfenster ausführen und Seitenquelltext anzeigen:

Sie können einige Fragen und Auswahlmöglichkeiten hinzufügen und die Gesamtleistung der App testen:

Gehen Sie zurück zum Polls-Index http://your_server_public_ip/polls und versuchen Sie, bei der Frage abzustimmen:

Nachdem Sie alles getestet und bestätigt haben, dass alles wie erwartet funktioniert, können Sie den Container beenden.

Fazit

Sie haben erfolgreich eine Django-Web-App für die Verwendung in einer containerbasierten Umgebung konfiguriert. Dies umfasste die Anpassung der App an externe Umgebungsvariablen, die Konfiguration der App zur Nutzung eines Cloud-Speicherdienstes für statische Dateien und das Erstellen eines Dockerfiles für das Container-Image. Sie können die Änderungen, die wir vorgenommen haben, um die App zu dockerisieren, im django-polls-docker-Branch des GitHub-Repositorys django-polls einsehen.

Von hier aus sind den Möglichkeiten nur durch Ihre Vorstellungskraft Grenzen gesetzt. Sie können einen Nginx-Reverse-Proxy einrichten, der zwischen den Clients und dem Gunicorn-Server steht. Sie können auch Certbot hinzufügen, um TLS-Zertifikate zur Absicherung Ihres Nginx-Servers zu erhalten. Wir empfehlen, einen HTTP-Proxy hinzuzufügen, um langsame Clients zu puffern und Ihren Gunicorn-Server vor Denial-of-Service-Angriffen zu schützen.

Obwohl wir im Startbefehl des Dockerfiles 3 Worker definiert haben, können Sie Ihre bevorzugte Anzahl je nach den auf Ihrem Server verfügbaren Ressourcen festlegen. Weitere Informationen finden Sie in den offiziellen Gunicorn-Design-Dokumenten. Wenn Sie möchten, können Sie das von Ihnen erstellte Docker-Image auf Docker Hub hochladen und versuchen, es in verschiedenen Umgebungen bereitzustellen, auf denen Docker installiert ist. Wenn Sie mehr erfahren möchten, besuchen Sie regelmäßig unseren Tutorial-Blog, da wir ein Folge-Tutorial veröffentlichen werden, um die Django-App mit Nginx und Let’s Encrypt abzusichern.

Schließlich finden Sie hier weitere Ressourcen, die Ihnen bei der Nutzung von Docker helfen:

• So hosten Sie ein Docker-Image-Repository und erstellen Docker-Images mit einer selbstverwalteten GitLab-Instanz auf Ubuntu 20.04
• Arbeiten mit Docker-Daten-Volumes auf Ubuntu 20.04
• Erstellen und Bereitstellen einer Flask-Anwendung mit Docker auf Ubuntu 20.04
• So stellen Sie WordPress mit Docker-Containern auf Ubuntu 20.04

Viel Spaß beim Computing!