Django CMS in Cloud Run

1. Einführung

89eb4723767d4525.png

Cloud Run ist eine verwaltete Computing-Plattform, 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 sie nativ mit vielen anderen Teilen des Google Cloud-Ökosystems kompatibel, darunter Cloud SQL für verwaltete Datenbanken, Cloud Storage für einheitlichen Objektspeicher und Secret Manager für die Verwaltung von Secrets.

Django CMS ist ein Enterprise-Content-Management-System (CMS), das auf Django basiert. Django ist ein Python-Web-Framework auf hoher Ebene.

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

Hinweis: Dieses Codelab wurde zuletzt mit Django CMS 4.1.2 über django-cms/cms-template v4.1 überprüft.

Lerninhalte

  • 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
  • Container Registry zum Speichern erstellter Container verwenden
  • In Cloud Run bereitstellen
  • Datenbankschema-Migrationen in Cloud Build ausführen

2. Einrichtung und Anforderungen

Umgebung zum selbstbestimmten 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 eines erstellen.

295004821bab6a87.png

37d264871000675d.png

96d86d3d5655cdbe.png

  • Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es handelt sich um einen String, der nicht von Google APIs verwendet wird. Sie können sie jederzeit aktualisieren.
  • Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und unveränderlich (kann nach dem Festlegen nicht mehr geändert werden). In der Cloud Console wird automatisch ein eindeutiger String generiert. Normalerweise ist es nicht wichtig, wie dieser String aussieht. In den meisten Codelabs müssen Sie auf Ihre Projekt-ID verweisen (in der Regel als PROJECT_ID angegeben). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige ID generieren. Alternativ können Sie es mit einem eigenen Namen versuchen und sehen, ob er 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
  1. Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs zu verwenden. Die Durchführung dieses Codelabs kostet wenig oder gar nichts. Wenn Sie Ressourcen herunterfahren möchten, um Kosten zu vermeiden, die über diese Anleitung hinausgehen, können Sie die erstellten Ressourcen oder das Projekt löschen. Neue Google Cloud-Nutzer können am kostenlosen Testzeitraum mit einem Guthaben von 300$ teilnehmen.

Google Cloud Shell

Während Sie Google Cloud von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Cloud Shell aktivieren

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

cb81e7c8e34bc8d.png

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

d95252b003979716.png

Das Herstellen der Verbindung mit der Cloud Shell sollte nur wenige Augenblicke dauern.

7833d5e1c5d18f54.png

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 sogar alle Aufgaben in diesem Codelab können mit einem Browser erledigt werden.

