Testa ed esegui il deployment dell'applicazione

ID regione

Il REGION_ID è un codice abbreviato che Google assegna in base alla regione selezionata quando crei l'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono sembrare simili ai codici di paesi e province di uso comune. Per le app create dopo febbraio 2020, REGION_ID.r è incluso negli URL App Engine. Per le app esistenti create prima di questa data, l'ID regione è facoltativo nell'URL.

Scopri di più sugli ID regione.

Ok

Go Java Node.js PHP Python Ruby

Scopri come eseguire la tua applicazione localmente, come eseguirne il deployment e come testarla in App Engine.

Esegui localmente

Per testare l'applicazione prima del deployment, esegui l'applicazione nel tuo ambiente locale con gli strumenti di sviluppo che utilizzi di solito. Ti consigliamo di utilizzare strumenti Python standard, come virtualenv per creare ambienti isolati e pytest per eseguire test unitari e di integrazione, anziché fare affidamento su dev_appserver, il server di sviluppo locale fornito con Google Cloud SDK.

Ad esempio, in genere puoi eseguire un'applicazione Flask con il server di sviluppo Flask utilizzando:

python main.py

Avvia le applicazioni Django utilizzando:

python manage.py runserver

Per simulare un ambiente di produzione App Engine, esegui localmente il server Web Server Gateway Interface (WSGI). Utilizza lo stesso comando specificato come punto di ingresso nel file app.yaml, ad esempio:

gunicorn -b :$PORT main:app

Prima di eseguire il deployment dell'applicazione

Prima di eseguire il deployment dell'applicazione:

• Il proprietario del progetto Google Cloud deve configurare il progetto Google Cloud per App Engine.
• Assicurati che il tuo account utente includa i privilegi richiesti.

Esegui il deployment dell'applicazione

Esegui il deployment dell'applicazione in App Engine utilizzando il comando gcloud app deploy. Durante il deployment, il servizio Cloud Build crea un'immagine container della tua applicazione da eseguire nell'ambiente standard. Ogni build viene eseguita nella stessa regione del tuo progetto Google Cloud . Per saperne di più, consulta Gestire le immagini di build.

Per eseguire il deployment delle tue app in modo programmatico, utilizza l'API Admin.

Esegui il deployment di un servizio

Esegui il deployment dell'applicazione su App Engine eseguendo il deployment delle versioni dei servizi dell'applicazione e di ciascuno dei relativi file di configurazione.

Per eseguire il deployment di una versione del servizio della tua applicazione, esegui questo comando dalla directory in cui si trova il file app.yaml del servizio:

gcloud app deploy

Se non specifichi alcun file con il comando, viene eseguito il deployment solo del file app.yaml nella directory corrente. Per impostazione predefinita, il comando deploy genera un ID univoco per la versione di cui esegui il deployment, esegue il deployment della versione nel progettoGoogle Cloud che hai configurato per l'utilizzo di Google Cloud CLI e indirizza tutto il traffico alla nuova versione.

Puoi modificare il comportamento predefinito del comando scegliendo come target file specifici o includendo parametri aggiuntivi:

• Per eseguire il deployment degli altri file di configurazione del servizio, devi scegliere come target ed eseguire il deployment di ogni file separatamente. Ad esempio:

  gcloud app deploy cron.yaml
  gcloud app deploy dispatch.yaml
  gcloud app deploy index.yaml

• Per specificare un ID versione personalizzato, utilizza il flag --version.
• Per impedire che il traffico venga indirizzato automaticamente alla nuova versione, utilizza il flag --no-promote.
• Per eseguire il deployment in un progetto Google Cloud specifico, utilizza il flag --project.

Ad esempio, per eseguire il deployment del servizio definito dal file app.yaml in un progettoGoogle Cloud specifico, assegnagli un ID versione personalizzato e impedisci il routing del traffico alla nuova versione:

gcloud app deploy --project PROJECT_ID --version VERSION_ID --no-promote

Per ulteriori informazioni su questo comando, consulta il gcloud app deploy riferimento.

Nota: puoi impostare le proprietà per Google Cloud CLI e creare e gestire configurazioni SDK in modo da non dover specificare flag come --project ogni volta che esegui il deployment.

