Nota: Go 1.11 ha raggiunto la fine del supporto il 30 gennaio 2024. Le applicazioni Go 1.11 esistenti continueranno a essere eseguite e a ricevere traffico. Tuttavia, App Engine potrebbe bloccare il ri deployment di applicazioni che utilizzano runtime dopo la data di fine del supporto. Ti consigliamo di eseguire la migrazione all'ultima versione supportata di Go.

Test e deployment dell'applicazione

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base alla regione selezionata al momento della creazione dell'app. Non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono apparire simili ai codici di paese e provincia di uso comune. Per le app create dopo febbraio 2020, REGION_ID.r è incluso negli URL di App Engine. Per le app esistenti create prima di questa data, l'ID regione è facoltativo nell'URL.

Scopri di più sugli ID regione.

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

Esecuzione in locale

Per testare la funzionalità della tua applicazione prima di eseguirne il deployment, eseguila nel tuo ambiente locale con gli strumenti di sviluppo che utilizzi abitualmente. Ad esempio, il comando go run.

Prima di eseguire il deployment dell'applicazione

Prima di eseguire il deployment della tua applicazione:

Il proprietario del progetto Google Cloud deve abilitare App Engine.
Devi assicurarti che il tuo account utente includa i privilegi necessari.

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 dell'applicazione da eseguire nell'ambiente standard di App Engine. Le build vengono create nella regione dell'app. Scopri di più in Gestire le immagini build.

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

Deployment di un servizio

Puoi eseguire il deployment della tua applicazione in App Engine eseguendo il deployment di versioni dei servizi dell'applicazione e di ciascuno dei relativi file di configurazione.

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

gcloud app deploy

Se non specifichi nessun file con il comando, viene eseguito solo il deployment del file app.yaml nella directory attuale. Per impostazione predefinita, il comando deploy genera un ID univoco per la versione di cui esegui il deployment, ne esegue il deployment nel progetto Google Cloud che hai configurato per l'utilizzo di Google Cloud CLI e instrada 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 evitare che il traffico venga instradato 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 progetto Google Cloud specifico, assegnagli un ID versione personalizzato e impedire 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 riferimento gcloud app deploy.

Deployment di più servizi

Devi utilizzare lo stesso comando di deployment per eseguire il deployment o l'aggiornamento di più servizi che costituiscono l'applicazione.

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

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

Requisiti per il deployment di più servizi

Inizialmente, devi eseguire il deployment di una versione della tua applicazione sul servizio default prima di poter creare ed eseguire il deployment di servizi successivi.
L'ID di ciascuno dei tuoi servizi 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, escludendo questa definizione di elemento dal file di configurazione, la versione viene implementata nel servizio default.

Visualizzazione dei log di build

Cloud Build trasmette in flussi di log di creazione e deployment i log visualizzabili nella sezione Cronologia di Cloud Build della console Google Cloud. Per visualizzare le build nella regione dell'app, utilizza il menu a discesa Regione nella parte superiore della pagina per scegliere la regione in base alla quale applicare il filtro.

Come 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. Questa opzione è utile per ignorare gli artefatti delle build e altri file che non devono essere caricati con il deployment.

Gestione delle immagini build

Ogni volta che esegui il deployment di una nuova versione, viene creata un'immagine container utilizzando il servizio Cloud Build. L'immagine container viene creata nell'area geografica dell'app, quindi viene eseguita nell'ambiente standard di App Engine.

Le immagini container create vengono archiviate nella cartella app-engine-tmp/app in Container Registry. Puoi scaricare queste immagini per conservarle o pubblicarle altrove. Una volta completato il deployment, App Engine non ha più bisogno delle immagini container. Tieni presente che non vengono eliminate automaticamente, quindi per evitare di raggiungere la quota di spazio di archiviazione, puoi eliminare in sicurezza tutte le immagini che non ti servono. Per ulteriori informazioni sulla gestione delle immagini in Container Registry, consulta la documentazione di Container Registry.

Visualizzazione dell'applicazione

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

gcloud app browse

Test su App Engine prima di spostare il traffico

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

Esegui il deployment della nuova versione, ma evita che il traffico venga instradato automaticamente alla nuova versione:
```
gcloud app deploy --no-promote
```
Accedi alla nuova versione visitando il seguente URL:

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

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

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

App Engine instrada le richieste inviate a https://PROJECT_ID.REGION_ID.r.appspot.com alla versione configurata in precedenza per ricevere il traffico.
Quando vuoi inviare il traffico alla nuova versione, utilizza la console Google Cloud per eseguirne la migrazione:

