CMS Django su Cloud Run

1. Introduzione

Cloud Run è una piattaforma gestita di computing che consente di eseguire container stateless richiamabili tramite richieste HTTP. Cloud Run è serverless. Astrae completamente la gestione dell'infrastruttura per consentirti di concentrarti su quello che conta davvero: creare applicazioni fantastiche.

Inoltre, si interfaccia in modo nativo con molte altre parti dell'ecosistema Google Cloud, tra cui Cloud SQL per i database gestiti, Cloud Storage per l'archiviazione unificata degli oggetti e Secret Manager per la gestione dei secret.

Django CMS è un sistema di gestione dei contenuti (CMS) aziendale basato su Django. Django è un framework web Python di alto livello.

In questo tutorial utilizzerai questi componenti per eseguire il deployment di un piccolo progetto Django CMS.

Nota: questo codelab è stato verificato l'ultima volta con Django CMS 4.1.2 tramite django-cms/cms-template v4.1.

Cosa imparerai a fare

• Come utilizzare Cloud Shell
• Come creare un database Cloud SQL
• Come creare un bucket Cloud Storage
• Come creare secret di Secret Manager
• Come utilizzare i secret di diversi servizi Google Cloud
• Come connettere i componenti di Google Cloud a un servizio Cloud Run
• Come utilizzare Container Registry per archiviare i container creati
• Come eseguire il deployment in Cloud Run
• Come eseguire le migrazioni dello schema del database in Cloud Build

2. Configurazione e requisiti

Configurazione dell'ambiente autonomo

1. Accedi alla console Google Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai ancora un account Gmail o Google Workspace, devi crearne uno.

• Il nome del progetto è il nome visualizzato per i partecipanti a questo progetto. È una stringa di caratteri non utilizzata dalle API di Google. Puoi sempre aggiornarlo.
• L'ID progetto è univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo l'impostazione). La console Cloud genera automaticamente una stringa univoca, di solito non ti interessa di cosa si tratta. Nella maggior parte dei codelab, dovrai fare riferimento all'ID progetto (in genere identificato come PROJECT_ID). Se l'ID generato non ti piace, puoi generarne un altro casuale. In alternativa, puoi provare a crearne uno e vedere se è disponibile. Non può essere modificato dopo questo passaggio e rimane per tutta la durata del progetto.
• Per tua informazione, esiste un terzo valore, un numero di progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.

Attenzione:un ID progetto è univoco a livello globale e non può essere utilizzato da altri dopo che lo hai selezionato. Sei l'unico utente di questo ID. Anche se un progetto viene eliminato, l'ID non può essere riutilizzato

Nota:se utilizzi un account Gmail, puoi lasciare la posizione predefinita impostata su Nessuna organizzazione. Se utilizzi un account Google Workspace, scegli una posizione adatta alla tua organizzazione.

2. Successivamente, devi abilitare la fatturazione in Cloud Console per utilizzare le risorse/API Cloud. Completare questo codelab non costa molto, se non nulla. Per arrestare le risorse ed evitare addebiti oltre a quelli previsti in questo tutorial, puoi eliminare le risorse che hai creato o il progetto. I nuovi utenti di Google Cloud possono beneficiare del programma prova senza costi di 300$.

Google Cloud Shell

Sebbene Google Cloud possa essere gestito da remoto dal tuo laptop, in questo codelab utilizzeremo Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.

Attiva Cloud Shell

1. Nella console Cloud, fai clic su Attiva Cloud Shell .

Se è la prima volta che avvii Cloud Shell, viene visualizzata una schermata intermedia che ne descrive le funzionalità. Se è stata visualizzata una schermata intermedia, fai clic su Continua.

Bastano pochi istanti per eseguire il provisioning e connettersi a Cloud Shell.

Questa macchina virtuale è caricata con tutti gli strumenti di sviluppo necessari. Offre una home directory permanente da 5 GB e viene eseguita in Google Cloud, migliorando notevolmente le prestazioni e l'autenticazione della rete. Gran parte del lavoro per questo codelab, se non tutto, può essere svolto con un browser.

