Con App Engine, puoi creare modelli applicazioni utilizzando il linguaggio di programmazione Python e sfruttare le numerose librerie, strumenti e framework per Python, che gli sviluppatori professionisti usano per creare applicazioni web di classe. L'applicazione Python viene eseguita sul dell'infrastruttura e utilizza archiviazione permanente e servizi su larga scala.
Introduzione
App Engine esegue il codice dell'applicazione Python utilizzando un Interprete Python in un ambiente sicuro con sandbox completamente gestito di Google Cloud. La tua app riceve informazioni richiede, esegue il lavoro e invia risposte interagendo con completamente gestito di Google Cloud.
Un'app web Python interagisce con il server web di App Engine utilizzando WSGI , in modo che le app possano utilizzare qualsiasi framework di applicazioni web compatibile con WSGI. Per app Engine include un semplice framework per applicazioni web, chiamato webapp2, per facilitare l'accesso a iniziare. Per le applicazioni più grandi, framework maturi di terze parti, come Django, funzionano bene con App Engine.
L'interprete Python può eseguire qualsiasi codice Python, inclusi i moduli Python che da includere nella tua applicazione, nonché la libreria standard Python. La l'interprete non può caricare moduli Python con codice C; è un approccio "puro" Pitone completamente gestito di Google Cloud.
La "sandbox" protetta isola l'applicazione per il servizio sicurezza. Garantisce che le app possano eseguire solo azioni che non interferiscono con le prestazioni e la scalabilità di altre app. Ad esempio, un'app non può scrivere dati nel file system locale o stabilire connessioni di rete arbitrarie. Le app utilizzano invece i servizi scalabili forniti da App Engine per archiviare i dati e comunicare su internet. L'interprete Python segnala un'eccezione quando un'app tenta di importare un modulo Python dalla libreria standard nota. in modo che non funzionino con le restrizioni della sandbox.
La piattaforma App Engine offre molte servizi che le tue che il codice può chiamare. L'applicazione può anche configurare programmati che vengono eseguite a intervalli specifici.
Selezione del runtime Python 2
Devi specificare l'ambiente di runtime Python nel file di configurazione app.yaml
,
utilizzata per eseguire il deployment
dell'applicazione in App Engine. Ad esempio,
aggiungi quanto segue al file app.yaml
da utilizzare
versione 2.7 di Python:
runtime: python27
api_version: 1
threadsafe: true
...
Il primo elemento, runtime
, seleziona l'ambiente di runtime Python.
Il secondo elemento, api_version
, seleziona la versione del runtime Python
dell'ambiente di analisi da utilizzare. Al momento della stesura del presente documento, App Engine ha una sola versione
dell'ambiente Python, 1
. Se il team di App Engine ha bisogno
rilasciare modifiche all'ambiente che potrebbero non essere compatibili con
codice, lo faranno con un nuovo identificatore di versione. L'app continuerà
Usa la versione selezionata finché non modifichi l'impostazione api_version
e non carichi
la tua app.
Per maggiori informazioni sul file app.yaml
e su come eseguire il deployment dell'app nell'app
di Google, consulta il riferimento app.yaml
,
Migrazione a Python 2.7,
e Deployment di un'app Python
argomenti.
Sabbiera
Consentire ad App Engine di distribuire le richieste per le applicazioni tra più server web ed evitare che un'applicazione interferisca con un'altra, l'applicazione viene eseguita in una "sandbox" limitata completamente gestito di Google Cloud. In questo ambiente, l'applicazione può eseguire codice, archiviare ed eseguire query sui dati Datastore, usa la posta, il recupero degli URL e ai servizi utente ed esaminare la richiesta web dell'utente e preparare la risposta.Un'applicazione App Engine non può:
scrivere nel file system. Le applicazioni devono utilizzare Datastore per l'archiviazione di dati permanenti. La lettura dal file system consentiti e tutti i file dell'applicazione caricati con quest'ultima sono disponibili.
rispondono lentamente. Le richieste web a un'applicazione devono essere gestite secondi. I processi che richiedono molto tempo per rispondere vengono interrotti evitare di sovraccaricare il server web.
effettuare altri tipi di chiamate di sistema.
Sandboxing in Python
Puoi caricare e utilizzare file .pyc
con il runtime Python 2.7, ma
impossibile caricare una versione .py
e una .pyc
dello stesso file. Puoi caricare file ZIP
file contenenti .py
o .pyc
file (o una combinazione). Un certo numero di
avvertenze importanti da fare se carichi file .pyc
:
- Per uno script CGI,
Gestore di script
devi comunque utilizzare l'estensione del file
.py
, anche se carichi un file.pyc
. - Per impostazione predefinita, i file
.pyc
vengono ignorati durante il deployment. Devi eseguire l'overrideskip_files
nel fileapp.yaml
in modo che il nuovo valore non causi.pyc
file da saltare. - Devi usare Python 2.7 per creare il file
.pyc
. Se disponi di un altro di Python (ad esempio Python 2.6) sulla tua macchina di sviluppo, devi ottenere la versione 2.7 per creare un file.pyc
compatibile.
Puro Python 2
Tutto il codice per l'ambiente di runtime Python deve essere Python puro e non includere qualsiasi estensione C o altro codice che deve essere compilato.
L'ambiente include lo standard Python
libreria di Google.
Alcuni moduli sono stati disabilitati perché le relative funzioni di base non sono supportate
da App Engine, come il networking o la scrittura nel file system. Nel
inoltre, il modulo os
è disponibile, ma con le funzionalità non supportate disattivate.
Se tenti di importare un modulo non supportato o di utilizzare una funzionalità non supportata
sollevare un'eccezione.
Alcuni moduli della libreria standard sono stati sostituiti o personalizzati in lavorare con App Engine. Questi moduli variano tra i due modelli i runtime, come descritto di seguito.
Librerie personalizzate in Python versione 2.7
Nel runtime di Python 2.7, i seguenti moduli sono stati sostituiti o personalizzato:
tempfile è disabilitata, ad eccezione di
TemporaryFile
che ha un alias StringIO.registrazione è disponibile e il suo utilizzo è vivamente consigliato! Consulta Logging.
Oltre alla libreria standard Python e alle librerie di App Engine, il runtime Python versione 2.7 include diversi librerie.
Aggiunta di librerie Python di terze parti
Puoi includere librerie Python di terze parti nell'applicazione inserendo il codice nella directory dell'applicazione. Se crei un link simbolico a una libreria nella directory dell'applicazione, questo link viene seguito e è inclusa nell'app di cui esegui il deployment in App Engine.
Il percorso di inclusione del modulo Python include il percorso principale dell'applicazione
ovvero la directory contenente il file app.yaml
. Moduli Python
create nella directory radice dell'applicazione siano disponibili utilizzando un percorso
dalla radice. Non dimenticare di creare i file __init__.py
richiesti nel tuo
in modo che Python le riconosca come pacchetti.
Assicurati inoltre che le librerie non abbiano bisogno di estensioni C.
Thread
I thread possono essere creati in Python versione 2.7 utilizzando
thread
o threading
moduli. Tieni presente che i thread verranno uniti dal runtime
quando termina la richiesta, in modo che i thread non possano essere eseguiti oltre la fine della richiesta.
Thread in background
Codice in esecuzione su un'istanza con scalabilità manuale o di base può avviare un thread in background che supera la richiesta che lo genera. Questo consente a un'istanza di eseguire attività periodiche o pianificate arbitrarie oppure di continuano a lavorare in background dopo che una richiesta è stata restituita all'utente.
L'elemento os.environ
di un thread in background e le voci di logging sono indipendenti da questi
del filo di riproduzione.
Devi importare il modulo google.appengine.api.background_thread
dall'SDK
per App Engine.
La
BackgroundThread
è come il normale Python threading.Threadclass
, ma può "outlive" il
che lo genera. C'è anche la funzione start_new_background_thread()
che crea un thread in background e lo avvia:
Strumenti
L'SDK per App Engine include strumenti per testare l'applicazione, caricare i file dell'applicazione, gestione degli indici Datastore, download dei dati di log e caricamento grandi quantità di dati a Datastore.
Lo sviluppo del server l'applicazione sul tuo computer locale per testarla. Il server simula i servizi Datastore e le restrizioni della sandbox. La può anche generare configurazioni per Datastore indici in base alle query eseguite dall'app durante il test.
Lo strumento gcloud
Gestisce tutte le interazioni tramite riga di comando con l'applicazione in esecuzione nell'app
di ricerca. Utilizzi gcloud app deploy
per caricare la tua domanda su
App Engine o per aggiornare singoli file di configurazione, come
Configurazione indice Datastore, che consente di creare nuovi
prima di eseguire il deployment del codice. Puoi anche visualizzare i dati di log dell'app,
puoi analizzare il rendimento della tua app
usando i tuoi strumenti.
Contemporaneità e latenza
La latenza della tua applicazione ha l'impatto maggiore sul numero di istanze necessarie per gestire il tuo traffico. Se elabori le richieste rapidamente, gestire molte richieste.
Le istanze a thread singolo possono gestire una richiesta in parallelo. Esiste quindi una relazione diretta tra latenza e numero di e richieste che possono essere gestite sull'istanza al secondo. Ad esempio, 10 ms equivale a 100 richieste al secondo per istanza.Le istanze multi-thread possono gestire molte richieste in parallelo. Pertanto, è una relazione diretta tra la CPU consumata e il numero richieste/secondo.
App Python versione 2.7 supporto simultaneo richieste, quindi una singola istanza può gestire nuove richieste mentre è in attesa che altre completato. La contemporaneità riduce notevolmente il numero di istanze della tua app ma devi progettare l'app per il multi-threading.
Ad esempio, se un B4 istanza (circa 2,4 GHz) consuma 10 Mcicli/richiesta, è possibile elaborare 240 richieste/secondo/istanza. Se consuma 100 Mcicli per richiesta, è possibile elaborare 24 richieste/secondo/istanza. Questi numeri sono il caso ideale, ma sono abbastanza sono realistici in termini di ciò che è possibile ottenere su un'istanza.
Variabili di ambiente
Le seguenti variabili di ambiente sono impostate dal runtime:
Variabile di ambiente | Descrizione |
---|---|
GAE_APPLICATION
|
L'ID della tua applicazione App Engine. Questo ID è preceduto dal prefisso "region code~" ad esempio "e~" per le applicazioni distribuite in Europa. |
GAE_DEPLOYMENT_ID |
L'ID del deployment attuale. |
GAE_ENV |
L'ambiente App Engine. Impostata su standard . |
GAE_INSTANCE |
L'ID dell'istanza su cui è attualmente in esecuzione il servizio. |
GAE_RUNTIME |
Il tempo di esecuzione specificato nel file app.yaml . |
GAE_SERVICE |
Il nome del servizio specificato nel file app.yaml . Se non viene specificato alcun nome di servizio, viene impostato su default . |
GAE_VERSION |
L'etichetta della versione corrente del servizio. |
GOOGLE_CLOUD_PROJECT |
L'ID progetto Google Cloud associato alla tua applicazione. |
PORT |
La porta che riceve le richieste HTTP. |
Puoi definire variabili di ambiente aggiuntive nel file app.yaml
,
ma i valori precedenti non possono essere sostituiti.