Migrazione al runtime Python 3

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:

  1. 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.

  2. Scegli una di queste strategie di implementazione per qualsiasi servizio in bundle di App Engine utilizzato dalla tua app:

    1. 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.

    2. 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.

  3. 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 in app.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 gestori script in app.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.

  4. 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

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:

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 errore 404

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: