Wagtail sur Cloud Run

1. Introduction

Cloud Run est une plate-forme de calcul gérée qui permet d'exécuter des conteneurs sans état accessibles via des requêtes HTTP. Cloud Run fonctionne sans serveur : il élimine toute gestion de l'infrastructure pour vous permettre de vous concentrer sur ce qui compte le plus : créer des applications de qualité.

Il s'interface également de manière native avec de nombreuses autres parties de l'écosystème Google Cloud, y compris Cloud SQL pour les bases de données gérées, Cloud Storage pour le stockage d'objets unifié et Secret Manager pour la gestion des secrets.

Wagtail est un système de gestion de contenu (CMS) Open Source basé sur Django. Django est un framework Web Python de haut niveau.

Dans ce tutoriel, vous allez utiliser ces composants pour déployer un petit projet Wagtail.

Remarque: Cet atelier de programmation a été validé pour la dernière fois avec Wagtail 5.2.2, qui est compatible avec Django 5.

Points abordés

• Utiliser Cloud Shell
• Créer une base de données Cloud SQL
• Créer un bucket Cloud Storage
• Créer des secrets Secret Manager
• Utiliser les secrets de différents services Google Cloud
• Connecter des composants Google Cloud à un service Cloud Run
• Utiliser Container Registry pour stocker les conteneurs créés
• Déployer sur Cloud Run
• Exécuter des migrations de schéma de base de données dans Cloud Build

2. Préparation

Configuration de l'environnement au rythme de chacun

1. Connectez-vous à la console Google Cloud, puis créez un projet ou réutilisez un projet existant. Si vous n'avez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.

