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

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.

Hay situaciones en las que no tienes una "app completa" requerir los recursos de App Engine o Cloud Run. Si tu código consta solo de un microservicio o una función simple, es probable que Cloud Functions sea la mejor opción. En este codelab, aprenderás a migrar apps simples de App Engine (o dividir apps más grandes en varios microservicios) y, luego, 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
  • Convierte una app pequeña 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. Información general

Los sistemas de PaaS, como Google App Engine y Cloud Functions, proporcionan muchos beneficios a los usuarios. Estas plataformas sin servidores permiten que tu equipo técnico se enfoque en crear soluciones empresariales en lugar de dedicar tiempo a investigar plataformas para usar y determinar la cantidad de hardware necesario. Las aplicaciones pueden aumentar la escala automáticamente según sea necesario, reducir la escala verticalmente a cero con la facturación de pago por uso para controlar los costos y permitir una variedad de lenguajes de desarrollo comunes de hoy en día.

Sin embargo, si bien el desarrollo de aplicaciones web de pila completa o los backends complejos para aplicaciones para dispositivos móviles son excelentes opciones para App Engine, los desarrolladores suelen intentar poner en línea algunas funciones, como actualizar un feed de noticias o obtener la puntuación más reciente de la eliminatoria del equipo local. Si bien la lógica de programación existe para ambas situaciones, ninguna parece ser una “aplicación” completa que requieren la potencia de App Engine. Aquí es donde Cloud Functions cobra importancia.

Cloud Functions sirve para implementar la porción pequeña de código que hace lo siguiente:

  • No es parte de toda la aplicación.
  • No se necesitan en toda una pila de desarrollo.
  • Se encuentra en una aplicación o un backend de una sola aplicación para dispositivos móviles que se enfoca en un aspecto

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. Si quieres alojar tu función o microservicio en un contenedor y que se ejecute sin servidores en Cloud Run, también puedes hacerlo.

Nuestra aplicación de muestra de App Engine que ha aparecido en casi todos los instructivos de migración es una aplicación 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 más rápida) y con menos “sobrecarga” en general. Esta migración incluye los siguientes pasos:

  • Configurar/trabajo previo
  • Quita los archivos de configuración
  • Modifica 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 de Cloud NDB del módulo 2 porque Cloud Functions no es compatible con Python 2. Primero, configuraremos nuestro proyecto, obtener el código y, luego, implementar la app de referencia para confirmar que empezamos con el código que funciona.

1. Configura el proyecto

Si completaste el codelab del Módulo 2 (y lo transferiste a Python 3), te recomendamos que vuelvas a usar ese mismo proyecto (y código). Como alternativa, puedes crear un proyecto completamente 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 de este codelab es tener una app de ejemplo del Módulo 2 que funcione. Si no tienes uno, completa cualquiera de los instructivos vinculados anteriormente antes de continuar con este paso. De lo contrario, si ya conoces su contenido, puedes comenzar por tomar el código del módulo 2 que aparece a continuación.

Ya sea que uses el tuyo o el nuestro, comenzaremos en el código de Python 3 del módulo 2. En este codelab del módulo 11, se explica cada paso y se concluye con un código similar al que hay en la carpeta del repositorio del módulo 11 (FINISH).

El directorio de los archivos STARTing del módulo 2 de Python 3 (tuyos o los nuestros) debería verse de la siguiente manera:

$ 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 correctamente esos pasos, estarás listo para convertirla en una Cloud Function.

4. Quita los archivos de configuración

El archivo app.yaml es un artefacto de App Engine que no se usa con Cloud Functions, así que bórralo ahora. Si olvida hacerlo, no hay problema, ya que Cloud Functions no lo usa. Ese es el único cambio de configuración, ya que requirements.txt permanece idéntico al del módulo 2.

Si también transferirás 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 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 producirán en este archivo.

Importaciones

Debido a que solo trabajamos con funciones, no hay necesidad de un framework de aplicación web. Sin embargo, para tu conveniencia, cuando se llama 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 pasó a su función).

Debido a que los frameworks web no forman parte del entorno de Cloud Functions, no hay importaciones de Flask, a menos que tu app use otras funciones de Flask. Este es nuestro caso, ya que la renderización de plantillas todavía se realiza después de la conversión a una función, lo que significa que aún se requiere una llamada a flask.render_template() y, por lo tanto, su importación desde Flask. Como no hay un framework web, no es necesario crear una instancia de una app de Flask, por lo que debes borrar app = Flask(__name__). Antes y después de aplicar los cambios, tu código se verá de la siguiente manera:

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 buscar proxies. Solo entonces podrás convertir tu código en una Cloud Function. De lo contrario, te recomendamos que permanezcas en App Engine o alojas tu app en contenedores para Cloud Run.

Actualiza la firma de la función del controlador principal

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

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

A continuación, te mostramos el antes y el después de 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 concluye todas las actualizaciones necesarias. Ten en cuenta que los cambios solo afectaron la "infraestructura" de la aplicación código. No se necesitaban cambios en el código principal de la aplicación y no se alteró ninguna funcionalidad de la app. A continuación, se incluye una representación visual de los cambios que se realizaron para ilustrar este punto:

668f30e3865b27a9.png

Desarrollo y pruebas locales

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

6. Compila e implementa

La implementación en Cloud Functions difiere un poco 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 la función, usa la URL del resultado de la implementación y visita tu app. La URL tiene el formato REGION-PROJECT_ID.cloudfunctions.net/visitme. El resultado debería ser idéntico al de la implementación anterior en App Engine:

2732ae9218f011a2.png

Al igual que con la mayoría de los demás codelabs y videos de la serie, la funcionalidad de referencia de la app no cambia. El propósito es aplicar una técnica de modernización y hacer que la app funcione exactamente como antes, pero con la tecnología de infraestructura más nueva, por ejemplo, migrar de un servicio heredado de App Engine 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 aplicación de App Engine en una Cloud Function. Otro caso de uso adecuado es dividir una aplicación 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 genera un modelo más "plug-and-play" componente (a la "pila de JAM"). Permite mezclar, hacer coincidir 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 del Módulo 2 de App Engine (de manera 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á mientras permanezcas 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 una parte de esa cuota. Ten en cuenta el uso del almacenamiento para minimizar los posibles costos, especialmente si tu región no cuenta con este nivel gratuito.

Desafortunadamente, Cloud Functions no tiene un . Crea una copia de seguridad de tu código y simplemente borra la función. Puedes volver a implementarla con el mismo nombre más adelante. Sin embargo, si no vas a continuar con ningún otro codelab de migración y deseas borrar todo por completo, cierra tus proyectos de Cloud.

Próximos pasos

Más allá de este instructivo, otros módulos de migración que puedes analizar incluyen la creación de contenedores para 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 reemplazos independientes de Cloud:

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 en lugar de Cloud Functions. Consulta el Módulo 4 para alojar tu app en contenedores con Docker, o el Módulo 5 para hacerlo sin contenedores, conocimiento de Docker ni Dockerfile. Ya sea que estés considerando usar Cloud Functions o Cloud Run, cambiar a otra plataforma sin servidores es opcional, y te recomendamos considerar 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.

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, 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 3

Módulo 2

código

Módulo 11

código

Recursos en línea

A continuación, hay recursos en línea que pueden ser relevantes para este tutorial:

App Engine

Cloud Functions

Otra información de Cloud

Videos

Licencia

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