Una volta eseguita la connessione a Cloud Shell, dovresti vedere che il tuo account è autenticato e il progetto è impostato sul tuo ID progetto.

2. Esegui questo comando in Cloud Shell per verificare che l'account sia autenticato:

gcloud auth list

Output comando

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

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

Nota:lo strumento a riga di comando gcloud è il potente strumento a riga di comando unificato di Google Cloud. È già installato in Cloud Shell. Noterai il supporto del completamento automatico. Potrebbe esserti chiesto di autenticarti la prima volta che esegui un comando. Per saperne di più, consulta la panoramica dello strumento a riga di comando gcloud.

3. Esegui questo comando in Cloud Shell per verificare che il comando gcloud conosca il tuo progetto:

gcloud config list project

Output comando

[core]
project = <PROJECT_ID>

In caso contrario, puoi impostarlo con questo comando:

gcloud config set project <PROJECT_ID>

Output comando

Updated property [core/project].

Nota:se completi questo tutorial al di fuori di Cloud Shell, segui la procedura per configurare le credenziali predefinite dell'applicazione.

3. Abilita le API Cloud

Da Cloud Shell, abilita le API Cloud per i componenti che verranno utilizzati:

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

Poiché è la prima volta che chiami le API da gcloud, ti verrà chiesto di autorizzare l'utilizzo delle tue credenziali per effettuare questa richiesta. Questa operazione viene eseguita una volta per sessione di Cloud Shell.

Il completamento di questa operazione potrebbe richiedere alcuni istanti.

Al termine, dovrebbe essere visualizzato un messaggio di operazione riuscita simile a questo:

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

4. Creare un progetto modello

Utilizzerai cms-template di Django CMS come progetto Django CMS di esempio.

Per creare questo progetto modello, utilizza Cloud Shell per creare una nuova directory denominata djangocms-cloudrun e accedi alla directory:

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

Installa il pacchetto django-cms in un ambiente virtuale temporaneo:

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

Crea una copia del progetto cms-template:

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

Rinomina il file requirements.in in requirements.txt. Il file .in viene utilizzato da pip-tools per generare file requirements.txt, ma può essere utilizzato così com'è se l'estensione viene modificata. Nei passaggi successivi, pip prevede l'estensione .txt.)

mv requirements.in requirements.txt

Ora avrai un progetto Django CMS modello in una cartella denominata myproject:

ls -F

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

Ora puoi uscire e rimuovere l'ambiente virtuale temporaneo:

deactivate
rm -rf venv

Da qui, Django CMS verrà chiamato all'interno del container.

5. Crea i servizi di backend

Ora creerai i servizi di backend: un service account dedicato, un Artifact Registry, un database Cloud SQL, un bucket Cloud Storage e una serie di valori di Secret Manager.

Proteggere i valori delle password utilizzate nel deployment è importante per la sicurezza di qualsiasi progetto e garantisce che nessuno inserisca accidentalmente le password dove non devono essere (ad esempio, direttamente nei file di impostazioni o digitate direttamente nel terminale, dove potrebbero essere recuperate dalla cronologia).

Per iniziare, imposta due variabili di ambiente di base, una per l'ID progetto:

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

E uno per la regione:

REGION=us-central1

Quando lavori con l'infrastruttura, è utile avere tutti i componenti nella stessa posizione, in modo che possano comunicare tra loro in modo più efficiente. Sebbene alcuni componenti siano disponibili a livello globale, non tutti sono disponibili in tutte le regioni.

Per questo Codelab, ti consigliamo di utilizzare us-central1, europe-north1 o asia-northeast1 oppure qualsiasi regione in cui è supportato Cloud Run (completamente gestito).

Scopri di più:

• Località di Cloud Run (completamente gestito)
• Località Cloud SQL
• Località Cloud Storage

Creare un account di servizio

Per limitare l'accesso del servizio ad altre parti di Google Cloud, crea un service account dedicato:

gcloud iam service-accounts create cloudrun-serviceaccount

