Migrazione a Cloud NDB

Località App Engine

App Engine ha una regione, vale a dire che l'infrastruttura che esegue le tue app si trova in una regione specifica, mentre Google la gestisce in modo che sia disponibile in modo ridondante in tutte le zone all'interno della regione.

Soddisfare i requisiti di latenza, disponibilità o durabilità sono fattori principali per la selezione della regione in cui vengono eseguite le app. In genere, puoi selezionare l'area geografica più vicina agli utenti della tua app, ma dovresti considerare le località in cui è disponibile App Engine nonché le località degli altri prodotti e servizi Google Cloud utilizzati dalla tua app. L'utilizzo dei servizi in più località può influire sulla latenza dell'app e sui relativi prezzi.

Non puoi modificare la regione di un'app dopo averla impostata.

Se hai già creato un'applicazione App Engine, puoi visualizzarne la regione eseguendo una delle seguenti operazioni:

Cloud NDB è una libreria client per Python che sostituisce App Engine NDB.

L'NDB di App Engine consente alle app Python 2 di archiviare ed eseguire query sui dati nei database Firestore in modalità Datastore (Datastore). Cloud NDB consente alle app Python 3 di archiviare ed eseguire query sui dati negli stessi database e utilizza Datastore come prodotto che gestisce tali database. Sebbene la libreria NDB di Cloud possa accedere a tutti i dati creati con NDB di App Engine, alcuni tipi di dati strutturati archiviati utilizzando Cloud NDB non sono accessibili con NDB di App Engine. Per questo motivo, la migrazione a Cloud NDB deve essere considerata irreversibile.

Le versioni più recenti di Cloud NDB supportano solo Python 3. Le versioni precedenti supportavano sia Python 2 che Python 3. Per eseguire la migrazione dell'applicazione Python 2 a Python 3, ti consigliamo di procedere come segue:

  1. Esegui la migrazione a Cloud NDB, versione 1.11.2. Questa è la release finale che supporta Python 2.
  2. Esegui l'upgrade dell'applicazione a Python 3.
  3. Esegui l'upgrade all'ultima versione stabile di Cloud NDB.

Questo approccio incrementale alla migrazione consente di mantenere un'app funzionante e testabile durante tutto il processo di migrazione.

Cloud NDB è rivolto agli sviluppatori Python che hanno dimestichezza con NDB App Engine e vogliono modernizzare le loro applicazioni. La migrazione a Cloud NDB aiuta a preparare la tua app Python 2 per Python 3 e ti offre la possibilità di uscire da App Engine in un secondo momento, se lo desideri.

Per ulteriori informazioni su Cloud NDB, consulta le pagine seguenti:

Confronto tra NDB App Engine e Cloud NDB

Somiglianze:

  • Cloud NDB supporta quasi tutte le funzionalità supportate da NDB di App Engine, con piccole differenze nella sintassi dei metodi.

Differenze:

  • Le API NDB di App Engine che si basano su servizi specifici dell'esecuzione di App Engine Python 2.7 sono state aggiornate o rimosse da Cloud NDB.

  • Le nuove funzionalità in Python 3 e Django hanno eliminato la necessità di google.appengine.ext.ndb.django_middleware. Puoi invece scrivere facilmente il tuo middleware con poche righe di codice.

  • Le applicazioni NDB di App Engine e il database Datastore devono trovarsi nello stesso progetto Google Cloud, con App Engine che fornisce le credenziali automaticamente. Cloud NDB può accedere ai database della modalità Datastore in qualsiasi progetto, a condizione che l'autenticazione del client venga eseguita correttamente. Ciò è coerente con altre API e librerie client di Google Cloud.

  • Cloud NDB non utilizza il servizio Memcache App Engine per memorizzare i dati nella cache.

    Cloud NDB può invece memorizzare nella cache i dati in un datastore in memoria Redis gestito da Memorystore, Redis Labs o altri sistemi. Sebbene solo i datastore Redis siano attualmente supportati, Cloud NDB ha generalizzato e definito la memorizzazione nella cache nell'interfaccia GlobalCache astratta, che può supportare implementazioni aggiuntive concrete.

    Per accedere a Memorystore for Redis, l'app deve utilizzare l'accesso VPC serverless.

    Né Memorystore for Redis né Accesso VPC serverless forniscono un livello gratuito e questi prodotti potrebbero non essere disponibili nella regione della tua app. Per ulteriori informazioni, vedi Prima di iniziare la migrazione.

