ID regione
REGION_ID
è un codice abbreviato assegnato da Google 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 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.
Eseguire l'app in locale
Esegui l'applicazione per testare la funzionalità prima di eseguirne il deployment
nel tuo ambiente locale con gli strumenti di sviluppo che usi abitualmente. Per
Ad esempio,
go run
.
Prima di eseguire il deployment dell'applicazione
Prima di poter eseguire il deployment dell'applicazione:
- Il proprietario del progetto Google Cloud deve abilitare App Engine.
- Devi assicurarti che il tuo account utente Includa i privilegi richiesti.
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 di App Engine. Le build vengono create nella regione dell'app. Scopri di più in Gestione delle immagini build.
Per eseguire il deployment delle app in modo programmatico, utilizza l'API Admin.
Deployment di un servizio
Esegui il deployment dell'applicazione in 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 dell'applicazione, esegui il comando seguente dalla directory in cui si trova il file app.yaml
del servizio:
gcloud app deploy
Se non specifichi nessun file con il comando, viene eseguito solo il deployment del file app.yaml
nel tuo
della directory corrente. Per impostazione predefinita, il comando deploy
genera un ID univoco per
di cui esegui il deployment, ne esegue il deployment
il progetto Google Cloud che hai configurato
in Google Cloud CLI per l'utilizzo
e instrada tutto il traffico alla nuova versione.
Puoi modificare il comportamento predefinito del comando scegliendo come target file specifici o includere parametri aggiuntivi:
- Per eseguire il deployment degli altri file di configurazione del servizio, devi scegliere come target
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 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 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 la gcloud app deploy
documentazione di riferimento.
Deployment di più servizi
Utilizzi lo stesso comando di deployment per il deployment o l'aggiornamento dai servizi che compongono la tua applicazione.
Per eseguire il deployment di più servizi, esegui il deployment separato del file app.yaml
di ciascun 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
- Devi inizialmente eseguire il deployment di una versione dell'applicazione nel servizio
default
prima di poter creare ed eseguire il deployment di servizi successivi. - L'ID di ciascun servizio deve essere specificato nei relativi file di configurazione
app.yaml
. Per specificare l'ID servizio, includi il parametro Definizione di elementoservice
in ogni file di configurazione. Per impostazione predefinita, escludendo questa definizione di elemento dal file di configurazione esegue il deployment della versione il serviziodefault
.
Visualizzazione dei log di build
Cloud Build crea ed esegue il deployment dei flussi di log visualizzabili in Sezione della cronologia di Cloud Build console Google Cloud. Per visualizzare le build nella regione dell'app, usa Regione menu a discesa nella parte superiore della pagina per scegliere la regione in cui filtra per.
Operazione per ignorare i file in corso...
Puoi utilizzare un file .gcloudignore
per specificare i file e le directory che verranno
non vengano caricate su App Engine quando esegui il deployment dei tuoi servizi. Questo è
utile per ignorare gli artefatti di 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, viene creata un'immagine container utilizzando Cloud Build. L'immagine del container viene creata nella regione dell'app e poi eseguita nell'ambiente standard di App Engine.
Le immagini container create vengono archiviate nella cartella app-engine-tmp/app
in Container Registry. Puoi
scarica queste immagini per conservarle o eseguirle altrove. Una volta completato il deployment,
App Engine non ha più bisogno
immagini container. Tieni presente che non vengono eliminate automaticamente, quindi per evitare di raggiungere la quota di spazio di archiviazione, puoi eliminare in sicurezza le immagini che non ti servono.
Per saperne di più sulla gestione delle immagini in Container Registry, consulta
Documentazione di Container Registry.
Visualizzazione dell'applicazione
Dopo aver eseguito il deployment dell'applicazione in App Engine, puoi eseguire il seguente comando per avviare il browser e visualizzarla 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 traffico, puoi testarla
in App Engine. Ad esempio, per testare una nuova versione del tuo servizio default
:
Esegui il deployment della nuova versione, ma impedisci che il traffico venga indirizzato automaticamente alla nuova versione:
gcloud app deploy --no-promote
Per accedere alla nuova versione, vai al seguente URL:
https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
Ora puoi testare la nuova versione nel runtime di App Engine completamente gestito di Google Cloud. Puoi eseguire il debug dell'applicazione visualizzandone i log. Per ulteriori informazioni, consulta Scrivere log delle applicazioni.
App Engine instrada le richieste inviate a
https://PROJECT_ID.REGION_ID.r.appspot.com
alla versione precedente configurate per ricevere traffico.Quando vuoi inviare traffico alla nuova versione, utilizza la console Google Cloud per eseguire la migrazione del traffico:
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 le 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 ulteriori informazioni sul targeting di servizi e versioni specifici, consulta Come vengono instradate le richieste.
Utilizzo delle variabili di ambiente di build
Puoi anche impostare le variabili di ambiente di compilazione 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
ti consentono di trasmettere le informazioni di configurazione
ai buildpack. Ad esempio, potresti voler personalizzare le opzioni del compilatore. Tu
puoi aggiungere o rimuovere queste variabili di ambiente di build configurando
build_env_variables
nel file app.yaml
.
Utilizzo del server di sviluppo locale
Puoi utilizzare dev_appserver
per eseguire le tue app localmente in modo da simulare l'esecuzione dell'applicazione in
App Engine per la produzione. Questo server di sviluppo simula parzialmente
ambiente in cui viene eseguita la tua applicazione, consentendoti di testare le app scritte
per qualsiasi runtime dell'ambiente standard.
Poiché Go 1.11 ha raggiunto il termine del supporto, non puoi più utilizzare la versione più recente di dev_appserver.py
per eseguire le tue applicazioni in locale. Per continuare a utilizzare dev_appserver.py
, segui le istruzioni riportate in
Utilizzo del server di sviluppo locale.
Eseguire il server di sviluppo locale
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.
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 comandodev_appserver.py
e specifica l'ID progetto e il percorso del tuo Fileapp.yaml
:python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml
Per cambiare 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 estrai la versione archiviata di
devapp_server.py
. Per ulteriori informazioni sul download e sull'utilizzo della versione archiviata didev_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.All'avvio, il server di sviluppo locale configura un ambiente di sviluppo che preinstalla le dipendenze presenti nel file
requirements.txt
.Il server di sviluppo locale è ora in esecuzione e rimane in ascolto delle richieste. Visita la pagina 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 dell'applicazione in corso...
Per determinare se il codice viene eseguito 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 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 esaminare la pagina del progetto nel
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 Cloud Datastore Cloud Bigtable Cloud Pub/Sub.
Ricaricamento automatico di requirements.txt
e app.yaml
modifiche
Il server di sviluppo locale installa automaticamente le dipendenze trovate nel tuo
requirements.txt
. dev_appserver
ti consente inoltre di testare la funzionalità configurata tramite app.yaml
. Ad esempio, puoi verificare la capacità della tua app di pubblicare file statici. Quando
dev_appserver
è in esecuzione. Eventuali modifiche a requirements.txt
e app.yaml
riavvia automaticamente l'app per applicare 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
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 ogni servizio e i client possono fare affidamento sul server per il bilanciamento del carico e la selezione automatica di un'istanza. Le assegnazioni delle porte per per 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 ciascuna istanza di un servizio. Puoi utilizzare il server amministrativo per rilevare 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 reindirizza 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
, lo stream dei messaggi di log include un
Porta supervisore:
INFO Starting dispatcher running at: http://localhost:8080
Le richieste a questa porta vengono instradate in base alle regole nel file di invio.
Il server non supporta le regole dei file dispatch.yaml
che includono hostname, ad esempio url: "customer1.myapp.com/*"
. Le regole con pattern di percorso relativi (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.