Farai riferimento a questo account tramite la sua email nelle sezioni successive di questo codelab. Imposta questo valore in una variabile di ambiente:

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

Crea un registro Artifact Registry

Per archiviare l'immagine container creata, crea un container registry nella regione che preferisci:

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

Farai riferimento a questo registro per nome nelle sezioni future di questo codelab:

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

Crea il database

Crea un'istanza Cloud SQL:

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

Il completamento dell'operazione potrebbe richiedere alcuni minuti.

In questa istanza, crea un database:

gcloud sql databases create mydatabase --instance myinstance

Nella stessa istanza, crea un utente:

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

Concedi all'account di servizio l'autorizzazione a connettersi all'istanza:

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

Crea il bucket di archiviazione

Crea un bucket Cloud Storage (il nome deve essere univoco a livello globale):

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

Concedi le autorizzazioni al service account per amministrare il bucket:

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

Poiché gli oggetti archiviati nel bucket avranno un'origine diversa (un URL del bucket anziché un URL Cloud Run), devi configurare le impostazioni di condivisione delle risorse tra origini (CORS).

Crea un nuovo file denominato cors.json con i seguenti contenuti:

touch cors.json
cloudshell edit cors.json

cors.json

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

Applica questa configurazione CORS al bucket di archiviazione appena creato:

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

Memorizza la configurazione come secret

Dopo aver configurato i servizi di backend, ora memorizzerai questi valori in un file protetto utilizzando Secret Manager.

Secret Manager ti consente di archiviare, gestire e accedere ai secret come blob binari o stringhe di testo. Funziona bene per archiviare informazioni relative alla configurazione, come password di database, chiavi API o certificati TLS richiesti da un'applicazione in fase di runtime.

Innanzitutto, crea un file con i valori per la stringa di connessione al database, il bucket multimediale, una chiave segreta per Django (utilizzata per la firma crittografica di sessioni e token) e per attivare il debug:

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

Poi, crea un secret denominato application_settings utilizzando questo file come secret:

gcloud secrets create application_settings --data-file .env

Consenti al service account di accedere a questo secret:

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

Conferma che il secret sia stato creato elencando i secret:

gcloud secrets versions list application_settings

Dopo aver confermato la creazione del secret, rimuovi il file locale:

rm .env

6. Configura la tua applicazione

Dato che hai appena creato i servizi di backend, dovrai apportare alcune modifiche al progetto modello per adattarlo.

Ciò includerà l'introduzione di django-environ per utilizzare le variabili di ambiente come impostazioni di configurazione, che inizializzerai con i valori definiti come secret. Per implementare questa funzionalità, estenderai le impostazioni del modello. Dovrai anche aggiungere dipendenze Python aggiuntive.

Configurare le impostazioni

Sposta il file settings.py rinominandolo in basesettings.py:

mv myproject/settings.py myproject/basesettings.py

Utilizzando l'editor web di Cloud Shell, crea un nuovo file settings.py con il seguente codice:

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

Prenditi il tempo di leggere il commento aggiunto su ogni configurazione.

Tieni presente che potresti visualizzare errori di linting in questo file. È previsto. Cloud Shell non ha il contesto dei requisiti per questo progetto e pertanto potrebbe segnalare importazioni non valide e importazioni inutilizzate.

Dipendenze Python

Individua il file requirements.txt e aggiungi i seguenti pacchetti:

cloudshell edit requirements.txt

requirements.txt (append)

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

Definisci l'immagine dell'applicazione

Cloud Run eseguirà qualsiasi container purché sia conforme al contratto del container Cloud Run. Questo tutorial sceglie di omettere un Dockerfile, ma utilizza invece Cloud Native Buildpacks. I buildpack aiutano a creare container per linguaggi comuni, tra cui Python.

Questo tutorial sceglie di personalizzare Procfile utilizzato per avviare l'applicazione web.

Per containerizzare il progetto modello, crea prima un nuovo file denominato Procfile nel livello superiore del progetto (nella stessa directory di manage.py) e copia il seguente contenuto:

touch Procfile
cloudshell edit Procfile

Procfile

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