Gestisci le versioni

Seleziona la versione di cui hai appena eseguito il deployment 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 tuo servizio:

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

Per maggiori informazioni sul targeting di versioni e servizi specifici, consulta Modalità di routing delle richieste.

Utilizzo delle variabili di ambiente di build

Puoi inoltre impostare variabili di ambiente di build per i runtime che supportano i buildpack di Google Cloud.

Le variabili di ambiente di build sono coppie chiave/valore distribuite insieme a un'app che consentono di passare informazioni di configurazione ai buildpack. Ad esempio, potresti voler personalizzare le opzioni del compilatore. Puoi aggiungere o rimuovere queste variabili di ambiente di compilazione configurando il campo build_env_variables nel file app.yaml.

Nota: le chiavi devono iniziare con una lettera ASCII maiuscola ed essere composte da lettere ASCII, numeri e trattini bassi maiuscole. Non creare chiavi di variabile con prefisso GOOGLE_*. Visualizza tutte le variabili di ambiente buildpacks supportate.

Utilizzo del server di sviluppo locale

Puoi utilizzare dev_appserver per eseguire le app localmente per simulare la tua applicazione in esecuzione in App Engine di produzione. 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.

Poiché Go 1.11 ha raggiunto la fine del supporto, non puoi più utilizzare la versione più recente di dev_appserver.py per eseguire le tue applicazioni localmente. Per continuare a utilizzare dev_appserver.py, segui le istruzioni riportate in Utilizzare il server di sviluppo locale.

Esecuzione del server di sviluppo locale

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

Per ottenere le credenziali di accesso per il tuo account utente, esegui:
```
gcloud auth login
```
Consenti all'applicazione locale di utilizzare temporaneamente le tue credenziali utente per l'accesso all'API:
```
gcloud auth application-default login
```
Per avviare il server di sviluppo locale:

Nella directory che contiene il file di configurazione app.yaml, esegui il comando dev_appserver.py e specifica l'ID progetto e il percorso al file app.yaml:
```
python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml
```
Per modificare la porta, includi l'opzione --port:
```
python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml --port=9999
```
Sostituisci DEVAPPSERVER_ROOT con il percorso della cartella in cui hai estratto la versione archiviata di devapp_server.py. Per ulteriori informazioni sul download e sull'utilizzo della versione archiviata di dev_appserver.py, consulta Utilizzare il server di sviluppo locale.

Per scoprire di più sulle opzioni del comando dev_appserver.py, consulta Opzioni del server di sviluppo locale.
Quando viene avviato, il server di sviluppo locale configura un ambiente di sviluppo che preinstalla le dipendenze trovate nel file requirements.txt.
Il server di sviluppo locale è ora in esecuzione e rimane in attesa delle richieste. Visita http://localhost:8080/ nel tuo 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.
Per arrestare il server locale dalla riga di comando, premi Ctrl-C sulla tastiera.

Rilevamento dell'ambiente di runtime delle applicazioni

Per determinare se il tuo codice è in esecuzione in produzione o sul 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.

Utilizzo del server di sviluppo locale con i servizi Google Cloud

Puoi integrare dev_appserver con altri componenti di Google Cloud.

Librerie client di Cloud

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

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 cloud

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

Ricaricamento automatico di modifiche di `requirements.txt` e `app.yaml` in corso...

Il server di sviluppo locale installa automaticamente le dipendenze trovate nel tuo file requirements.txt. dev_appserver consente anche di testare la funzionalità configurata 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 le modifiche. Ciò potrebbe causare un ritardo temporaneo durante il download e l'installazione delle dipendenze.

Gestione e routing delle istanze nel server di sviluppo

Rilevamento degli indirizzi delle istanze in corso...

Il server di sviluppo locale crea tutte le istanze con 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 ciascun servizio e i client possono dipendere dal server per bilanciare il carico e selezionare automaticamente un'istanza. Le assegnazioni di porte per gli indirizzi di ciascun servizio vengono visualizzate nel flusso di messaggi di log del server.

Di seguito sono riportate 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 questa istanza.

Il server assegna porte univoche a ogni istanza di un servizio. Puoi utilizzare il server di amministrazione per individuare queste porte. Nel log dei messaggi è presente una porta univoca per il server di amministrazione:

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.

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

File di invio

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

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

Le richieste verso questa porta vengono instradate in base alle regole nel file dispatch. Il server non supporta le regole file dispatch.yaml che includono nomi host, ad esempio url: "customer1.myapp.com/*". Le regole con pattern di percorso relativi (url: "*/fun", funziona, 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 su host.