• Le nom du projet est le nom à afficher pour les participants au projet. Il s'agit d'une chaîne de caractères non utilisée par les API Google. Vous pourrez toujours le modifier.
• L'ID du projet est unique parmi tous les projets Google Cloud et non modifiable une fois défini. La console Cloud génère automatiquement une chaîne unique (en général, vous n'y accordez d'importance particulière). Dans la plupart des ateliers de programmation, vous devrez indiquer l'ID de votre projet (généralement identifié par PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre de manière aléatoire. Vous pouvez également en spécifier un et voir s'il est disponible. Après cette étape, l'ID n'est plus modifiable et restera donc le même pour toute la durée du projet.
• Pour information, il existe une troisième valeur (le numéro de projet) que certaines API utilisent. Pour en savoir plus sur ces trois valeurs, consultez la documentation.

Attention : Un ID de projet est unique. Une fois que vous l'avez choisi, personne d'autre ne peut l'employer. Vous en êtes le seul utilisateur. Même si un projet est supprimé, son ID ne peut pas être réutilisé.

Remarque : Si vous utilisez un compte Gmail, vous pouvez conserver l'emplacement par défaut défini sur Aucune organisation. Si vous utilisez un compte Google Workspace, choisissez un emplacement qui ait du sens pour votre organisation.

2. Vous devez ensuite activer la facturation dans la console Cloud pour utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour désactiver les ressources et éviter ainsi que des frais ne vous soient facturés après ce tutoriel, vous pouvez supprimer le projet ou les ressources que vous avez créées. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300 $.

Google Cloud Shell

Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons utiliser Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.

Activer Cloud Shell

1. Dans Cloud Console, cliquez sur Activer Cloud Shell .

Si vous démarrez Cloud Shell pour la première fois, un écran intermédiaire vous explique de quoi il s'agit. Si un écran intermédiaire vous s'est présenté, cliquez sur Continue (Continuer).

Le provisionnement et la connexion à Cloud Shell ne devraient pas prendre plus de quelques minutes.

Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute dans Google Cloud, ce qui améliore considérablement les performances du réseau et l'authentification. Une grande partie, voire la totalité, de votre travail dans cet atelier de programmation peut être effectué dans un navigateur.

Une fois connecté à Cloud Shell, vous êtes en principe authentifié, et le projet est défini avec votre ID de projet.

2. Exécutez la commande suivante dans Cloud Shell pour vérifier que vous êtes authentifié :

gcloud auth list

Résultat de la commande

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

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

Remarque : gcloud est l'outil de ligne de commande performant et unifié de Google Cloud. Il est préinstallé dans Cloud Shell. Il est également compatible avec la saisie semi-automatique via la touche de tabulation. Vous pouvez être invité à vous authentifier la première fois que vous exécutez une commande. Pour en savoir plus, consultez la présentation de l'outil de ligne de commande gcloud.

3. Exécutez la commande suivante dans Cloud Shell pour vérifier que la commande gcloud connaît votre projet:

gcloud config list project

Résultat de la commande

[core]
project = <PROJECT_ID>

Si vous obtenez un résultat différent, exécutez cette commande :

gcloud config set project <PROJECT_ID>

Résultat de la commande

Updated property [core/project].

Remarque : Si vous suivez ce tutoriel en dehors de Cloud Shell, suivez la procédure Configurer les identifiants par défaut de l'application.

3. Activer les API Cloud

Dans Cloud Shell, activez les API Cloud pour les composants qui seront utilisés :

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

Étant donné que vous appelez des API à partir de gcloud pour la première fois, vous êtes invité à autoriser l'utilisation de vos identifiants pour effectuer cette requête. Cela se produit une fois par session Cloud Shell.

Cette opération peut prendre quelques minutes.

Une fois l'opération terminée, un message de confirmation semblable à celui-ci doit s'afficher:

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

4. Créer un projet de modèle

Vous utiliserez le modèle de projet Wagtail par défaut comme exemple de projet Wagtail. Pour ce faire, vous allez installer temporairement Wagtail afin de générer le modèle.

Pour créer ce projet de modèle, utilisez Cloud Shell pour créer un répertoire nommé wagtail-cloudrun et accédez-y :

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

Ensuite, installez Wagtail dans un environnement virtuel temporaire:

virtualenv venv
source venv/bin/activate
pip install wagtail

Créez ensuite un projet de modèle dans le dossier actuel :

wagtail start myproject .

Vous disposez désormais d'un projet Wagtail de modèle dans le dossier actuel :

ls -F

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

Vous pouvez maintenant quitter et supprimer votre environnement virtuel temporaire :

deactivate
rm -rf venv

Wagtail est ensuite appelé dans le conteneur.

5. Créer les services externes

Vous allez maintenant créer vos services de base : un compte de service dédié, un Artifact Registry, une base de données Cloud SQL, un bucket Cloud Storage et un certain nombre de valeurs Secret Manager.

La sécurisation des valeurs des mots de passe utilisés lors du déploiement est importante pour la sécurité de tout projet. Elle garantit que personne ne place accidentellement des mots de passe là où ils ne devraient pas se trouver (par exemple, directement dans des fichiers de paramètres ou saisis directement dans votre terminal, où ils pourraient être récupérés à partir de l'historique).

Pour commencer, définissez deux variables d'environnement de base, une pour l'ID du projet:

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

Et une pour la région :

REGION=us-central1

Lorsque vous travaillez avec une infrastructure, il est utile de placer tous vos composants au même endroit afin qu'ils puissent communiquer plus efficacement. Certains composants sont disponibles dans le monde entier, mais certains ne le sont pas dans toutes les régions.

Pour cet atelier de programmation, nous vous recommandons d'utiliser us-central1, europe-north1 ou asia-northeast1. ou toute région dans laquelle Cloud Run (entièrement géré) est disponible.

En savoir plus :

• Emplacements Cloud Run (entièrement géré)
• Emplacements Cloud SQL
• Emplacements Cloud Storage

Créer un compte de service

Pour limiter l'accès du service à d'autres parties de Google Cloud, créez un compte de service dédié:

gcloud iam service-accounts create cloudrun-serviceaccount

Vous mentionnerez ce compte par son adresse e-mail dans les prochaines sections de cet atelier de programmation. Définissez cette valeur dans une variable d'environnement :

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

Créer un dépôt Artifact Registry

Pour stocker l'image de conteneur créée, créez un registre de conteneurs dans la région de votre choix :

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

Vous ferez référence à ce registre par nom dans les prochaines sections de cet atelier de programmation :

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

Créer la base de données

Créez une instance Cloud SQL :

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

Cette opération peut prendre quelques minutes.

Dans cette instance, créez une base de données:

gcloud sql databases create mydatabase --instance myinstance

Dans cette même instance, créez un utilisateur :

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

Accordez au compte de service l'autorisation de se connecter à l'instance :

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

Créer le bucket de stockage

Créez un bucket Cloud Storage (notant que le nom doit être unique) :

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

Accordez au compte de service les autorisations nécessaires pour administrer le bucket:

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

Étant donné que les objets stockés dans le bucket auront une origine différente (une URL de bucket et non une URL Cloud Run), vous devez configurer les paramètres de partage des ressources entre origines multiples (CORS).

Créez un fichier nommé cors.json avec le contenu suivant:

touch cors.json
cloudshell edit cors.json

cors.json

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

Appliquez cette configuration CORS au bucket de stockage nouvellement créé :

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

Stocker la configuration en tant que secret

Après avoir configuré les services de support, vous allez maintenant stocker ces valeurs dans un fichier protégé à l'aide de Secret Manager.

Secret Manager vous permet de stocker et de gérer des secrets sous forme de blobs binaires ou de chaînes de texte, ainsi que d'y accéder. Il est parfaitement adapté au stockage des informations de configuration telles que les mots de passe de base de données, les clés API ou les certificats TLS requis par une application lors de son exécution.

Commencez par créer un fichier contenant les valeurs de la chaîne de connexion à la base de données, du bucket multimédia, d'une clé secrète pour Django (utilisée pour la signature cryptographique des sessions et des jetons) et pour activer le débogage :

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

Créez ensuite un secret appelé application_settings en utilisant ce fichier comme secret:

gcloud secrets create application_settings --data-file .env

Autorisez le compte de service à accéder à ce secret:

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

Vérifiez que le secret a été créé en listant les secrets :

gcloud secrets versions list application_settings

Après avoir vérifié que le secret a été créé, supprimez le fichier local :

rm .env

6. Configurer votre application

Le projet de modèle que vous avez créé précédemment doit maintenant être modifié. Ces modifications réduiront la complexité des configurations des paramètres de modèle fournies avec Wagtail et intégreront Wagtail aux services de base que vous avez précédemment créés.

Configurer les paramètres

Recherchez le fichier de paramètres base.py généré et renommez-le basesettings.py dans le dossier myproject principal:

mv myproject/settings/base.py myproject/basesettings.py

À l'aide de l'éditeur Web Cloud Shell, créez un fichier settings.py avec le code suivant :

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

Prenez le temps de lire les commentaires ajoutés à chaque configuration.

Notez que vous pouvez voir des erreurs d'analyse lint sur ce fichier. Ce comportement est normal. Cloud Shell ne connaît pas le contexte des exigences de ce projet, et peut donc signaler des importations non valides et des importations inutilisées.

Supprimez ensuite l'ancien dossier de paramètres.

rm -rf myproject/settings/

Vous disposez alors de deux fichiers de paramètres : un provenant de Wagtail et un que vous venez de créer à partir de ces paramètres :

ls myproject/*settings*

myproject/basesettings.py  myproject/settings.py

Enfin, ouvrez le fichier de paramètres manage.py et mettez à jour la configuration pour indiquer à Wagtail de pointer vers le fichier settings.py principal.

cloudshell edit manage.py

Ligne management.py (avant)

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

Ligne "manage.py" (après)

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

Apportez la même modification de configuration au fichier myproject/wsgi.py :

cloudshell edit myproject/wsgi.py

Ligne myproject/wsgi.py (avant)

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

Ligne myproject/wsgi.py (après)

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

Supprimez le fichier Dockerfile créé automatiquement :

rm Dockerfile

Dépendances Python

Recherchez le fichier requirements.txt et ajoutez les packages suivants:

cloudshell edit requirements.txt

requirements.txt (ajout)

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

Définir l'image de votre application

Cloud Run exécute n'importe quel conteneur, à condition qu'il respecte le contrat relatif au conteneur Cloud Run. Dans ce tutoriel, nous avons choisi d'omettre un Dockerfile et d'utiliser à la place des buildpacks cloud natifs. Les buildpacks vous aident à créer des conteneurs pour les langages courants, y compris Python.

Dans ce tutoriel, nous allons personnaliser le Procfile utilisé pour démarrer l'application Web.

Pour conteneuriser le modèle de projet, commencez par créer un fichier nommé Procfile au premier niveau de votre projet (dans le même répertoire que manage.py), puis copiez le contenu suivant:

touch Procfile
cloudshell edit Procfile

Procfile

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

7. Configurer, compiler et exécuter les étapes de migration

Pour créer le schéma de base de données dans votre base de données Cloud SQL et renseigner votre bucket Cloud Storage avec vos composants statiques, vous devez exécuter migrate et collectstatic.

Ces commandes de migration Django de base doivent être exécutées dans le contexte de l'image de conteneur créée ayant accès à votre base de données.

Vous devrez également exécuter createsuperuser pour créer un compte administrateur permettant de vous connecter à l'administrateur Django.

Pour ce faire, vous allez utiliser des jobs Cloud Run. Les jobs Cloud Run vous permettent d'exécuter des processus ayant une fin définie, ce qui les rend parfaits pour les tâches d'administration.

Définir votre mot de passe de super-utilisateur Django

Pour créer le super-utilisateur, utilisez la version non interactive de la commande createsuperuser. Cette commande nécessite une variable d'environnement spécialement nommée à utiliser à la place d'une invite de saisie du mot de passe.

Créez un secret à l'aide d'un mot de passe généré de manière aléatoire :

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

Autorisez votre compte de service à accéder à ce secret :

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

Mettre à jour votre fichier Procfile

Pour clarifier vos tâches Cloud Run, créez des raccourcis dans votre fichier Procfile et ajoutez les points d'entrée suivants à Procfile :

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

Vous devriez maintenant avoir trois entrées : le point d'entrée web par défaut, le point d'entrée migrate pour appliquer les migrations de base de données et le point d'entrée createuser pour exécuter la commande createsuperuser.

Créer l'image de votre application

Une fois les mises à jour de Procfile en place, créez l'image:

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

Créer des tâches Cloud Run

Maintenant que l'image existe, vous pouvez créer des jobs Cloud Run à l'aide de celle-ci.

Ces tâches utilisent l'image précédemment créée, mais avec des valeurs command différentes. Elles sont mappées aux valeurs de Procfile.

Créez un job pour la 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

Créez une tâche pour la création de l'utilisateur :

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

Exécuter des tâches Cloud Run

Une fois les configurations de tâche en place, exécutez les migrations :

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

Assurez-vous que le résultat de la commande indique que l'exécution a bien abouti.

Vous exécuterez cette commande ultérieurement lorsque vous apporterez des modifications à votre application.

Une fois la base de données configurée, créez l'utilisateur à l'aide de la tâche:

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

Assurez-vous que le résultat de la commande indique que l'exécution a bien abouti.

Vous n'aurez pas besoin d'exécuter à nouveau cette commande.

8. Déployer dans Cloud Run

Une fois les services externes créés et renseignés, vous pouvez créer le service Cloud Run pour y accéder.

Le déploiement initial de votre application conteneurisée sur Cloud Run est créé à l'aide de la commande suivante:

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

Patientez quelques instants jusqu'à la fin du déploiement. En cas de réussite, la ligne de commande affiche l'URL du service :

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

Vous pouvez maintenant accéder au conteneur déployé en ouvrant cette URL dans un navigateur Web :

9. Accéder à l'interface administrateur Django

Mettre à jour les paramètres CSRF

Changement dans Django 4.0: la vérification de l'en-tête d'origine CSRF est désormais appliquée. Consultez la documentation Django.

Django inclut des protections contre la falsification de requête intersites (CSRF). Le paramètre "Trusted Origins" (Origines approuvées) est coché chaque fois qu'un formulaire est envoyé sur votre site Django, y compris lorsque vous vous connectez à l'administrateur Django. S'il ne correspond pas à l'origine de la requête, Django renvoie une erreur.

Dans le fichier mysite/settings.py, si la variable d'environnement CLOUDRUN_SERVICE_URL est définie, elle est utilisée dans les paramètres CSRF_TRUSTED_ORIGINS et ALLOWED_HOSTS. Bien que la définition de ALLOWED_HOSTS ne soit pas obligatoire, il est recommandé de l'ajouter, car il est déjà obligatoire pour CSRF_TRUSTED_ORIGINS.

Comme vous avez besoin de l'URL de votre service, vous ne pouvez ajouter cette configuration qu'après votre premier déploiement.

Vous devrez mettre à jour votre service pour ajouter cette variable d'environnement. Elle peut être ajoutée au secret application_settings ou directement en tant que variable d'environnement.

L'implémentation ci-dessous utilise la mise en forme et l'échappement gcloud.

Récupérez l'URL de votre service :

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

Définissez cette valeur en tant que variable d'environnement sur votre service Cloud Run :

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

Connexion à l'administrateur Django

Pour accéder à l'interface d'administration de Django, ajoutez /admin à l'URL de votre service.

Connectez-vous maintenant avec le nom d'utilisateur "admin". puis récupérez votre mot de passe à l'aide de la commande suivante:

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

10. Développer votre application

Lorsque vous développez votre application, vous devez la tester en local. Pour ce faire, vous devez vous connecter à votre base de données Cloud SQL ("production") ou à une base de données locale ("test").

Se connecter à votre base de données de production

Vous pouvez vous connecter à vos instances Cloud SQL à l'aide du proxy d'authentification Cloud SQL. Cette application crée une connexion entre votre ordinateur local et la base de données.

Une fois que vous avez installé le proxy d'authentification Cloud SQL, procédez comme suit:

# 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

Veillez à supprimer le fichier temp_settings après avoir terminé votre travail.

Se connecter à une base de données SQLite locale

Vous pouvez également utiliser une base de données locale lorsque vous développez votre application. Django est compatible avec les bases de données PostgreSQL et SQLite. PostgreSQL dispose de certaines fonctionnalités que SQLite ne propose pas, mais dans de nombreux cas, les fonctionnalités sont identiques.

Pour configurer SQLite, vous devez mettre à jour les paramètres de votre application pour qu'elle pointe vers une base de données locale, puis appliquer vos migrations de schéma.

Pour configurer cette méthode :

# 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

Veillez à supprimer le fichier temp_settings après avoir terminé votre travail.

Créer des migrations

Lorsque vous modifiez vos modèles de base de données, vous devrez peut-être générer les fichiers de migration de Django en exécutant python manage.py makemigrations.

Vous pouvez exécuter cette commande après avoir configuré la connexion à la base de données de production ou de test. Vous pouvez également générer les fichiers de migration sans base de données en définissant des paramètres vides:

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

Application des mises à jour de l'application...

Pour appliquer des modifications à votre application, vous devez :

• intégrer vos modifications dans une nouvelle image ;
• appliquer les migrations statiques ou de base de données, puis
• mettre à jour votre service Cloud Run pour qu'il utilise la nouvelle image.

Pour créer votre image :

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

Si vous avez des migrations à appliquer, exécutez le job Cloud Run:

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

Pour mettre à jour votre service avec la nouvelle image :

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

11. Félicitations !

Vous venez de déployer un projet complexe sur Cloud Run.

• Cloud Run effectue un scaling automatique et horizontal de votre image de conteneur pour traiter les requêtes reçues, puis un scaling à la baisse lorsque la demande diminue. Vous ne payez que pour le processeur, la mémoire et le réseau utilisés lors du traitement des requêtes.
• Cloud SQL vous permet de provisionner une instance PostgreSQL gérée qui est automatiquement gérée pour vous et qui s'intègre nativement à de nombreux systèmes Google Cloud.
• Cloud Storage vous offre un stockage cloud accessible de manière transparente dans Django.
• Secret Manager vous permet de stocker des secrets et de les rendre accessibles à certaines parties de Google Cloud, mais pas à d'autres.

Bien que ce bref atelier ait été réalisé à l'aide de la ligne de commande gcloud, Cloud Run est disponible via Cloud Console (console.cloud.google.com). Accédez simplement à Compute > Cloud Run. Votre service devrait s'afficher.

Nettoyage

Afin d'éviter la facturation sur votre compte Google Cloud Platform des ressources utilisées dans ce tutoriel, procédez comme suit :

• Dans la console Cloud, accédez à la page Gérer les ressources.
• Dans la liste des projets, sélectionnez votre projet, puis cliquez sur Supprimer.
• Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

En savoir plus

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

/