Django CMS in Cloud Run

Django CMS in Cloud Run

Informationen zu diesem Codelab

subjectZuletzt aktualisiert: Jan. 31, 2024
account_circleVerfasst von Katie McLaughlin

1. Einführung

894762ebb681671c.png

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.

Django CMS ist ein Content-Management-System (CMS) für Unternehmen, das auf Django basiert. Django ist ein übergeordnetes Python-Web-Framework.

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

Hinweis: Dieses Codelab wurde zuletzt mit Django CMS 3.11.4 bis django-cms/cms-template v3.11 überprüft.

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 Projekt. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie eines erstellen.

fbef9caa1602edd0.png

a99b7ace416376c4.png

5e3ff691252acf41.png

  • Der Projektname ist der Anzeigename für die Projektteilnehmer. Es handelt sich um eine Zeichenfolge, die von Google APIs nicht verwendet wird. Sie können sie jederzeit aktualisieren.
  • Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und unveränderlich. Sie kann nach dem Festlegen 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 einen eigenen verwenden und nachsehen, ob er verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts erhalten.
  • Zur Information gibt es noch einen dritten Wert, die Projektnummer, die von manchen APIs verwendet wird. Weitere Informationen zu allen drei Werten finden Sie in der Dokumentation.
  1. Als Nächstes müssen Sie in der Cloud Console die Abrechnung 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. Neue Google Cloud-Nutzer haben Anspruch auf das kostenlose Testprogramm mit 300$Guthaben.

Google Cloud Shell

Sie können Google Cloud zwar von Ihrem Laptop aus aus der Ferne bedienen, 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 853e55310c205094.png.

5c1dabeca90e44e5.png

Wenn Sie Cloud Shell zum ersten Mal starten, wird ein Zwischenbildschirm mit einer Beschreibung der Funktion angezeigt. Wenn ein Zwischenbildschirm angezeigt wird, klicken Sie auf Weiter.

9c92662c6a846a5c.png

Die Bereitstellung und Verbindung zu Cloud Shell dauert nur einen Moment.

9f0e51b578fecce5.png

Diese virtuelle Maschine verfügt über alle erforderlichen Entwicklertools. Es bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und wird in Google Cloud ausgeführt. Dadurch werden die Netzwerkleistung und die Authentifizierung erheblich verbessert. Viele, wenn nicht sogar alle Arbeiten 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.

  1. 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`
  1. 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].

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, diese Anfrage mit Ihren Anmeldedaten zu autorisieren. Dies geschieht einmal pro Cloud Shell-Sitzung.

Dieser Vorgang kann einen Moment 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 das Django CMS cms-template als Django-CMS-Beispielprojekt.

Erstellen Sie zum Erstellen dieses Vorlagenprojekts in Cloud Shell ein neues Verzeichnis mit dem Namen djangocms-cloudrun und wechseln Sie zu diesem Verzeichnis:

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-3]

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

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

Sie haben nun eine Vorlage für ein Django CMS-Projekt in einem Ordner namens myproject:

ls -F
manage.py*  media/  myproject/  project.db  requirements.in requirements.txt  static/ venv/

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

deactivate
rm -rf venv

Von hier aus wird das CMS von Django im Container aufgerufen.

Sie können auch die automatisch kopierte Datei „requirements.in“ entfernen, die von pip-tools zum Generieren von „requirements.txt“-Dateien verwendet wird. Er wird in diesem Codelab nicht verwendet:

rm requirements.in

5. Sicherungsdienste erstellen

Sie erstellen nun Ihre Sicherungsdienste: ein dediziertes 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 eines Projekts wichtig und sorgt dafür, dass niemand versehentlich Passwörter an einen anderen Ort legt, z. B. direkt in Einstellungsdateien oder direkt in Ihr 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

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 späteren Abschnitten dieses Codelab werden Sie mit der entsprechenden E-Mail-Adresse auf dieses Konto 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

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

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

In späteren Abschnitten dieses Codelabs werden Sie namentlich auf diese Registry 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 diesem Fall 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 im 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 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 aufrufen. 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

Für die von Ihnen gerade erstellten Sicherungsdienste müssen Sie einige Änderungen an dem passenden Vorlagenprojekt vornehmen.

Dazu gehört auch die Einführung von django-environ zur Verwendung von Umgebungsvariablen als Konfigurationseinstellungen, die mit den Werten versehen werden, die Sie als Secrets definiert haben. Erweitern Sie dazu die Vorlageneinstellungen. 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 URL to Django security settings
CLOUDRUN_SERVICE_URL
= env("CLOUDRUN_SERVICE_URL", default=None)
if CLOUDRUN_SERVICE_URL:
    ALLOWED_HOSTS
= [urlparse(CLOUDRUN_SERVICE_URL).netloc]
    CSRF_TRUSTED_ORIGINS
= [CLOUDRUN_SERVICE_URL]
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
= []
DEFAULT_FILE_STORAGE
= "storages.backends.gcloud.GoogleCloudStorage"
STATICFILES_STORAGE
= "storages.backends.gcloud.GoogleCloudStorage"
GS_DEFAULT_ACL
= "publicRead"

Lesen Sie sich die Kommentare zu jeder Konfiguration durch.

Beachten Sie, dass Linting-Fehler für diese Datei auftreten können. 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 (Anhang)

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

Anwendungs-Image definieren

Cloud Run führt alle Container aus, die dem Cloud Run-Containervertrag entsprechen. In dieser Anleitung wird Dockerfile weggelassen. Stattdessen werden Cloudnative Buildpacks verwendet. Buildpacks unterstützen das Erstellen von Containern für gängige Sprachen, einschließlich Python.

In dieser Anleitung wird die Procfile angepasst, mit der 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 den 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 und sind damit ideal für Verwaltungsaufgaben.

Definieren Sie Ihr Django-Superuser-Passwort

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=-

Erlauben Sie Ihrem Dienstkonto den 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 noop@example.com --noinput

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

Anwendungs-Image erstellen

Erstellen Sie nach den Procfile-Updates 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 andere 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

Führen Sie die Migrationen mit den Jobkonfigurationen 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 mit der Datenbankeinrichtung den Nutzer mithilfe des Jobs:

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

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

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 djangocms-cloudrun \
  --platform managed \
  --region $REGION \
  --image gcr.io/${PROJECT_ID}/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-...-uc.a.run.app

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

e54d1a1486427431.png

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

9. Auf den Django-Administrator zugreifen

Eine der Hauptfunktionen von Django CMS ist der interaktive Administrator.

CSRF-Einstellungen werden aktualisiert

Django bietet Schutz vor Cross-Site Request Forgery (CSRF). Bei jedem Senden eines Formulars auf Ihrer Django-Website, einschließlich der Anmeldung beim Django-Administrator, ist die Einstellung "Trusted Origins" (Vertrauenswürdige Ursprünge) aktiviert. 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 Ihrer ersten Bereitstellung hinzugefügt werden.

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

Rufen Sie die Dienst-URL ab:

CLOUDRUN_SERVICE_URL=$(gcloud run services describe djangocms-cloudrun \
  --platform managed \
  --region $REGION  \
  --format "value(status.url)")
echo $CLOUDRUN_SERVICE_URL

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

gcloud run services update djangocms-cloudrun \
  --region $REGION \
  --update-env-vars CLOUDRUN_SERVICE_URL=$CLOUDRUN_SERVICE_URL

Anmeldung beim Django-Administrator

Um auf die Django-Administratoroberfläche zuzugreifen, hängen Sie /admin an Ihre 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 ""

13d77046e2e7427.png

10. Anwendungsupdates werden angewendet

Bei der Entwicklung Ihrer Anwendung sollten Sie sie lokal testen. Dazu müssen Sie entweder eine Verbindung zu Ihrer Cloud SQL-Datenbank (Produktion) oder zu einer lokalen (Test-)Datenbank 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 vom 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

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

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. Es gibt einige Funktionen, die PostgreSQL über SQLite nicht hat, aber in vielen Fällen ist die Funktionalität identisch.

Zum Einrichten von SQLite müssen Sie Ihre Anwendungseinstellungen so aktualisieren, dass 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

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 durch Ausführen von python manage.py makemigrations generieren.

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:

  • Änderungen in einem neuen Image einzubinden.
  • 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 Migrationen angewendet werden sollen, 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 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 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 für bestimmte Bereiche von Google Cloud zugänglich machen.

Aufräumen

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

  • Rufen Sie in der Cloud Console die Seite Ressourcen verwalten auf.
  • Wählen Sie Ihr Projekt in der Projektliste 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