Módulo 5: Migra de Google App Engine a Cloud Run con Cloud Buildpacks

1. Descripción general

Esta serie de codelabs (instructivos de autoaprendizaje prácticos) tiene como objetivo ayudar a los desarrolladores de Google App Engine (estándar) a modernizar sus apps guiándolos a través de una serie de migraciones. Una vez que se realiza, los usuarios pueden lograr que sus apps sean más portátiles mediante la creación de contenedores para Cloud Run, el servicio de alojamiento de contenedores de Google Cloud en App Engine y otros servicios de alojamiento de contenedores.

En este instructivo, aprenderás a crear contenedores para las apps de App Engine a fin de implementarlas en el servicio completamente administrado de Cloud Run con Cloud Buildpacks, una alternativa a Docker. Cloud Buildpacks organiza tus apps en contenedores sin administrar archivos Dockerfile ni saber nada sobre Docker.

Este codelab está dirigido a desarrolladores de App Engine para Python 2 que trasladaron sus apps de los servicios integrados originales y las portaron a Python 3, y ahora buscan ejecutarlas en un contenedor. El codelab COMIENZA con una app completada de Módulo 2 o Módulo 3 de Python 3.

Obtendrás información para hacer las siguientes acciones

  • Aloja tu app en contenedores con Cloud Buildpacks
  • Implementa imágenes de contenedor en Cloud Run

Qué necesitará

Encuesta

¿Cómo usarás este codelab?

Solo leerlo Léelo y completa los ejercicios. . .

2. Información general

Los sistemas PaaS, como App Engine y Cloud Functions, ofrecen muchos beneficios para tu equipo y aplicación. Por ejemplo, estas plataformas sin servidores permiten que el administrador de sistemas y los desarrolladores se enfoquen en la compilación de soluciones. La app puede 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 que ayuda a controlar los costos, y usa una variedad de lenguajes de desarrollo comunes.

Sin embargo, la flexibilidad de los contenedores también es atractiva, debido a la capacidad de elegir cualquier lenguaje, cualquier biblioteca y cualquier objeto binario. Brindamos a los usuarios lo mejor de ambos mundos, la comodidad de la computación sin servidores y la flexibilidad de los contenedores, es de lo que se trata Google Cloud Run.

Aprender a usar Cloud Run no está dentro del alcance de este codelab. Consulta la documentación de Cloud Run. El objetivo aquí es que aprendas a alojar en contenedores tu app de App Engine para Cloud Run (u otros servicios). Existen algunos aspectos que debes saber antes de continuar, que tu experiencia de usuario será un poco diferente, un poco más bajo, dado que dejarás de implementar el código de la aplicación y de implementarlo.

En su lugar, deberás aprender algo sobre los contenedores, cómo compilarlos e implementarlos. También puedes decidir lo que deseas colocar en la imagen del contenedor, incluido un servidor web, dado que ya no usará el servidor web de App Engine. Si prefieres no seguir esta ruta de acceso, mantener tus apps en App Engine no es una opción adecuada.

En este instructivo, aprenderás a crear contenedores para tu app, quitar los archivos de configuración de App Engine, administrar un servidor web y, también, iniciar tu app.

Esta migración incluye los siguientes pasos:

  1. Configurar/trabajo previo
  2. Alojar la aplicación en contenedores
    • Reemplazar los archivos de configuración
    • Modifica archivos de la aplicación

3. Configurar/trabajo previo

Antes de comenzar con la parte principal del instructivo, configuremos nuestro proyecto, obtengamos el código e implementemos la app de modelo de referencia para que comencemos a trabajar con el código.

1. Configura el proyecto