L'elenco completo delle differenze è disponibile nelle note sulla migrazione per il progetto GitHub di Cloud NDB.

Esempi di codice:

Prima di avviare la migrazione

Prima di iniziare la migrazione:

  1. Stabilisci se devi memorizzare i dati nella cache.

  2. Se devi memorizzare i dati nella cache, assicurati che la regione della tua app sia supportata da Accesso VPC serverless e Memorystore for Redis.

  3. Informazioni sulle autorizzazioni in modalità Datastore.

Determinare se è necessario memorizzare i dati nella cache

Devi assicurarti che la tua app richieda la memorizzazione nella cache, dal momento che Memorystore per Redis e Accesso VPC serverless non hanno un livello gratuito e non supportano tutte le regioni Google Cloud.

In generale:

  • Se l'app legge spesso gli stessi dati, la memorizzazione nella cache potrebbe ridurre la latenza.

  • Maggiore è il numero di richieste pubblicate dall'app, maggiore sarà l'impatto della memorizzazione nella cache.

Per sapere quanto attualmente ti affidi ai dati memorizzati nella cache, visualizza la dashboard di Memcache per conoscere il rapporto tra hit della cache e errori mancati. Se il rapporto è elevato, l'utilizzo di una cache di dati probabilmente avrà un grande impatto sulla riduzione della latenza delle app.

Visualizzare la dashboard Memcache

Per informazioni sui prezzi, consulta Prezzi di Memorystore e Prezzi di accesso VPC serverless.

Conferma dell'area geografica 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:

  1. Visualizza l'area geografica della tua app, visualizzata nella parte superiore della dashboard di App Engine nella console Google Cloud.

    Apri la dashboard

    L'area geografica viene visualizzata nella parte superiore della pagina, appena sotto l'URL dell'app.

  2. Verifica che la tua app si trovi in una delle regioni supportate dall'accesso VPC serverless.

  3. Verifica che la tua app si trovi in una delle regioni supportate da Memorystore for Redis visitando la pagina Crea connettore e visualizzando le regioni nell'elenco Regioni.

    Visualizzare la pagina Crea connettore

Se la tua app non si trova in una regione supportata da Memorystore for Redis e da un accesso VPC serverless:

  1. Creare un progetto Google Cloud.

  2. Crea una nuova app App Engine nel progetto e seleziona una regione supportata.

  3. Creare i servizi Google Cloud che la tua app utilizza nel nuovo progetto.

    In alternativa, puoi aggiornare l'app per utilizzare i servizi esistenti nel progetto precedente, ma l'utilizzo dei prezzi e delle risorse potrebbe differire quando utilizzi i servizi in un progetto e una regione diversi. Per ulteriori informazioni, consulta la documentazione di ogni servizio.

  4. Esegui il deployment dell'app nel nuovo progetto.

Informazioni sulle autorizzazioni della 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, l'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 si verifica una qualsiasi delle seguenti condizioni:

  • La tua app e il database della 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 alternative, consulta la pagina Configurare l'autenticazione per le applicazioni di produzione da server a server.

Panoramica del processo di migrazione

Per eseguire la migrazione a Cloud NDB da App Engine NDB:

  1. Aggiorna l'app Python:

    1. Installa la libreria client di Cloud NDB.

    2. Aggiorna le istruzioni di importazione per importare i moduli da Cloud NDB.

    3. Aggiungi il codice che crea un client Cloud NDB. Il client può leggere le variabili di ambiente dell'app e utilizzare i dati per eseguire l'autenticazione in modalità Datastore.

    4. Aggiungi il codice che utilizza il contesto di runtime del client per mantenere la memorizzazione nella cache e le transazioni separate tra i thread.

    5. Rimuovi o aggiorna il codice che utilizza metodi e proprietà non più supportati.

  2. Attiva la memorizzazione nella cache.

  3. Verifica gli aggiornamenti.

  4. Esegui il deployment dell'app in App Engine.

    Come per ogni modifica apportata alla tua app, ti consigliamo di utilizzare la suddivisione del traffico per aumentare il traffico lentamente. Monitora attentamente l'app per individuare eventuali problemi con il database prima di indirizzare più traffico all'app aggiornata.