7. Configura, crea ed esegui i passaggi di migrazione

Per creare lo schema del database nel database Cloud SQL e popolare il bucket Cloud Storage con gli asset statici, devi eseguire migrate e collectstatic.

Questi comandi di migrazione Django di base devono essere eseguiti nel contesto dell'immagine container creata con accesso al database.

Dovrai anche eseguire createsuperuser per creare un account amministratore per accedere all'amministrazione di Django.

Per farlo, utilizzerai Cloud Run Jobs per eseguire queste attività. I job Cloud Run consentono di eseguire processi con una fine definita, il che li rende ideali per le attività di amministrazione.

Definisci la password del superutente Django

Per creare il superutente, utilizzerai la versione non interattiva del comando createsuperuser. Questo comando richiede una variabile di ambiente con un nome specifico da utilizzare al posto di una richiesta di inserimento della password.

Crea un nuovo secret utilizzando una password generata in modo casuale:

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

Consenti al service account di accedere a questo secret:

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

Aggiornare il Procfile

Per migliorare la chiarezza dei job Cloud Run, crea scorciatoie nel Procfile, aggiungi i seguenti punti di ingresso a Procfile:

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

Ora dovresti avere tre voci: l'entry point web predefinito, l'entry point migrate per applicare le migrazioni del database e l'entry point createuser per eseguire il comando createsuperuser.

Creare l'immagine dell'applicazione

Con gli aggiornamenti del Procfile in posizione, crea l'immagine:

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

Crea job Cloud Run

Ora che l'immagine esiste, puoi creare job Cloud Run utilizzandola.

Questi job utilizzano l'immagine creata in precedenza, ma valori command diversi. Questi valori sono mappati ai valori in Procfile.

Crea un job per la migrazione:

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

Crea un job per la creazione dell'utente:

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

Esegui job Cloud Run

Con le configurazioni dei job in posizione, esegui le migrazioni:

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

Assicurati che l'output del comando indichi che l'esecuzione è stata "completata correttamente".

Esegui questo comando in un secondo momento quando apporti aggiornamenti alla tua applicazione.

Con la configurazione del database, crea l'utente utilizzando il job:

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

Assicurati che l'output del comando indichi che l'esecuzione è stata "completata correttamente".

Non dovrai eseguire di nuovo questo comando.

8. Esegui il deployment in Cloud Run

Ora che i servizi di backend sono stati creati e compilati, puoi creare il servizio Cloud Run per accedervi.

Il deployment iniziale dell'applicazione containerizzata su Cloud Run viene creato utilizzando questo comando:

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

Attendi qualche istante fino al completamento del deployment. Se l'operazione riesce, la riga di comando visualizza l'URL del servizio:

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

Ora puoi visitare il container di cui hai eseguito il deployment aprendo questo URL in un browser web:

Poiché si tratta di una nuova installazione, verrà eseguito automaticamente il reindirizzamento alla pagina di accesso.

9. Accedere all'amministrazione di Django

Una delle funzionalità principali di Django CMS è la sua amministrazione interattiva.

Aggiornamento delle impostazioni CSRF

Modifica in Django 4.0: ora viene applicato il controllo dell'intestazione di origine CSRF. Consulta la documentazione di Django.

Django include protezioni contro Cross-Site Request Forgery (CSRF). Ogni volta che viene inviato un modulo sul tuo sito Django, incluso l'accesso alla pagina di amministrazione di Django, viene controllata l'impostazione Origini attendibili. Se non corrisponde all'origine della richiesta, Django restituisce un errore.

Nel file mysite/settings.py, se è definita la variabile di ambiente CLOUDRUN_SERVICE_URL, questa viene utilizzata nelle impostazioni CSRF_TRUSTED_ORIGINS e ALLOWED_HOSTS. Sebbene la definizione di ALLOWED_HOSTS non sia obbligatoria, è buona norma aggiungerla, in quanto è già richiesta per CSRF_TRUSTED_ORIGINS.

Poiché è necessario l'URL del servizio, questa configurazione non può essere aggiunta prima del primo deployment.