Si completaste los Codelabs del Módulo 2 o del Módulo 3, te recomendamos volver a usar los mismos proyectos (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 que App Engine (app) esté 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 o 3 que funcione. Si no tienes uno, te recomendamos que completes cualquiera de los instructivos (vínculos anteriores) antes de continuar. De lo contrario, si ya conoces su contenido, puedes comenzar por tomar una de sus carpetas de código que aparecen a continuación.

Ya sea que uses el tuyo o el nuestro, ahí es donde comienza este instructivo. Este codelab te guiará a través de la migración y, cuando termines, debería coincidir principalmente con lo que hay en la carpeta del repositorio FINISH del módulo 5.

El directorio de los archivos START (tuyo o el nuestro) 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 esos pasos de manera correcta, estás listo para alojarla en contenedores.

4. Alojar la aplicación en contenedores

En la actualidad, Docker es la plataforma de creación de contenedores estándar en la industria. Un desafío sobre el uso de este, como se mencionó antes, es que se requiere un esfuerzo para seleccionar un Dockerfile eficaz, el archivo de configuración que determina cómo se compilan las imágenes de tu contenedor. Por otro lado, los Buildpacks requieren poco esfuerzo, ya que usan la introspección a fin de determinar las dependencias de tu app, lo que hace que el contenedor de Buildpacks sea lo más eficiente posible para tu app.

Estás en el lugar correcto si quieres omitir el aprendizaje de Docker y quieres alojar tu app de App Engine en contenedores para que se ejecute en Cloud Run o en cualquier otra plataforma de hosting de contenedores. Si te interesa aprender a usar Docker para la creación de contenedores de apps, puedes realizar el codelab del módulo 4 cuando termines este. Es idéntico a este, pero usa Docker para que comprendas mejor cómo administrar imágenes de contenedor.

Los pasos de migración incluyen el reemplazo de los archivos de configuración de App Engine y la especificación de cómo se debe iniciar tu app. A continuación, se muestra una tabla que resume los archivos de configuración que se esperarán para cada tipo de plataforma. Compara la columna de App Engine con la columna Buildpacks (y, de forma opcional, Docker):

Descripción

App Engine

Docker

Paquetes de compilación

Configuración general

app.yaml

Dockerfile

(service.yaml)

Bibliotecas de terceros

requirements.txt

requirements.txt

requirements.txt

Configuración de terceros

app.yaml (más appengine_config.py y lib [solo para 2.x])

(n/a)

(n/a)

Inicio

(n/a) o app.yaml (si se usa entrypoint)

Dockerfile

Procfile

Ignora los archivos

.gcloudignore y .gitignore

.gcloudignore, .gitignore y .dockerignore

.gcloudignore y .gitignore

Una vez que tu aplicación está alojada en contenedores, se puede implementar en Cloud Run. Otras opciones de plataformas de contenedores de Google Cloud incluyen Compute Engine, GKE y Anthos.

Configuración general

App Engine inicia tu aplicación de forma automática, pero Cloud Run no. Procfile cumple una función similar a la directiva app.yaml entrypoint. En el caso de la app de ejemplo, nuestro Procfile ejecutará python main.py para iniciar el servidor de desarrollo de Flask. Si lo deseas, también puedes usar un servidor web de producción, como gunicorn. Si lo haces, asegúrate de agregarlo a requirements.txt. Obtén más información para implementar desde el código fuente con Buildpacks en esta página de documentos de Cloud Run.

Solo debes mover tu directiva app.yaml entrypoint a una Procfile. Si no tienes una, usa el servidor de desarrollo Flask por ahora, ya que esta es solo una app de prueba de muestra para que los usuarios se familiaricen con esta migración. Tu app será un comando de inicio específico que conoces mejor. De forma oculta, el servicio de Cloud Run crea un service.yaml que se parece o se comporta más como un app.yaml. Puedes ver el service.yaml generado automáticamente si visitas un vínculo como este, pero para tu servicio SVC_NAME y REGION: https://console.cloud.google.com/run/detail/REGION/SVC_NAME/yaml/view.

Bibliotecas de terceros

No es necesario cambiar el archivo requirements.txt. Flask debe estar allí, junto con tu biblioteca cliente de Datastore (Cloud Datastore o Cloud NDB). Si deseas usar otro servidor HTTP compatible con WSGI, como Gunicorn, la versión actual al momento de esta escritura, es 20.0.4, agrega gunicorn==20.0.4 a requirements.txt.

Configuración de terceros

Los paquetes de compilación no son compatibles con Python 2, por lo que no hablaremos sobre eso aquí. Las apps de Python 3 que se ejecutan en contenedores en Cloud Run son similares a las apps de Python 3 de App Engine, ya que las bibliotecas de terceros deben especificarse en requirements.txt.

Inicio

Los usuarios de Python 3 tienen la opción de convertir sus archivos app.yaml para tener un entrypoint, en lugar de directivas script: auto en su sección handlers. Si usas entrypoint en app.yaml de Python 3, se vería de la siguiente manera:

runtime: python38
entrypoint: python main.py

La directiva entrypoint indica a App Engine cómo iniciar tu servidor. Puedes moverlo casi directamente a tu Procfile. Resumir dónde iría una directiva de punto de entrada entre ambas plataformas: Esto se traduce directamente a lo siguiente: También se muestra el equivalente de Docker como una información:

  • Buildpacks: línea en Procfile: web: python main.py
  • Docker: línea en Dockerfile: ENTRYPOINT ["python", "main.py"]

Para las pruebas y la etapa de pruebas, es fácil ejecutar el servidor de desarrollo de Flask desde Python como se indicó antes, pero los desarrolladores pueden optar por algo más potente para la producción, como la muestra de inicio rápido de Cloud Run que usa gunicorn.

Archivos de aplicación

Todas las aplicaciones del módulo 2 o el módulo 3 son totalmente compatibles con Python 2 y 3, lo que significa que no hay cambios en los componentes principales de main.py. Solo agregaremos algunas líneas de código de inicio. Agrega un par de líneas en la parte inferior de main.py a fin de iniciar el servidor de desarrollo, ya que Cloud Run requiere que el puerto 8080 esté abierto para que pueda llamar a tu aplicación:

if __name__ == '__main__':
    import os
    app.run(debug=True, threaded=True, host='0.0.0.0',
            port=int(os.environ.get('PORT', 8080)))

5. Compila e implementa

Ahora que tu configuración de App Engine se reemplaza por Buildpacks y actualizaciones del archivo fuente completadas, está todo listo para que la ejecutes en Cloud Run. Antes de eso, analizaremos con brevedad los servicios.

Comparación entre los servicios y las apps

Si bien App Engine se creó principalmente para alojar aplicaciones, también es una plataforma que aloja servicios web o aplicaciones que constan de una colección de microservicios. En Cloud Run, todo es un servicio, ya sea un servicio real o una aplicación con interfaz web, por lo que debes considerar su uso como la implementación de un servicio en lugar de una aplicación.

A menos que tu aplicación de App Engine esté compuesta por varios servicios, no tienes que escribir ningún nombre cuando implementas tus aplicaciones. Los cambios que realizas en Cloud Run lo hacen con un nombre de servicio. Por otro lado, el dominio appspot.com de App Engine tiene su ID del proyecto, p .ej., https://PROJECT_ID.appspot.com y tal vez la abreviatura del ID de región, p. ej., http://PROJECT_ID.REGION_ID.r.appspot.com.

Sin embargo, el dominio de un servicio de Cloud Run incluye el nombre de servicio, la abreviatura del ID de región y un hash, pero no el ID del proyecto, p. ej., https://SVC_NAME-HASH-REG_ABBR.a.run.app. En resumen, comienza a pensar en el nombre del servicio.

Implementar servicio

Ejecuta el siguiente comando para compilar su imagen de contenedor e implementarla en Cloud Run. Cuando se le solicite, seleccione su región y permita conexiones sin autenticación para realizar pruebas más fácilmente y seleccione su región según corresponda, en el que SVC_NAME es el nombre del servicio que implementará.

$ gcloud run deploy SVC_NAME --source .
Please choose a target platform:
 [1] Cloud Run (fully managed)
 [2] Cloud Run for Anthos deployed on Google Cloud
 [3] Cloud Run for Anthos deployed on VMware
 [4] cancel
Please enter your numeric choice:  1

To specify the platform yourself, pass `--platform managed`. Or, to make this the default target platform, run `gcloud config set run/platform managed`.

Please specify a region:
 [1] asia-east1
 [2] asia-east2
 [3] asia-northeast1
 [4] asia-northeast2
 [5] asia-northeast3
 [6] asia-south1
 [7] asia-southeast1
 [8] asia-southeast2
 [9] australia-southeast1
 [10] europe-north1
 [11] europe-west1
 [12] europe-west2
 [13] europe-west3
 [14] europe-west4
 [15] europe-west6
 [16] northamerica-northeast1
 [17] southamerica-east1
 [18] us-central1
 [19] us-east1
 [20] us-east4
 [21] us-west1
 [22] us-west2
 [23] us-west3
 [24] us-west4
 [25] cancel
Please enter your numeric choice: <select your numeric region choice>

To make this the default region, run `gcloud config set run/region REGION`.

Allow unauthenticated invocations to [SVC_NAME] (y/N)?  y

Building using Buildpacks and deploying container to Cloud Run service [SVC_NAME] in project [PROJECT_ID] region [REGION]
✓ Building and deploying... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds/BUILD-HASH?project=PROJECT_NUM].
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [SVC_NAME] revision [SVC_NAME-00014-soc] has been deployed and is serving 100 percent of traffic.
Service URL: https://SVC_NAME-HASH-REG_ABBR.a.run.app

Visite la URL especificada con su navegador para confirmar que la implementación se realizó de forma correcta.

Como se indica en el comando gcloud, los usuarios pueden establecer varios parámetros de configuración predeterminados para reducir el resultado y la interactividad como se mostró antes. Por ejemplo, para evitar toda la interacción, puedes usar el siguiente comando de implementación de una línea:

$ gcloud beta run deploy SVC_NAME --source . --platform managed --region REGION --allow-unauthenticated

Si usas este, asegúrate de seleccionar el mismo nombre de servicio SVC_NAME y el nombre REGION deseado, no la selección del menú indexado como lo hicimos de forma interactiva anteriormente.

6. Resumen/limpieza

Confirma que la aplicación funcione en Cloud Run como en App Engine. Si alcanzaste esta serie sin hacer ninguno de los Codelabs anteriores, la aplicación en sí no cambia. Registra todas las visitas a la página web principal (/) y tendrá esta apariencia una vez que hayas visitado el sitio muchas veces:

app de visitme

Tu código ahora debería coincidir con el que hay en la carpeta del repositorio del módulo 5. Felicitaciones por completar este codelab del módulo 5.

Opcional: Limpieza

¿Qué te parece limpiar a fin de evitar que se te facture hasta que estés listo para pasar a la siguiente codelab de migración? Dado que ahora usa un producto diferente, asegúrate de consultar la guía de precios de Cloud Run.

Opcional: Inhabilita el servicio

Si aún no estás listo para continuar con el siguiente instructivo, inhabilita tu servicio a fin de evitar que se apliquen cargos adicionales. Cuando estés listo para pasar al siguiente codelab, puedes volver a habilitarla. Aunque tu app esté inhabilitada, no recibirá tráfico que genere cargos. Sin embargo, si se excede la cuota gratuita, se te cobrará por el uso de Datastore. así que borra lo suficiente para que quede dentro de ese límite.

Por otro lado, si no vas a continuar con las migraciones y quieres borrar todo el contenido por completo, puedes borrar tu servicio o cerrar el proyecto por completo.

Próximos pasos

¡Felicitaciones, alojaste tu aplicación en contenedores, lo que concluye con este instructivo! A partir de aquí, el siguiente paso es aprender a hacer lo mismo con Docker en el codelab del Módulo 4 (vínculo a continuación) o realizar otra migración de App Engine:

  • Módulo 4: Migra a Cloud Run con Docker
    • Organiza tu aplicación en contenedores para que se ejecute en Cloud Run con Docker
    • Te permite quedarte en Python 2
  • Módulo 7: Listas de tareas en cola de envío de App Engine (obligatorio si usas las listas de tareas en cola [enviar])
    • Agrega tareas de envío taskqueue de App Engine a la app del módulo 1
    • Prepara a los usuarios para la migración a Cloud Tasks en el módulo 8
  • Módulo 3:
    • Moderniza el acceso de Datastore de Cloud NDB a Cloud Datastore
    • Esta es la biblioteca que se usa para las aplicaciones de App Engine de Python 3 y las aplicaciones que no pertenecen a App Engine.
  • Módulo 6: Migra a Cloud Firestore
    • Migra a Cloud Firestore para acceder a las funciones de Firebase
    • Si bien Cloud Firestore es compatible con Python 2, este codelab solo está disponible en Python 3.

7. 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 de los módulos 2 y 3 (START) y 5 (FINISH). También se puede acceder a ellos desde el repositorio de todas las migraciones de codelab de App Engine, que te permite clonar o descargar un archivo ZIP.

Codelab

Python 2

Python 3

Módulo 2

código

(código)

Módulo 3

(código)

código

Module 5

(n/a)

código

Recursos de App Engine y Cloud Run

A continuación, se muestran recursos adicionales con respecto a esta migración específica: