Migrar a Cloud NDB

Ubicaciones de App Engine

App Engine es regional, lo que significa que la infraestructura que ejecuta tus aplicaciones está ubicada en una región concreta y Google la gestiona para que esté disponible de forma redundante en todas las zonas de esa región.

Cumplir con los requisitos de latencia, disponibilidad o durabilidad son factores principales para seleccionar la región donde se ejecutan tus aplicaciones. Por lo general, puedes seleccionar la región más cercana a los usuarios de tu aplicación, pero debes tener en cuenta las ubicaciones en las que está disponible App Engine, así como las ubicaciones de los demásGoogle Cloud productos y servicios que utilice tu aplicación. Usar servicios en varias ubicaciones puede afectar a la latencia de tu aplicación, así como a su precio.

No es posible cambiar la región de una aplicación después de configurarla.

Si ya has creado una aplicación de App Engine, puedes ver su región de una de las siguientes formas:

Cloud NDB es una biblioteca de cliente para Python que sustituye a App Engine NDB. App Engine NDB permite que las aplicaciones de Python 2 almacenen y consulten datos en bases de datos de Datastore. Cloud NDB permite que las aplicaciones de Python 2 y Python 3 almacenen y consulten datos en las mismas bases de datos. Sin embargo, el producto que gestiona esas bases de datos ha cambiado de Datastore a Firestore en modo Datastore. Aunque la biblioteca Cloud NDB puede acceder a cualquier dato creado con App Engine NDB, no se puede acceder a algunos tipos de datos estructurados almacenados con Cloud NDB mediante App Engine NDB. Por este motivo, la migración a Cloud NDB debe considerarse irreversible.

Te recomendamos que migres a Cloud NDB antes de actualizar tu aplicación a Python 3. Este enfoque incremental de la migración te permite mantener una aplicación funcional y que se pueda probar durante todo el proceso de migración.

Cloud NDB está diseñado para sustituir las funciones de App Engine NDB, por lo que no admitirá las nuevas funciones de Firestore en modo de almacén de datos. Recomendamos que las nuevas aplicaciones de Python 3 usen la biblioteca de cliente del modo Datastore en lugar de Cloud NDB.

Para obtener más información sobre Cloud NDB, consulta las siguientes páginas de GitHub:

Comparación entre App Engine NDB y Cloud NDB

Similitudes:

  • Cloud NDB admite casi todas las funciones compatibles con App Engine NDB, con solo pequeñas diferencias en la sintaxis de los métodos.

Diferencias:

  • Las APIs de App Engine NDB que dependen de servicios específicos del entorno de ejecución de App Engine Python 2.7 se han actualizado o eliminado de Cloud NDB.

  • Las nuevas funciones de Python 3 y Django han eliminado la necesidad de google.appengine.ext.ndb.django_middleware. En su lugar, puedes escribir fácilmente tu propio middleware con tan solo unas líneas de código.

  • App Engine NDB requería que las aplicaciones y la base de datos Datastore estuvieran en el mismo proyecto, y App Engine proporcionaba las credenciales automáticamente. Google Cloud Cloud NDB puede acceder a bases de datos en modo Datastore de cualquier proyecto, siempre que autentiques tu cliente correctamente. Esto es coherente con otras APIs y bibliotecas de cliente. Google Cloud

  • Cloud NDB no utiliza el servicio Memcache de App Engine para almacenar datos en caché.

    En su lugar, Cloud NDB puede almacenar en caché los datos en un almacén de datos en memoria de Redis gestionado por Memorystore, Redis Labs u otros sistemas. Aunque actualmente solo se admiten los almacenes de datos de Redis, Cloud NDB ha generalizado y definido el almacenamiento en caché en la interfaz abstracta GlobalCache, que puede admitir implementaciones concretas adicionales.

    Para acceder a Memorystore para Redis, tu aplicación debe usar Acceso a VPC sin servidor.

    Ni Memorystore para Redis ni Acceso a VPC sin servidor ofrecen un nivel gratuito, y es posible que estos productos no estén disponibles en la región de tu aplicación. Consulta Antes de empezar la migración para obtener más información.