Per aggiungere questa variabile di ambiente, devi aggiornare il servizio. Può essere aggiunto al secret application_settings o direttamente come variabile di ambiente.

L'implementazione riportata di seguito sfrutta la formattazione e l'escape di gcloud.

Recupera l'URL del servizio:

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

Imposta questo valore come variabile di ambiente nel servizio Cloud Run:

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

Accedere all'amministrazione di Django

Per accedere all'interfaccia di amministrazione di Django, aggiungi /admin all'URL del servizio.

Ora accedi con il nome utente "admin" e recupera la password utilizzando il seguente comando:

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

10. Applicazione degli aggiornamenti dell'applicazione

Durante lo sviluppo dell'applicazione, ti consigliamo di testarla localmente. Per farlo, devi connetterti al database Cloud SQL ("produzione") o a un database locale ("test").

Connettersi al database di produzione

Puoi connetterti alle istanze Cloud SQL utilizzando il proxy di autenticazione Cloud SQL. Questa applicazione crea una connessione dalla tua macchina locale al database.

Dopo aver installato il proxy di autenticazione Cloud SQL, segui questi passaggi:

# 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

Assicurati di rimuovere il file temp_settings al termine del lavoro.

Connettersi a un database SQLite locale

In alternativa, puoi utilizzare un database locale durante lo sviluppo dell'applicazione. Django supporta i database PostgreSQL e SQLite e alcune funzionalità di PostgreSQL non sono disponibili in SQLite, ma in molti casi la funzionalità è identica.

Per configurare SQLite, devi aggiornare le impostazioni dell'applicazione in modo che puntino a un database locale e poi devi applicare le migrazioni dello schema.

Per configurare questo metodo:

# 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

Assicurati di rimuovere il file temp_settings al termine del lavoro.

Migrazioni in fase di creazione

Quando apporti modifiche ai modelli di database, potresti dover generare i file di migrazione di Django eseguendo python manage.py makemigrations.

Puoi eseguire questo comando dopo aver configurato la connessione al database di produzione o di test. In alternativa, puoi generare i file di migrazione senza un database fornendo impostazioni vuote:

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

Applicazione degli aggiornamenti dell'applicazione

Per applicare le modifiche alla tua richiesta, devi:

• incorporare le modifiche in una nuova immagine,
• applica eventuali migrazioni statiche o di database, quindi
• aggiorna il servizio Cloud Run in modo da utilizzare la nuova immagine.

Per creare l'immagine:

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

Se hai migrazioni da applicare, esegui il job Cloud Run:

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

Per aggiornare il servizio con la nuova immagine:

gcloud run services update djangocms-cloudrun \
  --platform managed \
  --region $REGION \
  --image gcr.io/${PROJECT_ID}/myimage

11. Complimenti!

Hai eseguito il deployment di un progetto complesso su Cloud Run.

• Cloud Run scala automaticamente e orizzontalmente l'immagine container per gestire le richieste ricevute, quindi fa lo scale down quando la domanda diminuisce. Paghi solo per la CPU, la memoria e le risorse di rete utilizzate durante la gestione delle richieste.
• Cloud SQL consente di eseguire il provisioning di un'istanza PostgreSQL gestita che viene gestita automaticamente e si integra in modo nativo in molti sistemi Google Cloud.
• Cloud Storage ti consente di avere spazio di archiviazione cloud in modo da poter accedere facilmente a Django.
• Secret Manager ti consente di archiviare i secret e di renderli accessibili a determinate parti di Google Cloud e non ad altre.

Anche se questo breve lab è stato eseguito utilizzando la riga di comando gcloud, Cloud Run è disponibile tramite la console Cloud ( console.cloud.google.com). Basta andare su Compute > Cloud Run e dovresti vedere il tuo servizio elencato.

Pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial:

• In Cloud Console, vai alla pagina Gestisci risorse.
• Nell'elenco dei progetti, seleziona il tuo progetto e poi fai clic su Elimina.
• Nella finestra di dialogo, digita l'ID progetto, quindi fai clic su Chiudi per eliminare il progetto.

Scopri di più

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