Wagtail 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.

Es ist außerdem nativ mit vielen anderen Teilen der Google Cloud-Umgebung verknüpft, darunter Cloud SQL für verwaltete Datenbanken, Cloud Storage für einheitlichen Objektspeicher und Secret Manager für die Verwaltung von Secrets.

Wagtail ist ein Open-Source-Content-Management-System (CMS), das auf Django basiert. Django ist ein allgemeines Python-Web-Framework.

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

Hinweis: Dieses Codelab wurde zuletzt mit Wagtail 5.2.2 verifiziert, das Django 5 unterstützt.

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
• Build-Container mit Container Registry speichern
• In Cloud Run bereitstellen
• Datenbankschemamigrationen in Cloud Build ausführen

2. Einrichtung und Anforderungen

Umgebung für das selbstbestimmte Lernen einrichten

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 Projektteilnehmer. Es ist ein Zeichenstring, der von Google APIs nicht verwendet wird. Sie können sie jederzeit aktualisieren.
• Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und kann nach der Festlegung nicht mehr geändert werden. Die Cloud Console generiert automatisch einen eindeutigen String. ist Ihnen meist egal, was es ist. In den meisten Codelabs musst du auf deine Projekt-ID verweisen, die üblicherweise als PROJECT_ID bezeichnet wird. Wenn Ihnen die generierte ID nicht gefällt, können Sie eine weitere zufällige ID 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 erhalten.
• Zur Information: Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu allen 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 die Standardeinstellung Keine Organisation beibehalten. 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. Dieses Codelab ist kostengünstig. Sie können die von Ihnen erstellten Ressourcen oder das Projekt löschen, um Ressourcen herunterzufahren, um zu vermeiden, dass über diese Anleitung hinaus Kosten anfallen. Neuen Google Cloud-Nutzern steht das kostenlose Testprogramm mit einem Guthaben von 300 $ zur Verfügung.

Google Cloud Shell

Google Cloud kann zwar von Ihrem Laptop aus per Fernzugriff genutzt werden, 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 zu Cloud Shell dauert nur einen Moment.

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 eingestellt 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 ein leistungsstarkes und einheitliches Befehlszeilentool in Google Cloud. Es ist in Cloud Shell vorinstalliert. Sie werden feststellen, dass die Tab-Vervollständigung unterstützt wird. Bei der ersten Ausführung eines Befehls werden Sie möglicherweise zur Authentifizierung aufgefordert. 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 verwendeten 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.

Anschließend sollte eine Erfolgsmeldung ähnlich der folgenden angezeigt werden:

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

4. Vorlagenprojekt erstellen

Sie verwenden die Standard-Wagtail-Projektvorlage als Beispiel-Wagtail-Projekt. Dazu installieren Sie vorübergehend Wagtail, um die Vorlage zu generieren.

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

mkdir ~/wagtail-cloudrun
cd ~/wagtail-cloudrun

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

virtualenv venv
source venv/bin/activate
pip install wagtail

Erstellen Sie dann ein neues Vorlagenprojekt im aktuellen Ordner:

wagtail start myproject .

Sie haben jetzt ein Wagtail-Vorlageprojekt im aktuellen Ordner:

ls -F

Dockerfile  home/  manage.py*  myproject/  requirements.txt  search/ venv/

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

deactivate
rm -rf venv

Von hier aus wird Wagtail innerhalb des Containers aufgerufen.

5. Sicherungsdienste erstellen

Erstellen Sie jetzt 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 die Verwendung von us-central1, europe-north1 oder asia-northeast1. oder eine beliebige Region (vollständig verwaltet) von Cloud Run.

Weitere Informationen:

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

Dienstkonto erstellen

Wenn Sie den Zugriff des Dienstes auf andere Bereiche von Google Cloud beschränken möchten, erstellen Sie ein dediziertes 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 per Namen 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

Da Objekte, die im Bucket gespeichert sind, einen anderen Ursprung haben (eine Bucket-URL anstelle einer Cloud Run-URL), müssen Sie die CORS-Einstellungen (Cross-Origin Resource Sharing) konfigurieren.

Erstellen Sie eine neue Datei mit dem Namen cors.json und folgendem Inhalt:

touch cors.json
cloudshell edit cors.json

cors.json

[
    {
      "origin": ["*"],
      "responseHeader": ["Content-Type"],
      "method": ["GET"],
      "maxAgeSeconds": 3600
    }
]

Wenden Sie diese CORS-Konfiguration auf den neu erstellten Storage-Bucket an:

gsutil cors set cors.json gs://$GS_BUCKET_NAME

Konfiguration als Secret speichern

Nachdem Sie die Sicherungsdienste eingerichtet haben, speichern Sie diese Werte in einer Datei, die mit Secret Manager geschützt wird.

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

