Módulo 11: Migra de Google App Engine a Cloud Functions

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.

Hay situaciones en las que no tienes una "app completa" para requerir los recursos de App Engine o Cloud Run. Si tu código solo consta de un microservicio o una función simple, es probable que Cloud Functions sea una mejor opción. En este codelab, aprenderás a migrar apps sencillas de App Engine (o a dividir apps más grandes en varios microservicios) y a implementarlas en Cloud Functions, otra plataforma sin servidores creada específicamente para casos de uso como este.

En un próximo lab,

  • Uso de Cloud Shell
  • Habilita la API de Google Cloud Translation
  • Autentica solicitudes a la API
  • Cómo convertir una pequeña app de App Engine para que se ejecute en Cloud Functions
  • Implementa tu código en Cloud Functions

Requisitos

Encuesta

¿Cómo usarás este instructivo?

Leer 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

Los sistemas de PaaS, como Google App Engine y Cloud Functions, ofrecen muchos beneficios para los usuarios. Estas plataformas sin servidores permiten que tu equipo técnico se concentre en crear soluciones comerciales en lugar de dedicar tiempo a investigar qué plataformas usar y determinar la cantidad de hardware necesario. Las aplicaciones pueden realizar un ajuste de escala automático según sea necesario, reducir la escala verticalmente a cero con la facturación de pago por uso para controlar los costos y admiten una variedad de lenguajes de desarrollo comunes de la actualidad.

Sin embargo, si bien el desarrollo de aplicaciones web de pila completa o los back-ends complejos para aplicaciones para dispositivos móviles son ideales para App Engine, a menudo los desarrolladores solo intentan poner en línea alguna funcionalidad, como actualizar un feed de noticias o extraer el último resultado del partido de playoffs del equipo local. Si bien existe lógica de programación para ambos casos, ninguno parece ser una "aplicación" completa que requiera la potencia de App Engine. Aquí es donde entran en juego las Cloud Functions.

Cloud Functions se usa para implementar el pequeño fragmento de código que hace lo siguiente:

  • No forma parte de una aplicación completa
  • No se necesita en toda la pila de desarrollo
  • Se encuentra en una aplicación o en un backend de una sola app para dispositivos móviles que se enfoca en un solo tema.

También puedes usar Cloud Functions para dividir una aplicación monolítica grande en varios microservicios, cada uno con una base de datos común compartida, como Cloud Firestore o Cloud SQL. Y si quieres que tu función o microservicio se ejecute en un contenedor sin servidores en Cloud Run, también puedes hacerlo.

Nuestra app de ejemplo de App Engine que se incluyó en casi todos los instructivos de migración es una app corta con funcionalidad básica que funciona igual de bien en Cloud Functions. En este instructivo, aprenderás a modificar esa app para que se ejecute en Cloud Functions. Desde la perspectiva de App Engine, debido a que las funciones son más simples que las apps completas, tu experiencia de inicio debería ser más fácil (y rápida), y con menos "sobrecarga" en general. Esta migración incluye los siguientes pasos:

  • Configurar/trabajo previo
  • Cómo quitar archivos de configuración
  • Modifica los archivos de la aplicación

3. Configurar/trabajo previo

Este codelab comienza con la versión de Python 3 de la app de ejemplo de App Engine para Cloud NDB del módulo 2 porque Cloud Functions no admite Python 2. Primero, configuremos nuestro proyecto, obtengamos el código y, luego, implementemos la app de modelo de referencia para confirmar que comenzamos a trabajar con el código.

1. Configura el proyecto

Si completaste el codelab del Módulo 2 (y lo portaste a Python 3), te recomendamos volver 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 con el servicio de App Engine habilitado.

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

Uno de los requisitos previos para este codelab es tener una app de ejemplo del módulo 2 que funcione. Si aún no tienes una, completa uno de los instructivos vinculados anteriormente antes de avanzar. De lo contrario, si ya estás familiarizado con su contenido, puedes comenzar leyendo el código del Módulo 2 a continuación.

Sin importar si usas el tuyo o el nuestro, el código del módulo 2 de Python 3 es el que tendremos en cuenta. Este codelab del módulo 11 te guiará en cada paso y concluirá con un código que se parezca al que se encuentra en la carpeta del repositorio del módulo 11 (FINALIZAR).

El directorio de archivos de INICIO del módulo 2 de Python 3 (los tuyos o los nuestros) debe ser similar al siguiente:

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

3. (vuelve a) implementa la aplicación de modelo de referencia

Los pasos del trabajo previo restantes para ejecutar ahora sin estos:

  1. Familiarízate con la herramienta de línea de comandos de gcloud
  2. Vuelve a implementar la app de muestra con gcloud app deploy
  3. Confirma que la app se ejecuta en App Engine sin problemas

Una vez que hayas ejecutado esos pasos de manera correcta, podrás convertirla en una Cloud Function.

4. Cómo quitar archivos de configuración

El archivo app.yaml es un artefacto de App Engine que no se usa con Cloud Functions, por lo que debes borrarlo ahora. Si no lo haces o te olvidas de hacerlo, no hay ningún problema, ya que Cloud Functions no lo usa. Ese es el único cambio de configuración, ya que requirements.txt sigue siendo idéntico a lo que es desde el módulo 2.

Si también estás transfiriendo una app de App Engine de Python 2 a Python 3, borra appengine_config.py y la carpeta lib si tienes una. Son artefactos de App Engine que no se usan en el entorno de ejecución de Python 3.

5. Modifica los archivos de la aplicación

Solo hay un archivo de aplicación, main.py, por lo que todos los cambios necesarios para migrar a Cloud Functions se producen en este archivo.

Importaciones

Como solo trabajamos con funciones, no necesitamos un framework de aplicaciones web. Sin embargo, para mayor comodidad, cuando se llaman a Cloud Functions basadas en Python, se les pasa automáticamente un objeto de solicitud para que tu código lo use según sea necesario. (El equipo de Cloud Functions lo seleccionó para que sea un objeto Request de Flask que se pasa a tu función).

Dado que los frameworks web no forman parte del panorama de Cloud Functions, no hay importaciones de Flask a menos que tu app use otras funciones de Flask. Este es, de hecho, nuestro caso, ya que la renderización de la plantilla sigue teniendo lugar después de la conversión a una función, lo que significa que aún se requiere una llamada a flask.render_template(), por lo que se importa desde Flask. Como no hay framework web, no es necesario crear una instancia de una app de Flask, por lo que debes borrar app = Flask(__name__). Tu código se ve de la siguiente manera, antes y después de aplicar los cambios:

ANTES:

from flask import Flask, render_template, request
from google.cloud import ndb

app = Flask(__name__)
ds_client = ndb.Client()

DESPUÉS:

from flask import render_template
from google.cloud import ndb

ds_client = ndb.Client()

Si dependes del objeto de la app (app) o de cualquier otra infraestructura de framework web, debes resolver todas esas dependencias, encontrar soluciones alternativas adecuadas, quitar su uso por completo o encontrar proxies. Solo entonces podrás convertir tu código en una Cloud Function. De lo contrario, te convendrá más quedarte en App Engine o crear un contenedor para tu app en Cloud Run.

Actualiza la firma de la función del controlador principal

Los cambios necesarios en la firma de la función son los siguientes:

  1. Flask ya no se usa después de convertir la app en una función de Cloud Functions, por lo que debes quitar los decoradores de rutas.
  2. Cloud Functions pasa automáticamente el objeto Request de Flask como un parámetro, por lo que debes crear una variable para él. En nuestra app de ejemplo, la llamaremos request.
  3. Las Cloud Functions implementadas deben tener un nombre. Nuestro controlador principal se denominó root() de forma adecuada en App Engine para describir lo que era (el controlador de la aplicación raíz). Como Cloud Function, no tiene mucho sentido usar ese nombre. En su lugar, implementaremos la Cloud Function con el nombre visitme, así que usa ese nombre también para la función de Python. Del mismo modo, en los módulos 4 y 5, también llamamos al servicio de Cloud Run visitme.

Aquí se muestran los resultados antes y después de aplicar estas actualizaciones:

ANTES:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

DESPUÉS:

def visitme(request):
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

Con esto, se completan todas las actualizaciones necesarias. Ten en cuenta que los cambios realizados solo afectaron el código de "infraestructura" de la aplicación. No se necesitan cambios en el código principal de la aplicación, y no se alteró ninguna de las funciones de la app. A continuación, se muestra una representación gráfica de los cambios que se realizaron para ilustrar este punto:

668f30e3865b27a9.png

Desarrolla y prueba de forma local

Mientras que App Engine tiene el dev_appserver.py servidor de desarrollo local, Cloud Functions tiene su Functions Framework. Con este framework, puedes desarrollar y probar de forma local. Tu código se puede implementar en Cloud Functions, pero también en otras plataformas de procesamiento, como Compute Engine, Cloud Run o incluso en sistemas locales o de nube híbrida que admitan Knative. A continuación, encontrarás vínculos adicionales a Functions Framework.

6. Compila e implementa

La implementación en Cloud Functions difiere ligeramente de la de App Engine. Como no se usan archivos de configuración fuera de requirements.txt, se debe especificar más información sobre el código en la línea de comandos. Implementa tu nueva Cloud Function activada por HTTP que se ejecuta en Python 3.10 con este comando:

$ gcloud functions deploy visitme --runtime python310 --trigger-http --allow-unauthenticated

Espera un resultado similar al siguiente:

Deploying function (may take a while - up to 2 minutes)...⠛
For Cloud Build Logs, visit: https://console.cloud.google.com/cloud-build/builds;region=REGION/f5f6fc81-1bb3-4cdb-8bfe?project=PROJECT_ID
Deploying function (may take a while - up to 2 minutes)...done.
availableMemoryMb: 256
buildId: f5f6fc81-1bb3-4cdb-8bfe
buildName: projects/PROJECT_ID/locations/REGION/builds/f5f6fc81-1bb3-4cdb-8bfe
dockerRegistry: CONTAINER_REGISTRY
entryPoint: visitme
httpsTrigger:
  securityLevel: SECURE_OPTIONAL
  url: https://REGION-PROJECT_ID.cloudfunctions.net/visitme
ingressSettings: ALLOW_ALL
labels:
  deployment-tool: cli-gcloud
name: projects/PROJECT_ID/locations/REGION/functions/visitme
runtime: python310
serviceAccountEmail: PROJECT_ID@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/uploads-853031211983.REGION.cloudfunctions.appspot.com/8c923758-cee8-47ce-8e97-5720a5301c34.zip
status: ACTIVE
timeout: 60s
updateTime: '2022-05-16T18:28:06.153Z'
versionId: '8'

Después de que se implemente tu función, usa la URL del resultado de la implementación y visita tu app. La URL tiene el siguiente formato: REGION-PROJECT_ID.cloudfunctions.net/visitme. El resultado debería ser idéntico al que obtuviste cuando lo implementaste antes en App Engine:

2732ae9218f011a2.png

Al igual que con la mayoría de los otros codelabs y videos de la serie, la funcionalidad básica de la app no cambia. El objetivo es aplicar una técnica de modernización y hacer que la app funcione exactamente igual que antes, pero con una infraestructura más nueva. Por ejemplo, migrar de un servicio heredado de App Engine más antiguo a su producto independiente de Cloud de reemplazo o, como en el caso de este instructivo, trasladar una app a otra plataforma sin servidores de Google Cloud.

7. Resumen/Limpieza

¡Felicitaciones por convertir esta pequeña app de App Engine en una Cloud Function! Otro caso de uso adecuado es dividir una app monolítica grande de App Engine en una serie de microservicios, cada uno como una Cloud Function. Esta es una técnica de desarrollo más moderna que da como resultado un componente más "plug-and-play" (al estilo de " JAM stack"). Permite combinar y reutilizar código, que son dos objetivos, pero otro beneficio es que estos microservicios se seguirán depurando con el tiempo, lo que significa código estable y menores costos de mantenimiento en general.

Limpia

Después de completar este codelab, puedes inhabilitar la app de App Engine del módulo 2 (de forma temporal o permanente) para evitar que se te facture. La plataforma de App Engine tiene una cuota gratuita, por lo que no se te facturará siempre que te mantengas dentro de su nivel de uso. Lo mismo se aplica a Datastore. Consulta la página de precios de Cloud Datastore para obtener más detalles.

La implementación en plataformas como App Engine y Cloud Functions genera costos menores de compilación y almacenamiento. En algunas regiones, Cloud Build tiene su propia cuota gratuita, al igual que Cloud Storage. Las compilaciones consumen parte de esa cuota. Ten en cuenta tu uso de almacenamiento para minimizar los costos potenciales, en especial si tu región no tiene un nivel sin costo.

Lamentablemente, Cloud Functions no tiene una función para inhabilitar. Haz una copia de seguridad de tu código y borra la función. Puedes volver a implementarlo con el mismo nombre más adelante. Sin embargo, si no vas a continuar con ninguna otra codelab de migración y quieres borrar todo por completo, cierra tus proyectos de Cloud.

Próximos pasos

Además de este instructivo, otros módulos de migración que puedes consultar incluyen el alojamiento en contenedores de tu app de App Engine para Cloud Run. Consulta los vínculos a los codelabs de los módulos 4 y 5:

  • Módulo 4: Migra a Cloud Run con Docker
  • Organiza tu aplicación en contenedores para que se ejecute en Cloud Run con Docker
  • Esta migración te permite permanecer en Python 2.
  • Módulo 5: Migra a Cloud Run con Cloud Buildpacks
  • Crea contenedores para tu app a fin de que se ejecute en Cloud Run con paquetes de Cloud Build
  • No necesitas conocer los detalles de Docker, contenedores, ni Dockerfile.
  • Requiere que tu app ya se haya migrado a Python 3 (Buildpacks no es compatible con Python 2).

Muchos de los otros módulos se enfocan en mostrar a los desarrolladores cómo migrar de los servicios en paquetes de App Engine a los reemplazos independientes de Cloud:

  • Módulo 2: Migra de ndb de App Engine a Cloud NDB
  • Módulos 7 a 9: Migra de las tareas de envío de la lista de tareas en cola de App Engine a Cloud Tasks
  • Módulos 12 y 13: Migra de Memcache de App Engine a Cloud Memorystore
  • Módulos 15 y 16: Migra de Blobstore de App Engine a Cloud Storage
  • Módulos 18 y 19: Migra de la lista de tareas en cola de App Engine (tareas de extracción) a Cloud Pub/Sub

Si la contenerización se convirtió en parte de tu flujo de trabajo de desarrollo de aplicaciones, en especial si consiste en una canalización de CI/CD (integración continua/entrega o implementación continua), considera migrar a Cloud Run en lugar de Cloud Functions. 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. Ya sea que consideres Cloud Functions o Cloud Run, 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.

8. Recursos adicionales

Problemas o comentarios de los Codelabs del módulo de migración de App Engine

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 3

Módulo 2

código

Módulo 11

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 Functions

Otra información de la nube

Videos

Licencia

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