La migrazione al runtime Python 3 consente di utilizzare funzionalità del linguaggio aggiornate e di creare app più portabili, con codice idiomatico. Il runtime Python 3 utilizza la versione più recente dell'interprete Python open source fornito da Python Software Foundation.
Le app create con il runtime Python 3 possono utilizzare il ricco ecosistema di pacchetti e framework di Python nella tua app, inclusi quelli che utilizzano il codice C, dichiarando le dipendenze in un file requirements.txt
.
Panoramica del processo di migrazione in fase di runtime
Ti consigliamo il seguente approccio incrementale alla migrazione del runtime, in cui mantieni un'applicazione funzionante e testabile per tutto il processo:
Esegui l'upgrade dell'app affinché sia compatibile con Python 2 e Python 3.
Per questo upgrade sono disponibili diverse soluzioni. Ad esempio, utilizza Six, Python-Future o Python-Modernize.
Per ulteriori informazioni su questo passaggio del processo di migrazione del runtime, consulta la pagina relativa al trasferimento del codice Python 2 a Python 3 sul sito della documentazione di Python Software Foundation.
Scegli una di queste strategie di implementazione per qualsiasi servizio in bundle di App Engine utilizzato dalla tua app:
Esegui la migrazione dei servizi in bundle legacy nell'app Python 2 a servizi Google Cloud non in bundle, servizi di terze parti o altre sostituzioni consigliate.
Continua a utilizzare i servizi in bundle legacy nelle app Python 3. Questo approccio consente di passare ai servizi non in bundle più avanti nel ciclo di migrazione.
Assicurati di testare l'app dopo aver eseguito la migrazione di ogni servizio.
Prepara i file di configurazione di App Engine per il runtime Python 3. Varie modifiche importanti influiscono sulle impostazioni di configurazione in
app.yaml
, incluse, a titolo esemplificativo:- Ora si presume che le app siano threadsafe. Se la tua applicazione non è
threadsafe, devi impostare
max_concurrent_requests
inapp.yaml
su 1. Questa impostazione potrebbe comportare la creazione di più istanze del necessario per un'app threadsafe, con conseguenti costi superflui. Il file
app.yaml
non indirizza più le richieste ai tuoi script. Devi invece utilizzare un framework web con routing in-app e aggiornare o rimuovere tutti i gestoriscript
inapp.yaml
. Per un esempio di come eseguire questa operazione con il framework Flask, consulta l'esempio di codice della guida alla migrazione di App Engine in GitHub.Per scoprire di più sulla modifica di questo e di altri file di configurazione, consulta la sezione File di configurazione.
- Ora si presume che le app siano threadsafe. Se la tua applicazione non è
threadsafe, devi impostare
Testa ed esegui il deployment dell'app di cui è stato eseguito l'upgrade in un ambiente Python 3.
Una volta superati tutti i test, esegui il deployment dell'app aggiornata in App Engine, ma impedisci il routing automatico alla nuova versione. Utilizza la suddivisione del traffico per migrare lentamente il traffico dall'app nel runtime Python 2 all'app nel runtime Python 3. In caso di problemi, puoi instradare tutto il traffico a una versione stabile finché il problema non viene risolto.
Per esempi su come convertire le 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 deriva dalle seguenti differenze tra i runtime Python 2 e Python 3:
- Problemi di compatibilità tra Python 2 e Python 3
- Servizi in bundle di App Engine nel runtime Python 3
- Differenze nei file di configurazione
- È necessario un framework web per indirizzare le richieste di contenuti dinamici
- App con solo contenuti statici
- Differenze nei test
- Differenze di deployment
Problemi di compatibilità tra Python 2 e Python 3
Quando Python 3 è stato rilasciato per la prima volta nel 2008, sono state introdotte diverse modifiche incompatibili con le versioni precedenti. Alcune di queste modifiche richiedono solo aggiornamenti di minore entità al codice, ad esempio la modifica dell'istruzione print
in una funzione print()
.
Altre modifiche potrebbero richiedere aggiornamenti significativi al codice, come l'aggiornamento delle modalità di gestione di dati binari, testo e stringhe.
Anche molte librerie open source popolari, incluse le librerie Python standard, sono cambiate quando sono passati da Python 2 a Python 3.
Servizi in bundle di App Engine nel runtime Python 3
Per ridurre lo sforzo e la complessità della migrazione, l'ambiente standard di App Engine consente di accedere a molti servizi e API in bundle legacy nel runtime Python 3, come Memcache. L'app Python 3 può chiamare le API dei servizi in bundle tramite librerie idiomatiche di linguaggio e accedere alle stesse funzionalità del runtime Python 2.
Hai anche la possibilità di utilizzare prodotti Google Cloud che offrono funzionalità simili a quelle dei servizi in bundle legacy. Ti consigliamo di eseguire la migrazione ai prodotti Google Cloud non in bundle, in quanto ciò ti consente di sfruttare i miglioramenti continui e le nuove funzionalità.
Per i servizi in bundle che non sono disponibili come prodotti separati in Google Cloud, ad esempio elaborazione di immagini, ricerca e messaggistica, puoi utilizzare i nostri fornitori di terze parti suggeriti o altre soluzioni alternative.
File di configurazione
Prima di poter eseguire l'app nel runtime Python 3 dell'ambiente standard di App Engine, potresti dover modificare alcuni dei file di configurazione utilizzati da App Engine:
app.yaml
. Il comportamento di alcuni campi nel file di configurazione diapp.yaml
è stato modificato. Rimuovi tutti 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 pacchetti Python che richiedono estensioni C native. App Engine installa automaticamente queste dipendenze durante il deployment dell'app nel runtime Python 3. In precedenza, per installare le dipendenze nel runtime Python 2, dovevi elencare le librerie copiate o auto-integrate in questo file, quindi eseguire un comandopip install -t lib -r requirements.txt
oppure elencare le librerie di terze parti "integrate" richieste dalla tua app nel file app.yaml.appengine_config.py
. Questo file non viene utilizzato nel runtime Python 3 e viene ignorato se viene eseguito il deployment. In precedenza, nel runtime di Python 2, questo file veniva utilizzato per configurare i moduli Python e indirizzare l'app a librerie di terze parti copiate o auto-integrate.
Framework web necessario per indirizzare le richieste di contenuti dinamici
Nel runtime Python 2, puoi creare gestori di URL nel file app.yaml
per specificare l'app da eseguire quando viene richiesto un URL o un pattern URL specifico.
Nel runtime Python 3, la tua app deve utilizzare un framework web come Flask o Django per instradare le richieste di contenuti dinamici anziché utilizzare gestori di URL in app.yaml
. Per i contenuti statici, puoi continuare a creare gestori URL nel file app.yaml
dell'app.
App con solo contenuti statici
Quando ospiti 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 nel file app.yaml
, App Engine restituisce un codice di errore 404
.
In Python 3, se una richiesta non corrisponde a nessuno dei gestori, App Engine cerca un file main.py
e restituisce un errore 5xx
se un file main.py
non viene trovato. Poiché le app di App Engine con solo contenuti statici non richiedono un file main.py
, la maggior parte degli utenti vede questo errore, oltre a visualizzare errori di avvio dell'istanza nei log delle app.
Per mantenere lo stesso comportamento di restituzione di un errore 404
quando nessuno dei gestori statici corrisponde ed evitare errori nei log, puoi:
- Aggiungi un gestore statico catch-all che punta a una directory vuota nel file
app.yaml
- Aggiungi una semplice app dinamica nel file
main.py
per restituire un errore404
Esempi di utilizzo di una delle due opzioni:
app.yaml
Crea una directory vuota nella directory principale dell'app, ad esempio empty/
.
Nella sezione del gestore del file app.yaml
, crea un nuovo gestore alla fine per rilevare tutti gli altri pattern URL e specifica la directory empty
negli 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 di Python anziché dipendere da dev_appserver
. Ad esempio, potresti utilizzare venv
per creare un ambiente Python 3 locale isolato. Qualsiasi framework di test Python standard può essere utilizzato per scrivere i test delle unità, dell'integrazione e del sistema. Potresti anche prendere in considerazione la configurazione di versioni di sviluppo dei tuoi servizi o utilizzare gli emulatori locali disponibili per molti prodotti Google Cloud.
Facoltativamente, puoi utilizzare la versione di anteprima di dev_appserver
che supporta Python 3. Per ulteriori informazioni su questa funzionalità di test, consulta Utilizzo del server di sviluppo locale.
Deployment in corso
I deployment tramite appcfg.py
non sono supportati per Python 3.
Utilizza invece lo strumento a riga di comando gcloud
per eseguire il deployment della tua app.
Logging
Il logging nel runtime Python 3 segue lo standard di logging in 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 scoprire di più sulla lettura e sulla scrittura di log nel runtime Python 3, consulta la guida alla registrazione.
Risorse aggiuntive per la migrazione
Per ulteriori informazioni su come eseguire la migrazione delle app di App Engine ai servizi Cloud autonomi o al runtime Python 3, puoi fare riferimento a queste risorse di App Engine:
- Codelab e video per la migrazione delle app serverless
- Esempi forniti dalla community di migrazione delle app da Python 2 a Python 3