Migre para o Cloud NDB

Localizações do App Engine

O App Engine é regional, o que significa que a infraestrutura que executa as suas apps está localizada numa região específica e é gerida pela Google para estar disponível de forma redundante em todas as zonas dessa região.

O cumprimento dos requisitos de latência, disponibilidade ou durabilidade são fatores principais para selecionar a região onde as suas apps são executadas. Geralmente, pode selecionar a região mais próxima dos utilizadores da sua app, mas deve considerar as localizações onde o App Engine está disponível, bem como as localizações dos outrosGoogle Cloud produtos e serviços que a sua app usa. A utilização de serviços em várias localizações pode afetar a latência da sua app, bem como os respetivos preços.

Não pode alterar a região de uma app depois de a definir.

Se já tiver criado uma aplicação do App Engine, pode ver a respetiva região através de uma das seguintes ações:

O Cloud NDB é uma biblioteca cliente para Python que substitui o NDB do App Engine. O NDB do App Engine permite que as apps Python 2 armazenem e consultem dados em bases de dados do Datastore. O Cloud NDB permite que as apps Python 2 e Python 3 armazenem e consultem dados nas mesmas bases de dados. No entanto, o produto que gere essas bases de dados mudou do Datastore para o Firestore no modo Datastore. Embora a biblioteca Cloud NDB possa aceder a quaisquer dados criados com o App Engine NDB, não é possível aceder a alguns tipos de dados estruturados armazenados através do Cloud NDB com o App Engine NDB. Por esse motivo, a migração para o Cloud NDB deve ser considerada irreversível.

Recomendamos que migre para o Cloud NDB antes de atualizar a sua app para o Python 3. Esta abordagem incremental à migração permite-lhe manter uma app funcional e testável durante todo o processo de migração.

O Cloud NDB destina-se a substituir as funcionalidades no App Engine NDB, pelo que não suporta novas funcionalidades do Firestore no modo Datastore. Recomendamos que as novas apps Python 3 usem a biblioteca cliente do modo Datastore em vez do Cloud NDB.

Para mais informações sobre o Cloud NDB, consulte as seguintes páginas no GitHub:

Comparação entre o NDB do App Engine e o NDB da nuvem

Semelhanças:

  • O Cloud NDB suporta quase todas as funcionalidades suportadas pelo NDB do App Engine, com apenas pequenas diferenças na sintaxe dos métodos.

Diferenças:

  • As APIs NDB do App Engine que dependem de serviços específicos do tempo de execução do App Engine Python 2.7 foram atualizadas ou removidas do Cloud NDB.

  • As novas funcionalidades do Python 3 e do Django eliminaram a necessidade de usar o google.appengine.ext.ndb.django_middleware. Em alternativa, pode escrever facilmente o seu próprio middleware com apenas algumas linhas de código.

  • As apps necessárias do NDB do App Engine e a base de dados do Datastore têm de estar no mesmo Google Cloud projeto, com o App Engine a fornecer credenciais automaticamente. O Cloud NDB pode aceder a bases de dados do modo Datastore em qualquer projeto, desde que autentique o cliente corretamente. Isto é consistente com outras APIs e bibliotecas cliente. Google Cloud

  • O Cloud NDB não usa o serviço App Engine Memcache para colocar dados em cache.

    Em alternativa, o Cloud NDB pode colocar dados em cache num arquivo de dados na memória Redis gerido pelo Memorystore, Redis Labs ou outros sistemas. Embora apenas sejam suportados atualmente os repositórios de dados Redis, o Cloud NDB generalizou e definiu o armazenamento em cache na interface abstrata, que pode suportar implementações concretas adicionais.GlobalCache

    Para aceder ao Memorystore for Redis, a sua app tem de usar o Acesso a VPC sem servidor.

    Nem o Memorystore for Redis nem o Acesso a VPC sem servidor oferecem um nível gratuito, e estes produtos podem não estar disponíveis na região da sua app. Consulte a secção Antes de começar a migrar para mais informações.

A lista completa de diferenças está disponível nas notas de migração do projeto GitHub do Cloud NDB.

Exemplos de código:

Antes de começar a migrar

Antes de iniciar a migração:

  1. Se ainda não o fez, configure o seu ambiente de desenvolvimento Python para usar uma versão do Python compatível com o Google Cloude instale ferramentas de teste para criar ambientes Python isolados.

  2. Determine se precisa de colocar dados em cache.

  3. Se precisar de colocar dados em cache, certifique-se de que a região da sua app é suportada pelo Acesso a VPC sem servidor e pelo Memorystore para Redis.

  4. Compreenda as autorizações do modo Datastore.

Determinar se precisa de colocar dados em cache

Se a sua app precisar de colocar dados em cache, tenha em atenção que o Memorystore para Redis e o acesso a VPC sem servidor não têm um nível gratuito e não suportam todas asGoogle Cloud regiões.

Em geral:

  • Se a sua app ler frequentemente os mesmos dados, o armazenamento em cache pode diminuir a latência.

  • Quanto mais pedidos a sua app publicar, maior será o impacto da colocação em cache.

Para ver a quantidade de dados em cache que usa atualmente, consulte o painel de controlo do Memcache para ver a proporção de acessos à cache em relação a falhas. Se a proporção for elevada, é provável que a utilização de uma cache de dados tenha um grande impacto na redução da latência da sua app.

Aceda ao App Engine Memcache

Para ver informações sobre preços, consulte as secções Preços do Memorystore e Preços do Acesso a VPC sem servidor.

Confirmar a região da sua app

Se precisar de colocar dados em cache, certifique-se de que a região da sua app é suportada pelo Memorystore para Redis e pelo Acesso a VPC sem servidor:

  1. Veja a região da sua app, que aparece perto da parte superior do painel de controlo do App Engine na Google Cloud consola.

    Aceder ao App Engine

    A região é apresentada perto da parte superior da página, imediatamente abaixo do URL da sua app.

  2. Confirme que a sua app está numa das regiões suportadas pelo Acesso a VPC sem servidor.

  3. Confirme se a sua app está numa das regiões suportadas pelo Memorystore for Redis. Para tal, aceda à página Criar conetor e veja as regiões na lista Regiões.

    Aceda ao Acesso a VPC sem servidor

Se a sua app não estiver numa região suportada pelo Memorystore for Redis e pelo acesso a VPC sem servidor:

  1. Crie um Google Cloud projeto.

  2. Crie uma nova app do App Engine no projeto e selecione uma região suportada.

  3. Crie os Google Cloud serviços que a sua app usa no novo projeto.

    Em alternativa, pode atualizar a sua app para usar os serviços existentes no seu projeto antigo, mas os preços e a utilização de recursos podem ser diferentes quando usa serviços num projeto e região diferentes. Consulte a documentação de cada serviço para mais informações.

  4. Implemente a sua app no novo projeto.

Compreender as autorizações do modo Datastore

Todas as interações com um serviço Google Cloud têm de ser autorizadas. Por exemplo, para armazenar ou consultar dados numa base de dados do modo Datastore, a sua app tem de fornecer as credenciais de uma conta autorizada a aceder à base de dados.

Por predefinição, a sua app fornece as credenciais da conta de serviço predefinida do App Engine, que está autorizada a aceder a bases de dados no mesmo projeto que a sua app.

Tem de usar uma técnica de autenticação alternativa que forneça explicitamente credenciais se alguma das seguintes condições for verdadeira:

  • A sua app e a base de dados do modo Datastore estão emGoogle Cloud projetos diferentes.

  • Alterou as funções atribuídas à conta de serviço predefinida do App Engine.

Para informações sobre técnicas de autenticação alternativas, consulte o artigo Configurar a autenticação para aplicações de produção de servidor a servidor.

Vista geral do processo de migração

Para migrar para o Cloud NDB:

  1. Atualize a sua app Python:

    1. Instale a biblioteca cliente do Cloud NDB.

    2. Atualize as declarações de importação para importar módulos do Cloud NDB.

    3. Adicione código que crie um cliente do Cloud NDB. O cliente pode ler as variáveis de ambiente da sua app e usar os dados para autenticar com o modo Datastore.

    4. Adicione código que use o contexto de tempo de execução do cliente para manter a colocação em cache e as transações separadas entre threads.

    5. Remova ou atualize o código que usa métodos e propriedades que já não são suportados.

  2. Ative a colocação em cache.

  3. Teste as atualizações.

  4. Implemente a sua app no App Engine.

    Tal como acontece com qualquer alteração que faça à sua app, considere usar a divisão de tráfego para aumentar gradualmente o tráfego. Monitorize atentamente a app para detetar problemas na base de dados antes de encaminhar mais tráfego para a app atualizada.

Atualizar a sua app Python

Instalar a biblioteca Cloud NDB para apps Python

Para instalar a biblioteca cliente do Cloud NDB na sua app Python do App Engine:

  1. Atualize o ficheiro app.yaml. Siga as instruções para a sua versão do Python:

    Python 2

    Para apps Python 2, adicione as versões mais recentes das bibliotecas grpcio e setuptools.

    Segue-se um exemplo de um ficheiro app.yaml:

    runtime: python27
threadsafe: yes
api_version: 1

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

    Python 3

    Para apps Python 3, especifique o elemento runtime com uma versão do Python 3 suportada e elimine as linhas desnecessárias. Por exemplo, o ficheiro app.yaml pode ter o seguinte aspeto:

    runtime: python310 # or another support version

    O tempo de execução do Python 3 instala bibliotecas automaticamente, pelo que não tem de especificar bibliotecas incorporadas do tempo de execução do Python 2 anterior. Se a sua app Python 3 estiver a usar outros serviços incluídos antigos durante a migração, deixe o ficheiro app.yaml tal como está.

  2. Atualize o ficheiro requirements.txt. Siga as instruções para a sua versão do Python:

    Python 2

    Adicione as bibliotecas de cliente da Cloud para a Cloud NDB à sua lista de dependências no ficheiro requirements.txt.

    google-cloud-ndb

    Em seguida, execute pip install -t lib -r requirements.txt para atualizar a lista de bibliotecas disponíveis para a sua app.

    Python 3

    Adicione as bibliotecas de cliente da Cloud para a Cloud NDB à sua lista de dependências no ficheiro requirements.txt.

    google-cloud-ndb

    O App Engine instala automaticamente estas dependências durante a implementação da app no tempo de execução do Python 3. Por isso, elimine a pasta lib, se existir.

  3. Para apps Python 2, se a sua app estiver a usar bibliotecas incorporadas ou copiadas especificadas no diretório lib, tem de especificar esses caminhos no ficheiro 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)

    Certifique-se de que usa o módulopkg_resources, que garante que a sua app usa a distribuição correta das bibliotecas de cliente.

    O ficheiro appengine_config.py no exemplo anterior pressupõe que a pasta lib está localizada no diretório de trabalho atual. Se não puder garantir que lib está sempre no diretório de trabalho atual, especifique o caminho completo para a pasta lib. Por exemplo:

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

    Quando implementa a sua app, o App Engine carrega todas as bibliotecas no diretório especificado no ficheiro appengine_config.py.

Atualizar declarações de importação

A localização do módulo NDB foi movida para google.cloud.ndb. Atualize as declarações de importação da sua app, conforme mostrado na tabela seguinte:

Remover Substituir por
from google.appengine.ext import ndb from google.cloud import ndb

Criar um cliente do Cloud NDB

Tal como acontece com outras bibliotecas cliente baseadas em Google Cloud APIs, o primeiro passo para usar o Cloud NDB é criar um objeto Client. O cliente contém credenciais e outros dados necessários para estabelecer ligação ao modo Datastore. Por exemplo:

from google.cloud import ndb

client = ndb.Client()

No cenário de autorização predefinido descrito anteriormente, o cliente do Cloud NDB contém credenciais da conta de serviço predefinida do App Engine, que está autorizada a interagir com o modo Datastore. Se não estiver a trabalhar neste cenário predefinido, consulte o artigo Credenciais padrão da aplicação (ADC) para obter informações sobre como fornecer credenciais.

Usar o contexto de tempo de execução do cliente

Além de fornecer as credenciais necessárias para interagir com o modo Datastore, o cliente Cloud NDB contém o método context(), que devolve um contexto de tempo de execução. O contexto de tempo de execução isola o armazenamento em cache e os pedidos de transações de outras interações concorrentes do modo Datastore.

Todas as interações com o modo Datastore têm de ocorrer num contexto de tempo de execução do NDB. Uma vez que a criação de uma definição de modelo não interage com o modo Datastore, pode definir a classe de modelo antes de criar um cliente Cloud NDB e obter um contexto de tempo de execução e, em seguida, usar o contexto de tempo de execução no controlador de pedidos para obter dados da base de dados.

Por exemplo:

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

Apps com vários threads

O contexto de tempo de execução que o cliente do Cloud NDB devolve aplica-se apenas a um único segmento. Se a sua app usar várias linhas de execução para um único pedido, tem de obter um contexto de tempo de execução separado para cada linha de execução que vai usar a biblioteca Cloud NDB.

Usar um contexto de tempo de execução com frameworks WSGI

Se a sua app Web usar uma framework WSGI, pode criar automaticamente um novo contexto de tempo de execução para cada pedido criando um objeto de middleware que obtenha o contexto de tempo de execução e, em seguida, envolva a app no objeto de middleware.

No exemplo seguinte de utilização de middleware com o Flask:

  • O método middleware cria um objeto de middleware WSGI no contexto de tempo de execução do cliente NDB.

  • A app Flask está envolvida no objeto de middleware.

  • Em seguida, o Flask transmite cada pedido através do objeto de middleware, que obtém um novo contexto de tempo de execução do NDB para cada pedido.

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 um contexto de tempo de execução com o Django

O middleware Django fornecido pela biblioteca NDB do App Engine não é suportado pela biblioteca NDB do Google Cloud. Se usou este middleware (google.appengine.ext.ndb.django_middleware) na sua app, siga estes passos para atualizar a app:

  1. Use o sistema de middleware do Django para criar um novo contexto de tempo de execução para cada pedido.

    No exemplo seguinte:

    • O método ndb_django_middleware cria um cliente do Cloud NDB.

    • O método middleware cria um objeto de middleware no contexto de tempo de execução do cliente 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. No ficheiro settings.py do Django, atualize a MIDDLEWARE definição para que liste o novo middleware que criou em vez de google.appengine.ext.ndb.NdbDjangoMiddleware.

O Django vai agora passar cada pedido através do objeto de middleware que indicou na definição MIDDLEWARE, e este objeto vai obter um novo contexto de tempo de execução do NDB para cada pedido.

Atualizar código para APIs NDB removidas ou alteradas

As APIs NDB que dependem de APIs e serviços específicos do App Engine foram atualizadas ou removidas da biblioteca Cloud NDB.

Tem de atualizar o seu código se usar alguma das seguintes APIs NDB:

Modelos e propriedades do modelo

Os seguintes métodos de google.appengine.ext.ndb.Model não estão disponíveis na biblioteca Cloud NDB porque usam APIs específicas do App Engine que já não estão disponíveis.

API removida Substituição
Model.get_indexes e
Model.get_indexes_async 		Nenhum
Model._deserialize e
Model._serialize 		Nenhum
Model.make_connection Nenhum

A tabela seguinte descreve as propriedades específicas google.appengine.ext.ndb.Model que foram alteradas na biblioteca Cloud NDB:

Propriedade Alterar
TextProperty Não é possível indexar google.cloud.ndb.TextProperty. Se tentar definir google.cloud.ndb.TextProperty.indexed, é gerado um NotImplementedError.
StringProperty StringProperty é sempre indexado. Se tentar definir google.cloud.ndb.StringProperty.indexed, é gerado um NotImplementedError.
Todas as propriedades com argumentos name ou kind no construtor. name ou kind têm de ser tipos de dados str, uma vez que unicode foi substituído por str no Python 3.

As classes e os métodos na tabela seguinte já não estão disponíveis porque usam recursos específicos do App Engine que já não estão disponíveis.

API removida Substituição
google.appengine.ext.ndb.msgprop.MessageProperty e
google.appengine.ext.ndb.msgprop.EnumProperty 		Nenhum

Se tentar criar estes objetos, é gerado um erro 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 		Nenhum

Estes métodos baseiam-se em buffers de protocolo do modo Datastore que foram alterados.
Model.make_connection Nenhum

Chaves

Os seguintes métodos de google.appengine.ext.ndb.Key não estão disponíveis na biblioteca do Cloud NDB. Estes métodos foram usados para transmitir chaves para e a partir da API DB Datastore, que já não é suportada (DB foi o predecessor do App Engine NDB).

API removida Substituição
Key.from_old_key e
Key.to_old_key 		Nenhum

Além disso, tenha em atenção as seguintes alterações:

NDB do App Engine Cloud NDB
Os tipos e os IDs de strings têm de ter menos de 500 bytes Os tipos e os IDs de strings têm de ter menos de 1500 bytes.
Key.app() devolve o ID do projeto que especificou quando criou a chave. O valor devolvido por google.cloud.ndb.Key.app() pode diferir do ID original transmitido ao construtor. Isto deve-se ao facto de os IDs de apps com prefixos, como s~example, serem identificadores antigos do App Engine. Foram substituídos por IDs de projetos equivalentes, como example.

Consultas

Tal como o App Engine NDB, o Cloud NDB fornece uma classe QueryOptions (google.cloud.ndb.query.QueryOptions) que lhe permite reutilizar um conjunto específico de opções de consulta em vez de as redefinir para cada consulta. No entanto, QueryOptions no Cloud NDB não herda de google.appengine.datastore.datastore_rpc.Configuration e, por isso, não suporta métodos ...datastore_rpc.Configuration.

Além disso, google.appengine.datastore.datastore_query.Order foi substituído por google.cloud.ndb.query.PropertyOrder. Semelhante a Order, a classe PropertyOrder permite-lhe especificar a ordem de ordenação em várias consultas. O construtor PropertyOrder é igual ao construtor de Order. Apenas o nome da classe foi alterado.

API removida Substituição
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)

Consulte o código-fonte para ver uma descrição destes métodos.

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

Utils

O módulo ndb.utils (google.appengine.ext.ndb.utils) já não está disponível. A maioria dos métodos nesse módulo era interna ao App Engine NDB. Alguns métodos foram rejeitados devido a diferenças de implementação no novo NDB, enquanto outros métodos foram tornados obsoletos pelas novas funcionalidades do Python 3.

Por exemplo, o decorador posicional no módulo utils antigo declarou que apenas os primeiros n argumentos de uma função ou um método podem ser posicionais. No entanto, o Python 3 pode fazê-lo através de argumentos apenas de palavras-chave. O que era escrito como:

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

Pode ser escrito da seguinte forma em Python 3:

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

Espaços de nomes

Os espaços de nomes permitem que uma aplicação multi-inquilino use silos de dados separados para cada inquilino, enquanto continua a usar a mesma base de dados do modo Datastore. Ou seja, cada inquilino armazena dados no seu próprio espaço de nomes.

Em vez de usar o google.appengine.api.namespacemanager específico do App Engine, especifica um espaço de nomes predefinido quando cria um cliente do Cloud NDB e, em seguida, usa o espaço de nomes predefinido chamando os métodos do Cloud NDB no contexto de tempo de execução do cliente. Isto segue o mesmo padrão que outras Google Cloud APIs que suportam espaços de nomes.

API removida Substituição
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")
ou 
key-non-default-namespace=ndb.Key("SomeKind," "AnotherId",
namespace="non-default-nspace")
Todos os outros métodos de google.appengine.api.namespacemanager Nenhum

Tasklets

Agora, os Tasklets podem usar uma declaração return padrão para devolver um resultado em vez de gerar uma exceção Return. Por exemplo:

Biblioteca NDB do 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

Tenha em atenção que ainda pode devolver resultados no Cloud NDB ao gerar uma exceção, mas não é recomendado.Return

Além disso, os seguintes métodos e subclasses Tasklets já não estão disponíveis, principalmente devido a alterações na forma como um contexto NDB é criado e usado na biblioteca Cloud NDB.

API removida Substituição
de google.appengine.api.ext.ndb.tasklets:
add_flow_exception
make_context
make_default_context
set_context 		Nenhum
de google.appengine.api.ext.ndb.tasklets:
QueueFuture
ReducedFuture
SerialQueueFuture 		Nenhum

Exceções

Embora o google.cloud.ndb.exceptions módulo na biblioteca do NDB da Cloud contenha muitas das mesmas exceções da biblioteca do NDB do App Engine, nem todas as exceções antigas estão disponíveis na nova biblioteca. A tabela seguinte lista as exceções que já não estão disponíveis:

API removida Substituição
de google.appengine.api.datastore_errors:
BadKeyError
BadPropertyError
CommittedButStillApplying
EntityNotFoundError
InternalError
NeedIndexError
QueryNotFoundError
ReferencePropertyResolveError
Timeout
TransactionFailedError
TransactionNotFoundError 		google.cloud.ndb.exceptions

Ativar o armazenamento em cache de dados

O Cloud NDB pode colocar dados em cache num armazenamento de dados na memória Redis gerido pelo Memorystore, Redis Labs ou outros sistemas. Este guia descreve como usar o Memorystore for Redis para colocar dados em cache:

  1. Configure o Acesso a VPC sem servidor.

  2. Configure o Memorystore for Redis.

  3. Adicione o URL de ligação do Redis à sua app.

  4. Crie um objeto RedisCache.

Configurar o Acesso a VPC sem servidor

A sua app só pode comunicar com o Memorystore através de um conetor do Acesso a VPC sem servidor. Para configurar um conetor do Acesso a VPC sem servidor:

  1. Crie um conetor do Acesso a VPC sem servidor.

  2. Configure a sua app para usar o conetor.

Configurar o Memorystore for Redis

Para configurar o Memorystore for Redis:

  1. Crie uma instância do Redis no Memorystore. Quando estiver a criar a instância:

  2. Tome nota do endereço IP e do número da porta da instância do Redis que criar. Vai usar estas informações quando ativar o armazenamento em cache de dados para o Cloud NDB.

    Certifique-se de que usa o comando gcloud beta para implementar as atualizações da app. Apenas o comando beta pode atualizar a sua app para usar um conetor de VPC.

Adicionar o URL de ligação do Redis

Pode ligar-se à cache Redis adicionando a variável de ambiente REDIS_CACHE_URL ao ficheiro app.yaml da sua app. O valor de REDIS_CACHE_URL tem o seguinte formato:

redis://IP address for your instance:port

Por exemplo, pode adicionar as seguintes linhas ao ficheiro app.yaml da sua app:

     env_variables:
      REDIS_CACHE_URL: redis://10.0.0.3:6379

Criar e usar um objeto de cache Redis

Se tiver definido REDIS_CACHE_URL como uma variável de ambiente, pode criar um objeto RedisCache com uma única linha de código e, em seguida, usar a cache transmitindo-a a Client.context() quando configurar o contexto de tempo de execução:

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 não definir REDIS_CACHE_URL como uma variável de ambiente, tem de construir um cliente Redis e passá-lo para o construtor ndb.RedisCache(). Por exemplo:

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

Tenha em atenção que não precisa de declarar uma dependência na biblioteca do cliente Redis, uma vez que a biblioteca do Cloud NDB já depende da biblioteca do cliente Redis.

Consulte a aplicação de exemplo do Memorystore para ver um exemplo de criação de um cliente Redis.

Testar as atualizações

Para configurar uma base de dados de teste e executar a sua app localmente antes de a implementar no App Engine:

  1. Execute o emulador local do modo Datastore para armazenar e obter dados.

    Certifique-se de que segue as instruções para definir as variáveis de ambiente, para que a sua app se ligue ao emulador em vez do ambiente de produção do modo Datastore.

    Também pode importar dados para o emulador se quiser iniciar o teste com dados pré-carregados na base de dados.

  2. Use o servidor de desenvolvimento local para executar a sua app.

    Para se certificar de que a variável de ambiente GOOGLE_CLOUD_PROJECT está definida corretamente durante o desenvolvimento local, inicialize dev_appserver com o seguinte parâmetro: 

    --application=PROJECT_ID

    Substitua PROJECT_ID pelo ID do seu Google Cloud projeto. Pode encontrar o ID do projeto executando o comando gcloud config list project ou consultando a página do projeto na Google Cloud consola.

Implementar a sua app

Assim que a app estiver a ser executada no servidor de desenvolvimento local sem erros:

  1. Teste a app no App Engine.

  2. Se a app for executada sem erros, use a divisão de tráfego para aumentar gradualmente o tráfego para a app atualizada. Monitorize atentamente a app para detetar problemas na base de dados antes de encaminhar mais tráfego para a app atualizada.

O que se segue?