Aggiornamento dell'app Python

Installazione della libreria Cloud NDB per le app Python 2

  1. Crea una directory per archiviare le tue librerie di terze parti, ad esempio lib/.

  2. Crea un file requirements.txt nella stessa cartella del file app.yaml e aggiungi il nome della libreria client:

    google-cloud-ndb==1.11.2

  3. Utilizza pip (versione 6 o successiva) con il flag -t <directory> per installare le librerie nella cartella creata nel passaggio precedente. Ad esempio:

    pip install -t lib -r requirements.txt

  4. Specifica le librerie RPC e setuptools nella sezione libraries del file app.yaml:

    libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0

  5. Crea un file appengine_config.py nella stessa cartella del file app.yaml, se non ne hai già uno. Aggiungi quanto segue al tuo file appengine_config.py:

    # appengine_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 giusta distribuzione delle librerie client.

    Il file appengine_config.py nell'esempio precedente presuppone che la cartella lib si trovi nella directory di lavoro corrente. Se non puoi garantire che lib sarà sempre nella directory di lavoro attuale, specifica il percorso completo della cartella lib. 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.

Installazione della libreria Cloud NDB per le app Python 3

Il runtime Python 3 di App Engine utilizza il file requirements.txt di un'app per determinare quali pacchetti e versioni installare per le app. Per installare la libreria Cloud NDB nel runtime Python 3, aggiungi la seguente riga al file requirements.txt della tua app:

google-cloud-ndb

App Engine carica automaticamente tutte le librerie nel file requirements.txt dell'app quando esegui il deployment dell'app.

Installazione delle dipendenze in locale

Quando sviluppi e testi la tua app in locale, ti consigliamo vivamente di utilizzare un ambiente virtuale per isolare le dipendenze dell'app dai pacchetti di sistema. In questo modo l'app carica solo le dipendenze che hai dichiarato nel file requirements.txt e l'app sincronizza le versioni delle dipendenze tra gli ambienti locali e di produzione.

In Python 2, puoi usare virtualenv per creare un ambiente virtuale.

In Python 3, venv è il metodo consigliato per creare un ambiente virtuale.

Aggiornamento degli estratti conto

La posizione del modulo NDB è stata spostata in google.cloud.ndb. Aggiorna gli estratti conto dell'app come mostrato nella tabella seguente:

Rimuovi Sostituisci con
from google.appengine.ext import ndb from google.cloud import ndb

Creazione di un client Cloud NDB

Come con altre librerie client basate sulle API Google Cloud, il primo passo nell'utilizzo di Cloud NDB è creare un oggetto Client. Il client contiene le credenziali e gli altri dati necessari per la connessione alla modalità Datastore. Ad esempio:

from google.cloud import ndb

client = ndb.Client()

Nello scenario predefinito di autorizzazione 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 stai lavorando in questo scenario predefinito, consulta ADC (Application Default Credentials) 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 NDB Cloud contiene il metodo context() che restituisce un contesto di runtime. Il contesto di runtime isola le richieste di memorizzazione nella cache e transazione da altre interazioni in modalità Datastore simultanee.

Tutte le interazioni con la modalità Datastore devono avvenire in un contesto di runtime NDB. Poiché la creazione di una definizione di 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 di richieste per ottenere i dati dal database.

Ad esempio:

datastore/cloud-ndb/quickstart.py 
from google.cloud import ndb

class Book(ndb.Model):
    title = ndb.StringProperty()

client = ndb.Client()

def list_books():
    with client.context():
        books = Book.query()
        for book in books:
            print(book.to_dict())

App con più thread

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 eseguendo il wrapping dell'app nell'oggetto middleware.

Nell'esempio seguente relativo all'utilizzo del middleware con Flask:

  • Il metodo middleware crea un oggetto middleware WSGI nel contesto di runtime del client NDB.

  • L'app Flask è inserita nell'oggetto middleware.

  • Flask trasmetterà quindi ogni richiesta tramite l'oggetto middleware, che recupera un nuovo contesto di runtime NDB per ogni richiesta.

datastore/cloud-ndb/flask_app.py 
from flask import Flask

from google.cloud import ndb

client = ndb.Client()

def ndb_wsgi_middleware(wsgi_app):
    def middleware(environ, start_response):
        with client.context():
            return wsgi_app(environ, start_response)

    return middleware

app = Flask(__name__)
app.wsgi_app = ndb_wsgi_middleware(app.wsgi_app)  # Wrap the app in middleware.

class Book(ndb.Model):
    title = ndb.StringProperty()

@app.route('/')
def list_books():
    books = Book.query()
    return str([book.to_dict() for book in books])

Utilizzo di un contesto di runtime con Django

Il middleware Django fornito dalla libreria NDB di App Engine non è supportato dalla libreria NDB di Cloud. Se utilizzavi questo middleware (google.appengine.ext.ndb.django_middleware) nell'app, procedi nel seguente modo per aggiornarla:

  1. Usa il sistema middleware di Django per creare un nuovo contesto di runtime per ogni richiesta.

    Nell'esempio seguente:

    • Il metodo ndb_django_middleware crea un client Cloud NDB.

    • Il metodo middleware crea un oggetto middleware all'interno del contesto di runtime del client NDB.

    datastore/cloud-ndb/django_mediumware.py 
    from google.cloud import ndb

# Once this middleware is activated in Django settings, NDB calls inside Django
# views will be executed in context, with a separate context for each request.
def ndb_django_middleware(get_response):
    client = ndb.Client()

    def middleware(request):
        with client.context():
            return get_response(request)

    return middleware

  2. Nel file Django settings.py, aggiorna l'impostazione MIDDLEWARE in modo da elencare i nuovi middleware che hai creato invece di google.appengine.ext.ndb.NdbDjangoMiddleware.

Django ora trasmetterà ogni richiesta tramite l'oggetto middleware che hai elencato nell'impostazione MIDDLEWARE, e questo oggetto 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.

Sarà necessario aggiornare il codice se utilizza una delle seguenti API NDB:

Modelli e proprietà del modello

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 seguente tabella descrive le proprietà google.appengine.ext.ndb.Model specifiche che sono cambiate nella libreria Cloud NDB:

Proprietà Cambia
TextProperty google.cloud.ndb.TextProperty non può essere indicizzato. Se tenti di impostare google.cloud.ndb.TextProperty.indexed, verrà generato un NotImplementedError.
StringProperty StringProperty è sempre indicizzato. Se tenti di 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 NotImplementedError.
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 cambiati.
Model.make_connection Nessuno

Chiavi

I seguenti metodi di google.appengine.ext.ndb.Key non sono disponibili nella libreria Cloud NDB. Questi metodi venivano usati per passare le chiavi da e verso l'API DB Datastore, che non è più supportata (il database 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 trasmesso nel costruttore. Questo avviene 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 nel caso dell'NDB di App Engine, Cloud NDB fornisce una classe QueryOptions (google.cloud.ndb.query.QueryOptions) che ti consente di riutilizzare un insieme specifico di opzioni di query invece di ridefinerle per ogni query. Tuttavia, QueryOptions in Cloud NDB non eredita da google.appengine.datastore.datastore_rpc.Configuration, 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 PropertyOrder è uguale al costruttore per Order. È cambiato solo il nome della classe.

API rimossa Sostituzione
da 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)

Util

Il modulo ndb.utils (google.appengine.ext.ndb.utils) non è più disponibile. La maggior parte dei metodi nel modulo era interna all'NDB di App Engine, alcuni 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. Solo un numero limitato di metodi è disponibile per facilitare la migrazione.

Ad esempio, il decorator posizionale nel vecchio modulo utils ha dichiarato che solo i primi n argomenti di una funzione o di un metodo possono essere posizionali. Tuttavia, Python 3 può eseguire questa operazione utilizzando gli argomenti solo per le parole chiave. In precedenza:

@utils.positional(2)
def function1(arg1, arg2, arg3=None, arg4=None)
  pass

Puoi scriverlo in questo modo in Python 3:

def function1(arg1, arg2, *, arg3=None, arg4=None)
  pass

Spazi dei nomi

Gli spazi dei nomi consentono a un'applicazione multitenant di utilizzare silos di dati separati per ogni tenant, pur utilizzando lo stesso database in modalità Datastore. Ciò significa che ogni tenant archivia i dati all'interno del proprio spazio dei nomi.

Invece di utilizzare uno spazio dei nomi specifico di App Engine google.appengine.api.namespacemanager, puoi specificare uno spazio dei nomi predefinito quando crei un client Cloud NDB e poi utilizzarlo chiamando i metodi NDB di Cloud nel contesto di runtime del client. Segue lo stesso pattern delle altre API Google Cloud che supportano gli spazi dei nomi.

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")
o 

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 invece di sollevare un'eccezione Return. Ad esempio:

Libreria NDB di App Engine Libreria NDB Cloud 

        @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 i risultati in Cloud NDB sollevando un'eccezione Return, ma non è consigliabile.

Inoltre, i seguenti metodi e sottoclassi Tasklets non sono più disponibili, principalmente a causa delle modifiche al modo in cui un contesto NDB viene creato e utilizzato 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 modulo google.cloud.ndb.exceptions nella libreria Cloud NDB contenga molte delle stesse eccezioni della libreria NDB di App Engine, non tutte le vecchie eccezioni sono disponibili nella nuova libreria. La seguente tabella elenca le eccezioni che non sono 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 di un datastore in memoria Redis gestito da Memorystore, Redis Labs o altri sistemi. Questa guida descrive come utilizzare Memorystore for Redis per memorizzare i dati nella cache:

  1. Configura l'accesso VPC serverless.

  2. Configurare Memorystore for Redis

  3. Aggiungi l'URL di connessione Redis alla tua app.

  4. Crea un oggetto RedisCache.

Configurazione dell'accesso VPC serverless

La tua app può comunicare con Memorystore solo tramite un connettore di accesso VPC serverless. Per configurare un connettore di accesso VPC serverless:

  1. Crea un connettore di accesso VPC serverless.

  2. Configura la tua app per l'utilizzo del connettore.

Configurazione di Memorystore for Redis

Per configurare Memorystore for Redis:

  1. Crea un'istanza Redis in Memorystore. Quando crei l'istanza:

  2. Prendi nota dell'indirizzo IP e del numero di porta dell'istanza Redis che crei. Utilizzerai queste informazioni quando attivi 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 per utilizzare un connettore VPC.

Aggiungere l'URL della 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 della tua 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 e utilizzarlo nella cache passandolo 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, devi creare un client Redis e passare il client al costruttore ndb.RedisCache(). Ad esempio:

global_cache = ndb.RedisCache(redis.StrictRedis(host=IP-address, port=redis_port))

Non è necessario dichiarare una dipendenza dalla libreria client Redis, poiché la libreria Cloud NDB dipende già dalla libreria client Redis.

Fai riferimento all'applicazione di esempio Memorystore per un esempio di creazione di un client Redis.

Test degli aggiornamenti

Per configurare un database di test ed eseguire l'app in locale prima del deployment in App Engine:

  1. Esegui l'emulatore locale in modalità Datastore per archiviare e recuperare i dati.

    Assicurati di seguire le istruzioni per impostare le variabili di ambiente in modo che la tua app si connetta all'emulatore anziché all'ambiente di modalità Datastore di produzione.

    Puoi anche importare dati nell'emulatore se vuoi iniziare il test con i dati precaricati nel database.

  2. Utilizza il server di sviluppo locale per eseguire l'applicazione.

    Per assicurarti che la variabile di ambiente GOOGLE_CLOUD_PROJECT sia impostata correttamente durante lo sviluppo locale, inizializza dev_appserver utilizzando il seguente parametro: 

    --application=PROJECT_ID

    PROJECT_ID dovrebbe essere il tuo ID 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

Quando l'app è in esecuzione nel server di sviluppo locale senza errori:

  1. Testa l'app su App Engine.

  2. Se l'app viene eseguita senza errori, utilizza la suddivisione del traffico per aumentare lentamente il traffico verso l'app aggiornata. Monitora attentamente l'app per verificare se ci sono problemi del database prima di indirizzare più traffico all'app aggiornata.