Django in Cloud Run

1. Einführung

Cloud Run ist eine verwaltete Rechenplattform, mit der Sie zustandslose Container ausführen können, die über HTTP-Anfragen abrufbar sind. Cloud Run arbeitet serverlos und benötigt keine Infrastrukturverwaltung. So können Sie sich ganz auf das Programmieren von Anwendungen konzentrieren.

Außerdem ist es nativ mit vielen anderen Teilen des Google Cloud-Ökosystems verbunden, darunter Cloud SQL für verwaltete Datenbanken, Cloud Storage für einheitlichen Objektspeicher und Secret Manager für die Verwaltung von Geheimnissen.

Django ist ein allgemeines Python-Web-Framework.

In dieser Anleitung verwenden Sie diese Komponenten, um ein kleines Django-Projekt bereitzustellen.

Hinweis: Dieses Codelab wurde zuletzt mit Django 5.0 geprüft. Sofern es keine gravierenden Änderungen bei zukünftigen Updates gibt, sollte dieses Codelab weiterhin funktionieren. Lesen Sie die zukünftigen Django-Versionshinweisen.

Aufgaben in diesem Lab

• Cloud Shell verwenden
• Cloud SQL-Datenbank erstellen
• Cloud Storage-Bucket erstellen
• Secret Manager-Secrets erstellen
• Secrets aus verschiedenen Google Cloud-Diensten verwenden
• Google Cloud-Komponenten mit einem Cloud Run-Dienst verbinden
• Erstellte Container mit Container Registry speichern
• In Cloud Run bereitstellen
• Datenbankschemamigrationen in Cloud Build ausführen

2. Einrichtung und Anforderungen

Einrichtung der Umgebung im eigenen Tempo

1. Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie ein Konto erstellen.

• Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es ist ein Zeichenstring, der von Google APIs nicht verwendet wird. Sie können ihn jederzeit aktualisieren.
• Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und kann nach der Festlegung nicht mehr geändert werden. In der Cloud Console wird automatisch ein eindeutiger String generiert. In der Regel spielt es keine Rolle, wie er lautet. In den meisten Codelabs müssen Sie auf Ihre Projekt-ID verweisen (normalerweise als PROJECT_ID gekennzeichnet). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige generieren. Alternativ können Sie Ihr eigenes Konto ausprobieren und prüfen, ob es verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts bestehen.
• Zur Information: Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu diesen drei Werten finden Sie in der Dokumentation.

Achtung:Eine Projekt-ID ist global eindeutig und kann nach der Auswahl nicht mehr von anderen verwendet werden. Sie sind der einzige Nutzer dieser ID. Auch wenn ein Projekt gelöscht wird, kann die ID nicht wiederverwendet werden.

Hinweis:Wenn Sie ein Gmail-Konto verwenden, können Sie den Standardspeicherort auf Keine Organisation belassen. Wenn Sie ein Google Workspace-Konto verwenden, wählen Sie einen Standort aus, der für Ihre Organisation sinnvoll ist.

2. Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs verwenden zu können. Die Durchführung dieses Codelabs ist kostenlos oder kostet nur sehr wenig. Wenn Sie die Ressourcen deaktivieren möchten, um Kosten nach Abschluss dieser Anleitung zu vermeiden, können Sie die von Ihnen erstellten Ressourcen oder das Projekt löschen. Neuen Google Cloud-Nutzern steht das kostenlose Testprogramm mit einem Guthaben von 300$ zur Verfügung.

Google Cloud Shell

Sie können Google Cloud zwar per Fernzugriff von Ihrem Laptop aus nutzen, in diesem Codelab verwenden wir jedoch Google Cloud Shell, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Cloud Shell aktivieren

1. Klicken Sie in der Cloud Console auf Cloud Shell aktivieren .

Wenn Sie Cloud Shell zum ersten Mal starten, wird ein Zwischenbildschirm mit einer Beschreibung angezeigt. Klicken Sie in diesem Fall auf Weiter.

Die Bereitstellung und Verbindung mit Cloud Shell sollte nur wenige Minuten dauern.

Auf dieser virtuellen Maschine sind alle erforderlichen Entwicklungstools installiert. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft in Google Cloud, was die Netzwerkleistung und Authentifizierung erheblich verbessert. Die meisten, wenn nicht alle Aufgaben in diesem Codelab können mit einem Browser erledigt werden.

Sobald Sie mit Cloud Shell verbunden sind, sollten Sie sehen, dass Sie authentifiziert sind und das Projekt auf Ihre Projekt-ID festgelegt ist.

2. Führen Sie in Cloud Shell den folgenden Befehl aus, um zu prüfen, ob Sie authentifiziert sind:

gcloud auth list

Befehlsausgabe

 Credentialed Accounts
ACTIVE  ACCOUNT
*       <my_account>@<my_domain.com>

To set the active account, run:
    $ gcloud config set account `ACCOUNT`

Hinweis:Das gcloud-Befehlszeilentool ist das leistungsstarke und einheitliche Befehlszeilentool in Google Cloud. Es ist in Cloud Shell vorinstalliert. Sie werden feststellen, dass es die Tab-Vervollständigung unterstützt. Wenn Sie zum ersten Mal einen Befehl ausführen, werden Sie möglicherweise aufgefordert, sich zu authentifizieren. Weitere Informationen finden Sie in der Übersicht über das gcloud-Befehlszeilentool.

3. Führen Sie in Cloud Shell den folgenden Befehl aus, um zu prüfen, ob der gcloud-Befehl Ihr Projekt kennt:

gcloud config list project

Befehlsausgabe

[core]
project = <PROJECT_ID>

Ist dies nicht der Fall, können Sie die Einstellung mit diesem Befehl vornehmen:

gcloud config set project <PROJECT_ID>

Befehlsausgabe

Updated property [core/project].

Hinweis:Wenn Sie diese Anleitung nicht in Cloud Shell ausführen, folgen Sie der Anleitung unter Standardanmeldedaten für Anwendungen einrichten.

3. Cloud APIs aktivieren

Aktivieren Sie in Cloud Shell die Cloud APIs für die zu verwendenden Komponenten:

gcloud services enable \
  run.googleapis.com \
  sql-component.googleapis.com \
  sqladmin.googleapis.com \
  compute.googleapis.com \
  cloudbuild.googleapis.com \
  secretmanager.googleapis.com \
  artifactregistry.googleapis.com

Da Sie zum ersten Mal APIs über gcloud aufrufen, werden Sie aufgefordert, die Verwendung Ihrer Anmeldedaten für diese Anfrage zu autorisieren. Dies geschieht einmal pro Cloud Shell-Sitzung.

Dieser Vorgang kann einige Minuten dauern.

Nach Abschluss sollte eine Erfolgsmeldung wie die folgende angezeigt werden:

Operation "operations/acf.cc11852d-40af-47ad-9d59-477a12847c9e" finished successfully.

4. Vorlagenprojekt erstellen

Sie verwenden die Standard-Django-Projektvorlage als Beispiel-Django-Projekt.

Erstellen Sie mit Cloud Shell ein neues Verzeichnis mit dem Namen django-cloudrun und rufen Sie es auf:

mkdir ~/django-cloudrun
cd ~/django-cloudrun

Installieren Sie dann Django in einer temporären virtuellen Umgebung:

virtualenv venv
source venv/bin/activate
pip install Django

Liste der auf requirements.txt installierten Pakete speichern

pip freeze > requirements.txt

Diese Liste sollte Django und seine Abhängigkeiten enthalten: sqlparse und asgiref.

Erstellen Sie dann ein neues Vorlagenprojekt:

django-admin startproject myproject .

Sie erhalten eine neue Datei namens manage.py und einen neuen Ordner namens myproject, der mehrere Dateien enthält, darunter eine settings.py.

Prüfen Sie, ob der Inhalt des übergeordneten Ordners wie erwartet aussieht:

ls -F

manage.py myproject/ requirements.txt venv/

Prüfen Sie, ob der Inhalt des Ordners myproject wie erwartet ist:

ls -F myproject/

__init__.py asgi.py settings.py  urls.py  wsgi.py

Sie können die temporäre virtuelle Umgebung jetzt beenden und entfernen:

deactivate
rm -rf venv

Von hier aus wird Django innerhalb des Containers aufgerufen.

5. Sicherungsdienste erstellen

Jetzt erstellen Sie die zugrunde liegenden Dienste: ein spezielles Dienstkonto, eine Artifact Registry, eine Cloud SQL-Datenbank, einen Cloud Storage-Bucket und eine Reihe von Secret Manager-Werten.

Die Sicherung der Werte der bei der Bereitstellung verwendeten Passwörter ist für die Sicherheit jedes Projekts wichtig und sorgt dafür, dass niemand versehentlich Passwörter an eine falsche Stelle setzt, z. B. direkt in die Konfigurationsdateien oder direkt in das Terminal, wo sie aus dem Verlauf abgerufen werden können.

Legen Sie zuerst zwei grundlegende Umgebungsvariablen fest, eine für die Projekt-ID:

PROJECT_ID=$(gcloud config get-value core/project)

Und eine für die Region:

REGION=us-central1

Bei der Arbeit mit der Infrastruktur ist es sinnvoll, alle Komponenten am selben Ort zu platzieren, damit sie effizienter miteinander kommunizieren können. Einige Komponenten sind zwar weltweit verfügbar, aber nicht alle Komponenten in allen Regionen.

Für dieses Codelab empfehlen wir us-central1, europe-north1 oder asia-northeast1 oder eine beliebige Region, in der Cloud Run (vollständig verwaltet) unterstützt wird.

Weitere Informationen:

• Cloud Run-Standorte (vollständig verwaltet)
• Cloud SQL-Standorte
• Cloud Storage-Standorte

Dienstkonto erstellen

Wenn Sie den Zugriff des Dienstes auf andere Teile von Google Cloud einschränken möchten, erstellen Sie ein spezielles Dienstkonto:

gcloud iam service-accounts create cloudrun-serviceaccount

In den folgenden Abschnitten dieses Codelabs beziehen Sie sich auf dieses Konto anhand seiner E-Mail-Adresse. Legen Sie diesen Wert in einer Umgebungsvariablen fest:

SERVICE_ACCOUNT=$(gcloud iam service-accounts list \
    --filter cloudrun-serviceaccount --format "value(email)")

Artifact Registry erstellen

Erstellen Sie zum Speichern des erstellten Container-Images eine Container Registry in der ausgewählten Region:

gcloud artifacts repositories create containers --repository-format docker --location $REGION

In den folgenden Abschnitten dieses Codelabs werden Sie auf diese Registry namentlich verweisen:

ARTIFACT_REGISTRY=${REGION}-docker.pkg.dev/${PROJECT_ID}/containers

Datenbank erstellen

Erstellen Sie eine Cloud SQL-Instanz:

gcloud sql instances create myinstance --project $PROJECT_ID \
  --database-version POSTGRES_14 --tier db-f1-micro --region $REGION

Dieser Vorgang kann einige Minuten dauern.

Erstellen Sie in dieser Instanz eine Datenbank:

gcloud sql databases create mydatabase --instance myinstance

Erstellen Sie in derselben Instanz einen Nutzer:

DJPASS="$(cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 30 | head -n 1)"
gcloud sql users create djuser --instance myinstance --password $DJPASS

Gewähren Sie dem Dienstkonto die Berechtigung, eine Verbindung zur Instanz herzustellen:

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:${SERVICE_ACCOUNT} \
    --role roles/cloudsql.client

Storage-Bucket erstellen

Erstellen Sie einen Cloud Storage-Bucket. Der Name muss global eindeutig sein:

GS_BUCKET_NAME=${PROJECT_ID}-media
gcloud storage buckets create gs://${GS_BUCKET_NAME} --location ${REGION} 

Gewähren Sie dem Dienstkonto Berechtigungen zum Verwalten des Buckets:

gcloud storage buckets add-iam-policy-binding gs://${GS_BUCKET_NAME} \
    --member serviceAccount:${SERVICE_ACCOUNT} \
    --role roles/storage.admin

Konfiguration als Secret speichern

Nachdem Sie die zugrunde liegenden Dienste eingerichtet haben, speichern Sie diese Werte jetzt in einer Datei, die mit Secret Manager geschützt ist.

Mit Secret Manager können Sie Secrets als binäre Blobs oder Textstrings speichern, verwalten und darauf zugreifen. Er eignet sich gut zum Speichern von Konfigurationsinformationen wie Datenbankpasswörtern, API-Schlüsseln oder TLS-Zertifikaten, die von einer Anwendung zur Laufzeit benötigt werden.

Erstelle zuerst eine Datei mit den Werten für den Datenbankverbindungsstring, den Medien-Bucket, einen geheimen Schlüssel für Django (wird für die kryptografische Signatur von Sitzungen und Tokens verwendet) und zum Aktivieren der Fehlerbehebung:

echo DATABASE_URL=\"postgres://djuser:${DJPASS}@//cloudsql/${PROJECT_ID}:${REGION}:myinstance/mydatabase\" > .env

echo GS_BUCKET_NAME=\"${GS_BUCKET_NAME}\" >> .env

echo SECRET_KEY=\"$(cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 50 | head -n 1)\" >> .env

echo DEBUG=True >> .env

Erstellen Sie dann ein Secret mit dem Namen application_settings und verwenden Sie diese Datei als Secret:

gcloud secrets create application_settings --data-file .env

Gewähren Sie dem Dienstkonto Zugriff auf dieses Secret:

gcloud secrets add-iam-policy-binding application_settings \
  --member serviceAccount:${SERVICE_ACCOUNT} --role roles/secretmanager.secretAccessor

Prüfen Sie, ob das Secret erstellt wurde, indem Sie die Secrets auflisten:

gcloud secrets versions list application_settings

Entfernen Sie die lokale Datei, nachdem Sie bestätigt haben, dass das Secret erstellt wurde:

rm .env

6. Anwendung konfigurieren

Aufgrund der von Ihnen gerade erstellten unterstützenden Dienste müssen Sie einige Änderungen am Vorlagenprojekt vornehmen.

Dazu gehört auch die Einführung von django-environ, um Umgebungsvariablen als Konfigurationseinstellungen zu verwenden, die Sie mit den Werten ausfüllen, die Sie als Secrets definiert haben. Dazu erweitern Sie die Vorlageneinstellungen. Außerdem müssen Sie zusätzliche Python-Abhängigkeiten hinzufügen.

Einstellungen konfigurieren

Datei settings.py verschieben und in basesettings.py: umbenennen

mv myproject/settings.py myproject/basesettings.py

Erstellen Sie mit dem Cloud Shell-Webeditor eine neue settings.py-Datei mit dem folgenden Code:

touch myproject/settings.py
cloudshell edit myproject/settings.py

myproject/settings.py

import io
import os
from urllib.parse import urlparse

import environ

# Import the original settings from each template
from .basesettings import *

# Load the settings from the environment variable
env = environ.Env()
env.read_env(io.StringIO(os.environ.get("APPLICATION_SETTINGS", None)))

# Setting this value from django-environ
SECRET_KEY = env("SECRET_KEY")

# Ensure myproject is added to the installed applications
if "myproject" not in INSTALLED_APPS:
    INSTALLED_APPS.append("myproject")

# If defined, add service URLs to Django security settings
CLOUDRUN_SERVICE_URLS = env("CLOUDRUN_SERVICE_URLS", default=None)
if CLOUDRUN_SERVICE_URLS:
    CSRF_TRUSTED_ORIGINS = env("CLOUDRUN_SERVICE_URLS").split(",")
    # Remove the scheme from URLs for ALLOWED_HOSTS
    ALLOWED_HOSTS = [urlparse(url).netloc for url in CSRF_TRUSTED_ORIGINS]
else:
    ALLOWED_HOSTS = ["*"]

# Default false. True allows default landing pages to be visible
DEBUG = env("DEBUG", default=False)

# Set this value from django-environ
DATABASES = {"default": env.db()}

# Change database settings if using the Cloud SQL Auth Proxy
if os.getenv("USE_CLOUD_SQL_AUTH_PROXY", None):
    DATABASES["default"]["HOST"] = "127.0.0.1"
    DATABASES["default"]["PORT"] = 5432

# Define static storage via django-storages[google]
GS_BUCKET_NAME = env("GS_BUCKET_NAME")
STATICFILES_DIRS = []
GS_DEFAULT_ACL = "publicRead"
STORAGES = {
    "default": {
        "BACKEND": "storages.backends.gcloud.GoogleCloudStorage",
    },
    "staticfiles": {
        "BACKEND": "storages.backends.gcloud.GoogleCloudStorage",
    },
}

Lesen Sie sich die Kommentare zu den einzelnen Konfigurationen durch.

Möglicherweise werden in dieser Datei Lint-Fehler angezeigt. Dies ist zu erwarten. Cloud Shell kennt die Anforderungen für dieses Projekt nicht und meldet daher möglicherweise ungültige und nicht verwendete Importe.

Python-Abhängigkeiten

Suchen Sie die Datei requirements.txt und hängen Sie die folgenden Pakete an:

cloudshell edit requirements.txt

requirements.txt (append)

gunicorn
psycopg2-binary
django-storages[google]
django-environ

Anwendungsbild definieren

Cloud Run führt jeden Container aus, solange er dem Cloud Run-Containervertrag entspricht. In dieser Anleitung wird Dockerfile weggelassen und stattdessen Cloud Native Buildpacks verwendet. Buildpacks unterstützen das Erstellen von Containern für gängige Sprachen, einschließlich Python.

In dieser Anleitung wird Procfile angepasst, mit dem die Webanwendung gestartet wird.

Erstellen Sie zum Containerisieren des Vorlagenprojekts zuerst eine neue Datei namens Procfile in der obersten Ebene Ihres Projekts (im selben Verzeichnis wie manage.py) und kopieren Sie den folgenden Inhalt hinein:

touch Procfile
cloudshell edit Procfile

Procfile

web: gunicorn --bind 0.0.0.0:$PORT --workers 1 --threads 8 --timeout 0 myproject.wsgi:application

7. Migrationsschritte konfigurieren, erstellen und ausführen

Um das Datenbankschema in Ihrer Cloud SQL-Datenbank zu erstellen und Ihren Cloud Storage-Bucket mit Ihren statischen Assets zu füllen, müssen Sie migrate und collectstatic ausführen.

Diese grundlegenden Django-Migrationsbefehle müssen im Kontext Ihres erstellten Container-Images mit Zugriff auf Ihre Datenbank ausgeführt werden.

Außerdem müssen Sie createsuperuser ausführen, um ein Administratorkonto zu erstellen, mit dem Sie sich im Django-Adminbereich anmelden können.

Dazu verwenden Sie Cloud Run-Jobs. Mit Cloud Run-Jobs können Sie Prozesse mit einem definierten Ende ausführen. Sie eignen sich daher ideal für Verwaltungsaufgaben.

Django-Superuser-Passwort definieren

Verwenden Sie zum Erstellen des Superusers die nicht interaktive Version des Befehls createsuperuser. Für diesen Befehl ist eine speziell benannte Umgebungsvariable erforderlich, die anstelle einer Aufforderung zur Eingabe des Passworts verwendet wird.

Erstellen Sie ein neues Secret mit einem zufällig generierten Passwort:

echo -n $(cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 30 | head -n 1) | gcloud secrets create django_superuser_password --data-file=-

Gewähren Sie Ihrem Dienstkonto Zugriff auf dieses Secret:

gcloud secrets add-iam-policy-binding django_superuser_password \
  --member serviceAccount:${SERVICE_ACCOUNT} \
  --role roles/secretmanager.secretAccessor

Procfile aktualisieren

Um für mehr Übersichtlichkeit bei Ihren Cloud Run-Jobs zu sorgen, können Sie Verknüpfungen in Ihrer Procfile erstellen und Procfile die folgenden Einträge hinzufügen:

migrate: python manage.py migrate && python manage.py collectstatic --noinput --clear
createuser: python manage.py createsuperuser --username admin --email [e-mail] --noinput

