Migrazione a Cloud NDB

Località App Engine

App Engine è regionale, il che significa che l'infrastruttura che esegue le app si trova in una regione specifica e Google la gestisce in modo che sia disponibile in modo ridondante in tutte le zone all'interno di quella regione.

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

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

Se hai già creato un'applicazione App Engine, puoi visualizzarne l'area geografica in uno dei seguenti modi:

Cloud NDB è una libreria client per Python che sostituisce NDB di App Engine. 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. Tuttavia, il prodotto che gestisce questi database è cambiato da Datastore a Firestore in modalità Datastore. Sebbene la libreria Cloud NDB possa accedere a qualsiasi dato creato con App Engine NDB, alcuni tipi di dati strutturati archiviati utilizzando Cloud NDB non sono accessibili con App Engine NDB. Per questo motivo, la migrazione a Cloud NDB dovrebbe essere considerata irreversibile.

Ti consigliamo di eseguire la migrazione a Cloud NDB prima di eseguire l'upgrade dell'app a Python 3. Questo approccio incrementale alla migrazione consente di mantenere un'app funzionante e testabile durante l'intero processo di migrazione.

Cloud NDB è pensato per sostituire le funzionalità di App Engine NDB, pertanto non supporterà le nuove funzionalità di Firestore in modalità Datastore. Consigliamo che le nuove app Python 3 utilizzino la libreria client in modalità Datastore anziché Cloud NDB.

Per maggiori informazioni su Cloud NDB, consulta le seguenti pagine su GitHub:

Confronto tra NDB di App Engine 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 NDB di App Engine che si basano su servizi Python 2.7 specifici del runtime di App Engine specifici 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.

  • App Engine NDB richiedeva che le app e il database Datastore fossero nello stesso progetto Google Cloud, con App Engine che fornisce automaticamente le credenziali. Cloud NDB può accedere ai database in modalità Datastore in qualsiasi progetto, a condizione che il client sia autenticato correttamente. Questo è coerente con le altre API e librerie client di Google Cloud.

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

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

    Per accedere a Memorystore for Redis, la tua app deve utilizzare l'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 Prima di avviare 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 avviare la migrazione:

  1. Se non l'hai ancora fatto, configura l'ambiente di sviluppo Python in modo che utilizzi una versione Python compatibile con Google Cloud e installa gli strumenti di test per creare ambienti Python isolati.

  2. Stabilisci se è necessario memorizzare i dati nella cache.

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

  4. Informazioni sulle autorizzazioni in modalità Datastore.

Determinare se è necessario memorizzare i dati nella cache

Se la tua app deve memorizzare dati nella cache, tieni presente che Memorystore for Redis e l'accesso VPC serverless non hanno un livello gratuito e non supportano tutte le regioni di 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 gestite dalla tua app, maggiore sarà l'impatto che la memorizzazione nella cache potrebbe avere.

Per sapere in che misura utilizzi attualmente i dati memorizzati nella cache, visualizza la dashboard Memcache per vedere il rapporto tra hit dalla cache e errori. Se il rapporto è alto, è probabile che l'utilizzo di una cache di dati abbia un grande impatto sulla riduzione della latenza dell'app.

Vai a App Engine Memcache

Per informazioni sui prezzi, consulta i prezzi di Memorystore e i prezzi dell'accesso VPC serverless.

Conferma della regione dell'app in corso...

Se devi memorizzare i dati nella cache, assicurati che la regione della tua app sia supportata da Memorystore for Redis e dall'accesso VPC serverless:

  1. Visualizza la regione dell'app, visualizzata nella parte superiore della dashboard di App Engine nella console Google Cloud.

    Vai ad App Engine

    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. Per verificare che la tua app si trovi in una delle regioni supportate da Memorystore per Redis, visita la pagina Crea connettore e visualizza le regioni nell'elenco Regioni.

    Vai all'accesso VPC serverless

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

  1. Creare un progetto Google Cloud.

  2. Creare una nuova app App Engine nel progetto e selezionare una regione supportata.

  3. Crea i servizi Google Cloud utilizzati dalla tua app nel nuovo progetto.

    In alternativa, puoi aggiornare l'app per utilizzare i servizi esistenti nel progetto precedente, ma i prezzi e l'utilizzo delle risorse potrebbero essere diversi quando usi i servizi in un'altra regione e un progetto diverso. Per ulteriori informazioni, consulta la documentazione di ciascun servizio.

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

Informazioni sulle autorizzazioni in 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, la tua app fornisce le credenziali dell'account di servizio predefinito di App Engine, che è autorizzato ad accedere ai database nello stesso progetto della tua app.

Dovrai utilizzare una tecnica di autenticazione alternativa che fornisca esplicitamente le credenziali se si verifica una delle seguenti condizioni:

  • L'app e il database in modalità Datastore si trovano in progetti Google Cloud diversi.

  • Hai modificato i ruoli assegnati all'account di servizio predefinito di App Engine.

Per informazioni sulle tecniche di autenticazione alternativa, consulta Configurazione dell'autenticazione per applicazioni di produzione da server a server.

Panoramica del processo di migrazione

Per eseguire la migrazione a Cloud NDB:

  1. Aggiorna l'app Python:

    1. Installa la libreria client 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 l'autenticazione con la modalità Datastore.

    4. Aggiungi codice che utilizza il contesto di runtime del client per mantenere separate la memorizzazione nella cache e le transazioni 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 qualsiasi modifica apportata alla tua app, valuta la possibilità di utilizzare la suddivisione del traffico per incrementare lentamente il traffico. Monitora attentamente l'app per rilevare eventuali problemi di 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 nell'app Python di App Engine:

  1. Aggiorna il file app.yaml. Segui le istruzioni per la tua versione di Python:

    Python 2

    Per le app Python 2, aggiungi le versioni più recenti delle librerie grpcio e setuptools.

    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 tuo file app.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 l'app Python 3 utilizza altri servizi in bundle legacy durante la migrazione, lascia il file app.yaml invariato.

  2. Aggiorna il file requirements.txt. Segui le istruzioni per la tua versione di Python:

    Python 2

    Aggiungi le librerie client di Cloud per Cloud NDB al tuo elenco di 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 al tuo elenco di dipendenze nel file requirements.txt.

    google-cloud-ndb

    App Engine installa automaticamente queste dipendenze durante il deployment dell'app nel runtime Python 3, quindi elimina la cartella lib se esistente.

  3. Per le app Python 2, se la tua app utilizza librerie integrate o copiate specificate nella directory lib, devi specificare questi percorsi nel file 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 l'app utilizzi la corretta 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 si trovi 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 della tua 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 altre librerie client basate sulle API Google Cloud, il primo passaggio nell'utilizzo di Cloud NDB consiste nel creare un oggetto Client. Il client contiene credenziali e altri dati necessari per connettersi alla modalità Datastore. Ad esempio:

from google.cloud import ndb

client = ndb.Client()

Nello scenario di autorizzazione predefinita 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 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 simultanee in modalità Datastore.

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 delle richieste per ottenere dati dal database.

Ad esempio:

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 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 recuperi il contesto di runtime e quindi eseguendo il wrapping dell'app nell'oggetto middleware.

Nell'esempio seguente di utilizzo del middleware con Flask:

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

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

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

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 Cloud NDB. Se hai utilizzato questo middleware (google.appengine.ext.ndb.django_middleware) nella tua app, segui questi passaggi per aggiornare l'app:

  1. Utilizza 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 nel contesto di runtime del client NDB.

    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 settings.py di Django, aggiorna l'impostazione MIDDLEWARE in modo che elenchi il nuovo middleware creato anziché google.appengine.ext.ndb.NdbDjangoMiddleware.

Django ora passerà ogni richiesta tramite l'oggetto middleware 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.

Occorre 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 		Nessuna
Model._deserialize e
Model._serialize 		Nessuna
Model.make_connection Nessuna

La seguente tabella descrive le proprietà specifiche di google.appengine.ext.ndb.Model che sono state modificate nella libreria Cloud NDB:

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 seguente tabella 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 		Nessuna

Se provi a creare questi oggetti, verrà visualizzato 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 		Nessuna

Questi metodi si basano su buffer di protocollo in modalità Datastore che sono stati modificati.
Model.make_connection Nessuna

Chiavi

I seguenti metodi di google.appengine.ext.ndb.Key non sono disponibili nella libreria Cloud NDB. Questi metodi venivano utilizzati per passare chiavi da e verso l'API DB Datastore, che non è più supportata (DB era il predecessore dell'API NDB di App Engine).

API rimossa Sostituzione
Key.from_old_key e
Key.to_old_key 		Nessuna

Tieni inoltre 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 contenere meno di 1500 byte.
Key.app() restituisce l'ID progetto specificato al momento della creazione della chiave. Il valore restituito da google.cloud.ndb.Key.app() potrebbe essere diverso dall'ID originale trasmesso nel costruttore. Questo perché gli ID app con prefisso come s~example sono identificatori legacy di App Engine. Sono stati sostituiti da ID progetto equivalenti, come example.

Query

Come App Engine NDB, Cloud NDB fornisce una classe QueryOptions (google.cloud.ndb.query.QueryOptions) che ti consente di riutilizzare un set specifico di opzioni di query invece di ridefinire le opzioni 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 per più query. Il costruttore PropertyOrder è uguale al costruttore di Order. Solo il nome della classe è cambiato.

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.

 Nessuna
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)

Utili

Il modulo ndb.utils (google.appengine.ext.ndb.utils) non è più disponibile. La maggior parte dei metodi in quel modulo erano interni all'NDB di App Engine. Alcuni metodi sono stati ignorati 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 decorator posizionale nel precedente modulo utils ha dichiarato che solo i primi argomenti n di una funzione o di un metodo possono essere posizionali. Tuttavia, Python 3 può farlo utilizzando argomenti solo parola chiave. Come si scriveva:

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

Può essere scritto 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, continuando a utilizzare lo stesso database in modalità Datastore. In altre parole, ogni tenant archivia i dati nel proprio spazio dei nomi.

Invece di utilizzare google.appengine.api.namespacemanager, specifico di App Engine, devi specificare uno spazio dei nomi predefinito quando crei un client Cloud NDB, quindi utilizzare quello predefinito chiamando i metodi Cloud NDB all'interno del contesto di runtime del client. Questo 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 Nessuna

Tasklet

Ora le Tasklet possono utilizzare un'istruzione return standard per restituire un risultato anziché generare 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 i risultati in Cloud NDB aumentando un'eccezione Return, ma questa operazione è sconsigliata.

Inoltre, i seguenti metodi e sottoclassi Tasklets non sono più disponibili, principalmente a causa di modifiche nel 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 		Nessuna
da google.appengine.api.ext.ndb.tasklets:
QueueFuture
ReducedFuture
SerialQueueFuture 		Nessuna

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 eccezioni precedenti 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 in un datastore in memoria Redis gestito da Memorystore, Redis Labs o da altri sistemi. Questa guida descrive come utilizzare Memorystore for Redis per memorizzare i dati nella cache:

  1. Configura l'accesso VPC serverless.

  2. Configura Memorystore per Redis

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

  4. Crea un oggetto RedisCache.

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:

  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 hai creato. Potrai utilizzare 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 la tua 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 della tua app. Il valore di REDIS_CACHE_URL assume la seguente forma:

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() durante la configurazione del 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 passarlo al costruttore 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.

Test degli aggiornamenti

Per impostare un database di test ed eseguire la tua app in locale prima di eseguirne il deployment in App Engine:

  1. 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 dati nell'emulatore se vuoi iniziare il test con dati precaricati nel database.

  2. 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, inizializza dev_appserver utilizzando il seguente parametro: 

    --application=PROJECT_ID

    Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud. Puoi trovare il tuo ID progetto eseguendo il comando gcloud config list project o guardando la pagina del progetto nella console Google Cloud.

Deployment dell'app

Dopo che l'app viene eseguita nel server di sviluppo locale senza errori:

  1. Testa l'app in App Engine.

  2. Se l'app viene eseguita senza errori, utilizza la suddivisione del traffico per accelerare lentamente il traffico per l'app aggiornata. Monitora attentamente l'app per rilevare eventuali problemi del database prima di indirizzare più traffico all'app aggiornata.

Passaggi successivi