Quando esegui il deployment di una nuova versione con lo stesso nome di una versione esistente, App Engine esegue immediatamente la migrazione del traffico alla nuova versione. Si verifica un picco di latenza quando App Engine carica le richieste nella nuova versione. La nuova versione sovrascrive quella precedente e non potrai eseguire la migrazione del traffico alla versione precedente. Tutte le istanze della versione precedente vengono immediatamente arrestate. Per maggiori informazioni, consulta la sezione Eseguire la migrazione del traffico.

Esegui il deployment di più servizi

Utilizzi lo stesso comando di deployment per eseguire il deployment o l'aggiornamento dei più servizi che compongono la tua applicazione.

Prima di iniziare:

• Devi inizialmente eseguire il deployment di una versione dell'applicazione nel servizio default prima di poter creare ed eseguire il deployment dei servizi successivi.
• L'ID di ciascun servizio deve essere specificato nei file di configurazione app.yaml corrispondenti. Per specificare l'ID servizio, includi la definizione dell'elemento service in ogni file di configurazione. Per impostazione predefinita, l'esclusione di questa definizione di elemento dal file di configurazione esegue il deployment della versione nel servizio default.

Per eseguire il deployment di più servizi, esegui il deployment separato del file app.yaml di ciascun servizio. Puoi specificare più file con un singolo comando gcloud app deploy:

gcloud app deploy service1/app.yaml service2/app.yaml

Visualizza i log di build

Cloud Build trasmette in streaming i log di compilazione e deployment visualizzabili nella sezione Cronologia build di Cloud Build della console Google Cloud . Per visualizzare le build nella regione dell'app, utilizza il menu Regione per filtrare in base alla regione.

Gestire le immagini di build

Attenzione: Container Registry è stato ritirato. A partire dal 18 marzo 2025, Container Registry è stato chiuso e la scrittura di immagini in Container Registry non è disponibile. Per dettagli sul ritiro e su come eseguire la migrazione ad Artifact Registry, consulta Ritiro di Container Registry.

Ogni volta che esegui il deployment di una nuova versione:

1. App Engine crea un'immagine container utilizzando il servizio Cloud Build.

2. Cloud Build crea l'immagine container nella regione dell'app e viene eseguito nell'ambiente standard di App Engine.

3. App Engine archivia le immagini container create in Artifact Registry. Puoi scaricare queste immagini per conservarle o utilizzarle altrove.

Al termine del deployment, App Engine non ha più bisogno delle immagini container. Le immagini container non vengono eliminate automaticamente. Per evitare di raggiungere la quota di spazio di archiviazione, puoi eliminare in sicurezza le immagini che non ti servono. Tuttavia, se potresti aver bisogno delle immagini in futuro o vuoi conservarne una copia, devi esportarne una prima dell'eliminazione. Per ulteriori informazioni sulla gestione delle immagini in Artifact Registry, consulta Gestire le immagini.

Ignorare i file

Puoi utilizzare un file .gcloudignore per specificare i file e le directory che non verranno caricati su App Engine quando esegui il deployment dei servizi. Questo è utile per ignorare gli artefatti di build e altri file che non devono essere caricati con la distribuzione.

Nota: non puoi specificare il campo skip_files nel file app.yaml se hai un file .gcloudignore.

visualizza l'applicazione

Dopo aver eseguito il deployment dell'applicazione in App Engine, puoi eseguire il comando seguente per avviare il browser e visualizzarla all'indirizzo https://PROJECT_ID.REGION_ID.r.appspot.com:

gcloud app browse

Testare su App Engine prima di spostare il traffico

Prima di configurare una nuova versione per ricevere traffico, puoi testarla su App Engine. Ad esempio, per testare una nuova versione del servizio default:

1. Esegui il deployment della nuova versione, ma impedisci che il traffico venga indirizzato automaticamente alla nuova versione:

   gcloud app deploy --no-promote

2. Accedi alla nuova versione andando al seguente URL:

   https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

   Nota :puoi trovare l'ID versione nella consoleGoogle Cloud o specificarne uno quando esegui il deployment con --version flag. Google Cloud CLI restituisce anche l'ID versione durante il deployment.

   Ora puoi testare la nuova versione nell'ambiente di runtime di App Engine. Puoi eseguire il debug dell'applicazione visualizzando i relativi log. Per ulteriori informazioni, consulta Scrittura dei log delle applicazioni.

   App Engine indirizza le richieste inviate a https://PROJECT_ID.REGION_ID.r.appspot.com alla versione precedentemente configurata per ricevere traffico.