Sobald die Verbindung mit der Cloud Shell hergestellt ist, sehen Sie, dass Sie authentifiziert sind und für das Projekt Ihre Projekt-ID eingestellt ist.

  1. Führen Sie in der 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`
  1. Führen Sie den folgenden Befehl in Cloud Shell aus, um zu bestätigen, dass 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].

3. Cloud APIs aktivieren

Aktivieren Sie in Cloud Shell die Cloud APIs für die Komponenten, die verwendet werden:

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 APIs zum ersten Mal ü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 Momente dauern.

Anschließend sollte eine Erfolgsmeldung wie die folgende angezeigt werden:

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

4. Vorlagenprojekt erstellen

Sie verwenden das Django CMS-cms-template als Django CMS-Beispielprojekt.

Erstellen Sie mit Cloud Shell ein neues Verzeichnis namens djangocms-cloudrun und rufen Sie es auf, um dieses Vorlagenprojekt zu erstellen:

mkdir ~/djangocms-cloudrun
cd ~/djangocms-cloudrun

Installieren Sie das django-cms-Paket in einer temporären virtuellen Umgebung:

virtualenv venv
source venv/bin/activate
pip install djangocms-frontend\[cms-4]

Erstellen Sie eine Kopie des Projekts „cms-template“:

django-admin startproject --template https://github.com/django-cms/cms-template/archive/4.1.zip myproject .

Benennen Sie die Datei requirements.in in requirements.txt um. Die Datei .in wird von pip-tools zum Generieren von requirements.txt-Dateien verwendet. Sie kann aber auch unverändert verwendet werden, wenn die Dateiendung geändert wird. In späteren Schritten erwartet pip die Erweiterung .txt.)

mv requirements.in requirements.txt

Sie haben jetzt ein Django CMS-Vorlagenprojekt in einem Ordner mit dem Namen myproject:

ls -F

manage.py*  media/  myproject/  project.db requirements.txt  static/ venv/

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

deactivate
rm -rf venv

Von hier aus wird Django CMS im Container aufgerufen.

5. Sicherungsdienste erstellen

Als Nächstes erstellen Sie Ihre Backing Services: ein dediziertes Dienstkonto, eine Artifact Registry, eine Cloud SQL-Datenbank, einen Cloud Storage-Bucket und eine Reihe von Secret Manager-Werten.

Die Werte der bei der Bereitstellung verwendeten Passwörter zu schützen, ist wichtig für die Sicherheit jedes Projekts. So wird verhindert, dass Passwörter versehentlich an Stellen platziert werden, an denen sie nicht hingehören, z. B. direkt in Einstellungsdateien oder direkt in das Terminal eingegeben, wo sie aus dem Verlauf abgerufen werden könnten.

Legen Sie zuerst zwei 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

Dienstkonto erstellen

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

gcloud iam service-accounts create cloudrun-serviceaccount

In den folgenden Abschnitten dieses Codelabs werden Sie auf dieses Konto anhand seiner E-Mail-Adresse verweisen. 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 eine Container Registry in der gewünschten Region, um das erstellte Container-Image zu speichern:

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

In späteren Abschnitten dieses Codelabs verweisen Sie mit dem Namen auf diese Registry:

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 in dem Bucket gespeicherte Objekte einen anderen Ursprung haben (eine Bucket-URL anstelle einer Cloud Run-URL), müssen Sie die Einstellungen für Cross-Origin Resource Sharing (CORS) 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 Speicher-Bucket an:

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

Konfiguration als Secret speichern

Nachdem Sie die unterstützenden Dienste eingerichtet haben, speichern Sie diese Werte 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. Es 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.

Erstellen Sie zuerst eine Datei mit den Werten für den Datenbank-Verbindungsstring, den Medien-Bucket, einen geheimen Schlüssel für Django (der für die kryptografische Signierung von Sitzungen und Tokens verwendet wird) und zum Aktivieren des Debuggings:

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 mit dieser Datei ein Secret mit dem Namen application_settings:

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

Angesichts der gerade erstellten Backing Services 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 als Secrets definierten Werten initialisieren. Dazu müssen Sie die Vorlageneinstellungen erweitern. Außerdem müssen Sie zusätzliche Python-Abhängigkeiten hinzufügen.

Einstellungen konfigurieren

Verschieben Sie die Datei settings.py und benennen Sie sie in basesettings.py: um.

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",
    },
}

Nehmen Sie sich die Zeit, die Kommentare zu den einzelnen Konfigurationen zu lesen.

Möglicherweise werden für diese Datei Linting-Fehler angezeigt. Dies ist zu erwarten. Cloud Shell hat keinen Kontext für die Anforderungen dieses Projekts 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, sofern er dem Cloud Run-Containervertrag entspricht. In dieser Anleitung wird auf ein Dockerfile verzichtet und stattdessen Cloud Native Buildpacks verwendet. Buildpacks unterstützen Sie beim Erstellen von Containern für gängige Sprachen wie Python.

In dieser Anleitung wird die Anpassung des Procfile zum Starten der Webanwendung beschrieben.

Erstellen Sie zum Containerisieren des Vorlagenprojekts zuerst eine neue Datei mit dem Namen Procfile auf der obersten Ebene des 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 in der Django-Administration anmelden können.

Dazu verwenden Sie Cloud Run-Jobs. Mit Cloud Run-Jobs können Sie Prozesse ausführen, die ein definiertes Ende haben. Sie eignen sich daher ideal für Verwaltungsaufgaben.

Passwort für Django-Superuser definieren

Zum Erstellen des Superusers verwenden Sie die nicht interaktive Version des Befehls createsuperuser. Für diesen Befehl ist eine Umgebungsvariable mit einem speziellen Namen 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 die Übersichtlichkeit Ihrer Cloud Run-Jobs zu verbessern, können Sie in Ihrer Procfile-Datei Aliasse erstellen. Hängen Sie dazu die folgenden Einstiegspunkte an Procfile an:

migrate: python manage.py migrate && python manage.py collectstatic --noinput --clear
createuser: python manage.py createsuperuser --username admin --email noop@example.com --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 createsuperuser-Befehls.

Anwendungs-Image erstellen

Nachdem Sie die Procfile aktualisiert 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

Führen Sie die Migrationen aus, nachdem Sie die Jobkonfigurationen eingerichtet haben:

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

Prüfen Sie, ob in der Ausgabe dieses Befehls steht, dass die Ausführung „successfully completed“ (erfolgreich abgeschlossen) wurde.

Sie führen diesen Befehl später aus, wenn Sie Änderungen an Ihrer Anwendung vornehmen.

Erstellen Sie den Nutzer mit dem Job:

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

Prüfen Sie, ob in der Ausgabe dieses Befehls steht, dass die Ausführung „successfully completed“ (erfolgreich abgeschlossen) wurde.

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

8. In Cloud Run bereitstellen

Nachdem die Sicherungsdienste erstellt und mit Daten gefüllt wurden, können Sie jetzt den Cloud Run-Dienst erstellen, um auf sie zuzugreifen.

Die erste Bereitstellung Ihrer containerisierten Anwendung in Cloud Run erfolgt mit dem folgenden Befehl:

gcloud run deploy djangocms-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 [djangocms-cloudrun] revision [djangocms-cloudrun-00001-...] has been deployed and is serving 100 percent of traffic.
Service URL: https://djangocms-cloudrun-...run.app

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

e1fb6858bf11626a.png

Da es sich um eine Neuinstallation handelt, werden Sie automatisch zur Anmeldeseite weitergeleitet.

9. Auf die Django-Verwaltung zugreifen

Eine der wichtigsten Funktionen von Django CMS ist die interaktive Administration.

CSRF-Einstellungen werden aktualisiert

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

Wenn die Umgebungsvariable CLOUDRUN_SERVICE_URL in der Datei mysite/settings.py 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 empfiehlt sich, sie hinzuzufügen, da sie bereits für CSRF_TRUSTED_ORIGINS erforderlich ist.

Da Sie die Dienst-URL benötigen, kann diese Konfiguration erst nach dem ersten Deployment hinzugefügt werden.

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

Bei der folgenden Implementierung werden die Formatierung und die Escaping-Funktion von gcloud genutzt.

Rufen Sie Ihre Dienst-URL ab:

CLOUDRUN_SERVICE_URLS=$(gcloud run services describe djangocms-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 djangocms-cloudrun \
  --region $REGION \
  --update-env-vars "^##^CLOUDRUN_SERVICE_URLS=$CLOUDRUN_SERVICE_URLS"

Beim Django-Administrator anmelden

Wenn Sie auf die Django-Administratoroberfläche zugreifen möchten, hängen 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 ""

da10a148bc1c7994.png

10. Anwendungsupdates anwenden

Während Sie Ihre Anwendung entwickeln, sollten Sie sie lokal testen. Dazu müssen Sie entweder eine Verbindung zu Ihrer Cloud SQL-Datenbank („Produktion“) oder zu einer lokalen Datenbank („Test“) 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, wenn Sie Ihre Arbeit abgeschlossen haben.

Verbindung zu einer lokalen SQLite-Datenbank herstellen

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

Um SQLite einzurichten, müssen Sie Ihre Anwendungseinstellungen aktualisieren, damit sie auf eine lokale Datenbank verweisen, und dann 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, wenn Sie Ihre Arbeit abgeschlossen haben.

Migrationen werden erstellt

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

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

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

Anwendungsupdates anwenden

So übernehmen Sie Änderungen an Ihrer Anwendung:

  • Ihre Änderungen in ein neues Image einbauen
  • Datenbank- oder statische Migrationen anwenden und dann
  • Aktualisieren Sie Ihren Cloud Run-Dienst, damit er das neue Image verwendet.

So erstellen Sie Ihr Image:

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

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

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

So aktualisieren Sie Ihren Dienst mit dem neuen Bild:

gcloud run services update djangocms-cloudrun \
  --platform managed \
  --region $REGION \
  --image gcr.io/${PROJECT_ID}/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 gewartet wird und nativ in viele Google Cloud-Systeme eingebunden ist.
  • Mit Cloud Storage können Sie Cloud-Speicher so nutzen, dass er in Django nahtlos zugänglich ist.
  • Mit Secret Manager können Sie Secrets speichern und dafür sorgen, dass sie nur für bestimmte Teile von Google Cloud zugänglich sind.

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