Erstellen Sie zuerst eine Datei mit den Werten für den Datenbankverbindungsstring, den Medien-Bucket und einen geheimen Schlüssel für Django (zur kryptografischen Signierung von Sitzungen und Tokens), und aktivieren Sie die 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

Nachdem Sie bestätigt haben, dass das Secret erstellt wurde, entfernen Sie die lokale Datei:

rm .env

6. Anwendung konfigurieren

Das Vorlagenprojekt, das Sie zuvor erstellt haben, muss jetzt geändert werden. Durch diese Änderungen wird die Komplexität der mit Wagtail gelieferten Vorlageneinstellungen reduziert und Wagtail wird in die zuvor erstellten unterstützenden Dienste eingebunden.

Einstellungen konfigurieren

Suchen Sie die generierte base.py-Datei und benennen Sie sie im Hauptordner myproject in basesettings.py um:

mv myproject/settings/base.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.

Entfernen Sie dann den alten Ordner „Einstellungen“.

rm -rf myproject/settings/

Sie haben dann zwei Konfigurationsdateien: eine von Wagtail und eine, die Sie gerade erstellt haben und die auf diesen Einstellungen basiert:

ls myproject/*settings*

myproject/basesettings.py  myproject/settings.py

Öffnen Sie abschließend die manage.py-Datei und aktualisieren Sie die Konfiguration, damit Wagtail auf die Hauptdatei settings.py verweist.

cloudshell edit manage.py

Zeile „manage.py“ (vorher)

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings.dev")

manage.py-Zeile (nachher)

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")

Nehmen Sie dieselbe Konfigurationsänderung für die Datei myproject/wsgi.py vor:

cloudshell edit myproject/wsgi.py

Zeile „myproject/wsgi.py“ (vorher)

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings.dev")

myproject/wsgi.py-Zeile (nachher)

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")

Entfernen Sie das automatisch erstellte Dockerfile:

rm Dockerfile

Python-Abhängigkeiten

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

cloudshell edit requirements.txt

requirements.txt (Anhang)

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

Anwendungs-Image 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 mit dem Namen Procfile auf der obersten Ebene Ihres Projekts (im selben Verzeichnis wie manage.py) und kopieren Sie den folgenden Inhalt:

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 für die Anmeldung beim Django-Administrator zu erstellen.

Dazu verwenden Sie Cloud Run-Jobs, um diese Aufgaben auszuführen. 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

Um den Superuser zu erstellen, verwenden Sie 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

Erstellen Sie Verknüpfungen in Ihrer Procfile und hängen Sie die folgenden Einstiegspunkte an Procfile an, um die Übersichtlichkeit Ihrer Cloud Run-Jobs zu verbessern:

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

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

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

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

Achten Sie darauf, dass in dieser Befehlsausgabe die Ausführung „erfolgreich abgeschlossen“ angezeigt wird.

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.

Die erste Bereitstellung Ihrer Containeranwendung in Cloud Run wird mit dem folgenden Befehl erstellt:

gcloud run deploy wagtail-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

Warten Sie dann einige Sekunden, bis die Bereitstellung abgeschlossen ist. Wenn die Bereitstellung erfolgreich war, wird in der Befehlszeile die Dienst-URL angezeigt:

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

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

9. Auf die Django-Verwaltungsoberfläche zugreifen

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 auf Ihrer Django-Website ein Formular gesendet wird, einschließlich der Anmeldung im Django-Adminbereich, wird die Einstellung „Vertrauenswürdige Ursprünge“ geprüft. Wenn er 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 obligatorisch, aber es hat sich bewährt, dies hinzuzufügen, da es 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. Sie können dem Secret application_settings oder direkt als Umgebungsvariable hinzugefügt werden.

Bei der folgenden Implementierung werden die gcloud-Formatierung und escaping genutzt.

Rufen Sie die Dienst-URL ab:

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

Legen Sie diesen Wert als Umgebungsvariable in Ihrem Cloud Run-Dienst fest:

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

In der Django-Verwaltungskonsole anmelden

Wenn Sie auf die Django-Benutzeroberfläche zugreifen möchten, fügen Sie /admin an die Dienst-URL 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

Mit dem Cloud SQL Auth Proxy können Sie 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 --instances=${PROJECT_ID}:${REGION}:myinstance=tcp:5432

# 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

Achten Sie darauf, die Datei temp_settings wieder zu entfernen, wenn Sie fertig sind.

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 werden angewendet

So wenden Sie Änderungen in Ihrer Anwendung an:

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

So erstellen Sie Ihr 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 wagtail-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 nativ in viele Google Cloud-Systeme eingebunden ist.
• Mit Cloud Storage haben Sie einen nahtlosen Zugriff auf Cloud-Speicher in Django.
• 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 jedoch ü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

/