Sie sollten jetzt drei Einträge haben: den Standard-web-Einstiegspunkt, den migrate-Einstiegspunkt zum Anwenden von Datenbankmigrationen und den createuser-Einstiegspunkt zum Ausführen des Befehls createsuperuser.

Anwendungs-Image erstellen

Nachdem Sie die Änderungen an der Procfile vorgenommen haben, erstellen Sie das Image:

gcloud builds submit --pack image=${ARTIFACT_REGISTRY}/myimage

Cloud Run-Jobs erstellen

Nachdem das Image vorhanden ist, können Sie damit Cloud Run-Jobs erstellen.

Diese Jobs verwenden das zuvor erstellte Image, aber unterschiedliche command-Werte. Diese entsprechen den Werten in Procfile.

Erstellen Sie einen Job für die Migration:

gcloud run jobs create migrate \
  --region $REGION \
  --image ${ARTIFACT_REGISTRY}/myimage \
  --set-cloudsql-instances ${PROJECT_ID}:${REGION}:myinstance \
  --set-secrets APPLICATION_SETTINGS=application_settings:latest \
  --service-account $SERVICE_ACCOUNT \
  --command migrate

Erstellen Sie einen Job für die Nutzererstellung:

gcloud run jobs create createuser \
  --region $REGION \
  --image ${ARTIFACT_REGISTRY}/myimage \
  --set-cloudsql-instances ${PROJECT_ID}:${REGION}:myinstance \
  --set-secrets APPLICATION_SETTINGS=application_settings:latest \
  --set-secrets DJANGO_SUPERUSER_PASSWORD=django_superuser_password:latest \
  --service-account $SERVICE_ACCOUNT \
  --command createuser

Cloud Run-Jobs ausführen

Nachdem Sie die Jobkonfigurationen eingerichtet haben, führen Sie die Migrationen aus:

gcloud run jobs execute migrate --region $REGION --wait

Die Befehlsausgabe muss „successfully completed“ (erfolgreich abgeschlossen) enthalten.

Sie führen diesen Befehl später aus, wenn Sie Ihre Anwendung aktualisieren.

Erstellen Sie den Nutzer mit dem Job in der Datenbankeinrichtung:

gcloud run jobs execute createuser --region $REGION --wait

Die Befehlsausgabe muss „successfully completed“ (erfolgreich abgeschlossen) enthalten.

Sie müssen diesen Befehl nicht noch einmal ausführen.

8. In Cloud Run bereitstellen

Nachdem Sie die Sicherungsdienste erstellt und ausgefüllt haben, können Sie jetzt den Cloud Run-Dienst erstellen, um darauf zuzugreifen.

Stellen Sie den Dienst mit dem zuvor erstellten Image mit dem folgenden Befehl in Cloud Run bereit:

gcloud run deploy django-cloudrun \
  --region $REGION \
  --image ${ARTIFACT_REGISTRY}/myimage \
  --set-cloudsql-instances ${PROJECT_ID}:${REGION}:myinstance \
  --set-secrets APPLICATION_SETTINGS=application_settings:latest \
  --service-account $SERVICE_ACCOUNT \
  --allow-unauthenticated

Wenn die Bereitstellung erfolgreich war, wird in der Befehlszeile die Dienst-URL angezeigt:

Service [django-cloudrun] revision [django-cloudrun-00001-...] has been deployed and is serving 100 percent of traffic.
Service URL: https://django-cloudrun-...run.app

Sie können jetzt den bereitgestellten Container aufrufen. Dazu öffnen Sie diese URL in einem Webbrowser:

9. Auf die Django-Verwaltungsoberfläche zugreifen

Eine der Hauptfunktionen von Django ist die interaktive Verwaltung.

CSRF-Einstellungen aktualisieren

In Django 4.0 geändert: Die Überprüfung des CSRF-Ursprungs-Headers ist jetzt erzwungen. Weitere Informationen finden Sie in der Django-Dokumentation.

Django bietet Schutz vor Cross-Site Request Forgery (CSRF). Jedes Mal, wenn ein Formular auf Ihrer Django-Website gesendet wird, einschließlich der Anmeldung im Django-Adminbereich, wird die Einstellung „Vertrauenswürdige Ursprünge“ geprüft. Wenn sie nicht mit dem Ursprung der Anfrage übereinstimmt, gibt Django einen Fehler zurück.