La lista completa de diferencias está disponible en las notas de migración del proyecto de GitHub de Cloud NDB.

Ejemplos de código:

Antes de empezar la migración

Antes de empezar la migración:

  1. Si aún no lo has hecho, configura tu entorno de desarrollo de Python para usar una versión de Python compatible con Google Cloude instala herramientas de prueba para crear entornos de Python aislados.

  2. Determina si necesitas almacenar datos en caché.

  3. Si necesitas almacenar datos en caché, asegúrate de que la región de tu aplicación sea compatible con Acceso a VPC sin servidor y Memorystore para Redis.

  4. Información sobre los permisos del modo Datastore

Determinar si necesitas almacenar datos en caché

Si tu aplicación necesita almacenar datos en caché, ten en cuenta que Memorystore para Redis y el acceso a VPC sin servidor no tienen un nivel gratuito y no admiten todas lasGoogle Cloud regiones.

En general:

  • Si tu aplicación lee con frecuencia los mismos datos, el almacenamiento en caché podría reducir la latencia.

  • Cuantas más solicitudes sirva tu aplicación, mayor será el impacto que puede tener el almacenamiento en caché.

Para ver cuánto dependes actualmente de los datos almacenados en caché, consulta el panel de control de Memcache para ver la proporción de aciertos y fallos de caché. Si la proporción es alta, es probable que el uso de una caché de datos tenga un gran impacto en la reducción de la latencia de tu aplicación.

Ir a Memcache de App Engine

Para obtener información sobre los precios, consulta las páginas Precios de Memorystore y Precios de acceso a VPC sin servidor.

Confirmar la región de tu aplicación

Si necesitas almacenar datos en caché, asegúrate de que la región de tu aplicación sea compatible con Memorystore para Redis y con Acceso a VPC sin servidor:

  1. Consulta la región de tu aplicación, que aparece cerca de la parte superior del panel de control de App Engine en la Google Cloud consola.

    Ir a App Engine

    La región aparece en la parte superior de la página, justo debajo de la URL de tu aplicación.

  2. Confirma que tu aplicación se encuentra en una de las regiones admitidas por el acceso a VPC sin servidor.

  3. Confirma que tu aplicación se encuentra en una de las regiones admitidas por Memorystore para Redis. Para ello, ve a la página Crear conector y consulta las regiones de la lista Regiones.

    Ir a Acceso a VPC sin servidor

Si tu aplicación no está en una región compatible con Memorystore para Redis y Acceso a VPC sin servidor:

  1. Crea un Google Cloud proyecto.

  2. Crea una aplicación de App Engine en el proyecto y selecciona una región admitida.

  3. Crea los Google Cloud servicios que usa tu aplicación en el nuevo proyecto.

    También puedes actualizar tu aplicación para que use los servicios que ya tienes en tu proyecto antiguo, pero los precios y el uso de recursos pueden ser diferentes si usas los servicios en otro proyecto y otra región. Consulta la documentación de cada servicio para obtener más información.

  4. Despliega tu aplicación en el nuevo proyecto.

Información sobre los permisos del modo Datastore

Cada interacción con un servicio de Google Cloud debe autorizarse. Por ejemplo, para almacenar o consultar datos en una base de datos en modo Datastore, tu aplicación debe proporcionar las credenciales de una cuenta que tenga autorización para acceder a la base de datos.

De forma predeterminada, tu aplicación proporciona las credenciales de la cuenta de servicio predeterminada de App Engine, que tiene autorización para acceder a las bases de datos del mismo proyecto que tu aplicación.

Deberás usar una técnica de autenticación alternativa que proporcione credenciales de forma explícita si se cumple alguna de las siguientes condiciones:

  • Tu aplicación y la base de datos en modo Datastore están en proyectos diferentes.Google Cloud

  • Has cambiado los roles asignados a la cuenta de servicio predeterminada de App Engine.

Para obtener información sobre técnicas de autenticación alternativas, consulta el artículo Configurar la autenticación para aplicaciones de producción de servidor a servidor.

Visión general del proceso de migración

Para migrar a Cloud NDB, sigue estos pasos:

  1. Actualiza tu aplicación Python:

    1. Instala la biblioteca de cliente de Cloud NDB.

    2. Actualiza las instrucciones de importación para importar módulos de Cloud NDB.

    3. Añade código que cree un cliente de Cloud NDB. El cliente puede leer las variables de entorno de tu aplicación y usar los datos para autenticarse con el modo Datastore.

    4. Añade código que use el contexto de tiempo de ejecución del cliente para mantener la caché y las transacciones separadas entre los hilos.

    5. Quita o actualiza el código que utilice métodos y propiedades que ya no se admitan.

  2. Habilitar el almacenamiento en caché.

  3. Prueba las actualizaciones.

  4. Despliega tu aplicación en App Engine.

    Al igual que con cualquier cambio que hagas en tu aplicación, te recomendamos que uses la división del tráfico para aumentar el tráfico gradualmente. Monitoriza la aplicación de cerca para detectar cualquier problema con la base de datos antes de dirigir más tráfico a la aplicación actualizada.

Actualizar una aplicación Python

Instalar la biblioteca de Cloud NDB para aplicaciones Python

Para instalar la biblioteca de cliente de Cloud NDB en tu aplicación de Python de App Engine, sigue estos pasos:

  1. Actualiza el archivo app.yaml. Sigue las instrucciones correspondientes a tu versión de Python:

    Python 2

    En el caso de las aplicaciones de Python 2, añade las versiones más recientes de las bibliotecas grpcio y setuptools.

    A continuación, se muestra un ejemplo de archivo app.yaml:

    runtime: python27
threadsafe: yes
api_version: 1

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

    Python 3

    En las aplicaciones de Python 3, especifica el elemento runtime con una versión compatible de Python 3 y elimina las líneas innecesarias. Por ejemplo, tu archivo app.yaml podría tener el siguiente aspecto:

    runtime: python310 # or another support version

    El tiempo de ejecución de Python 3 instala las bibliotecas automáticamente, por lo que no es necesario especificar las bibliotecas integradas del tiempo de ejecución de Python 2 anterior. Si tu aplicación de Python 3 usa otros servicios antiguos empaquetados al migrar, deja el archivo app.yaml tal cual.

  2. Actualiza el archivo requirements.txt. Sigue las instrucciones correspondientes a tu versión de Python:

    Python 2

    Añade las bibliotecas de cliente de Cloud para Cloud NDB a tu lista de dependencias en el archivo requirements.txt.

    google-cloud-ndb

    A continuación, ejecuta pip install -t lib -r requirements.txt para actualizar la lista de bibliotecas disponibles para tu aplicación.

    Python 3

    Añade las bibliotecas de cliente de Cloud para Cloud NDB a tu lista de dependencias en el archivo requirements.txt.

    google-cloud-ndb

    App Engine instala automáticamente estas dependencias durante el despliegue de la aplicación en el entorno de ejecución de Python 3, así que elimina la carpeta lib si existe.

  3. En el caso de las aplicaciones de Python 2, si tu aplicación usa bibliotecas integradas o copiadas especificadas en el directorio lib, debes especificar esas rutas en el archivo 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)

    Asegúrate de usar el módulo pkg_resources, que garantiza que tu aplicación use la distribución correcta de las bibliotecas de cliente.

    En el archivo appengine_config.py del ejemplo anterior se da por hecho que la carpeta lib se encuentra en el directorio de trabajo actual. Si no puedes garantizar que lib siempre esté en el directorio de trabajo actual, especifica la ruta completa a la carpeta lib. Por ejemplo:

    import os
path = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'lib')

    Cuando despliegas tu aplicación, App Engine sube todas las bibliotecas del directorio que hayas especificado en el archivo appengine_config.py.

Actualizar las instrucciones de importación

La ubicación del módulo NDB se ha trasladado a google.cloud.ndb. Actualiza las instrucciones de importación de tu aplicación tal como se muestra en la siguiente tabla:

Quitar Reemplazar con
from google.appengine.ext import ndb from google.cloud import ndb

Crear un cliente de Cloud NDB

Al igual que con otras bibliotecas de cliente basadas en APIs, el primer paso para usar Cloud NDB es crear un Clientobjeto. Google Cloud El cliente contiene credenciales y otros datos necesarios para conectarse al modo Datastore. Por ejemplo:

from google.cloud import ndb

client = ndb.Client()

En el caso de autorización predeterminado descrito anteriormente, el cliente de Cloud NDB contiene credenciales de la cuenta de servicio predeterminada de App Engine, que está autorizada para interactuar con el modo Datastore. Si no trabajas en este caso predeterminado, consulta el artículo sobre las credenciales predeterminadas de la aplicación (ADC) para obtener información sobre cómo proporcionar credenciales.

Usar el contexto de tiempo de ejecución del cliente

Además de proporcionar las credenciales necesarias para interactuar con el modo Datastore, el cliente NDB de Cloud contiene el método context(), que devuelve un contexto de tiempo de ejecución. El contexto de tiempo de ejecución aísla las solicitudes de almacenamiento en caché y de transacciones de otras interacciones simultáneas en el modo Datastore.

Todas las interacciones con el modo Datastore deben producirse en un contexto de tiempo de ejecución de NDB. Como la creación de una definición de modelo no interactúa con el modo Datastore, puedes definir tu clase de modelo antes de crear un cliente de Cloud NDB y obtener un contexto de tiempo de ejecución. Después, puedes usar el contexto de tiempo de ejecución en el controlador de solicitudes para obtener datos de la base de datos.

Por ejemplo:

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

Aplicaciones multihilo

El contexto de tiempo de ejecución que devuelve el cliente de Cloud NDB solo se aplica a un único subproceso. Si tu aplicación usa varios subprocesos para una sola solicitud, debes obtener un contexto de tiempo de ejecución independiente para cada subproceso que vaya a usar la biblioteca Cloud NDB.

Usar un contexto de tiempo de ejecución con frameworks WSGI

Si tu aplicación web usa un framework WSGI, puedes crear automáticamente un contexto de tiempo de ejecución nuevo para cada solicitud creando un objeto de middleware que recupere el contexto de tiempo de ejecución y, a continuación, envolviendo la aplicación en el objeto de middleware.

En el siguiente ejemplo de uso de middleware con Flask:

  • El método middleware crea un objeto de middleware WSGI en el contexto de tiempo de ejecución del cliente NDB.

  • La aplicación Flask se incluye en el objeto de middleware.

  • A continuación, Flask pasará cada solicitud por el objeto de middleware, que recupera un nuevo contexto de tiempo de ejecución de NDB para cada solicitud.

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

Usar un contexto de tiempo de ejecución con Django

El middleware de Django proporcionado por la biblioteca NDB de App Engine no es compatible con la biblioteca NDB de Cloud. Si has usado este middleware (google.appengine.ext.ndb.django_middleware) en tu aplicación, sigue estos pasos para actualizarla:

  1. Usa el sistema de middleware de Django para crear un nuevo contexto de tiempo de ejecución para cada solicitud.

    En el siguiente ejemplo:

    • El método ndb_django_middleware crea un cliente de Cloud NDB.

    • El método middleware crea un objeto de middleware en el contexto de tiempo de ejecución del cliente de 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. En el archivo settings.py de Django, actualiza el MIDDLEWARE ajuste para que incluya el nuevo middleware que has creado en lugar de google.appengine.ext.ndb.NdbDjangoMiddleware.

Ahora, Django pasará cada solicitud por el objeto de middleware que hayas indicado en el ajuste MIDDLEWARE, y este objeto recuperará un nuevo contexto de tiempo de ejecución de NDB para cada solicitud.

Actualizar el código de las APIs de NDB eliminadas o modificadas

Las APIs de NDB que dependen de APIs y servicios específicos de App Engine se han actualizado o eliminado de la biblioteca de Cloud NDB.

Deberá actualizar su código si utiliza alguna de las siguientes APIs de NDB:

Modelos y propiedades de modelos

Los siguientes métodos de google.appengine.ext.ndb.Model no están disponibles en la biblioteca de Cloud NDB porque usan APIs específicas de App Engine que ya no están disponibles.

API eliminada Sustitución
Model.get_indexes y
Model.get_indexes_async 		Ninguno
Model._deserialize y
Model._serialize 		Ninguno
Model.make_connection Ninguno

En la siguiente tabla se describen las propiedades específicas de google.appengine.ext.ndb.Model que han cambiado en la biblioteca NDB de Cloud:

Propiedad Cambiar
TextProperty No se puede indexar google.cloud.ndb.TextProperty. Si intentas definir google.cloud.ndb.TextProperty.indexed, se generará un NotImplementedError.
StringProperty StringProperty siempre se indexa. Si intentas definir google.cloud.ndb.StringProperty.indexed, se NotImplementedError generará.
Todas las propiedades con argumentos name o kind en el constructor. name o kind deben ser tipos de datos str, ya que unicode se sustituyó por str en Python 3.

Las clases y los métodos de la siguiente tabla ya no están disponibles porque usan recursos específicos de App Engine que ya no están disponibles.

API eliminada Sustitución
google.appengine.ext.ndb.msgprop.MessageProperty y
google.appengine.ext.ndb.msgprop.EnumProperty 		Ninguno

Si intentas crear estos objetos, se producirá un NotImplementedError.
de google.appengine.ext.ndb.model.Property:
_db_get_value
_db_set_value
_db_set_compressed_meaning
_db_set_uncompressed_meaning
__creation_counter_global 		Ninguno

Estos métodos se basan en los búferes de protocolo del modo Datastore, que han cambiado.
Model.make_connection Ninguno

Claves

Los siguientes métodos de google.appengine.ext.ndb.Key no están disponibles en la biblioteca Cloud NDB. Estos métodos se usaban para transferir claves a la API Datastore de DB y desde ella, que ya no se admite (DB era el predecesor de App Engine NDB).

API eliminada Sustitución
Key.from_old_key y
Key.to_old_key 		Ninguno

Además, ten en cuenta los siguientes cambios:

NDB de App Engine Cloud NDB
Los tipos y los IDs de cadena deben tener menos de 500 bytes Los tipos y los IDs de cadena deben tener menos de 1500 bytes.
Key.app() devuelve el ID del proyecto que especificaste al crear la clave. El valor devuelto por google.cloud.ndb.Key.app() puede ser diferente del ID original que se ha pasado al constructor. Esto se debe a que los IDs de aplicación con prefijo, como s~example, son identificadores antiguos de App Engine. Se han sustituido por IDs de proyecto equivalentes, como example.

Consultas

Al igual que App Engine NDB, Cloud NDB proporciona una clase QueryOptions (google.cloud.ndb.query.QueryOptions) que te permite reutilizar un conjunto específico de opciones de consulta en lugar de volver a definirlas para cada consulta. Sin embargo, QueryOptions en Cloud NDB no hereda de google.appengine.datastore.datastore_rpc.Configuration y, por lo tanto, no admite los ...datastore_rpc.Configuration métodos.

Además, google.appengine.datastore.datastore_query.Order se ha sustituido por google.cloud.ndb.query.PropertyOrder. Al igual que Order, la clase PropertyOrder te permite especificar el orden de clasificación en varias consultas. El constructor de PropertyOrder es el mismo que el constructor de Order. Solo ha cambiado el nombre de la clase.

API eliminada Sustitución
de 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 el código fuente para ver una descripción de estos métodos.

 Ninguno
google.appengine.ext.ndb.Order
Por ejemplo:
order=Order(-Account.birthday, Account.name) 		google.cloud.ndb.PropertyOrder
Por ejemplo:
google.cloud.ndb.PropertyOrder(-Account.birthday, Account.name)

Utils

El módulo ndb.utils (google.appengine.ext.ndb.utils) ya no está disponible. La mayoría de los métodos de ese módulo eran internos a App Engine NDB. Algunos se han descartado debido a las diferencias de implementación en el nuevo ndb, mientras que otros han quedado obsoletos por las nuevas funciones de Python 3.

Por ejemplo, el decorador posicional del antiguo módulo utils declaraba que solo los primeros n argumentos de una función o un método podían ser posicionales. Sin embargo, Python 3 puede hacerlo mediante argumentos solo por palabra clave. Lo que antes se escribía como:

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

Se puede escribir de esta forma en Python 3:

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

Espacios de nombres

Los espacios de nombres permiten que una aplicación multiinquilino use silos de datos independientes para cada inquilino y, al mismo tiempo, utilice la misma base de datos en modo Datastore. Es decir, cada inquilino almacena datos en su propio espacio de nombres.

En lugar de usar google.appengine.api.namespacemanager, específico de App Engine, debes especificar un espacio de nombres predeterminado al crear un cliente de Cloud NDB y, a continuación, usarlo llamando a los métodos de Cloud NDB en el contexto de tiempo de ejecución del cliente. Sigue el mismo patrón que otras APIs de Google Cloudque admiten espacios de nombres.

API eliminada Sustitución
google.appengine.api.namespace_manager.namespace_manager.set_namespace(str) y
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")
Todos los demás métodos de google.appengine.api.namespacemanager Ninguno

Tasklets

Ahora, los tasklets pueden usar una instrucción return estándar para devolver un resultado en lugar de generar una excepción Return. Por ejemplo:

Biblioteca NDB de App Engine Biblioteca 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

Ten en cuenta que puedes seguir devolviendo resultados en Cloud NDB generando una excepción Return, pero no es recomendable.

Además, los siguientes métodos y subclases Tasklets ya no están disponibles, principalmente debido a los cambios en la forma en que se crea y se usa un contexto de NDB en la biblioteca de NDB de Cloud.

API eliminada Sustitución
de google.appengine.api.ext.ndb.tasklets:
add_flow_exception
make_context
make_default_context
set_context 		Ninguno
de google.appengine.api.ext.ndb.tasklets:
QueueFuture
ReducedFuture
SerialQueueFuture 		Ninguno

Excepciones

Aunque el google.cloud.ndb.exceptions módulo de la biblioteca de Cloud NDB contiene muchas de las mismas excepciones que la biblioteca de App Engine NDB, no todas las excepciones antiguas están disponibles en la nueva biblioteca. En la siguiente tabla se enumeran las excepciones que ya no están disponibles:

API eliminada Sustitución
de google.appengine.api.datastore_errors:
BadKeyError
BadPropertyError
CommittedButStillApplying
EntityNotFoundError
InternalError
NeedIndexError
QueryNotFoundError
ReferencePropertyResolveError
Timeout
TransactionFailedError
TransactionNotFoundError 		google.cloud.ndb.exceptions

Habilitar el almacenamiento en caché de datos

Cloud NDB puede almacenar datos en caché en un almacén de datos en memoria de Redis gestionado por Memorystore, Redis Labs u otros sistemas. En esta guía se describe cómo usar Memorystore para Redis para almacenar datos en caché:

  1. Configura Acceso a VPC sin servidor.

  2. Configura Memorystore para Redis.

  3. Añade la URL de conexión de Redis a tu aplicación.

  4. Crea un objeto RedisCache.

Configurar Acceso a VPC sin servidor

Tu aplicación solo puede comunicarse con Memorystore a través de un conector de acceso a VPC sin servidor. Para configurar un conector de Acceso a VPC sin servidor, sigue estos pasos:

  1. Crea un conector de Acceso a VPC sin servidor.

  2. Configura tu aplicación para que use el conector.

Configurar Memorystore para Redis

Para configurar Memorystore para Redis, sigue estos pasos:

  1. Crea una instancia de Redis en Memorystore. Cuando crees la instancia, haz lo siguiente:

  2. Anota la dirección IP y el número de puerto de la instancia de Redis que crees. Usará esta información cuando habilite el almacenamiento en caché de datos para Cloud NDB.

    Asegúrate de usar el comando gcloud beta para implementar las actualizaciones de tu aplicación. Solo el comando beta puede actualizar tu aplicación para que use un conector de VPC.

Añadir la URL de conexión de Redis

Para conectarte a la caché de Redis, añade la variable de entorno REDIS_CACHE_URL al archivo app.yaml de tu aplicación. El valor de REDIS_CACHE_URL tiene el siguiente formato:

redis://IP address for your instance:port

Por ejemplo, puedes añadir las siguientes líneas al archivo app.yaml de tu aplicación:

     env_variables:
      REDIS_CACHE_URL: redis://10.0.0.3:6379

Crear y usar un objeto de caché de Redis

Si has definido REDIS_CACHE_URL como variable de entorno, puedes crear un objeto RedisCache con una sola línea de código y, a continuación, usar la caché pasándolo a Client.context() al configurar el contexto de tiempo de ejecución:

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

Si no defines REDIS_CACHE_URL como variable de entorno, tendrás que crear un cliente de Redis y pasarlo al constructor de ndb.RedisCache(). Por ejemplo:

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

Ten en cuenta que no es necesario que declares una dependencia en la biblioteca de cliente de Redis, ya que la biblioteca de Cloud NDB ya depende de ella.

Consulta la aplicación de ejemplo de Memorystore para ver un ejemplo de cómo crear un cliente de Redis.

Probar las actualizaciones

Para configurar una base de datos de prueba y ejecutar tu aplicación de forma local antes de desplegarla en App Engine, sigue estos pasos:

  1. Ejecuta el emulador local del modo almacén de datos para almacenar y recuperar datos.

    Sigue las instrucciones para definir variables de entorno de forma que tu aplicación se conecte al emulador en lugar de al entorno del modo de producción de Datastore.

    También puede importar datos al emulador si quiere empezar la prueba con datos precargados en la base de datos.

  2. Usa el servidor de desarrollo local para ejecutar tu aplicación.

    Para asegurarte de que la variable de entorno GOOGLE_CLOUD_PROJECT se ha definido correctamente durante el desarrollo local, inicializa dev_appserver con el siguiente parámetro: 

    --application=PROJECT_ID

    Sustituye PROJECT_ID por el ID de tu proyecto. Google Cloud Puedes encontrar el ID de tu proyecto ejecutando el comando gcloud config list project o consultando la página del proyecto en la Google Cloud consola.

Desplegar una aplicación

Una vez que tu aplicación se ejecute en el servidor de desarrollo local sin errores, haz lo siguiente:

  1. Prueba la aplicación en App Engine.

  2. Si la aplicación se ejecuta sin errores, usa la división del tráfico para aumentar lentamente el tráfico de la aplicación actualizada. Monitoriza la aplicación de cerca para detectar cualquier problema con la base de datos antes de dirigir más tráfico a la aplicación actualizada.

Siguientes pasos