Questa pagina contiene le istruzioni per eseguire la migrazione dal da prima a seconda generazione i runtime Python. Per eseguire l'upgrade dell'app di seconda generazione in modo che utilizzi l'app più recente supportata di Python, consulta Eseguire l'upgrade di un'applicazione esistente.
Python 2.7 ha raggiunto la fine del supporto il 31 gennaio 2024. Le applicazioni Python 2.7 esistenti continueranno a esistere per eseguire e ricevere traffico. Tuttavia, App Engine potrebbe bloccare il rideployment delle applicazioni che utilizzano i runtime dopo la data di fine del supporto. Ti consigliamo di eseguire la migrazione alla versione più recente supportata di Python usando le linee guida in questa pagina.
La migrazione al runtime Python 3 ti consente di utilizzare funzionalità del linguaggio aggiornate
e creare app più portabili con un codice idiomatico. Runtime Python 3
utilizza la versione più recente dell'interprete Python open source fornito
Fondazione software Python.
Le app integrate nel runtime Python 3 possono utilizzare il ricco ecosistema di pacchetti di Python
e i framework nella tua app, inclusi quelli che utilizzano il codice C, dichiarando
di dipendenze in un file requirements.txt
.
Panoramica del processo di migrazione del runtime
Consigliamo il seguente approccio incrementale alla migrazione del runtime, in cui mantieni un'applicazione funzionante e verificabile durante l'intero processo:
Esegui l'upgrade dell'app in modo che sia compatibile con Python 3.
Sono disponibili diverse soluzioni per aiutarti a eseguire questo upgrade. Ad esempio: usa Six, Python-Future o Python-Modernize.
Per ulteriori informazioni su questo passaggio del processo di migrazione del runtime, consulta Trasferimento del codice Python 2 a Python 3 sulla Python Software Foundation sito di documentazione.
Scegli una di queste strategie di implementazione per qualsiasi App Engine servizio in bundle utilizzato dalla tua app:
Eseguire la migrazione dei servizi in bundle precedenti nell'app Python 2 ai servizi Google Cloud non in bundle, o altre sostituzioni consigliate.
Continua a utilizzare i servizi in bundle legacy nel tuo App Python 3. Questo offre la flessibilità di passare ai servizi non in bundle più avanti nel di migrazione.
Assicurati di testare l'app dopo la migrazione di ciascun servizio.
Prepara la configurazione di App Engine per il runtime Python 3. Alcune importanti modifiche interessano impostazioni di configurazione in
app.yaml
, incluse, a titolo esemplificativo:- Ora si presume che le app siano sicure per i thread. Se la tua applicazione non è
threadsafe, devi impostare
max_concurrent_requests
inapp.yaml
a 1. Questa impostazione potrebbe comportare la presenza di un numero maggiore di istanze del necessario per un'app threadsafe, generando costi inutili. Il file
app.yaml
non instrada più le richieste ai tuoi script. Invece, Devi usare un framework web con routing in-app e aggiornare oppure rimuovi tutti i gestoriscript
inapp.yaml
. Per un esempio di come fare con il framework Flask, controlla Esempio di codice della guida alla migrazione di App Engine in GitHub.Per saperne di più sulla modifica di questo e di altri file di configurazione, consulta File di configurazione.
- Ora si presume che le app siano sicure per i thread. Se la tua applicazione non è
threadsafe, devi impostare
Nei runtime di seconda generazione, i log delle app non sono più nidificati nei log delle richieste. Sono necessari ulteriori passaggi per visualizzare la visualizzazione nidificata dei log delle richieste e delle app in Esplora log. Per ulteriori informazioni, consulta Eseguire la migrazione a Cloud Logging.
Test e deployment dell'app sottoposta ad upgrade in un ambiente Python 3.
Dopo aver superato tutti i test, esegui il deployment dell'app di cui è stato eseguito l'upgrade in App Engine ma impediscono l'instradamento automatico alla nuova versione. Utilizza le funzionalità di suddivisione del traffico verso eseguire lentamente la migrazione del traffico dalla tua app in Python 2 all'app nel runtime di Python 3. Se riscontri problemi, può indirizzare tutto il traffico a una versione stabile fino a quando il problema non viene risolto.
Per esempi su come convertire le tue app Python 2 in Python 3, puoi fare riferimento a queste risorse aggiuntive.
Differenze principali tra i runtime Python 2 e Python 3
La maggior parte delle modifiche da apportare durante la migrazione del runtime proviene le seguenti differenze tra i runtime Python 2 e Python 3:
- Differenze nell'utilizzo della memoria
- Differenze di utilizzo della CPU
- Differenze nelle intestazioni delle richieste
- Differenze tra i worker di Gunicorn
- Problemi di compatibilità tra Python 2 e Python 3
- App Engine ha in bundle i servizi nel runtime di Python 3
- Differenze nei file di configurazione
- Per indirizzare le richieste di contenuti dinamici è necessario un framework web
- App con solo contenuti statici
- Differenze nei test
- Differenze di deployment
Differenze di utilizzo della memoria
I runtime di seconda generazione registrano una base di utilizzo della memoria più elevata rispetto ai runtime di prima generazione. Ciò è dovuto a più fattori, come diversi versioni delle immagini di base e le differenze nel modo in cui le due generazioni calcolano la memoria all'utilizzo delle risorse.
I runtime di seconda generazione calcolano l'utilizzo della memoria dell'istanza come la somma di quanto un degli utilizzi da parte del processo dell'applicazione e il numero di file delle applicazioni memorizzati in modo dinamico nella cache in memoria. Per evitare che le applicazioni che usano molta memoria utilizzino l'istanza arresti anomali dovuti al superamento dei limiti di memoria, esegui l'upgrade a una versione classe dell'istanza con più memoria.
Differenze di utilizzo della CPU
I runtime di seconda generazione possono vedere una base di utilizzo più alta della CPU al momento dell'istanza avvio a freddo. A seconda della configurazione di scalabilità di un'applicazione, effetti collaterali imprevisti, come un conteggio delle istanze più elevato del previsto è configurata per la scalabilità in base all'utilizzo della CPU. Per evitare che questo accada esaminare e testare le configurazioni di scalabilità delle applicazioni per garantire di istanze sono accettabili.
Differenze nell'intestazione della richiesta
I runtime di prima generazione consentono intestazioni delle richieste con trattini bassi
(ad es. X-Test-Foo_bar
) da inoltrare alla domanda. Di seconda generazione
introduce Nginx nell'architettura host. Per effetto di ciò,
modifica, i runtime di seconda generazione sono configurati per rimuovere automaticamente
intestazioni con trattini bassi (_
). Per evitare problemi con l'applicazione, evita di utilizzare
trattini bassi nelle intestazioni delle richieste dell'applicazione.
Differenze worker gunicorn
Per i runtime Python 3 e versioni successive, il numero di worker Gunicorn ha un impatto diretto su memoria utilizzata. L'aumento dell'utilizzo della memoria è direttamente proporzionale al di aumento del numero di worker. Per ridurre il consumo di memoria, valuta la possibilità di ridurre di worker Gunicorn. Consulta le best practice per il punto di ingresso per istruzioni su come configurare il conteggio dei worker Gunicorn
Problemi di compatibilità tra Python 2 e Python 3
Quando Python 3 è stato rilasciato per la prima volta nel 2008,
diverse modifiche incompatibili con le versioni precedenti
sono stati introdotti al linguaggio. Alcune di queste modifiche richiedono solo aggiornamenti di minore entità
al codice, ad esempio modificando l'istruzione print
in una funzione print()
.
Altre modifiche potrebbero richiedere aggiornamenti significativi del codice, ad esempio
nel modo in cui gestisci dati, testo e stringhe binari.
Molte librerie open source note, incluse le librerie standard Python, è cambiato anche quando sono passati da Python 2 a Python 3.
App Engine ha in bundle i servizi nel runtime di Python 3
Per ridurre le attività di migrazione e la complessità, l'ambiente standard di App Engine consente per accedere a molti dei servizi in bundle legacy e di API nel file Python 3 runtime, ad esempio Memcache. L'app Python 3 può chiamare le API dei servizi in bundle utilizzando un linguaggio idiomatico librerie e accedere alla stessa funzionalità del runtime Python 2.
Hai anche la possibilità di utilizzare i prodotti Google Cloud che offrono con funzionalità simili a quelle dei precedenti servizi in bundle. Ti consigliamo di prendi in considerazione eseguendo la migrazione ai prodotti Google Cloud non in bundle, così potrai usufruire dei miglioramenti continui e di nuove funzioni.
Per i servizi in bundle che non sono disponibili come prodotti separati in Google Cloud, come elaborazione di immagini, ricerca e messaggistica, puoi utilizza le nostre fornitori di terze parti suggeriti o altre soluzioni alternative.
File di configurazione
Prima di poter eseguire l'app nel runtime Python 3 dello standard App Engine potrebbe essere necessario modificare alcuni file di configurazione App Engine utilizza:
app.yaml
. Comportamento di alcuni campi nella configurazioneapp.yaml
file è stato modificato. Rimuovi i campi deprecati e aggiorna gli altri campi come descritto nella guida alla migrazione.requirements.txt
. Crea questo file per installare dipendenze di terze parti, inclusi i pacchetti Python che richiedono estensioni C native. App Engine installa automaticamente queste dipendenze durante il deployment dell'app nella libreria Python 3 runtime. In precedenza, per installare le dipendenze nel runtime Python 2, dover elencare le librerie copiate o autoin bundle in questo file, quindi eseguire unpip install -t lib -r requirements.txt
oppure elenco "integrato" librerie di terze parti richiesto dall'app nel file app.yaml.appengine_config.py
. Questo file non viene utilizzato nel runtime di Python 3 ed è ignorato se viene eseguito il deployment. In precedenza, nel runtime di Python 2, questo file veniva utilizzato configurare i moduli Python e indirizzare l'app a librerie di terze parti copiate o raggruppate autonomamente.
Framework web necessario per indirizzare le richieste di contenuti dinamici
Nel runtime di Python 2, puoi creare gestori di URL nel file app.yaml
per specificare quale app eseguire
quando viene richiesto un URL o un pattern URL specifico.
Nel runtime di Python 3, la tua app deve utilizzare un framework web come
Flask o Django per indirizzare le richieste per i contenuti dinamici anziché utilizzare
Gestori di URL in app.yaml
. Per i contenuti statici, puoi continuare a creare un URL
Gestori
nel file app.yaml
dell'app.
App con solo contenuti statici
Quando ospita un'app web statica su App Engine,
devi specificare i gestori nel file app.yaml
per mappare gli URL ai file statici.
In Python 2, se una richiesta non corrisponde a nessuno dei gestori specificati nella
app.yaml
, App Engine restituisce un codice di errore 404
.
In Python 3, se una richiesta non corrisponde ad alcun gestore, App Engine
cerca un file main.py
e restituisce un errore 5xx
se un file main.py
non è
trovato. Poiché le app App Engine con solo contenuti statici non richiedono un
main.py
file, la maggior parte degli utenti vede questo errore, oltre a vedere l'istanza
errori di avvio nei log dell'app.
Per mantenere lo stesso comportamento della restituzione di un errore 404
quando nessuno dei gestori statici
ed evitare errori nei log, puoi:
- Aggiungi un gestore statico catch-all che rimandi a una directory vuota nel file
app.yaml
- Aggiungi un'app dinamica semplice nel file
main.py
per restituire un errore404
Esempi di utilizzo di una delle due opzioni:
app.yaml
Crea una directory vuota nella directory dell'app principale, ad esempio empty/
.
Nella sezione relativa al gestore del file app.yaml
, crea un nuovo gestore alla fine per individuare
tutti gli altri pattern URL e specifica la directory empty
nel
Elementi static_files
e upload
:
handlers:
- url:
.
.
.
- url: /(.*)$
static_files: empty/\1
upload: empty/.*$
main.py
Crea un file main.py
e aggiungi il codice seguente per restituire un errore 404
:
def app(env, start_response):
start_response('404 Not Found', [('Content-Type','text/html')])
return [b"Not Found"]
Test
Ti consigliamo di utilizzare un approccio di test idiomatico a Python, anziché
rispetto alla dipendenza da dev_appserver
. Ad esempio, potresti usare venv
per
un ambiente Python 3 locale isolato. Qualsiasi test Python standard
questo framework può essere utilizzato per scrivere i test dell'unità, dell'integrazione e del sistema. Tu
potrebbe anche valutare la configurazione di versioni di sviluppo dei servizi o utilizzare
disponibili per molti prodotti Google Cloud.
Facoltativamente, puoi utilizzare la versione di anteprima di dev_appserver
che supporta
Python 3. Per scoprire di più su questa funzionalità di test, consulta
Utilizzo del server di sviluppo locale.
Deployment in corso…
I deployment tramite appcfg.py
non sono
non supportato per Python 3.
Utilizza invece il gcloud
strumento a riga di comando
per eseguire il deployment della tua app.
Logging
Il logging nel runtime Python 3 segue lo standard di logging Cloud Logging. Nel runtime Python 3, i log delle app non sono più in bundle con i log delle richieste, ma sono separati in record diversi. Per apprendere sulla lettura e sulla scrittura dei log nel runtime Python 3, consulta guida al logging.
Risorse aggiuntive per la migrazione
Per ulteriori informazioni su come eseguire la migrazione delle app di App Engine a dai servizi Cloud autonomi o dal runtime Python 3, puoi fare riferimento a questi Risorse di App Engine:
- Codelab e video per la migrazione di app serverless
- Esempi di migrazione dalle app da Python 2 a Python 3 forniti dalla community