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

La serie de codelabs Serverless Migration Station (instructivos prácticos y autoaprendizaje) y los videos relacionados tienen como objetivo ayudar a los desarrolladores de Google Cloud sin servidores a modernizar sus apps guiándolos a través de una o más migraciones, en especial al alejarse 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á integrarlas con una variedad más amplia de productos de Cloud y acceder a ella, y actualizar con mayor facilidad a versiones de idiomas más recientes. Aunque inicialmente 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 cualquier otra, si corresponde.

El propósito de este codelab es transferir la app de ejemplo del módulo 8 a Python 3, así como cambiar el acceso de Datastore (Cloud Firestore en modo Datastore) 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 la lista de tareas en cola para las tareas push en el módulo 7 y, luego, migramos ese uso a Cloud Tasks en el módulo 8. En el módulo 9, continuamos con Python 3 y Cloud Datastore. Aquellos que usen listas de tareas en cola para tareas de extracción migrarán a Cloud Pub/Sub y, en su lugar, deberán consultar los módulos 18-19.

En un próximo lab,

  • Cómo realizar la portabilidad de la app de ejemplo del módulo 8 a Python 3
  • Cambia el acceso a 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 leerlo Léelo y completa 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. Información general

El módulo 7 demuestra cómo usar las tareas push de la lista de tareas en cola de App Engine en las apps de Flask en Python 2 en App Engine. En el módulo 8, migrarás esa app de la lista de tareas en cola a Cloud Tasks. En el Módulo 9, continuarás ese recorrido y podrás migrar la app a Python 3, así como cambiar el acceso a Datastore de 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. Realizar una migración adicional de bibliotecas cliente a Cloud Datastore es completamente opcional y solo hay un motivo para considerarla: tienes aplicaciones que no son de App Engine (o aplicaciones de App Engine para Python 3) que ya utilizan 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 desarrolladores de Python 2 en App Engine como una herramienta de migración de Python 3. Por lo tanto, si aún no tienes código que usa la biblioteca cliente de Cloud Datastore, no debes considerar esta migración.

Por último, el desarrollo de la biblioteca cliente de Cloud Tasks continúa solo en Python 3, por lo que estamos “migrando” de una de las versiones finales de Python 2 a la versión contemporánea de Python 3. Por suerte, no hay cambios rotundos en comparación con Python 2, lo que significa que no debes hacer nada más aquí.

En este instructivo, se muestran 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. (Re)Implementa y valida la app de referencia

Estos pasos garantizan que comiences con el código de trabajo y que esté listo para migrar a los servicios de Cloud.

1. Configura el proyecto

Si completaste el codelab del módulo 8, vuelve a usar ese mismo proyecto (y código). Como alternativa, crea un proyecto completamente nuevo o reutiliza otro proyecto existente. Asegúrate de que el proyecto tenga una cuenta de facturación activa y una app de App Engine habilitada. Encuentra tu ID del proyecto, ya que necesitarás tenerlo a mano durante este codelab, utilízalo cada vez que encuentres la variable PROJECT_ID.

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

Uno de los requisitos previos es tener una app del módulo 8 de App Engine que funcione. Completa el codelab del módulo 8 (recomendado) o copia la app del módulo 8 del repositorio. Sin importar si usa el suyo o el nuestro, comenzaremos en el código del Módulo 8 (“COMENZAR”). En este codelab, se explica la migración y se concluye con un código similar al que hay en la carpeta del repositorio del Módulo 9 (“FINISH”).

Independientemente de la app del Módulo 7 que uses, la carpeta debería tener el siguiente aspecto, posiblemente con una carpeta lib:

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

3. (Re)Implementa y valida la app de referencia

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

  1. Borra la carpeta lib si hay una y ejecuta pip install -t lib -r requirements.txt para volver a propagar lib. Es posible que debas usar pip2 si tienes Python 2 y 3 instalados en tu máquina de desarrollo.
  2. Asegúrate de haber instalado e 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 el PROJECT_ID con cada comando gcloud que emitas.
  4. Implementa la app de ejemplo con gcloud app deploy
  5. Confirma que la app se ejecute como se espera sin problemas. Si completaste el codelab del módulo 8, la app mostrará los visitantes principales junto con las visitas más recientes (que se ilustran a continuación). En la parte inferior, hay una indicación de las tareas más antiguas que se borrarán.

4aa8a2cb5f527079.png

4. Actualizar configuración

requirements.txt

El nuevo requirements.txt es casi el mismo que el del módulo 8, con solo un gran cambio: 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 presenta ningún número de versión, lo que significa que se seleccionaron las versiones más recientes. Si surge alguna incompatibilidad, el uso de números de versión para bloquear versiones de trabajo de una app es una práctica estándar.

app.yaml

El entorno de ejecución de App Engine de segunda generación no admite bibliotecas de terceros integradas, como la 2.x, ni la copia de bibliotecas no integradas. El único requisito para los paquetes de terceros es incluirlos en una lista 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 hagan su propio enrutamiento. Como resultado, todos los controladores de secuencia de comandos se deben cambiar a auto. Sin embargo, como todas las rutas deben cambiarse a auto y no hay archivos estáticos entregados desde esta app de ejemplo, es irrelevante tener cualquier controlador, así que quita también 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 app.yaml nuevo y 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 aprueba y que están disponibles en los servidores de App Engine, probablemente porque contienen código C/C++ que los desarrolladores no pueden implementar en la nube y ya no están disponibles en los entornos de ejecución de 2a generación.
  • Ya no es necesario copiar bibliotecas no integradas (a veces denominadas "proveedores" o "agrupación automática") en los entornos de ejecución de 2a generación. En su lugar, 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 2a generación, App Engine instala automáticamente los paquetes de terceros enumerados en requirements.txt. Resumen:

  1. No deben incluirse bibliotecas de terceros autoempaquetadas ni copiadas. incluirlas 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 deben enumerar bibliotecas de terceros integradas (por lo tanto, no hay una sección libraries) en app.yaml. incluirla en requirements.txt
  4. Si no hay bibliotecas de terceros a las que hacer referencia desde tu app, significa que no hay un archivo appengine_config.py.

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

5. Actualizar archivos de la aplicación

Solo hay un archivo de la aplicación, main.py, por lo que todos los cambios en esta sección afectan solo a ese archivo. A continuación, se muestran las “diferencias” ilustración de los cambios generales que deben realizarse para refactorizar el código existente en la app nueva. 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 ilustrada de lo que se requiere en esta refactorización (pero puedes abrirlo en una pestaña nueva o descargarlo y acercarlo si lo deseas).

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

Logging se simplifica y mejora en los entornos de ejecución de segunda generación, como Python 3:

  • Para obtener una experiencia de registro integral, usa Cloud Logging.
  • Para un registro simple, simplemente envíalo 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 cambia google.cloud.ndb por google.cloud.datastore. Del mismo modo, 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 tendrá el siguiente aspecto:

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). en esta app es Visit. La función store_visit() funciona igual en todos los demás módulos de migración: registra una visita creando un nuevo registro Visit y guardando la dirección IP y el usuario-agente de un cliente visitante (tipo de navegador).

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 borrarla. Además, Cloud Datastore no crea automáticamente una marca de tiempo cuando se crean registros, por lo que debes hacerlo de forma manual. Esto se hace con la llamada datetime.now().

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

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 consulta original para las últimas Visit, sino que también toma la marca de tiempo de la última Visit que se muestra y crea la tarea de envío que llama a /trim (por lo tanto, trim()) para borrar de forma masiva los Visit anteriores. Aquí se usa 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. Intercambia la consulta de Cloud NDB por el equivalente de Cloud Datastore. los estilos de consulta difieren un poco.
  2. Datastore no requiere el uso de un administrador de contexto ni te obliga a extraer 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

Por lo general, eso sería todo lo que se necesitaba. Lamentablemente, hay un problema importante.

(Posiblemente) Crear una nueva cola (de aplicaciones en cola)

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

Un aspecto fundamental a tener en cuenta es que la nueva aplicación de App Engine ya no usa sus servicios y, por lo tanto, ya no se puede suponer que App Engine crea automáticamente una lista de tareas en cola en un producto diferente (Cloud Tasks). Como está escrito, la creación de una tarea en fetch_visits() (para una cola que no existe) fallará. Se necesita una función nueva para verificar si existe la cola (“predeterminada”) y, de no ser así, crear una.

Llama a esta función _create_queue_if() y agrégala a tu aplicación justo por encima de fetch_visits(), ya que allí es donde se la llama. El 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 el nombre de ruta completo de la cola, excepto el nombre de esta. Para simplificar, crea otra variable PATH_PREFIX que represente el 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 en 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

_create_queue_if() y fetch_visits() ahora 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

Además de tener que agregar este código adicional, el resto del código de Cloud Tasks está casi intacto del Módulo 8. El último fragmento de código que hay que analizar es el controlador de tareas.

Actualiza el controlador de tareas (envío)

En el controlador de tareas, trim(), el código de Cloud NDB realiza consultas para las visitas anteriores a la más antigua que se muestra. Usa una consulta de solo clave 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 un 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ía de los cambios implican 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 de la aplicación principal root().

Puerto a Python 3

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

Actualización de Cloud Tasks

La versión final de la biblioteca cliente de Cloud Tasks compatible con Python 2 es 1.5.0. En el momento en que se redacta este documento, 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 incluye 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 el puerto a Python 3, implementa tu app con gcloud app deploy. El resultado debería ser idéntico al de las apps de los Módulos 7 y 8, con la excepción de que transferiste 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 ya terminaste, te recomendamos que inhabilites la aplicación de App Engine para evitar que se te facture. Sin embargo, si deseas probar o experimentar un poco más, la plataforma de App Engine tiene una cuota gratuita y, siempre y cuando no superes ese nivel de uso, no se te debería cobrar. Eso es para procesamiento, pero es posible que también se apliquen cargos por servicios relevantes de App Engine, así que consulta la página de precios para obtener más información. Si esta migración implica otros servicios de Cloud, estos se facturan por separado. En ambos casos, si corresponde, consulta la sección "Específico de este codelab" a continuación.

Para una divulgación completa, la implementación en una plataforma de procesamiento 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 ocupa parte de esa cuota. Sin embargo, es posible que vivas en una región que no cuenta con ese nivel gratuito, así que ten en cuenta el uso que haces del almacenamiento para minimizar posibles costos. “Carpetas” específicas de Cloud Storage que debes revisar incluyen

  • 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*; por ejemplo, "us" si tu app está alojada en EE.UU.

Por otro lado, si no vas a continuar con esta aplicación o algún otro codelab de migración relacionado y quieres borrar todo por completo, cierra tu proyecto.

Información específica de 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

Aquí concluye nuestra migración de las tareas push de la lista de tareas en cola de App Engine a Cloud Tasks. La migración opcional de Cloud NDB a Cloud Datastore también se aborda por sí sola (sin lista de tareas en cola 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 alejarse de los servicios en paquetes heredados de App Engine que se deben considerar, entre los que se incluyen los siguientes:

App Engine ya no es la única plataforma sin servidores en Google Cloud. Si tienes una aplicación pequeña de App Engine o una con funcionalidad limitada y deseas convertirla en un microservicio independiente, o si deseas dividir una aplicación monolítica en varios componentes reutilizables, estas son buenas razones para considerar cambiar a Cloud Functions. Si la creación de contenedores se volvió parte del flujo de trabajo de desarrollo de tu aplicación, en especial si consta de una canalización de CI/CD (integración continua/entrega o implementación continuas), considera migrar a Cloud Run. Estas situaciones 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 alojar tu app en contenedores con Docker, o el Módulo 5 para hacerlo sin contenedores, conocimiento sobre Docker ni Dockerfile.

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, puedes acceder a todo el contenido de Serverless Migration Station (codelabs, videos, código fuente [si está disponible]) a través de su repositorio de código abierto. El README del repositorio 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 sobre 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, encontrarás los vínculos a las carpetas de repositorio del módulo 8 (START) y el módulo 9 (FINISH). También puedes acceder a ellos desde el repositorio para todas las migraciones del codelab de App Engine. 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, hay recursos en línea que pueden ser relevantes para este tutorial:

App Engine

Cloud NDB

Cloud Datastore

Cloud Tasks

Otra información de Cloud

Licencia

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