Scopri come eseguire la tua applicazione in locale, eseguirne il deployment e testarla in App Engine.
Esecuzione 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 normalmente.
Consigliamo di utilizzare gli strumenti Python standard, come
virtualenv
per creare ambienti isolati e pytest
per eseguire test delle unità e test di integrazione, anziché dipendere da
dev_appserver
, il server di sviluppo locale fornito con
Google Cloud SDK.
Ad esempio, puoi eseguire un'applicazione Flask con il server di sviluppo Flask utilizzando:
python main.py
È possibile avviare le applicazioni Django utilizzando:
python manage.py runserver
Per simulare un ambiente App Engine di produzione, puoi eseguire il server WSGI (Web Server Gateway Interface) completo. Per fare ciò, utilizza lo stesso comando specificato come punto di accesso in app.yaml
, ad esempio:
gunicorn -b :$PORT main:app
Prima di eseguire il deployment dell'applicazione
Prima di poter eseguire il deployment dell'applicazione:
- Il proprietario del progetto Cloud deve attivare App Engine.
- Devi assicurarti che il tuo account utente includa i privilegi obbligatori.
Deployment dell'applicazione
Esegui il deployment della tua applicazione in App Engine utilizzando il comandogcloud 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ù nella pagina Gestire le immagini build.
Per eseguire il deployment delle app in modo programmatico, utilizza l'API Admin.
Deployment di un servizio
Esegui il deployment della tua 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 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 attuale. Per impostazione predefinita, il comando deploy
genera un ID univoco per la versione di cui esegui il deployment, esegue il deployment della versione nel progetto Google Cloud che hai configurato per utilizzare 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 ogni deployment 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 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, assegnargli un ID versione personalizzato e impedire il routing del traffico verso la nuova versione:
gcloud app deploy --project PROJECT_ID --version VERSION_ID --no-promote
Per ulteriori informazioni su questo comando, consulta il riferimento di gcloud app deploy
.
Deployment di più servizi
Usi lo stesso comando di deployment per il deployment o l'aggiornamento dei diversi 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 singolo comando gcloud app deploy
:
gcloud app deploy service1/app.yaml service2/app.yaml
Requisiti per il deployment di più servizi
- Prima di poter creare ed eseguire il deployment di servizi successivi, devi eseguire il deployment di una versione della tua applicazione nel servizio
default
. - 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'elementoservice
in ogni file di configurazione. Per impostazione predefinita, l'esclusione di questa definizione di elemento dal file di configurazione comporta il deployment della versione nel serviziodefault
.
Visualizzazione dei log di build
I flussi di Cloud Build creano ed eseguono il deployment di log visualizzabili nella sezione Cronologia di Cloud Build di Google 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 i risultati.
Ignorare i file
Puoi utilizzare un file .gcloudignore
per specificare file e directory che non verranno caricati in App Engine quando eseguirai il deployment dei tuoi servizi. È utile per ignorare gli artefatti di build e altri file che non devono essere caricati con il deployment.
Gestione delle immagini di 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 e viene eseguita nell'ambiente standard di App Engine.
Le immagini container container vengono archiviate nella cartella app-engine-tmp/app
in Container Registry. Puoi scaricare queste immagini per conservarle o eseguirle altrove. Al termine del deployment, App Engine non ha più bisogno di immagini container. Tieni presente che non vengono eliminati automaticamente. 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 il seguente comando per avviare il browser e visualizzarlo in
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 su App Engine. Ad esempio, per testare una nuova versione del servizio default
:
Esegui il deployment della nuova versione, ma impedisci 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
Ora puoi testare la tua nuova versione nell'ambiente di runtime di App Engine. Puoi eseguire il debug dell'applicazione visualizzando i relativi log. Per ulteriori informazioni, consulta la sezione 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.Se vuoi inviare traffico alla nuova versione, utilizza Google Cloud Console 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 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 versioni e servizi specifici, vedi Come vengono instradate le richieste.
usando 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 di cui viene eseguito il deployment insieme a un'app che
ti consentono 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 tuo file app.yaml
.
Utilizzo del server di sviluppo locale
Google Cloud CLI include un server di sviluppo locale denominato
dev_appserver
che puoi eseguire localmente per simulare l'applicazione in esecuzione in App Engine in produzione. Questo server di sviluppo simula parzialmente l'ambiente in cui viene eseguita la tua applicazione, consentendoti di testare le app scritte per tutti 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'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:
Esegui il comando
dev_appserver.py
dalla directory principale della directory del progetto. Se Python 2 non è l'interprete predefinito sul sistema, devi eseguirepython2 dev_appserver.py
per assicurarti che venga utilizzato l'interprete Python 2.Specifica l'ID progetto e il percorso del file
app.yaml
:dev_appserver.py --application=PROJECT_ID app.yaml
Per cambiare il trasferimento, includi l'opzione
--port
:dev_appserver.py --application=PROJECT_ID app.yaml --port=9999
Per testare un'app Python 3, esegui
dev_appserver.py
con l'interprete Python 3, devi specificare il programma binario Python 3 nel flag--runtime_python_path
. Ad esempio:dev_appserver.py --runtime_python_path=/usr/bin/python3 --application=PROJECT_ID app.yaml --port=9999
Per scoprire di più sulle opzioni dei comandi di
dev_appserver.py
, consulta la pagina relativa alle opzioni del server di sviluppo locale.All'avvio del server di sviluppo locale, viene configurato un ambiente di sviluppo che preinstalla le dipendenze trovate nel file
requirements.txt
.Il server di sviluppo locale è in esecuzione e in ascolto delle richieste. Visita http://localhost:8080/ nel browser web per vedere l'applicazione in azione.
Se hai specificato una porta personalizzata con l'opzione
--port
, ricordati di aprire il browser su tale porta.Per interrompere il server locale dalla riga di comando, premi Ctrl-C sulla tastiera.
Rilevamento dell'ambiente di runtime dell'applicazione
Per determinare se il tuo 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 di Google Cloud.
Librerie client di Cloud
Molte librerie client di Google Cloud dipendono dalla presenza della variabile di ambiente GOOGLE_CLOUD_PROJECT
, che dovrebbe essere il tuo ID progetto Cloud. Per verificarne il valore, esegui il comando gcloud config list project
o consulta 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 precedente.
Emulatori di cloud
Puoi testare la tua applicazione con emulatori per Cloud Datastore, Cloud Bigtable e Cloud Pub/Sub.
Ricarica automaticamente requirements.txt
e app.yaml
modifiche
Il server di sviluppo locale installa automaticamente le dipendenze trovate nel 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 apportata a requirements.txt
e app.yaml
riavvia automaticamente la tua app per riflettere tali modifiche. Ciò potrebbe causare un ritardo temporaneo man mano che 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à automatici e di base vengono gestite in modo dinamico. Il server assegna una porta a ciascun servizio e i client possono dipendere dal server per il bilanciamento del carico e selezionare automaticamente un'istanza. Le assegnazioni delle porte per l'indirizzamento di ogni servizio vengono visualizzate nello stream dei 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 tale istanza.
Il server assegna porte univoche a ogni istanza di un servizio. Puoi utilizzare l'amministratore per scoprire 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 all'istanza.
Invio di file
Se la tua app include un file dispatch.yaml
, lo stream dei messaggi di log include una porta del disco:
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 nomi host, 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
contenente regole basate su host.