Ambiente di runtime Python 2

Con App Engine, puoi creare applicazioni web utilizzando il linguaggio di programmazione Python e sfruttare le numerose librerie, gli strumenti e i framework per Python utilizzati dagli sviluppatori professionisti per creare applicazioni web di livello mondiale. L'applicazione Python viene eseguita sul dell'infrastruttura e utilizza servizi e archiviazione permanente su larga scala.

Introduzione

App Engine esegue il codice dell'applicazione Python utilizzando un interprete Python precompilato in un ambiente "sandboxed" sicuro. L'app riceve richieste web, esegue operazioni e invia risposte interagendo con questo ambiente.

Un'app web Python interagisce con il server web App Engine utilizzando il protocollo WSGI, pertanto le app possono 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 ambiente "puro" Pitone completamente gestito di Google Cloud.

L'ambiente "sandbox" protetto isola l'applicazione per il servizio e la 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 servizi scalabili forniti da App Engine per archiviare i dati e comunicare tramite internet. L'interprete Python solleva un'eccezione quando un'app tenta di importare un modulo Python dalla libreria standard noto per non funzionare all'interno delle limitazioni della sandbox.

La piattaforma App Engine offre molte servizi che le tue che il codice può chiamare. L'applicazione può anche configurare programmati attività che vengono eseguite a intervalli specificati.

Selezione del runtime Python 2

Lo specifichi nel file di configurazione app.yaml, che viene utilizzato 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 dell'ambiente di runtime di Python 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.

La sandbox

Per consentire ad App Engine di distribuire le richieste per le applicazioni su più server web e per impedire a un'applicazione di interferire con un'altra, l'applicazione viene eseguita in un ambiente "sandbox" limitato. 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. Una richiesta web a un'applicazione deve essere gestita entro pochi secondi. I processi che richiedono molto tempo per rispondere vengono interrotti per 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 contenenti file .py o .pyc (o una combinazione). Se carichi file .pyc, si applicano una serie di importanti limitazioni:

  • 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 sostituire l'elemento skip_files nel file app.yaml in modo che il nuovo valore non causi il salto dei file .pyc.
  • Devi usare Python 2.7 per creare il file .pyc. Se sulla tua macchina di sviluppo è installata una versione diversa di Python (ad esempio Python 2.6), dovrai ottenere la versione 2.7 per creare un file .pyc compatibile.

Python 2 puro

Tutto il codice per l'ambiente di runtime di Python deve essere puro Python e non deve includere estensioni C o altro codice che deve essere compilato.

L'ambiente include la libreria standard di Python. Alcuni moduli sono stati disabilitati perché le loro funzioni di base non sono supportate da App Engine, come il networking o la scrittura nel file system. 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 per funzionare con App Engine. Questi moduli variano in base ai due ambienti di runtime di Python, come descritto di seguito.

Librerie personalizzate nella versione 2.7 di Python

Nel runtime della versione 2.7 di Python, i seguenti moduli sono stati sostituiti o personalizzati:

  • tempfile è disabilitata, ad eccezione di TemporaryFile che ha un alias StringIO.

  • Il logging è disponibile e il suo utilizzo è vivamente incoraggiato. Consulta: Logging.

Oltre alla libreria standard di Python e alle librerie di App Engine, il runtime della versione 2.7 di Python include diverse librerie di terze parti.

Aggiunta di librerie Python di terze parti

Puoi includere librerie Python di terze parti nella tua 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. I moduli Python che crei nella directory principale dell'applicazione sono disponibili utilizzando un percorso dalla radice. Non dimenticare di creare i file __init__.py richiesti nelle sottodirectory in modo che Python li riconosca come pacchetti. Inoltre, assicurati che le librerie non richiedano estensioni C.

Thread

I thread possono essere creati nella versione 2.7 di Python utilizzando i moduli thread o threading. Tieni presente che i thread verranno uniti dal runtime al termine della richiesta, quindi non possono essere eseguiti oltre la fine della richiesta.

Thread in background

Il codice in esecuzione su un'istanza con scalabilità manuale o di base può avviare un thread in background che può sopravvivere alla richiesta che lo genera. In questo modo, un'istanza può eseguire attività periodiche o pianificate arbitrarie o continuare a lavorare in background dopo che una richiesta è stata restituita all'utente.

Le voci di logging e os.environ di un thread in background sono indipendenti da quelle del thread di generazione.

Devi importare il modulo google.appengine.api.background_thread dall'SDK per App Engine.

from google.appengine.api import background_thread

La BackgroundThread è come il normale Python threading.Threadclass, ma può "outlive" il che lo genera. Esiste anche la funzione start_new_background_thread() che crea e avvia un thread in background:

# sample function to run in a background thread
def change_val(arg):
    global val
    val = arg

if auto:
    # Start the new thread in one command
    background_thread.start_new_background_thread(change_val, ['Cat'])
else:
    # create a new thread and start it
    t = background_thread.BackgroundThread(
        target=change_val, args=['Cat'])
    t.start()
Il numero massimo di thread in background simultanei creati dall'API App Engine è 10 per istanza. Questo limite non si applica ai thread Java comuni non correlati all'API App Engine.

Strumenti

L'SDK per App Engine include strumenti per testare l'applicazione, caricare i file dell'applicazione, gestire gli indici di Datastore, scaricare i dati dei log e caricare grandi quantità di dati in Datastore.

Il server di sviluppo esegue la tua applicazione sul computer locale per testarla. Il server simula i servizi Datastore e le limitazioni 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 di 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, una latenza di 10 ms equivale a 100 richieste/secondo/istanza.

Le istanze multi-thread possono gestire molte richieste in parallelo. Pertanto, esiste una relazione diretta tra la CPU consumata e il numero di richieste al secondo.

Le app Python versione 2.7 supportano le richieste contemporaneamente, pertanto una singola istanza può gestire nuove richieste in attesa del completamento di altre richieste. La contemporaneità riduce notevolmente il numero di istanze della tua app ma devi progettare l'app per il multi-threading.

Ad esempio, se un'istanza B4 (circa 2,4 GHz) consuma 10 Mcycle/richiesta, puoi elaborare 240 richieste/secondo/istanza. Se consuma 100 Mcycle/richiesta, puoi 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 vengono 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 sopra indicati non possono essere sostituiti.