Wenn in der Datei mysite/settings.py die Umgebungsvariable CLOUDRUN_SERVICE_URL definiert ist, wird sie in den Einstellungen CSRF_TRUSTED_ORIGINS und ALLOWED_HOSTS verwendet. Die Definition von ALLOWED_HOSTS ist zwar nicht zwingend erforderlich, wird aber empfohlen, da sie für CSRF_TRUSTED_ORIGINS bereits erforderlich ist.

Da Sie Ihre Dienst-URL benötigen, kann diese Konfiguration erst nach der ersten Bereitstellung hinzugefügt werden.

Sie müssen Ihren Dienst aktualisieren, um diese Umgebungsvariable hinzuzufügen. Es kann dem application_settings-Secret oder direkt als Umgebungsvariable hinzugefügt werden.

In der folgenden Implementierung werden die Formatierungs- und escaping von gcloud genutzt.

Rufen Sie Ihre Dienst-URLs ab:

CLOUDRUN_SERVICE_URLS=$(gcloud run services describe django-cloudrun \
  --region $REGION  \
  --format "value(metadata.annotations[\"run.googleapis.com/urls\"])" | tr -d '"[]')
echo $CLOUDRUN_SERVICE_URLS

Legen Sie diesen Wert als Umgebungsvariable für Ihren Cloud Run-Dienst fest:

gcloud run services update django-cloudrun \
  --region $REGION \
  --update-env-vars "^##^CLOUDRUN_SERVICE_URLS=$CLOUDRUN_SERVICE_URLS"

In der Django-Verwaltungskonsole anmelden

Wenn Sie auf die Django-Admin-Benutzeroberfläche zugreifen möchten, fügen Sie Ihrer Dienst-URL /admin an.

Melden Sie sich jetzt mit dem Nutzernamen „admin“ an und rufen Sie Ihr Passwort mit dem folgenden Befehl ab:

gcloud secrets versions access latest --secret django_superuser_password && echo ""

10. Anwendungen entwickeln

Während Sie Ihre Anwendung entwickeln, sollten Sie sie lokal testen. Dazu müssen Sie entweder eine Verbindung zu Ihrer Cloud SQL-Datenbank („Produktionsdatenbank“) oder zu einer lokalen Datenbank („Testdatenbank“) herstellen.

Verbindung zur Produktionsdatenbank herstellen

Sie können über den Cloud SQL Auth-Proxy eine Verbindung zu Ihren Cloud SQL-Instanzen herstellen. Diese Anwendung stellt eine Verbindung von Ihrem lokalen Computer zur Datenbank her.

Nachdem Sie den Cloud SQL Auth-Proxy installiert haben, gehen Sie so vor:

# Create a virtualenv
virtualenv venv
source venv/bin/activate
pip install -r requirements.txt

# Copy the application settings to your local machine
gcloud secrets versions access latest --secret application_settings > temp_settings

# Run the Cloud SQL Auth Proxy
./cloud-sql-proxy ${PROJECT_ID}:${REGION}:myinstance

# In a new tab, start the local web server using these new settings
USE_CLOUD_SQL_AUTH_PROXY=true APPLICATION_SETTINGS=$(cat temp_settings) python manage.py runserver

Entfernen Sie die temp_settings-Datei, nachdem Sie Ihre Arbeit abgeschlossen haben.

Verbindung zu einer lokalen SQLite-Datenbank herstellen

Alternativ können Sie bei der Entwicklung Ihrer Anwendung eine lokale Datenbank verwenden. Django unterstützt sowohl PostgreSQL- als auch SQLite-Datenbanken. PostgreSQL bietet einige Funktionen, die SQLite nicht hat, aber in vielen Fällen sind die Funktionen identisch.

Um SQLite einzurichten, müssen Sie Ihre Anwendungseinstellungen so aktualisieren, dass sie auf eine lokale Datenbank verweisen. Anschließend müssen Sie Ihre Schemamigrationen anwenden.

So richten Sie diese Methode ein:

# Create a virtualenv
virtualenv venv
source venv/bin/activate
pip install -r requirements.txt

# Copy the application settings to your local machine
gcloud secrets versions access latest --secret application_settings > temp_settings

# Edit the DATABASE_URL setting to use a local sqlite file. For example:
DATABASE_URL=sqlite:////tmp/my-tmp-sqlite.db

# Set the updated settings as an environment variable
APPLICATION_SETTINGS=$(cat temp_settings) 

# Apply migrations to the local database
python manage.py migrate

# Start the local web server
python manage.py runserver

Entfernen Sie die temp_settings-Datei, nachdem Sie Ihre Arbeit abgeschlossen haben.

Migrationen werden erstellt

Wenn Sie Änderungen an Ihren Datenbankmodellen vornehmen, müssen Sie möglicherweise die Migrationsdateien von Django generieren, indem Sie python manage.py makemigrations ausführen.

Sie können diesen Befehl ausführen, nachdem Sie die Produktions- oder Testdatenbankverbindung eingerichtet haben. Alternativ können Sie die Migrationsdateien ohne Datenbank generieren, indem Sie leere Einstellungen angeben:

SECRET_KEY="" DATABASE_URL="" GS_BUCKET_NAME="" python manage.py makemigrations

Anwendungsupdates anwenden

Wenn Sie Änderungen an Ihrer Anwendung anwenden möchten, müssen Sie Folgendes tun:

• die Änderungen in ein neues Image einbinden,
• Datenbank- oder Static-Migrationen anwenden und dann
• Aktualisieren Sie Ihren Cloud Run-Dienst, um das neue Image zu verwenden.

So erstellen Sie ein Image:

gcloud builds submit --pack image=${ARTIFACT_REGISTRY}/myimage

Wenn Sie Migrationen anwenden möchten, führen Sie den Cloud Run-Job aus:

gcloud run jobs execute migrate --region $REGION --wait

So aktualisieren Sie Ihren Dienst mit dem neuen Image:

gcloud run services update django-cloudrun \
  --region $REGION \
  --image ${ARTIFACT_REGISTRY}/myimage

11. Glückwunsch!

Sie haben gerade ein komplexes Projekt in Cloud Run bereitgestellt.

• Cloud Run skaliert das Container-Image automatisch horizontal, damit die empfangenen Anfragen bearbeitet werden können, und skaliert es wieder herunter, wenn der Bedarf sinkt. Es fallen nur Kosten für die CPU-, Arbeitsspeicher- und Netzwerkressourcen an, die während der Anfrageverarbeitung verbraucht werden.
• Mit Cloud SQL können Sie eine verwaltete PostgreSQL-Instanz bereitstellen, die automatisch für Sie verwaltet wird und sich nahtlos in viele Google Cloud-Systeme einbinden lässt.
• Mit Cloud Storage können Sie Cloud-Speicher so nutzen, dass er nahtlos in Django zugänglich ist.
• Mit Secret Manager können Sie Secrets speichern und festlegen, dass nur bestimmte Teile von Google Cloud darauf zugreifen können.

In diesem kurzen Lab wurde die gcloud-Befehlszeile verwendet. Cloud Run ist aber auch über die Cloud Console ( console.cloud.google.com) verfügbar. Rufen Sie einfach Compute > Cloud Run auf. Ihr Dienst sollte dort aufgeführt sein.

Aufräumen

So vermeiden Sie, dass Ihrem Google Cloud Platform-Konto die in dieser Anleitung verwendeten Ressourcen berechnet werden:

• Wechseln Sie in der Cloud Console zur Seite Ressourcen verwalten.
• Wählen Sie in der Projektliste Ihr Projekt aus und klicken Sie auf Löschen.
• Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Beenden, um das Projekt zu löschen.

Weitere Informationen

• Django in Cloud Run: https://cloud.google.com/python/django/run
• Hallo Cloud Run mit Python: https://codelabs.developers.google.com/codelabs/cloud-run-hello-python3
• Python in Google Cloud: https://cloud.google.com/python
• Google Cloud Python-Client: https://github.com/googleapis/google-cloud-python