Questa pagina è stata tradotta dall'API Cloud Translation.

Test e deployment dell'applicazione

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base all'area geografica selezionata al momento della creazione dell'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID di area geografica potrebbero essere 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 area geografica è facoltativo nell'URL.

Scopri di più sugli ID dell'area geografica.

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 del deployment, esegui l'applicazione 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 dell'applicazione:

Il proprietario del progetto Cloud deve abilitare App Engine.
Devi assicurarti che l'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 nell'area geografica dell'app. Scopri di più nella pagina Gestione delle immagini di build.

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

Deployment di un servizio

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

Per eseguire il deployment di una versione del servizio dell'applicazione, esegui il comando seguente 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 solo il deployment 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, ne esegue il deployment nel progetto Google Cloud che hai configurato per l'interfaccia a riga di comando di Google Cloud 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 tuo servizio, devi scegliere come target ogni file ed eseguirne il deployment 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 automaticamente indirizzato alla nuova versione, utilizza il flag --no-promote.
Per eseguire il deployment in uno specifico progetto Google Cloud, 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 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 riferimento gcloud app deploy.

Deployment di più servizi

Puoi utilizzare lo stesso comando di deployment per eseguire il deployment o aggiornare i vari servizi che compongono la tua 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 unico 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 al servizio default prima di poter creare e implementare i servizi successivi.
L'ID di ciascuno dei tuoi servizi deve essere specificato nei file di configurazione app.yaml corrispondenti. Per specificare l'ID del 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 al servizio default.

Visualizzazione dei log di build

I flussi di Cloud Build creano e eseguono il deployment dei log visualizzabili nella sezione della cronologia di Cloud Build di Cloud Console. Per visualizzare le build nell'area geografica dell'app, utilizza il menu a discesa Area geografica nella parte superiore della pagina per scegliere l'area geografica in base alla quale filtrare.

Ignorare i file

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

Gestione delle immagini build

Ogni volta che esegui il deployment di una nuova versione, l'immagine del container viene creata tramite il servizio Cloud Build. L'immagine del container viene creata nell'area geografica dell'app e viene quindi 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 tenerle o eseguirle altrove. Una volta completato il deployment, App Engine non ha più bisogno delle immagini container. Tieni presente che non vengono eliminati automaticamente, quindi per evitare di raggiungere la quota di spazio di archiviazione, puoi eliminare in sicurezza 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 il comando seguente 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 su App Engine. Ad esempio, per testare una nuova versione del servizio default:

Esegui il deployment della nuova versione, ma impedisci il routing automatico del traffico alla nuova versione:
```
gcloud app deploy --no-promote
```
Accedi alla nuova versione accedendo al seguente URL:

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

Nota: puoi trovare l'ID versione in Cloud Console o specificarne uno quando esegui il deployment con --version flag. Nell'interfaccia a riga di comando di Google Cloud viene restituito 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 visualizzandone i log. Per ulteriori informazioni, consulta la pagina relativa alla 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 traffico alla nuova versione, utilizza Cloud Console per eseguire la migrazione del traffico:

Gestisci le versioni

Seleziona la versione appena sottoposta a 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 tuo nome del servizio:

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

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

Utilizzo delle variabili di ambiente di build

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

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

Nota: le chiavi devono iniziare con una lettera ASCII maiuscola e possono contenere solo lettere ASCII maiuscole, cifre e trattini bassi. Ti consigliamo inoltre di evitare di creare variabili con un prefisso di chiave GOOGLE_*, a meno che tu non stia intenzionalmente configurando buildpack utilizzando variabili di ambiente. Attualmente le seguenti chiavi sono riservate per l'utilizzo da parte di Google:

GOOGLE_RUNTIME
GOOGLE_RUNTIME_VERSION
GOOGLE_ENTRYPOINT
GOOGLE_DEVMODE

Puoi utilizzare qualsiasi altra chiave supportata dai buildpack.

Utilizzo del server di sviluppo locale

L'interfaccia a riga di comando di Google Cloud include un server di sviluppo locale denominato dev_appserver che puoi eseguire localmente per simulare l'applicazione in esecuzione nell'ambiente di produzione di App Engine. Questo server di sviluppo simula parzialmente l'ambiente in cui viene eseguita l'applicazione, consentendoti di testare le app scritte per i runtime dell'ambiente standard.

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'applicazione 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 credenziali utente per l'accesso all'API:
```
gcloud auth application-default login
```
Per avviare il server di sviluppo locale:

Esegui il comando dev_appserver.py dalla directory principale del progetto. Specifica l'ID progetto e il percorso del file app.yaml:
```
dev_appserver.py --application=PROJECT_ID app.yaml
```
Per cambiare porta, includi l'opzione --port:
```
dev_appserver.py --application=PROJECT_ID app.yaml --port=9999
```
Se vuoi eseguire dev_appserver.py con l'interprete Python 3, devi specificare il flag --runtime_python_path=[PATH_TO_PYTHON3_BINARY]. Ad esempio:
```
dev_appserver.py --runtime_python_path=/usr/bin/python3 --application=PROJECT_ID app.yaml --port=9999
```
Per ulteriori informazioni sulle opzioni dei comandi di dev_appserver.py, vedi Opzioni del server di sviluppo locale.
Quando viene avviato, il server di sviluppo locale configura un ambiente di sviluppo che preinstalla le dipendenze contenute nel file requirements.txt.
Ora il server di sviluppo locale è in esecuzione e rimane in attesa delle richieste. Visita la pagina 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.
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 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.

Utilizzo del 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 l'ID del progetto Cloud. Puoi trovare il suo valore eseguendo il comando gcloud config list project o guardando la pagina del tuo 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 sopra.

Emulatori Cloud

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

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

Il server di sviluppo locale installa automaticamente le dipendenze rilevate nel file requirements.txt. dev_appserver consente inoltre di testare funzionalità configurate tramite app.yaml. Ad esempio, puoi testare la capacità dell'app di pubblicare file statici. Quando dev_appserver è in esecuzione, le modifiche a requirements.txt e app.yaml riavviano automaticamente l'app per riflettere tali modifiche. Questo potrebbe comportare un ritardo temporaneo poiché le dipendenze vengono scaricate e installate.

Gestione e routing delle istanze nel server di sviluppo

Rilevamento degli 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 sono gestite in modo dinamico. Il server assegna una porta a ciascun 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 ciascun servizio vengono visualizzate nel flusso di messaggi del log del server.

Di seguito sono riportate le porte di 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 un indirizzo di servizio, ad esempio http://localhost:8082/, il server crea o seleziona un'istanza del servizio e invia la richiesta a tale istanza.

Il server assegna porte univoche a ciascuna istanza di un servizio. Puoi utilizzare il server di amministrazione per rilevare queste porte. Nel log dei messaggi è presente una porta univoca per l'amministratore, che viene visualizzata:

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

che ti indirizzerà alla Console del server di amministrazione. Fai clic su Istanze per visualizzare lo stato dinamico delle istanze dell'app.

Per ciascuna istanza manuale e di base viene visualizzata una voce separata. I numeri delle istanze sono link con indirizzi di porta univoci per ogni istanza. Fai clic sul link per inviare una richiesta direttamente a tale istanza.

Inviare file

Se la tua app include un file dispatch.yaml, lo stream dei messaggi di log include una porta del distributore:

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

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