Informazioni su questo codelab
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 di oggetti e Secret Manager per la gestione dei secret.
Django CMS è un sistema di gestione dei contenuti aziendali (CMS) 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 CMS Django.
Nota: questo codelab è stato verificato l'ultima volta con Django CMS 3.11.4 tramite django-cms/cms-template v3.11.
Cosa imparerai a fare
- Come utilizzare Cloud Shell
- Creare un database Cloud SQL
- Creare un bucket Cloud Storage
- Come creare secret di Secret Manager
- Come utilizzare i secret da diversi servizi Google Cloud
- Come connettere i componenti Google Cloud a un servizio Cloud Run
- Utilizzare Container Registry per archiviare i container creati
- Eseguire il deployment in Cloud Run
- Come eseguire migrazioni degli schemi dei database in Cloud Build
2. Configurazione e requisiti
Configurazione dell'ambiente da seguire in modo autonomo
- 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 progetto è il nome visualizzato dei partecipanti del progetto. Si tratta di una stringa di caratteri non utilizzata dalle API di Google. Puoi sempre aggiornarla.
- L'ID progetto è univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo essere stato impostato). La console Cloud genera automaticamente una stringa univoca. di solito non ti importa cosa sia. Nella maggior parte dei codelab, dovrai fare riferimento al tuo ID progetto (in genere identificato come
PROJECT_ID
). Se l'ID generato non ti soddisfa, potresti generarne un altro casuale. In alternativa, puoi provarne una personalizzata per verificare se è disponibile. Non può essere modificato dopo questo passaggio e rimane per tutta la durata del progetto. - Per informazione, c'è un terzo valore, un numero di progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.
- Successivamente, dovrai abilitare la fatturazione nella console Cloud per utilizzare risorse/API Cloud. L'esecuzione di questo codelab non ha alcun costo. Per arrestare le risorse ed evitare di incorrere in fatturazione dopo questo tutorial, puoi eliminare le risorse che hai creato o eliminare il progetto. I nuovi utenti di Google Cloud sono idonei al programma prova senza costi di 300$.
Google Cloud Shell
Anche se Google Cloud può essere utilizzato 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
- Dalla console Cloud, fai clic su Attiva Cloud Shell
.
Se è la prima volta che avvii Cloud Shell, ti verrà mostrata una schermata intermedia che descrive di cosa si tratta. Se ti è stata presentata una schermata intermedia, fai clic su Continua.
Il provisioning e la connessione a Cloud Shell dovrebbero richiedere solo qualche istante.
Questa macchina virtuale viene 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 di rete e l'autenticazione. Gran parte, se non tutto, del lavoro in questo codelab può essere svolto con un browser.
Una volta stabilita la connessione a Cloud Shell, dovresti vedere che hai eseguito l'autenticazione e che il progetto è impostato sul tuo ID progetto.
- 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`
- Esegui questo comando in Cloud Shell per confermare che il comando gcloud è a conoscenza del 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].
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 verrà eseguita una volta per sessione di Cloud Shell.
Questa operazione potrebbe richiedere alcuni istanti.
Al termine dell'operazione, dovrebbe essere visualizzato un messaggio di operazione riuscita simile a questo:
Operation "operations/acf.cc11852d-40af-47ad-9d59-477a12847c9e" finished successfully.
4. Crea un progetto modello
Utilizzerai il CMS Django cms-template come progetto Django CMS di esempio.
Per creare questo progetto modello, usa Cloud Shell per creare una nuova directory denominata djangocms-cloudrun
e vai 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-3]
Crea una copia del progetto cms-template:
django-admin startproject --template https://github.com/django-cms/cms-template/archive/3.11.zip myproject .
Ora avrai un modello di progetto CMS Django in una cartella chiamata myproject
:
ls -F
manage.py* media/ myproject/ project.db requirements.in requirements.txt static/ venv/
Ora puoi uscire e rimuovere l'ambiente virtuale temporaneo:
deactivate rm -rf venv
Da qui, il CMS Django verrà chiamato all'interno del container.
Puoi anche rimuovere il file requirements.in copiato automaticamente (utilizzato da pip-tools per generare file requirements.txt). Non verrà utilizzato per questo codelab:
rm requirements.in
5. crea i servizi di supporto
Ora creerai i tuoi servizi di supporto: un account di servizio dedicato, un Artifact Registry, un database Cloud SQL, un bucket Cloud Storage e una serie di valori di Secret Manager.
La protezione dei valori delle password utilizzate durante l'implementazione è importante per la sicurezza di qualsiasi progetto e garantisce che nessuno inserisca per sbaglio le password dove non appartengono (ad esempio direttamente nei file delle impostazioni o direttamente nel terminale per recuperarle 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
Creare un account di servizio
Per limitare l'accesso che il servizio avrà ad altre parti di Google Cloud, crea un account di servizio dedicato:
gcloud iam service-accounts create cloudrun-serviceaccount
Nelle sezioni future di questo codelab, farai riferimento a questo account tramite la relativa email. Imposta quel valore in una variabile di ambiente:
SERVICE_ACCOUNT=$(gcloud iam service-accounts list \ --filter cloudrun-serviceaccount --format "value(email)")
Crea un Artifact Registry
Per archiviare l'immagine container creata, crea un Container Registry nella regione scelta:
gcloud artifacts repositories create containers --repository-format docker --location $REGION
Nelle sezioni future di questo codelab farai riferimento a questo registro per nome:
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
Questa operazione potrebbe richiedere alcuni minuti.
In questo caso, 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 per 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 all'account di servizio le autorizzazioni 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 hanno un'origine diversa (un URL del bucket anziché un URL di Cloud Run), devi configurare le impostazioni di condivisione delle risorse tra origini (CORS).
Crea un nuovo file denominato cors.json
, con il seguente contenuto:
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
Archivia la configurazione come secret
Dopo aver configurato i servizi di supporto, archivierai questi valori in un file protetto con Secret Manager.
Secret Manager consente di archiviare, gestire e accedere ai secret come BLOB binari o stringhe di testo. È ideale per archiviare informazioni di configurazione quali password dei database, chiavi API o certificati TLS necessari per un'applicazione in fase di runtime.
Innanzitutto, crea un file con i valori per la stringa di connessione del database, il bucket multimediale, una chiave segreta per Django (utilizzata per la firma crittografica di sessioni e token) e per abilitare 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
Quindi, crea un secret denominato application_settings
utilizzando tale file come secret:
gcloud secrets create application_settings --data-file .env
Consenti all'account di servizio di accedere a questo secret:
gcloud secrets add-iam-policy-binding application_settings \ --member serviceAccount:${SERVICE_ACCOUNT} --role roles/secretmanager.secretAccessor
Verifica che il secret sia stato creato elencando i secret:
gcloud secrets versions list application_settings
Dopo aver confermato che il secret è stato creato, rimuovi il file locale:
rm .env
6. Configura la tua applicazione
Dati i servizi di supporto appena creati, dovrai apportare alcune modifiche al progetto del modello di conseguenza.
Ciò includerà l'introduzione di django-environ
per utilizzare le variabili di ambiente come impostazioni di configurazione, che verranno disinserite con i valori definiti come secret. Per implementarlo, estenderai le impostazioni del modello. Dovrai anche aggiungere ulteriori dipendenze Python.
Configurare le impostazioni
Sposta il file settings.py
rinominandolo basesettings.py:
mv myproject/settings.py myproject/basesettings.py
Utilizzando l'editor web di Cloud Shell, crea un nuovo file settings.py, con il codice seguente:
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"
Prenditi il tempo necessario per leggere i commenti aggiunti su ogni configurazione.
Tieni presente che potresti riscontrare errori di analisi tramite lint in questo file. È un comportamento previsto. Cloud Shell non dispone del contesto dei requisiti per questo progetto, pertanto potrebbe segnalare importazioni non valide e inutilizzate.
Dipendenze Python
Individua il file requirements.txt
e aggiungi i seguenti pacchetti:
cloudshell edit requirements.txt
requirements.txt (aggiunta)
gunicorn psycopg2-binary django-storages[google] django-environ
Definire l'immagine dell'applicazione
Cloud Run eseguirà qualsiasi container, a condizione che sia conforme al Contratto relativo ai container di Cloud Run. Questo tutorial sceglie di omettere un Dockerfile
, ma utilizza invece Buildpacks Cloud Native. I Buildpack aiutano a creare container per i linguaggi più comuni, incluso Python.
Questo tutorial sceglie di personalizzare il Procfile utilizzato per avviare l'applicazione web.
Per containerizzare il progetto di modello, crea prima un nuovo file denominato Procfile
nel livello superiore del progetto (nella stessa directory di manage.py
) e copia i seguenti contenuti:
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 della migrazione
Per creare lo schema del database nel database Cloud SQL e completare il bucket Cloud Storage con gli asset statici, devi eseguire migrate
e collectstatic
.
Questi comandi di migrazione di base di Django 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'amministratore di Django.
Per farlo, utilizzerai i job Cloud Run per eseguire queste attività. I job Cloud Run ti consentono di eseguire processi che hanno un finale definito, rendendoli ideali per le attività di amministrazione.
Definire la password del super user Django
Per creare il super user, utilizzerai la versione non interattiva del comando createsuperuser
. Questo comando richiede una variabile di ambiente appositamente denominata da utilizzare al posto della 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 tuo account di servizio di accedere a questo secret:
gcloud secrets add-iam-policy-binding django_superuser_password \ --member serviceAccount:${SERVICE_ACCOUNT} \ --role roles/secretmanager.secretAccessor
Aggiornare il tuo Procfile
Per rendere più chiari i job Cloud Run, crea scorciatoie in Procfile e 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 noop@example.com --noinput
A questo punto dovresti avere tre voci: l'entry point predefinito sul web, migrate
per applicare le migrazioni del database e createuser
per eseguire il comando createsuperuser
.
Immagine della creazione dell'applicazione
Dopo aver applicato gli aggiornamenti a Procfile, crea l'immagine:
gcloud builds submit --pack image=${ARTIFACT_REGISTRY}/myimage
Crea job Cloud Run
Ora che l'immagine esiste, puoi utilizzarla per creare job Cloud Run.
Questi job utilizzano l'immagine creata in precedenza, ma valori command
diversi. Queste vengono mappate ai valori all'interno di 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
Eseguire i job di Cloud Run
Una volta definite le configurazioni del job, esegui le migrazioni:
gcloud run jobs execute migrate --region $REGION --wait
Assicurati che l'output comando indichi che l'esecuzione è "completata".
Eseguirai questo comando in un secondo momento, quando effettuerai gli aggiornamenti dell'applicazione.
Dopo aver configurato il database, crea l'utente utilizzando il job:
gcloud run jobs execute createuser --region $REGION --wait
Assicurati che l'output comando indichi che l'esecuzione è "completata".
Non dovrai eseguire di nuovo questo comando.
8. Esegui il deployment in Cloud Run
Dopo aver creato e completato i servizi di supporto, ora puoi creare il servizio Cloud Run per accedervi.
Il deployment iniziale della tua applicazione containerizzata su Cloud Run viene creato utilizzando il seguente comando:
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
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-...-uc.a.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, il sistema ti reindirizzerà automaticamente alla pagina di accesso.
9. Accesso all'amministratore Django
Una delle funzionalità principali del CMS Django è l'amministrazione interattiva.
Aggiornamento delle impostazioni CSRF
Django include protezioni contro la falsificazione delle richieste cross-site (CSRF). Ogni volta che viene inviato un modulo sul tuo sito Django, incluso l'accesso all'amministratore di Django, viene selezionata l'impostazione Trusted Origins. 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
, viene utilizzata nelle impostazioni di CSRF_TRUSTED_ORIGINS
e ALLOWED_HOSTS
. La definizione di ALLOWED_HOSTS
non è obbligatoria, ma è buona norma aggiungerla, poiché è già obbligatoria per CSRF_TRUSTED_ORIGINS
.
Poiché hai bisogno dell'URL del servizio, questa configurazione non può essere aggiunta fino al primo deployment.
Dovrai aggiornare il servizio per aggiungere questa variabile di ambiente. Potrebbe essere aggiunto al secret application_settings oppure direttamente come variabile di ambiente.
Recupera l'URL del tuo servizio:
CLOUDRUN_SERVICE_URL=$(gcloud run services describe djangocms-cloudrun \ --platform managed \ --region $REGION \ --format "value(status.url)") echo $CLOUDRUN_SERVICE_URL
Imposta questo valore come variabile di ambiente sul servizio Cloud Run:
gcloud run services update djangocms-cloudrun \ --region $REGION \ --update-env-vars CLOUDRUN_SERVICE_URL=$CLOUDRUN_SERVICE_URL
Accedere all'amministratore Django
Per accedere all'interfaccia di amministrazione di Django, aggiungi /admin all'URL del tuo 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 aggiornamenti delle applicazioni
Durante lo sviluppo dell'applicazione, vorrai testarla localmente. Per farlo, devi connetterti al tuo database Cloud SQL ("produzione") o a un database locale ("test").
Connettiti al tuo database di produzione
Puoi connetterti alle tue istanze Cloud SQL utilizzando il proxy di autenticazione Cloud SQL. Questa applicazione crea una connessione dalla 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 --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
Assicurati di rimuovere il file temp_settings
al termine del lavoro.
Connettiti a un database SQLite locale
In alternativa, puoi utilizzare un database locale durante lo sviluppo dell'applicazione. Django supporta sia i database PostgreSQL che SQLite e, in molti casi, SQLite offre alcune funzionalità che non sono disponibili, ma in molti casi la funzionalità è identica.
Per configurare SQLite, devi aggiornare le impostazioni dell'applicazione, in modo che punti a un database locale, quindi applicare le migrazioni degli schemi.
Per impostare 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 del tuo database, potrebbe essere necessario 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 assegnando impostazioni vuote:
SECRET_KEY="" DATABASE_URL="" GS_BUCKET_NAME="" python manage.py makemigrations
Applicazione aggiornamenti delle applicazioni
Per applicare le modifiche alla tua applicazione, devi:
- creare le modifiche in una nuova immagine,
- applicare migrazioni statiche o di database
- aggiornare il servizio Cloud Run per 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 appena eseguito il deployment di un progetto complesso in 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 il networking utilizzati durante la gestione delle richieste.
- Cloud SQL ti consente di eseguire il provisioning di un'istanza PostgreSQL gestita che viene mantenuta automaticamente e si integra in modo nativo in molti sistemi Google Cloud.
- Cloud Storage ti offre spazio di archiviazione sul cloud in un modo facilmente accessibile in Django.
- Secret Manager ti consente di archiviare i secret e di renderli accessibili da determinate parti di Google Cloud e non ad altre.
Pulizia
Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial:
- Nella console Cloud, vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona il progetto e fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID progetto e fai clic su Chiudi per eliminare il progetto.
Scopri di più
- Django su Cloud Run: https://cloud.google.com/python/django/run
- Introduzione a 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 di Google Cloud: https://github.com/googleapis/google-cloud-python