Comparar App Engine y Cloud Run

Esta guía ofrece una introducción a Cloud Run para los usuarios que conocen App Engine. En él se describen las principales similitudes y diferencias entre las plataformas sin servidor para ayudarte a prepararte para migrar desde el entorno estándar o el entorno flexible de App Engine.

Información general

Cloud Run es la última evolución de Google Cloud sin servidor, basada en la experiencia de ejecutar App Engine durante más de una década. Cloud Run se ejecuta en gran parte de la misma infraestructura que el entorno estándar de App Engine, por lo que hay muchas similitudes entre estas dos plataformas.

Cloud Run está diseñado para mejorar la experiencia de App Engine e incorpora muchas de las mejores funciones del entorno estándar y flexible de App Engine. Los servicios de Cloud Run pueden gestionar las mismas cargas de trabajo que los servicios de App Engine, pero Cloud Run ofrece a los clientes mucha más flexibilidad a la hora de implementar estos servicios. Esta flexibilidad, junto con las integraciones mejoradas con Google Cloud y servicios de terceros, también permite que Cloud Run gestione cargas de trabajo que no se pueden ejecutar en App Engine.

Resumen de la comparación

Aunque hay muchas similitudes y diferencias entre App Engine y Cloud Run, esta descripción general se centra en las áreas más relevantes para los clientes de App Engine que empiezan a usar Cloud Run.

Modelo de recurso

El modelo de recursos de Cloud Run es muy similar al de App Engine, pero hay algunas diferencias clave:

• Cloud Run no tiene un recurso Application de nivel superior ni el servicio default correspondiente.
• Los servicios de Cloud Run del mismo proyecto se pueden desplegar en diferentes regiones. En App Engine, todos los servicios del proyecto están en la misma región.
• Cloud Run usa el término Revisión en lugar de Versión para ajustarse al modelo de recursos de Knative.
• Los nombres de las revisiones de Cloud Run tienen el formato SERVICE_NAME-REVISION_SUFFIX, donde REVISION_SUFFIX se genera automáticamente o se define mediante la marca de despliegue --revision-suffix=REVISION_SUFFIX.
• Las revisiones de Cloud Run son inmutables, lo que significa que no puedes reutilizar nombres como en las versiones de App Engine (con la marca de implementación --version=VERSION_ID).
• Las URLs de servicio de Cloud Run se basan en un identificador de servicio que se genera automáticamente en el primer despliegue del servicio. Los identificadores de servicio tienen el formato SERVICE_NAME-<auto-generated identifier>. El identificador de servicio es único y no cambia durante el tiempo de vida del servicio.
• En Cloud Run, solo se exponen de forma predeterminada las URLs de servicio (SERVICE_IDENTIFIER.run.app y https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app). Para dirigirte a una revisión específica, debes configurar una etiqueta de tráfico. En App Engine, se exponen automáticamente tanto las URLs de servicio como las de versión.

Implementación y configuración

En App Engine, la mayoría de las configuraciones se realizan en el archivo app.yaml, que se incluye en cada implementación. Esta sencillez tiene un coste, ya que, aunque se pueden actualizar algunos ajustes mediante la API Admin, la mayoría de los cambios requieren volver a implementar el servicio.

Aunque Cloud Run tiene el archivo de configuración service.yaml, no se usa de la misma forma que app.yaml. El service.yaml de Cloud Run no se puede usar al implementar desde el código fuente, ya que uno de los elementos obligatorios es la ruta a la imagen de contenedor final. Además, service.yaml cumple las especificaciones de Knative y puede resultar difícil de leer para quienes no estén familiarizados con los archivos de configuración de Kubernetes. Para obtener más información sobre cómo usar service.yaml para gestionar la configuración, consulta la documentación de Cloud Run.

Para los clientes de App Engine que empiezan a usar Cloud Run, el uso de las marcas de despliegue de la CLI gcloud se ajusta mucho más a la gestión de la configuración de App Engine en el momento del despliegue.

Para definir la configuración al desplegar código nuevo en Cloud Run, usa las marcas gcloud run deploy:

gcloud run deploy SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

Aunque no es necesario usar las marcas de configuración en todas las implementaciones (consulta Gestión de configuraciones), puedes hacerlo para simplificar la gestión de la configuración.

En Cloud Run, también puedes actualizar la configuración sin volver a desplegar el código fuente mediante gcloud run services update:

gcloud run services update SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

Como las revisiones de Cloud Run son inmutables, este comando creará una nueva revisión con la configuración actualizada, pero usará la misma imagen de contenedor que la revisión actual.

Gestionar configuraciones

En las implementaciones de App Engine, se deben proporcionar todos los ajustes para cada implementación. Los ajustes que no se proporcionen tendrán valores predeterminados. Por ejemplo, App Engine service-a, con versiones que usan los archivos app.yaml de la siguiente tabla:

runtime: python39
service: service-a
instance_class: F4

runtime: python39
service: service-a

runtime: python39
service: service-a
instance_class: F4
default values:
..
..

runtime: python39
service: service-a
default values:
instance_class: F1
..
..

version1 se configura con instance_class: F4, mientras que version2, que no ha proporcionado ningún valor para instance_class, se configura con el valor predeterminado instance_class: F1.

En Cloud Run, se aplican los ajustes de configuración que se proporcionen, pero los que no se proporcionen mantienen sus valores. Solo tiene que proporcionar valores para los ajustes que quiera cambiar. Por ejemplo:

gcloud run deploy service-a \
--cpu=4

gcloud run deploy service-a

service: service-a
vCPUs: 4
default values:
..
..

service: service-a
vCPUs: 4
default values:
..
..

En App Engine, si se realiza un despliegue sin ajustes de configuración, se crea una versión con todos los ajustes predeterminados. En Cloud Run, si se hace un despliegue sin ajustes de configuración, se crea una revisión con los mismos ajustes de configuración que la revisión anterior. En la primera revisión de un servicio de Cloud Run, si se despliega sin ajustes de configuración, se crea una revisión con todos los ajustes predeterminados.

Valores predeterminados de configuración

Punto de entrada

Cuando se implementa desde el origen, App Engine lee el comando de punto de entrada del atributo entrypoint en el archivo app.yaml. Si no se proporciona ningún punto de entrada, se utiliza un valor predeterminado específico del tiempo de ejecución. Cloud Run usa buildpacks de Google Cloud al desplegar desde una fuente. Algunos lenguajes no tienen un punto de entrada predeterminado, por lo que debes proporcionar uno o la compilación fallará. Por ejemplo, los paquetes de compilación de Python requieren un Procfile o especificar la variable de entorno de compilación GOOGLE_ENTRYPOINT.

Consulta la documentación de los buildpacks para ver los requisitos de configuración específicos de cada lenguaje.

Escalado

Aunque Cloud Run y el entorno estándar de App Engine comparten gran parte de la misma infraestructura de escalado, Cloud Run se ha optimizado para permitir un escalado mucho más rápido. Como parte de esta optimización, los ajustes configurables se limitan a los siguientes:

• Simultaneidad máxima
• Instancias máximas y mínimas

En las instancias de Cloud Run, la utilización de CPU objetivo no se puede configurar y se fija en el 60%. Consulta más información sobre el autoescalado en la documentación de Cloud Run.

El entorno flexible de App Engine usa la función Autoscaler de Compute Engine, por lo que tiene características de escalado muy diferentes a las del entorno estándar de App Engine y Cloud Run.

Tiempo de espera de instancia inactiva

En App Engine, las instancias inactivas permanecen activas hasta 15 minutos después de que se haya terminado de procesar la última solicitud. Cloud Run te permite configurar este comportamiento mediante la asignación de CPU. Para obtener el mismo comportamiento que App Engine, define la asignación de CPU como CPU siempre asignada. También puedes usar la opción CPU solo asignada durante el procesamiento de solicitudes para que las instancias inactivas se cierren inmediatamente (si no hay solicitudes pendientes).

Solicitudes de preparación

Cloud Run activa automáticamente las instancias mediante el comando de punto de entrada del contenedor, por lo que no tienes que habilitar manualmente las solicitudes de activación ni configurar un controlador /_ah/warmup. Si tienes código que quieres ejecutar al iniciar la instancia, antes de que se procese ninguna solicitud, puedes hacer lo siguiente:

• Configurar la aplicación para que escuche las solicitudes
• Configurar una sonda de inicio personalizada

Contenido estático

En el entorno estándar de App Engine, puedes publicar contenido estático sin usar recursos de computación publicándolo desde Cloud Storage o configurando gestores.Cloud Run no tiene la opción de gestores para publicar contenido estático, por lo que puedes publicar el contenido desde el servicio Cloud Run (igual que el contenido dinámico) o desde Cloud Storage.

Rol Invocador de Cloud Run

Cloud Run también ofrece la posibilidad de controlar el acceso a un servicio con Gestión de Identidades y Accesos (IAM). Los enlaces de políticas de gestión de identidades y accesos de un servicio se pueden configurar mediante la CLI de gcloud, la consola o Terraform.

Para replicar el comportamiento de App Engine, puedes hacer que el servicio sea público permitiendo las solicitudes sin autenticar. Se puede definir durante la implementación o actualizando los enlaces de la política de gestión de identidades y accesos en un servicio.

gcloud run deploy SERVICE_NAME ... --allow-unauthenticated

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member="allUsers" \
--role="roles/run.invoker"

También puedes controlar quién tiene acceso al servicio concediendo el rol de gestión de identidades y accesos Invocador de Cloud Run, que se puede configurar por servicio.

gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated
gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

Variables de entorno y metadatos

Tanto App Engine como Cloud Run tienen determinadas variables de entorno que se definen automáticamente. En la siguiente tabla se muestran las variables de entorno de App Engine y sus equivalentes en Cloud Run. Cloud Run solo implementa unas pocas variables de entorno, en comparación con App Engine, pero los datos disponibles en el servidor de metadatos son prácticamente los mismos.

Variables de entorno predeterminadas

Rutas comunes del servidor de metadatos

Siguientes pasos

• Guía de inicio rápido: despliega un servicio web con Cloud Run
• ¿Mi aplicación es adecuada para Cloud Run?
• Migrar mi dominio personalizado de App Engine a Cloud Load Balancing
• Otros recursos:
  • Migrar de App Engine a Cloud Run con Docker (Python: laboratorio, vídeo; Java: laboratorio)
  • Migrar de App Engine a Cloud Run con buildpacks (Python: codelab, vídeo; Java: codelab)