Località App Engine
App Engine è regionale, il che significa che l'infrastruttura che esegue le tue app si trova in una regione specifica e Google la gestisce in modo che sia disponibile in modo ridondante in tutte le zone della regione.
Soddisfare i requisiti di latenza, disponibilità o durabilità è uno dei fattori principali per la scelta della regione in cui vengono eseguite le app. In genere, puoi selezionare la regione più vicina agli utenti della tua app, ma devi prendere in considerazione le località in cui è disponibile App Engine, nonché le località degli altri prodotti e servizi Google Cloud utilizzati dalla tua app. L'utilizzo di servizi in più località può influire sulla latenza e sul prezzo della tua app.
Non puoi modificare la regione di un'app dopo averla impostata.
Se hai già creato un'applicazione App Engine, puoi visualizzarne la regione effettuando una delle seguenti operazioni:
Esegui il comando
gcloud app describe
.Apri la dashboard di App Engine nella console Google Cloud. La regione viene visualizzata nella parte superiore della pagina.
Cloud NDB è una libreria client per Python che sostituisce App Engine NDB. App Engine NDB consente alle app Python 2 di archiviare ed eseguire query sui dati nei database Datastore. Cloud NDB consente alle app Python 2 e Python 3 di archiviare ed eseguire query sui dati negli stessi database, ma il prodotto che gestisce questi database è passato da Datastore a Firestore in modalità Datastore. Sebbene la libreria Cloud NDB possa accedere a tutti i dati creati con App Engine NDB, non è possibile accedere ad alcuni tipi di dati strutturati archiviati utilizzando Cloud NDB con App Engine NDB. Per questo motivo, la migrazione a Cloud NDB deve essere considerata irreversibile.
Ti consigliamo di eseguire la migrazione a Cloud NDB prima di eseguire l'upgrade della tua app a Python 3. Questo approccio incrementale alla migrazione consente di mantenere un'app funzionante e testabile durante la procedura di migrazione.
Cloud NDB è progettato per sostituire le funzionalità di App Engine NDB, pertanto non supporterà le nuove funzionalità di Firestore in modalità Datastore. Consigliamo alle nuove app Python 3 di utilizzare la libreria client in modalità Datastore invece di Cloud NDB.
Per saperne di più su Cloud NDB, consulta le seguenti pagine su GitHub:
Confronto tra App Engine NDB e Cloud NDB
Analogie:
- Cloud NDB supporta quasi tutte le funzionalità supportate da App Engine NDB con solo piccole differenze nella sintassi dei metodi.
Differenze:
Le API App Engine NDB che si basano su servizi specifici per il runtime di App Engine Python 2.7 sono state aggiornate o rimosse da Cloud NDB.
Le nuove funzionalità di Python 3 e Django hanno eliminato la necessità di
google.appengine.ext.ndb.django_middleware
. In alternativa, puoi scrivere facilmente il tuo middleware con poche righe di codice.NDB di App Engine richiedeva che le app e il database Datastore fossero nello stesso progetto Google Cloud, con App Engine che forniva automaticamente le credenziali. Cloud NDB può accedere ai database in modalità Datastore in qualsiasi progetto, a condizione che tu autentichi correttamente il client. Questo è coerente con altre API e librerie client di Google Cloud.
Cloud NDB non utilizza il servizio Memcache di App Engine per memorizzare nella cache i dati.
Cloud NDB può invece memorizzare nella cache i dati in un datastore in memoria Redis gestito da Memorystore, Redis Labs o altri sistemi. Anche se al momento sono supportati solo gli archivi dati Redis, Cloud NDB ha generalizzato e definito la memorizzazione nella cache nell'interfaccia astratta
GlobalCache
, che può supportare ulteriori implementazioni concrete.Per accedere a Memorystore for Redis, l'app deve utilizzare Accesso VPC serverless.
Né Memorystore for Redis né l'accesso VPC serverless forniscono un livello gratuito e questi prodotti potrebbero non essere disponibili nella regione della tua app. Per ulteriori informazioni, consulta la sezione Prima di iniziare la migrazione.
L'elenco completo delle differenze è disponibile nelle note sulla migrazione per il progetto GitHub Cloud NDB.
Esempi di codice:
Operazioni di base del database utilizzando App Engine NDB
Operazioni di base del database utilizzando Cloud NDB
Prima di iniziare la migrazione
Prima di iniziare la migrazione:
Se non l'hai ancora fatto, configura il tuo ambiente di sviluppo Python per utilizzare una versione di Python compatibile con Google Cloud e installa gli strumenti di test per creare ambienti Python isolati.
Se devi memorizzare nella cache i dati, assicurati che la regione della tua app sia supportata da Accesso VPC serverless e Memorystore for Redis.
Determinare se è necessario memorizzare nella cache i dati
Se la tua app deve memorizzare nella cache i dati, tieni presente che Memorystore per Redis e Accesso VPC serverless non hanno un livello gratuito e non supportano tutte le regioni Google Cloud.
In generale:
Se la tua app legge spesso gli stessi dati, la memorizzazione nella cache potrebbe ridurre la latenza.
Più richieste vengono inviate dalla tua app, maggiore sarà l'impatto della memorizzazione nella cache.
Per sapere quanto attualmente fai affidamento sui dati memorizzati nella cache, visualizza la dashboard Memcache per vedere il rapporto tra hit e miss della cache. Se il rapporto è elevato, l'utilizzo di una cache di dati potrebbe avere un grande impatto sulla riduzione della latenza dell'app.
Per informazioni sui prezzi, consulta Prezzi di Memorystore e Prezzi dell'accesso VPC Serverless.
Conferma della regione dell'app
Se devi memorizzare nella cache i dati, assicurati che la regione della tua app sia supportata da Memorystore for Redis e dall'accesso VPC serverless:
Visualizza la regione della tua app, che viene visualizzata nella parte superiore della dashboard di App Engine nella console Google Cloud.
La regione viene visualizzata nella parte superiore della pagina, appena sotto l'URL dell'app.
Verifica che la tua app si trovi in una delle regioni supportate da Accesso VPC serverless.
Verifica che la tua app si trovi in una delle regioni supportate da Memorystore per Redis visitando la pagina Crea connettore e visualizzando le regioni nell'elenco Regioni.
Se la tua app non si trova in una regione supportata da Memorystore for Redis e Accesso VPC serverless:
Crea un progetto Google Cloud.
Crea una nuova app App Engine nel progetto e seleziona una regione supportata.
Crea i servizi Google Cloud utilizzati dalla tua app nel nuovo progetto.
In alternativa, puoi aggiornare l'app in modo da utilizzare i servizi esistenti nel tuo vecchio progetto, ma i prezzi e l'utilizzo delle risorse potrebbero essere diversi se utilizzi i servizi in un progetto e in una regione diversi. Per ulteriori informazioni, consulta la documentazione di ciascun servizio.
Esegui il deployment dell'app nel nuovo progetto.
Informazioni sulle autorizzazioni per la modalità Datastore
Ogni interazione con un servizio Google Cloud deve essere autorizzata. Ad esempio, per archiviare o eseguire query sui dati in un database in modalità Datastore, la tua app deve fornire le credenziali di un account autorizzato ad accedere al database.
Per impostazione predefinita, l'app fornisce le credenziali dell'account di servizio predefinito di App Engine, che è autorizzato ad accedere ai database nello stesso progetto dell'app.
Dovrai utilizzare una tecnica di autenticazione alternativa che fornisca esplicitamente le credenziali se una delle seguenti condizioni è vera:
L'app e il database in modalità Datastore si trovano in progetti Google Cloud diversi.
Hai modificato i ruoli assegnati all'account di servizio App Engine predefinito.
Per informazioni sulle tecniche di autenticazione alternativa, consulta Configurare l'autenticazione per le applicazioni di produzione server-to-server.
Panoramica del processo di migrazione
Per eseguire la migrazione a Cloud NDB:
-
Installa la libreria client Cloud NDB.
Aggiorna le istruzioni di importazione per importare i moduli da Cloud NDB.
Aggiungi il codice che crea un client Cloud NDB. Il client può leggere le variabili di ambiente dell'app e utilizzare i dati per autenticarsi con la modalità Datastore.
Aggiungi codice che utilizzi il contesto di runtime del client per mantenere la memorizzazione nella cache e le transazioni separate tra i thread.
Rimuovi o aggiorna il codice che utilizza metodi e proprietà non più supportati.
Esegui il deployment dell'app in App Engine.
Come per qualsiasi modifica apportata all'app, ti consigliamo di utilizzare la suddivisione del traffico per aumentare gradualmente il traffico. Monitora attentamente l'app per rilevare eventuali problemi del database prima di indirizzare più traffico all'app aggiornata.
Aggiornamento dell'app Python
Installazione della libreria Cloud NDB per le app Python
Per installare la libreria client Cloud NDB nella tua app App Engine Python:
Aggiorna il file
app.yaml
. Segui le istruzioni relative alla tua versione di Python:Python 2
Per le app Python 2, aggiungi le versioni più recenti delle librerie
grpcio
esetuptools
.Di seguito è riportato un esempio di file
app.yaml
:runtime: python27 threadsafe: yes api_version: 1 libraries: - name: grpcio version: latest - name: setuptools version: latest
Python 3
Per le app Python 3, specifica l'elemento
runtime
con una versione di Python 3 supportata ed elimina le righe non necessarie. Ad esempio, il fileapp.yaml
potrebbe avere il seguente aspetto:runtime: python310 # or another support version
Il runtime Python 3 installa le librerie automaticamente, quindi non è necessario specificare le librerie integrate del runtime Python 2 precedente. Se la tua app Python 3 utilizza altri servizi legacy raggruppati durante la migrazione, lascia invariato il file
app.yaml
.Aggiorna il file
requirements.txt
. Segui le istruzioni relative alla tua versione di Python:Python 2
Aggiungi le librerie client di Cloud per Cloud NDB all'elenco delle dipendenze nel file
requirements.txt
.google-cloud-ndb
Quindi, esegui
pip install -t lib -r requirements.txt
per aggiornare l'elenco delle librerie disponibili per la tua app.Python 3
Aggiungi le librerie client di Cloud per Cloud NDB all'elenco delle dipendenze nel file
requirements.txt
.google-cloud-ndb
App Engine installa automaticamente queste dipendenze durante il deployment dell'app nel runtime di Python 3, quindi elimina la cartella
lib
, se esistente.Per le app Python 2, se la tua app utilizza librerie integrate o copiate specificate nella directory
lib
, devi specificare questi percorsi nel fileappengine_config.py
:import pkg_resources from google.appengine.ext import vendor # Set PATH to your libraries folder. PATH = 'lib' # Add libraries installed in the PATH folder. vendor.add(PATH) # Add libraries to pkg_resources working set to find the distribution. pkg_resources.working_set.add_entry(PATH)
Assicurati di utilizzare il modulo
pkg_resources
, che garantisce che la tua app utilizzi la distribuzione corretta delle librerie client.Il file
appengine_config.py
nell'esempio precedente presuppone che lalib
cartella si trovi nella directory di lavoro corrente. Se non puoi garantire chelib
sarà sempre nella directory di lavoro corrente, specifica il percorso completo della cartellalib
. Ad esempio:import os path = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'lib')
Quando esegui il deployment dell'app, App Engine carica tutte le librerie nella directory specificata nel file
appengine_config.py
.
Aggiornamento delle istruzioni di importazione
La posizione del modulo NDB è stata spostata in
google.cloud.ndb
. Aggiorna le istruzioni di importazione dell'app come mostrato
nella seguente tabella:
Rimuovi | Sostituisci con |
---|---|
from google.appengine.ext import ndb |
from google.cloud import ndb |
Creazione di un client Cloud NDB
Come per le altre librerie client basate sulle API Google Cloud, il primo
passaggio per utilizzare Cloud NDB è creare un Client
oggetto. Il client contiene le credenziali e altri
dati necessari per connettersi alla modalità Datastore. Ad esempio:
from google.cloud import ndb
client = ndb.Client()
Nello scenario di autorizzazione predefinito descritto in precedenza, il client Cloud NDB contiene le credenziali dell'account di servizio predefinito di App Engine, che è autorizzato a interagire con la modalità Datastore. Se non utilizzi questo scenario predefinito, consulta Credenziali predefinite dell'applicazione (ADC) per informazioni su come fornire le credenziali.
Utilizzo del contesto di runtime del client
Oltre a fornire le credenziali necessarie per interagire con la modalità Datastore, il client Cloud NDB contiene il metodo context()
che restituisce un contesto di runtime.
Il contesto di runtime isola le richieste di memorizzazione nella cache e di transazione da altre interazioni con la modalità Datastore in contemporanea.
Tutte le interazioni con la modalità Datastore devono avvenire in un contesto di runtime NDB. Poiché la creazione di una definizione del modello non interagisce con la modalità Datastore, puoi definire la classe del modello prima di creare un client Cloud NDB e recuperare un contesto di runtime, quindi utilizzare il contesto di runtime nel gestore delle richieste per recuperare i dati dal database.
Ad esempio:
App multithread
Il contesto di runtime restituito dal client Cloud NDB si applica solo a un singolo thread. Se la tua app utilizza più thread per una singola richiesta, devi recuperare un contesto di runtime separato per ogni thread che utilizzerà la libreria Cloud NDB.
Utilizzo di un contesto di runtime con i framework WSGI
Se la tua app web utilizza un framework WSGI, puoi creare automaticamente un nuovo contesto di runtime per ogni richiesta creando un oggetto middleware che recupera il contesto di runtime e poi avvolgendo l'app nell'oggetto middleware.
Nel seguente esempio di utilizzo del middleware con Flask:
Il metodo
middleware
crea un oggetto middleware WSGI nel contesto di runtime del client NDB.L'app Flask è racchiusa nell'oggetto middleware.
Flask passerà quindi ogni richiesta all'oggetto middleware, che recupera un nuovo contesto di runtime NDB per ogni richiesta.
Utilizzo di un contesto di runtime con Django
Il middleware Django fornito dalla libreria App Engine NDB
non è supportato dalla libreria Cloud NDB. Se hai utilizzato questo middleware
(google.appengine.ext.ndb.django_middleware
) nella tua app, segui questi passaggi
per aggiornarla:
Utilizza il sistema di middleware di Django per creare un nuovo contesto di runtime per ogni richiesta.
Nel seguente esempio:
Il metodo
ndb_django_middleware
crea un client Cloud NDB.Il metodo
middleware
crea un oggetto middleware nel contesto di runtime del client NDB.
Nel file Django settings.py, aggiorna l'impostazione
MIDDLEWARE
in modo che elenchi il nuovo middleware che hai creato anzichégoogle.appengine.ext.ndb.NdbDjangoMiddleware
.
Ora Django passerà ogni richiesta all'oggetto middleware elencato nell'impostazione MIDDLEWARE
, che recupererà un nuovo contesto di runtime NDB per ogni richiesta.
Aggiornamento del codice per le API NDB rimosse o modificate
Le API NDB che si basano su API e servizi specifici di App Engine sono state aggiornate o rimosse dalla libreria Cloud NDB.
Dovrai aggiornare il codice se utilizza una delle seguenti API NDB:
google.appengine.ext.ndb.Model
e proprietà del modellogoogle.appengine.ext.ndb.Key
google.appengine.ext.ndb.query.QueryOptions
ePropertyOrder
google.appengine.ext.ndb.utils
google.appengine.api.namespacemanager
google.appengine.api.ext.ndb.tasklets
google.appengine.api.datastore_errors
Modelli e proprietà Model
I seguenti metodi di
google.appengine.ext.ndb.Model
non sono disponibili nella libreria Cloud NDB perché utilizzano
API specifiche di App Engine che non sono più disponibili.
API rimossa | Sostituzione |
---|---|
Model.get_indexes e Model.get_indexes_async
|
Nessuno |
Model._deserialize e Model._serialize
|
Nessuno |
Model.make_connection
|
Nessuno |
La tabella seguente descrive le proprietà specifiche di google.appengine.ext.ndb.Model
che sono cambiate nella libreria NDB di Cloud:
Proprietà | Cambia |
---|---|
TextProperty
|
google.cloud.ndb.TextProperty non può essere indicizzato. Se
provi a impostare google.cloud.ndb.TextProperty.indexed ,
verrà generato un NotImplementedError .
|
StringProperty
|
StringProperty è sempre indicizzato. Se provi a impostare
google.cloud.ndb.StringProperty.indexed , verrà generato un
NotImplementedError .
|
Tutte le proprietà con argomenti name o kind nel
costruttore.
|
name o kind devono essere tipi di dati str ,
poiché unicode è stato sostituito da str in Python 3.
|
Le classi e i metodi nella tabella seguente non sono più disponibili perché utilizzano risorse specifiche di App Engine che non sono più disponibili.
API rimossa | Sostituzione |
---|---|
google.appengine.ext.ndb.msgprop.MessageProperty e google.appengine.ext.ndb.msgprop.EnumProperty
|
Nessuno
Se provi a creare questi oggetti, verrà generato un |
da
google.appengine.ext.ndb.model.Property :_db_get_value _db_set_value _db_set_compressed_meaning _db_set_uncompressed_meaning __creation_counter_global
|
Nessuno
Questi metodi si basano su buffer di protocollo della modalità Datastore che sono stati modificati. |
Model.make_connection
|
Nessuno |
Chiavi
I seguenti metodi di
google.appengine.ext.ndb.Key
non sono disponibili nella libreria Cloud NDB. Questi metodi venivano utilizzati per trasmettere chiavi all'API Datastore DB e viceversa, che non è più supportata (DB era il predecessore di App Engine NDB).
API rimossa | Sostituzione |
---|---|
Key.from_old_key e Key.to_old_key
|
Nessuno |
Inoltre, tieni presente le seguenti modifiche:
NDB di App Engine | Cloud NDB |
---|---|
I tipi e gli ID stringa devono essere inferiori a 500 byte | I tipi e gli ID stringa devono essere inferiori a 1500 byte. |
Key.app() restituisce l'ID progetto specificato quando hai creato la chiave.
|
Il valore restituito da
google.cloud.ndb.Key.app() potrebbe essere diverso dall'ID
originale passato al costruttore. Questo perché gli ID app con prefisso come
s~example sono identificatori precedenti di App Engine.
Sono stati sostituiti da ID progetto equivalenti, ad esempio
example.
|
Query
Come App Engine NDB, Cloud NDB fornisce una classe QueryOptions
(google.cloud.ndb.query.QueryOptions
) che consente di riutilizzare un insieme specifico di
opzioni di query anziché ridefinirle per ogni query. Tuttavia, QueryOptions
in Cloud NDB non eredita da
google.appengine.datastore.datastore_rpc.Configuration
e pertanto non supporta i metodi ...datastore_rpc.Configuration
.
Inoltre, google.appengine.datastore.datastore_query.Order
è stato
sostituito con
google.cloud.ndb.query.PropertyOrder
. Analogamente a Order
, la classe PropertyOrder
consente di specificare l'ordinamento in più query. Il costruttore di PropertyOrder
è uguale a quello di Order
. È cambiato solo il nome del
corso.
API rimossa | Sostituzione |
---|---|
from google.appengine.datastore.datastore_rpc.Configuration :deadline(value) on_completion(value) read_policy(value) force_writes(value) max_entity_groups_per_rpc(value) max_allocate_ids_keys(value) max_rpc_bytes(value) max_get_keys(value) max_put_entities(value) max_delete_keys(value)
Consulta il codice sorgente per una descrizione di questi metodi. |
Nessuno |
google.appengine.ext.ndb.Order Ad esempio: order=Order(-Account.birthday, Account.name)
|
google.cloud.ndb.PropertyOrder Ad esempio: google.cloud.ndb.PropertyOrder(-Account.birthday, Account.name)
|
Utils
Il modulo ndb.utils
(google.appengine.ext.ndb.utils
) non è più disponibile. La maggior parte dei metodi di questo modulo era interna a
App Engine NDB, alcuni metodi sono stati eliminati a causa di differenze di implementazione
nel nuovo ndb, mentre altri metodi sono stati resi obsoleti dalle nuove
funzionalità di Python 3.
Ad esempio, il decoratore posizionale nel vecchio modulo utils
dichiarava che solo
i primi n argomenti di una funzione o di un metodo potevano essere posizionali. Tuttavia, Python
3 può farlo utilizzando
argomenti solo per parole chiave. In precedenza era scritto:
@utils.positional(2)
def function1(arg1, arg2, arg3=None, arg4=None)
pass
In Python 3 può essere scritto come segue:
def function1(arg1, arg2, *, arg3=None, arg4=None)
pass
Spazi dei nomi
Gli spazi dei nomi consentono a un'applicazione multi-tenant di utilizzare silos di dati separati per ogni tenant, continuando a utilizzare lo stesso database in modalità Datastore. In altre parole, ogni tenant archivia i dati nel proprio spazio dei nomi.
Anziché utilizzare google.appengine.api.namespacemanager
specifico per App Engine, specifica uno spazio dei nomi predefinito quando crei un client Cloud NDB e poi utilizzalo chiamando i metodi Cloud NDB nel contesto di runtime del client. Segue lo stesso schema di altre API Google Cloud che supportano i namespace.
API rimossa | Sostituzione |
---|---|
google.appengine.api.namespace_manager.namespace_manager.set_namespace(str)
e google.appengine.api.namespacemanager.getnamespace()
|
client=google.cloud.ndb.Client(namespace="my namespace") with client.context() as context: key = ndb.Key("SomeKind", "SomeId") key-non-default-namespace=ndb.Key("SomeKind," "AnotherId", namespace="non-default-nspace") |
Tutti gli altri metodi google.appengine.api.namespacemanager |
Nessuno |
Tasklet
Ora i tasklet possono utilizzare un'istruzione return
standard per
restituire un risultato anziché sollevare un'eccezione Return
. Ad esempio:
Libreria NDB di App Engine | Libreria Cloud NDB |
---|---|
@ndb.tasklet def get_cart(): cart = yield CartItem.query().fetch_async() raise Return(cart) |
@ndb.tasklet def get_cart(): cart = yield CartItem.query().fetch_async() return cart |
Tieni presente che puoi comunque restituire risultati in Cloud NDB sollevando un'Return
eccezione, ma questa operazione non è consigliata.
Inoltre, i seguenti metodi e sottoclassi Tasklets
non sono più disponibili, principalmente a causa delle modifiche al modo in cui viene creato e utilizzato un contesto NDB nella libreria Cloud NDB.
API rimossa | Sostituzione |
---|---|
da
google.appengine.api.ext.ndb.tasklets :add_flow_exception make_context make_default_context set_context
|
Nessuno |
da
google.appengine.api.ext.ndb.tasklets :QueueFuture ReducedFuture SerialQueueFuture
|
Nessuno |
Eccezioni
Sebbene il google.cloud.ndb.exceptions
modulo nella libreria Cloud NDB contenga molte delle
stesse eccezioni della libreria App Engine NDB, non tutte le vecchie
eccezioni sono disponibili nella nuova libreria. La tabella seguente elenca le eccezioni non più disponibili:
API rimossa | Sostituzione |
---|---|
da
google.appengine.api.datastore_errors :BadKeyError BadPropertyError CommittedButStillApplying EntityNotFoundError InternalError NeedIndexError QueryNotFoundError ReferencePropertyResolveError Timeout TransactionFailedError TransactionNotFoundError
|
google.cloud.ndb.exceptions |
Attivazione della memorizzazione nella cache dei dati
Cloud NDB può memorizzare nella cache i dati in un datastore in memoria Redis gestito da Memorystore, Redis Labs o altri sistemi. Questa guida descrive come utilizzare Memorystore for Redis per memorizzare nella cache i dati:
Configurazione dell'accesso VPC serverless
L'app può comunicare con Memorystore solo tramite un connettore di accesso VPC serverless. Per configurare un connettore di accesso VPC serverless:
Configurazione di Memorystore for Redis
Per configurare Memorystore for Redis:
Crea un'istanza Redis in Memorystore. Quando crei l'istanza:
In Regione, seleziona la stessa regione in cui si trova la tua app App Engine.
In Rete autorizzata, seleziona la stessa rete utilizzata dal connettore di accesso VPC serverless.
Prendi nota dell'indirizzo IP e del numero di porta dell'istanza Redis creata. Utilizzerai queste informazioni quando abiliti la memorizzazione nella cache dei dati per Cloud NDB.
Assicurati di utilizzare il comando
gcloud beta
per eseguire il deployment degli aggiornamenti dell'app. Solo il comando beta può aggiornare l'app in modo che utilizzi un connettore VPC.
Aggiunta dell'URL di connessione Redis
Puoi connetterti alla cache Redis aggiungendo la variabile di ambiente REDIS_CACHE_URL
al file app.yaml
dell'app. Il valore
di REDIS_CACHE_URL
ha il seguente formato:
redis://IP address for your instance:port
Ad esempio, puoi aggiungere le seguenti righe al file app.yaml
dell'app:
env_variables:
REDIS_CACHE_URL: redis://10.0.0.3:6379
Creazione e utilizzo di un oggetto cache Redis
Se hai impostato REDIS_CACHE_URL
come variabile di ambiente, puoi creare un oggetto RedisCache con una singola riga di codice, quindi utilizzare la cache passandola a Client.context()
quando configuri il contesto di runtime:
client = ndb.Client()
global_cache = ndb.RedisCache.from_environment()
with client.context(global_cache=global_cache):
books = Book.query()
for book in books:
print(book.to_dict())
Se non imposti REDIS_CACHE_URL
come variabile di ambiente, dovrai
costruire un client Redis e passarlo al constructor ndb.RedisCache()
. Ad esempio:
global_cache = ndb.RedisCache(redis.StrictRedis(host=IP-address, port=redis_port))
Tieni presente che non è necessario dichiarare una dipendenza dalla libreria client Redis, poiché la libreria Cloud NDB dipende già dalla libreria client Redis.
Consulta l'applicazione di esempio di Memorystore per un esempio di creazione di un client Redis.
Testare gli aggiornamenti
Per configurare un database di test ed eseguire l'app localmente prima di eseguirne il deployment in App Engine:
Esegui l'emulatore locale in modalità Datastore per archiviare e recuperare i dati.
Assicurati di seguire le istruzioni per l'impostazione delle variabili di ambiente in modo che l'app si connetta all'emulatore anziché all'ambiente di produzione in modalità Datastore.
Puoi anche importare i dati nell'emulatore se vuoi avviare il test con i dati precaricati nel database.
Utilizza il server di sviluppo locale per eseguire l'app.
Per assicurarti che la variabile di ambiente
GOOGLE_CLOUD_PROJECT
sia impostata correttamente durante lo sviluppo locale, inizializzadev_appserver
utilizzando il seguente parametro:--application=PROJECT_ID
Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud. Puoi trovare l'ID progetto eseguendo il comando
gcloud config list project
o consultando la pagina del progetto nella console Google Cloud.
Deployment dell'app
Una volta che l'app è in esecuzione nel server di sviluppo locale senza errori:
Se l'app funziona senza errori, utilizza la suddivisione del traffico per aumentare gradualmente il traffico per l'app aggiornata. Monitora attentamente l'app per rilevare eventuali problemi di database prima di indirizzare più traffico all'app aggiornata.
Passaggi successivi
- Per un tutorial pratico, consulta il codelab Esegui la migrazione da App Engine NDB a Cloud NDB.
- Per ulteriori dettagli, consulta la documentazione di Cloud NDB.