La maggior parte delle funzionalità fornite dai servizi in bundle legacy è ora fornita dalle librerie client di Cloud. Per saperne di più, consulta le alternative consigliate elencate di seguito.
Se la migrazione a una soluzione non in bundle non è un'opzione per il tuo progetto, allora potresti continuare a utilizzare i servizi in bundle legacy nelle tue app Python 3 come fallback. Questo approccio ti offre la flessibilità di passare ai servizi non in bundle in un secondo momento nel ciclo di migrazione.
Dopo aver eseguito la migrazione dai servizi in bundle legacy, puoi continuare a utilizzare App Engine o eseguire la migrazione a Cloud Run. Cloud Run è progettato per migliorare l'esperienza di App Engine e incorpora molte delle migliori funzionalità sia dell'ambiente standard sia dell'ambiente flessibile. Per confrontare le funzionalità e capire come eseguire la migrazione, consulta la guida al confronto tra App Engine e Cloud Run.
Google Cloud fornisce prodotti autonomi che offrono funzionalità simili a quelle di alcuni dei servizi in bundle legacy nel runtime Python. Per i servizi in bundle legacy che non sono disponibili come prodotti separati in Google Cloud, ad esempio, posta e messaggistica, questa guida consiglia provider di terze parti o altre soluzioni alternative.
Questa pagina introduce il percorso di migrazione per i servizi in bundle legacy.
Comprendere le Google Cloud autorizzazioni
L'app di cui è stata eseguita la migrazione e i Google Cloud servizi che utilizza non vengono eseguiti nello stesso ambiente sandbox e la tua app richiede l'autorizzazione per accedere a ogni servizio. Ad esempio, per interagire con Firestore in modalità Datastore (Datastore) o Cloud Tasks, la tua app deve fornire le credenziali di un account autorizzato ad accedere a questi servizi.
Per impostazione predefinita, le app in esecuzione nell'ambiente standard di App Engine forniscono le credenziali del service account App Engine predefinito, autorizzato ad accedere ai database nello stesso progetto dell'app.
Se è vera una delle seguenti condizioni, utilizza un metodo di autenticazione alternativo che fornisca esplicitamente le credenziali:
L'app e il database Memorystore si trovano in progetti diversi. Google Cloud
Hai modificato i ruoli assegnati al account di servizio App Engine predefinito.
Per informazioni sui metodi di autenticazione alternativi, consulta Configurare l'autenticazione per le applicazioni di produzione server-server.
Autenticazione per lo sviluppo locale
Per sviluppare o testare l'app in locale, crea e utilizza un account di servizio. Non utilizzare il service account App Engine predefinito perché dispone di autorizzazioni ampie per il tuo progetto. Crea e utilizza invece un account di servizio con le autorizzazioni minime necessarie per le attività di sviluppo e test specifiche.
Per configurare un account di servizio e collegarlo alla tua app, consulta Ottenere e fornire manualmente le credenziali account di servizio account.
Installazione delle librerie client
Per utilizzare i Google Cloud servizi da un'app Python, installa la libreria client Python per il servizio. Google Cloud I servizi forniscono anche API REST e altre interfacce.
Per installare una libreria client per il runtime Python 3:
Aggiungi il nome della libreria al file
requirements.txtdell'app. Ad esempio:google-cloud-ndb
App Engine carica automaticamente tutte le librerie elencate nel file requirements.txt nel runtime Python 3.
Percorsi di migrazione per i servizi in bundle di App Engine
Blobstore
Per archiviare e recuperare i dati, utilizza Cloud Storage tramite le librerie client di Cloud. Per iniziare, consulta Utilizzare Cloud Storage e la guida Eseguire la migrazione da Blobstore a Cloud Storage. Per simulare questa migrazione, aggiungi l'utilizzo di Blobstore a un'app di esempio e esegui la migrazione a Cloud Storage.
Datastore
Se la tua app Python 2 utilizza NDB per interagire con Datastore, esegui la migrazione alla libreria Cloud NDB. Cloud NDB è pensato principalmente come strumento di transizione per la migrazione delle app Python 2. Ti consigliamo di utilizzare la libreria client in modalità Datastore per le app Python 3.
Per saperne di più, consulta Eseguire la migrazione a Cloud NDB. Per simulare questa migrazione con un'app di esempio, consulta Eseguire la migrazione da App Engine ndb a Cloud NDB.
Immagini
Per eseguire la migrazione del servizio Immagini di App Engine, esegui il deployment di un servizio di trasformazione delle immagini containerizzato su Cloud Run e indirizza le chiamate al servizio Immagini di App Engine. Per ospitare e pubblicare le immagini, archiviale in un bucket Cloud Storage o distribuiscile utilizzando Cloud CDN. Per saperne di più, consulta Eseguire la migrazione del servizio Immagini.Logging
Ti consigliamo di aggiornare l'app per utilizzare Cloud Logging, che supporta funzionalità come la visualizzazione dei log in Esplora log, il download dei log, il filtro dei messaggi in base alla gravità e la correlazione dei messaggi dell'app con richieste specifiche. In alternativa, se preferisci la semplicità alla precisione dei dati, puoi scrivere log strutturati in stdout o stderr.
Per saperne di più, consulta
Scrivere e visualizzare i log ed Eseguire la migrazione a Cloud Logging.
Posta
Per migliorare la sicurezza delle email e garantire una consegna di email affidabile e ad alto volume, ti consigliamo di eseguire la migrazione dall'API Mail legacy a un servizio email basato su SMTP, come SendGrid, Mailgun o Mailjet.Memcache
Per memorizzare nella cache i dati dell'applicazione, utilizza Memorystore for Redis.
Per saperne di più, consulta Eseguire la migrazione di Memcache a Memorystore. Per simulare questa migrazione, aggiungi l'utilizzo di Memcache a un'app di esempio ed esegui la migrazione a Memorystore for Redis.
Per le app che utilizzano Memcache solo per ridurre la latenza delle richieste NDB (o Cloud NDB), utilizza il supporto integrato di Cloud NDB per Redis anziché Memcache o Memorystore for Redis.
Moduli
Per ottenere informazioni e modificare i servizi in esecuzione dell'applicazione, utilizza una combinazione di variabili di ambiente e l'API App Engine Admin:
| Informazioni sul servizio | Come accedere |
|---|---|
| ID applicazione corrente | Variabile di ambiente GAE_APPLICATION |
| ID progetto corrente | Variabile di ambiente GOOGLE_CLOUD_PROJECT |
| Nome del servizio corrente | Variabile di ambiente GAE_SERVICE |
| Versione del servizio corrente | Variabile di ambiente GAE_VERSION |
| ID istanza corrente | Variabile di ambiente GAE_INSTANCE |
| Nome host predefinito | Metodo apps.get dell'API Admin |
| Elenco di servizi | Metodo apps.services.list dell'API Admin |
| Elenco delle versioni di un servizio | Metodo apps.services.versions.list dell'API Admin |
| Versione predefinita di un servizio, inclusi eventuali split del traffico | Metodo apps.services.get dell'API Admin |
| Elenco delle istanze in esecuzione per una versione | Metodo apps.services.versions.instances.list dell'API Admin |
Per saperne di più sui dati disponibili sui servizi in esecuzione dell'applicazione, consulta Python 3 runtime environment.
Spazi dei nomi
L'API Namespaces consente alle app multitenant di partizionare i dati tra i tenant semplicemente specificando una stringa di spazio dei nomi univoca per ogni tenant.
Sebbene Datastore supporti la multitenancy direttamente, altri Google Cloud servizi non lo fanno. Se la tua app multitenant utilizza altri Google Cloud servizi, dovrai gestire manualmente la multitenancy. Per avere istanze di servizi completamente isolate, puoi creare nuovi progetti a livello di programmazione utilizzando l'API Cloud Resource Manager e accedere alle risorse tra i progetti.
OAuth
Anziché utilizzare il servizio OAuth di App Engine per verificare i token OAuth 2.0,
utilizza il
oauth2.tokeninfo
metodo dell'
API OAuth 2.0.
Cerca
Ospita qualsiasi database di ricerca full-text, come Elasticsearch, su Compute Engine e accedi da un servizio.
Coda di attività
Il servizio Coda di attività di App Engine è disponibile in due modalità diverse. La migrazione da entrambi i punti verso due diversi prodotti Cloud autonomi.
Attività push
Anziché utilizzare il servizio di attività push della coda di attività di App Engine per l'esecuzione asincrona del codice, utilizza Cloud Tasks librerie client con un endpoint dell'ambiente standard Python 3 come target. Per saperne di più, consulta Eseguire la migrazione delle code push a Cloud Tasks.
Per simulare questa migrazione con un'app di esempio, consulta Come utilizzare le code push di App Engine nelle app Flask ed eseguire la migrazione a Cloud Tasks.
Attività pull
Se utilizzi il servizio di attività pull della coda di attività, ad esempio, per accodare attività o messaggi da elaborare da worker separati, Cloud Pub/Sub può essere una buona alternativa. Offre funzionalità e garanzie di consegna simili. Come altri servizi Cloud, Pub/Sub fornisce client librerie pratiche per accedere al servizio. Per saperne di più, consulta Scrivere e rispondere ai messaggi Pub/Sub e la guida alla migrazione delle attività pull della coda di attività a Pub/Sub.
Per simulare questa migrazione con un'app di esempio, consulta Come utilizzare le attività pull di App Engine in un'app di esempio e eseguire la migrazione a Pub/Sub.
Recupero URL
Per impostazione predefinita, il runtime Python 2.7 utilizza il servizio Recupero URL per gestire le richieste HTTP(S) in uscita, anche se utilizzi le librerie Python standard per inviare queste richieste.
Se la tua app utilizza direttamente le API Recupero URL, ad esempio per effettuare richieste asincrone, ti consigliamo di eseguire la migrazione a una libreria Python standard come la libreria Requests.
Per saperne di più, consulta Eseguire la migrazione delle richieste in uscita.
Autenticazione degli utenti
Per un'alternativa all'API Users, utilizza uno dei meccanismi di autenticazione basati su HTTP descritti nella pagina Autenticazione degli utenti.