Migra un Cloud NDB de App Engine para Python 2 y App de Cloud Tasks en Python 3 y Cloud Datastore (módulo 9)

1. Descripción general

El objetivo de la serie de codelabs de Serverless Migration Station (instructivos prácticos y de autoaprendizaje) y los videos relacionados es ayudar a los desarrolladores de Google Cloud sin servidores a modernizar sus aplicaciones guiándolos a través de una o más migraciones, principalmente alejándose de los servicios heredados. De esta manera, tus apps serán más portátiles y tendrás más opciones y flexibilidad, lo que te permitirá integrar y acceder a una mayor variedad de productos de Cloud, y actualizarte más fácilmente a versiones de lenguaje más recientes. Si bien, en un principio, se enfoca en los primeros usuarios de Cloud, principalmente los desarrolladores de App Engine (entorno estándar), esta serie es lo suficientemente amplia como para incluir otras plataformas sin servidores, como Cloud Functions y Cloud Run, o en cualquier otro lugar si corresponde.

El objetivo de este codelab es transferir la app de muestra del módulo 8 a Python 3, así como cambiar el acceso a Datastore (Cloud Firestore en modo Datastore) del uso de Cloud NDB a la biblioteca cliente nativa de Cloud Datastore y actualizar a la versión más reciente de la biblioteca cliente de Cloud Tasks.

Agregamos el uso de Task Queue para las tareas de envío en el módulo 7 y, luego, migramos ese uso a Cloud Tasks en el módulo 8. En este módulo 9, continuamos con Python 3 y Cloud Datastore. Quienes usen Task Queues para tareas de extracción migrarán a Cloud Pub/Sub y deberán consultar los módulos 18 y 19.

En un próximo lab,

  • Porta la app de ejemplo del módulo 8 a Python 3
  • Cambia el acceso de Datastore de Cloud NDB a las bibliotecas cliente de Cloud Datastore
  • Actualiza a la versión más reciente de la biblioteca cliente de Cloud Tasks

Requisitos

Encuesta

¿Cómo usarás este instructivo?

Solo lo leeré Lo leeré y completaré los ejercicios

¿Cómo calificarías tu experiencia en Python?

Principiante Intermedio Avanzado

¿Cómo calificarías tu experiencia en el uso de los servicios de Google Cloud?

Principiante Intermedio Avanzado

2. Fondo

En el módulo 7, se muestra cómo usar las tareas de envío de la lista de tareas en cola de App Engine en las apps de App Engine de Flask de Python 2. En el módulo 8, migrarás esa app de Task Queue a Cloud Tasks. En el módulo 9, continuarás ese recorrido y transferirás esa app a Python 3, además de cambiar el acceso a Datastore de usar Cloud NDB a la biblioteca cliente nativa de Cloud Datastore.

Dado que Cloud NDB funciona tanto para Python 2 como para Python 3, es suficiente para los usuarios de App Engine que transfieren sus apps de Python 2 a 3. Una migración adicional de las bibliotecas cliente a Cloud Datastore es completamente opcional, y solo hay un motivo para considerarla: ya tienes aplicaciones que no son de App Engine (o aplicaciones de App Engine de Python 3) que usan la biblioteca cliente de Cloud Datastore y deseas consolidar tu base de código para acceder a Datastore con una sola biblioteca cliente. Cloud NDB se creó específicamente para los desarrolladores de App Engine de Python 2 como una herramienta de migración a Python 3, por lo que, si aún no tienes código que use la biblioteca cliente de Cloud Datastore, no es necesario que consideres esta migración.

Por último, el desarrollo de la biblioteca cliente de Cloud Tasks continúa solo en Python 3, por lo que "migramos" de una de las versiones finales de Python 2 a su versión contemporánea de Python 3. Afortunadamente, no hay cambios que interrumpan la compatibilidad con Python 2, lo que significa que no tienes que hacer nada más aquí.

En este instructivo, se incluyen los siguientes pasos:

  1. Configurar/trabajo previo
  2. Actualizar configuración
  3. Modifica el código de la aplicación

3. Configurar/trabajo previo

Esta sección explica cómo:

  1. Configura el proyecto de Cloud
  2. Obtén app de ejemplo del modelo de referencia
  3. (Vuelve a) implementar y validar la app de referencia

Estos pasos garantizan que comiences con un código funcional y que esté listo para la migración a los servicios de Cloud.

1. Configura el proyecto

Si completaste el codelab del módulo 8, vuelve a usar ese mismo proyecto (y el código). De manera alternativa, puedes crear un proyecto nuevo o reutilizar otro proyecto existente. Asegúrate de que el proyecto tenga una cuenta de facturación activa y una app de App Engine habilitada. Busca el ID de tu proyecto, ya que lo necesitarás durante este codelab. Úsalo cada vez que encuentres la variable PROJECT_ID.

2. Obtén app de ejemplo del modelo de referencia

Uno de los requisitos previos es una app de App Engine del módulo 8 que funcione: completa el codelab del módulo 8 (recomendado) o copia la app del módulo 8 del repo. Sin importar si usas el tuyo o el nuestro, el código del módulo 8 es el que tendremos en cuenta. Este codelab te guía por la migración y concluye con un código que se parece al que se encuentra en la carpeta del repositorio del módulo 9 ("FINISH").

Independientemente de la app del módulo 7 que uses, la carpeta debería verse como la siguiente, posiblemente con una carpeta lib también:

$ ls
README.md               appengine_config.py     requirements.txt
app.yaml                main.py                 templates

3. (Vuelve a) implementar y validar la app de referencia

Ejecuta los siguientes pasos para implementar la app del módulo 8:

  1. Borra la carpeta lib si existe y ejecuta pip install -t lib -r requirements.txt para volver a completar lib. Es posible que debas usar pip2 si tienes instalados Python 2 y 3 en tu máquina de desarrollo.
  2. Asegúrate de haber instalado y inicializado la herramienta de línea de comandos de gcloud, y de haber revisado su uso.
  3. (Opcional) Configura tu proyecto de Cloud con gcloud config set project PROJECT_ID si no quieres ingresar PROJECT_ID con cada comando gcloud que emitas.
  4. Implementa la app de ejemplo con gcloud app deploy
  5. Confirma que la app se ejecuta según lo esperado y sin problemas. Si completaste el codelab del módulo 8, la app muestra los visitantes principales junto con las visitas más recientes (como se ilustra a continuación). En la parte inferior, se indica cuáles son las tareas más antiguas que se borrarán.

4aa8a2cb5f527079.png

4. Actualizar configuración

requirements.txt

El nuevo requirements.txt es casi igual al del módulo 8, con un solo cambio importante: reemplaza google-cloud-ndb por google-cloud-datastore. Realiza este cambio para que tu archivo requirements.txt se vea de la siguiente manera:

flask
google-cloud-datastore
google-cloud-tasks

Este archivo requirements.txt no incluye números de versión, lo que significa que se seleccionan las versiones más recientes. Si surgen incompatibilidades, es una práctica estándar usar números de versión para fijar las versiones de trabajo de una app.

app.yaml

El entorno de ejecución de App Engine de segunda generación no admite bibliotecas de terceros integradas como en la versión 2.x ni copia de bibliotecas no integradas. El único requisito para los paquetes de terceros es incluirlos en requirements.txt. Como resultado, se puede borrar toda la sección libraries de app.yaml.

Otra actualización es que el entorno de ejecución de Python 3 requiere el uso de frameworks web que realicen su propio enrutamiento. Como resultado, todos los controladores de secuencias de comandos deben cambiarse a auto. Sin embargo, dado que todas las rutas deben cambiarse a auto y no se publican archivos estáticos desde esta app de ejemplo, no es relevante tener controladores any, por lo que también se debe quitar toda la sección handlers.

Lo único que se necesita en app.yaml es configurar el entorno de ejecución en una versión compatible de Python 3, por ejemplo, 3.10. Realiza este cambio para que el nuevo app.yaml abreviado sea solo esta línea:

runtime: python310

Borra appengine_config.py y lib

Los entornos de ejecución de App Engine de nueva generación renuevan el uso de paquetes de terceros:

  • Las bibliotecas integradas son aquellas que Google verificó y que están disponibles en los servidores de App Engine, probablemente porque contienen código en C/C++ que los desarrolladores no pueden implementar en la nube. Estas ya no están disponibles en los tiempos de ejecución de 2ª generación.
  • Ya no es necesario copiar bibliotecas no integradas (a veces llamadas "vendoring" o "self-bundling") en los entornos de ejecución de 2ª generación. En cambio, deben aparecer en requirements.txt, donde el sistema de compilación los instala automáticamente en tu nombre en el momento de la implementación.

Como resultado de esos cambios en la administración de paquetes de terceros, no se necesitan el archivo appengine_config.py ni la carpeta lib, por lo que debes borrarlos. En los entornos de ejecución de 2ª generación, App Engine instala automáticamente los paquetes de terceros que se indican en requirements.txt. Resumen:

  1. No hay bibliotecas de terceros copiadas ni autoagrupadas en paquetes; enuméralas en requirements.txt
  2. No hay pip install en una carpeta lib, lo que significa que no hay un período de carpeta lib
  3. No se enumeran las bibliotecas integradas de terceros (por lo tanto, no hay sección libraries) en app.yaml; se enumeran en requirements.txt
  4. No hay bibliotecas de terceros a las que hacer referencia desde tu app, lo que significa que no se necesita ningún archivo appengine_config.py

Enumerar todas las bibliotecas de terceros deseadas en requirements.txt es el único requisito para los desarrolladores.

5. Actualizar archivos de la aplicación

Solo hay un archivo de aplicación, main.py, por lo que todos los cambios de esta sección afectan solo a ese archivo. A continuación, se muestra una ilustración de las "diferencias" en los cambios generales que se deben realizar para refactorizar el código existente en la nueva app. No se espera que los lectores lean el código línea por línea, ya que su propósito es simplemente obtener una descripción general pictórica de lo que se requiere en esta refactorización (pero no dude en abrirlo en una pestaña nueva o descargarlo y acercarlo si lo desea).

5d043768ba7be742.png

Actualizar las importaciones y la inicialización

La sección de importación en main.py para el módulo 8 usa Cloud NDB y Cloud Tasks, y debería verse de la siguiente manera:

ANTES:

from datetime import datetime
import json
import logging
import time
from flask import Flask, render_template, request
import google.auth
from google.cloud import ndb, tasks

app = Flask(__name__)
ds_client = ndb.Client()
ts_client = tasks.CloudTasksClient()

El registro se simplificó y mejoró en los entornos de ejecución de segunda generación, como Python 3:

  • Para disfrutar de una experiencia de registro integral, usa Cloud Logging.
  • Para un registro simple, solo envía a stdout (o stderr) a través de print()
  • No es necesario usar el módulo logging de Python (así que quítalo).

Por lo tanto, borra la importación de logging y reemplaza google.cloud.ndb por google.cloud.datastore. De manera similar, cambia ds_client para que apunte a un cliente de Datastore en lugar de a un cliente de NDB. Con estos cambios, la parte superior de tu nueva app ahora se ve de la siguiente manera:

DESPUÉS:

from datetime import datetime
import json
import time
from flask import Flask, render_template, request
import google.auth
from google.cloud import datastore, tasks

app = Flask(__name__)
ds_client = datastore.Client()
ts_client = tasks.CloudTasksClient()

Migra a Cloud Datastore

Ahora es el momento de reemplazar el uso de la biblioteca cliente de NDB por Datastore. Tanto App Engine NDB como Cloud NDB requieren un modelo de datos (clase); para esta app, es Visit. La función store_visit() funciona de la misma manera en todos los demás módulos de migración: registra una visita creando un nuevo registro Visit, guardando la dirección IP y el agente de usuario (tipo de navegador) de un cliente visitante.

ANTES:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

Sin embargo, Cloud Datastore no usa una clase de modelo de datos, por lo que debes borrar la clase. Además, Cloud Datastore no crea automáticamente una marca de tiempo cuando se crean registros, por lo que debes hacerlo de forma manual con la llamada datetime.now().

Sin la clase de datos, tu store_visit() modificado debería verse así:

DESPUÉS:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    entity = datastore.Entity(key=ds_client.key('Visit'))
    entity.update({
        'timestamp': datetime.now(),
        'visitor': '{}: {}'.format(remote_addr, user_agent),
    })
    ds_client.put(entity)

La función clave es fetch_visits(). No solo realiza la búsqueda original de los Visit más recientes, sino que también toma la marca de tiempo del último Visit mostrado y crea la tarea de envío que llama a /trim (y, por lo tanto, a trim()) para borrar de forma masiva los Visit antiguos. Aquí se muestra cómo usar Cloud NDB:

ANTES:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    with ds_client.context():
        data = Visit.query().order(-Visit.timestamp).fetch(limit)
    oldest = time.mktime(data[-1].timestamp.timetuple())
    oldest_str = time.ctime(oldest)
    logging.info('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return (v.to_dict() for v in data), oldest_str

Los cambios principales son los siguientes:

  1. Reemplaza la consulta de Cloud NDB por el equivalente de Cloud Datastore. Los estilos de consulta difieren ligeramente.
  2. Datastore no requiere el uso de un administrador de contexto ni la extracción de sus datos (con to_dict()) como lo hace Cloud NDB.
  3. Reemplaza las llamadas de registro por print()

Después de esos cambios, fetch_visits() se verá de la siguiente manera:

DESPUÉS:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    visits = list(query.fetch(limit=limit))
    oldest = time.mktime(visits[-1]['timestamp'].timetuple())
    oldest_str = time.ctime(oldest)
    print('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

Normalmente, esto sería todo lo necesario. Lamentablemente, hay un problema importante.

(Posiblemente) crear una nueva cola (de envío)

En el módulo 7, agregamos el uso de taskqueue de App Engine a la app existente del módulo 1. Un beneficio clave de tener tareas de envío como una función heredada de App Engine es que se crea automáticamente una cola "predeterminada". Cuando esa app se migró a Cloud Tasks en el módulo 8, esa cola predeterminada ya estaba allí, por lo que aún no debíamos preocuparnos por ella. Eso cambia aquí, en el módulo 9.

Un aspecto fundamental que debes tener en cuenta es que la nueva aplicación de App Engine ya no usa los servicios de App Engine y, por lo tanto, ya no puedes suponer que App Engine crea automáticamente una fila de tareas en otro producto (Cloud Tasks). Tal como está escrito, fallará la creación de una tarea en fetch_visits() (para una cola no existente). Se necesita una nueva función para verificar si existe la cola ("default") y, si no es así, crear una.

Llama a esta función _create_queue_if() y agrégala a tu aplicación justo arriba de fetch_visits(), ya que es allí donde se la llama. Cuerpo de la función que se agregará:

def _create_queue_if():
    'app-internal function creating default queue if it does not exist'
    try:
        ts_client.get_queue(name=QUEUE_PATH)
    except Exception as e:
        if 'does not exist' in str(e):
            ts_client.create_queue(parent=PATH_PREFIX,
                    queue={'name': QUEUE_PATH})
    return True

La función create_queue() de Cloud Tasks requiere la ruta de acceso completa de la cola excepto el nombre de la cola. Para simplificar, crea otra variable PATH_PREFIX que represente QUEUE_PATH menos el nombre de la cola (QUEUE_PATH.rsplit('/', 2)[0]). Agrega su definición cerca de la parte superior para que el bloque de código con todas las asignaciones de constantes se vea de la siguiente manera:

_, PROJECT_ID = google.auth.default()
REGION_ID = 'REGION_ID'    # replace w/your own
QUEUE_NAME = 'default'     # replace w/your own
QUEUE_PATH = ts_client.queue_path(PROJECT_ID, REGION_ID, QUEUE_NAME)
PATH_PREFIX = QUEUE_PATH.rsplit('/', 2)[0]

Ahora modifica la última línea de fetch_visits() para usar _create_queue_if(). Primero, crea la cola si es necesario y, luego, crea la tarea:

    if _create_queue_if():
        ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

Ahora, tanto _create_queue_if() como fetch_visits() deberían verse de la siguiente manera en conjunto:

def _create_queue_if():
    'app-internal function creating default queue if it does not exist'
    try:
        ts_client.get_queue(name=QUEUE_PATH)
    except Exception as e:
        if 'does not exist' in str(e):
            ts_client.create_queue(parent=PATH_PREFIX,
                    queue={'name': QUEUE_PATH})
    return True

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    visits = list(query.fetch(limit=limit))
    oldest = time.mktime(visits[-1]['timestamp'].timetuple())
    oldest_str = time.ctime(oldest)
    print('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    if _create_queue_if():
        ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

Aparte de tener que agregar este código adicional, el resto del código de Cloud Tasks se mantiene casi intacto desde el módulo 8. El último fragmento de código que debes consultar es el controlador de tareas.

Actualiza el controlador de tareas (envío)

En el controlador de tareas, trim(), el código de Cloud NDB consulta las visitas más antiguas que las que se muestran. Utiliza una consulta de solo claves para acelerar el proceso. ¿Por qué recuperar todos los datos si solo necesitas los IDs de visita? Una vez que tengas todos los IDs de visita, bórralos en lote con la función delete_multi() de Cloud NDB.

ANTES:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    with ds_client.context():
        keys = Visit.query(
                Visit.timestamp < datetime.fromtimestamp(oldest)
        ).fetch(keys_only=True)
        nkeys = len(keys)
        if nkeys:
            logging.info('Deleting %d entities: %s' % (
                    nkeys, ', '.join(str(k.id()) for k in keys)))
            ndb.delete_multi(keys)
        else:
            logging.info(
                    'No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

Al igual que con fetch_visits(), la mayor parte de los cambios implica intercambiar el código de Cloud NDB por Cloud Datastore, ajustar los estilos de consulta, quitar el uso de su administrador de contexto y cambiar las llamadas de registro a print().

DESPUÉS:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    query = ds_client.query(kind='Visit')
    query.add_filter('timestamp', '<', datetime.fromtimestamp(oldest))
    query.keys_only()
    keys = list(visit.key for visit in query.fetch())
    nkeys = len(keys)
    if nkeys:
        print('Deleting %d entities: %s' % (
                nkeys, ', '.join(str(k.id) for k in keys)))
        ds_client.delete_multi(keys)
    else:
        print('No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

No hay cambios en el controlador principal de la aplicación root().

Portabilidad a Python 3

Esta app de ejemplo se diseñó para ejecutarse en Python 2 y 3. Los cambios específicos de Python 3 se abordaron anteriormente en las secciones pertinentes de este instructivo. No se requieren pasos adicionales ni bibliotecas de compatibilidad.

Actualización de Cloud Tasks

La versión final de la biblioteca cliente de Cloud Tasks que admite Python 2 es la 1.5.0. En el momento de escribir este artículo, la versión más reciente de la biblioteca cliente para Python 3 es totalmente compatible con esa versión, por lo que no se requieren más actualizaciones.

Actualización de la plantilla HTML

Tampoco se necesitan cambios en el archivo de plantilla HTML, templates/index.html, por lo que esto completa todos los cambios necesarios para llegar a la app del módulo 9.

6. Resumen/Limpieza

Implementa y verifica la aplicación

Una vez que completes las actualizaciones de código, principalmente la transferencia a Python 3, implementa tu app con gcloud app deploy. El resultado debe ser idéntico al de las apps de los módulos 7 y 8, excepto que moviste el acceso a la base de datos a la biblioteca cliente de Cloud Datastore y actualizaste a Python 3:

App de visitme del módulo 7

Con este paso, se completa el codelab. Te invitamos a comparar tu código con el contenido de la carpeta del módulo 9. ¡Felicitaciones!

Limpia

General

Si terminaste por ahora, te recomendamos que inhabilites tu app de App Engine para evitar incurrir en cargos de facturación. Sin embargo, si deseas realizar más pruebas o experimentos, la plataforma de App Engine tiene una cuota gratuita, por lo que no se te cobrará siempre que no excedas ese nivel de uso. Esto se aplica a la capacidad de procesamiento, pero también puede haber cargos por los servicios relevantes de App Engine, por lo que debes consultar su página de precios para obtener más información. Si esta migración involucra otros servicios de Cloud, estos se facturarán por separado. En cualquier caso, si corresponde, consulta la sección "Específico para este codelab" que se encuentra más abajo.

Para divulgar toda la información, la implementación en una plataforma de computación sin servidores de Google Cloud, como App Engine, genera costos menores de compilación y almacenamiento. Cloud Build tiene su propia cuota gratuita, al igual que Cloud Storage. El almacenamiento de esa imagen usa parte de esa cuota. Sin embargo, es posible que vivas en una región que no tenga ese nivel gratuito, por lo que debes tener en cuenta tu uso de almacenamiento para minimizar los costos potenciales. Las "carpetas" específicas de Cloud Storage que debes revisar incluyen las siguientes:

  • console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
  • console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
  • Los vínculos de almacenamiento anteriores dependen de tu PROJECT_ID y *LOC*ación, por ejemplo, "us" si tu app está alojada en EE.UU.

Por otro lado, si no vas a continuar con esta aplicación ni con otros codelabs de migración relacionados y quieres borrar todo por completo, cierra tu proyecto.

Específico para este codelab

Los servicios que se indican a continuación son exclusivos de este codelab. Consulta la documentación de cada producto para obtener más información:

Próximos pasos

Con esto, concluimos la migración de las tareas de envío de App Engine Task Queue a Cloud Tasks. La migración opcional de Cloud NDB a Cloud Datastore también se aborda por separado (sin Task Queue ni Cloud Tasks) en el módulo 3. Además del módulo 3, hay otros módulos de migración que se enfocan en dejar de usar los servicios agrupados en paquetes heredados de App Engine que debes tener en cuenta, incluidos los siguientes:

App Engine ya no es la única plataforma sin servidores de Google Cloud. Si tienes una app de App Engine pequeña o una que tiene funcionalidad limitada y deseas convertirla en un microservicio independiente, o bien quieres dividir una app monolítica en varios componentes reutilizables, estos son buenos motivos para considerar la posibilidad de migrar a Cloud Functions. Si la contenerización se convirtió en parte de tu flujo de trabajo de desarrollo de aplicaciones, en especial si consta de una canalización de CI/CD (integración continua/entrega o implementación continua), considera migrar a Cloud Run. Estos casos se abordan en los siguientes módulos:

  • Migra de App Engine a Cloud Functions: Consulta el módulo 11
  • Migra de App Engine a Cloud Run: Consulta el módulo 4 para organizar tu app en contenedores con Docker o el módulo 5 para hacerlo sin contenedores, conocimientos de Docker ni Dockerfiles.

Cambiar a otra plataforma sin servidores es opcional, y te recomendamos que consideres las mejores opciones para tus apps y casos de uso antes de realizar cualquier cambio.

Independientemente del módulo de migración que consideres a continuación, se puede acceder a todo el contenido de Serverless Migration Station (codelabs, videos, código fuente [cuando esté disponible]) en su repositorio de código abierto. El README del repo también proporciona orientación sobre qué migraciones considerar y cualquier "orden" relevante de los módulos de migración.

7. Recursos adicionales

Problemas o comentarios de los Codelabs

Si encuentras algún problema con este Codelab, primero busca el problema antes de enviarlo. Vínculos para buscar y crear problemas nuevos:

Recursos de migración

En la siguiente tabla, puedes encontrar vínculos a las carpetas del repositorio para el módulo 8 (INICIAR) y el módulo 9 (FINALIZAR). También se puede acceder a ellos desde el repositorio de todas las migraciones de codelab de App Engine, que puedes clonar o descargar un archivo ZIP.

Codelab

Python 2

Python 3

Módulo 8

código

(n/a)

Módulo 9

(n/a)

código

Recursos en línea

A continuación, se incluyen recursos en línea que pueden ser pertinentes para este instructivo:

App Engine

Cloud NDB

Cloud Datastore

Cloud Tasks

Otra información de la nube

Licencia

Este trabajo cuenta con una licencia Atribución 2.0 Genérica de Creative Commons.