3. Quando vuoi inviare traffico alla nuova versione, utilizza la consoleGoogle Cloud per eseguire la migrazione del traffico:

   Gestisci le versioni

   Seleziona la versione appena implementata e fai clic su Esegui la migrazione del traffico.

Puoi utilizzare la stessa procedura per testare nuove versioni di altri servizi sostituendo default nell'URL con il nome del servizio:

https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

Per saperne di più sul targeting di servizi e versioni specifici, consulta la sezione Come vengono instradate le richieste.

Utilizzare le variabili di ambiente di build

Puoi impostare le variabili di ambiente di build per i runtime che supportano i buildpack.

Le variabili di ambiente di build sono coppie chiave-valore che puoi specificare per configurare il buildpack che utilizzi per il deployment dell'app. Ad esempio, potresti voler specificare le opzioni del compilatore.

Prima di iniziare:

• Le chiavi devono iniziare con una lettera ASCII maiuscola e possono includere lettere ASCII maiuscole, cifre e trattini bassi.
• Evita di creare variabili con un prefisso della chiave GOOGLE_*.
• Le seguenti chiavi sono riservate all'utilizzo da parte di Google:
  • GOOGLE_RUNTIME
  • GOOGLE_RUNTIME_VERSION
  • GOOGLE_ENTRYPOINT
  • GOOGLE_DEVMODE
• Puoi utilizzare qualsiasi chiave supportata dai buildpack.

Per utilizzare le variabili di ambiente con i buildpack, specifica il campo build_env_variables nel file app.yaml.

Scopri di più sui buildpack.

Utilizzare il server di sviluppo locale

Google Cloud CLI include un server di sviluppo locale denominato dev_appserver che puoi eseguire localmente per simulare l'esecuzione della tua applicazione nell'ambiente di produzione App Engine. Questo server di sviluppo simula parzialmente l'ambiente in cui viene eseguita l'applicazione, consentendoti di testare le app scritte per uno qualsiasi dei runtime dell'ambiente standard.

Esegui il server di sviluppo locale

Importante: prima di eseguire il server di sviluppo locale, segui le istruzioni di configurazione.

Dopo aver creato il file di configurazione app.yaml per la tua app, puoi avviare il server di sviluppo locale con il comando dev_appserver.py per eseguire l'app localmente.

1. Per ottenere le credenziali di accesso per il tuo account utente, esegui:

   gcloud auth login
   

2. Consenti alla tua applicazione locale di utilizzare temporaneamente le tue credenziali utente per l'accesso all'API:

   gcloud auth application-default login
   

3. Per avviare il server di sviluppo locale:

   Nella directory contenente il file di configurazione app.yaml, esegui il comando dev_appserver.py e specifica l'ID progetto e il percorso del file app.yaml:

   python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --application=PROJECT_ID app.yaml

   Per modificare la porta, includi l'opzione --port:

   python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --application=PROJECT_ID app.yaml --port=9999

   Per testare un'app Python 3, esegui dev_appserver.py con un interprete Python 3. Devi specificare il binario Python 3 nel flag --runtime_python_path, ad esempio:

   python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --runtime_python_path=/usr/bin/python3 --application=PROJECT_ID app.yaml --port=9999

   Per scoprire di più sulle opzioni del comando dev_appserver.py, consulta Opzioni del server di sviluppo locale.

4. Quando il server di sviluppo locale viene avviato, configura un ambiente di sviluppo che preinstalla le dipendenze trovate nel file requirements.txt.

5. Ora il server di sviluppo locale è in esecuzione e rimane in attesa delle richieste. Visita http://localhost:8080/ nel browser web per vedere l'app in azione.

   Se hai specificato una porta personalizzata con l'opzione --port, ricordati di aprire il browser su quella porta.

6. Per arrestare il server locale dalla riga di comando, premi Ctrl+C sulla tastiera.

Rilevare l'ambiente di runtime dell'applicazione

Per determinare se il codice è in esecuzione in produzione o nel server di sviluppo locale, puoi controllare la variabile di ambiente GAE_ENV:

if os.getenv('GAE_ENV', '').startswith('standard'):
  # Production in the standard environment
else:
  # Local execution.

Utilizzare il server di sviluppo locale con i servizi Google Cloud

Puoi integrare dev_appserver con altri componenti Google Cloud .

Librerie client di Cloud

Molte librerie client di Google Cloud dipendono dalla presenza della variabile di ambiente GOOGLE_CLOUD_PROJECT, che deve essere il tuo ID progettoGoogle Cloud . Puoi trovare il suo valore eseguendo il comando gcloud config list project o esaminando la pagina del progetto in Google Cloud console.

Per assicurarti che questa variabile di ambiente sia impostata correttamente durante lo sviluppo locale, inizializza dev_appserver utilizzando il parametro --application=PROJECT_ID come mostrato nell'esempio precedente.

Emulatori di Cloud

Puoi testare la tua applicazione con emulatori per Cloud Datastore, Cloud Bigtable e Cloud Pub/Sub.

Modifiche alla ricarica automatica requirements.txt e app.yaml

Il server di sviluppo locale installa automaticamente le dipendenze trovate nel file requirements.txt. dev_appserver ti consente anche di testare le funzionalità configurate tramite app.yaml. Ad esempio, puoi testare la capacità della tua app di pubblicare file statici. Quando dev_appserver è in esecuzione, qualsiasi modifica a requirements.txt e app.yaml riavvia automaticamente l'app per riflettere queste modifiche. Ciò potrebbe comportare un ritardo temporaneo durante il download e l'installazione delle dipendenze.

Gestione e routing delle istanze nel server di sviluppo

Scopri gli indirizzi delle istanze

Il server di sviluppo locale crea tutte le istanze di scalabilità manuale all'avvio. Le istanze per i servizi di scalabilità automatica e di base vengono gestite in modo dinamico. Il server assegna una porta a ogni servizio e i client possono fare affidamento sul server per bilanciare il carico e selezionare automaticamente un'istanza. Le assegnazioni delle porte per l'indirizzamento di ogni servizio vengono visualizzate nel flusso di messaggi di log del server.

Ecco le porte per un'app che definisce tre servizi:

INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083

Quando utilizzi l'indirizzo di un servizio, ad esempio http://localhost:8082/, il server crea o seleziona un'istanza del servizio e invia la richiesta a quell'istanza.

Il server assegna porte univoche a ogni istanza di un servizio. Puoi utilizzare il server di amministrazione per scoprire queste porte. Esiste una porta univoca per il server amministrativo, che viene visualizzata nel log dei messaggi:

INFO Starting admin server at: http://localhost:8000

Questo indirizzo ti indirizza alla console del server di amministrazione. Fai clic su Istanze per visualizzare lo stato dinamico delle istanze della tua app

Per ogni istanza manuale e di base viene visualizzata una voce separata. I numeri dell'istanza sono link con indirizzi porta unici per ogni istanza. Fai clic sul link per inviare una richiesta direttamente a quell'istanza.

File di distribuzione

Se la tua app include un file dispatch.yaml, il flusso di messaggi di log include una porta dispatcher:

INFO Starting dispatcher running at: http://localhost:8080

Le richieste a questa porta vengono instradate in base alle regole nel file dispatch. Il server non supporta le regole per i file dispatch.yaml che includono nomi host, ad esempio url: "customer1.myapp.com/*". Le regole con pattern di percorso relativo (url: "*/fun") funzionano, quindi puoi utilizzare URL come http://localhost/fun/mobile per raggiungere le istanze. Il server segnala un errore nel flusso di log se provi ad avviare un'applicazione con un file dispatch.yaml che contiene regole basate sull'host.

Utilizzare Cloud Trace

Cloud Trace è utile per capire come si propagano le richieste nella tua applicazione. Puoi analizzare informazioni dettagliate sulla latenza per una singola richiesta o visualizzare la latenza aggregata per l'intera applicazione.

Per visualizzare i dettagli della traccia in Cloud Trace, puoi seguire le istruzioni riportate in Trovare ed esplorare le tracce. In Explorer tracce, puoi utilizzare i filtri per filtrare in base al servizio e alla versione di App Engine specifici.