Cómo se dirigen las solicitudes

ID de región

El REGION_ID es un código abreviado que Google asigna en función de la región que selecciones al crear tu aplicación. El código no corresponde a un país o provincia, aunque algunos IDs de región pueden parecerse a los códigos de país y provincia que se usan habitualmente. En las aplicaciones creadas después de febrero del 2020, REGION_ID.r se incluye en las URLs de App Engine. En las aplicaciones creadas antes de esa fecha, el ID de región es opcional en la URL.

Más información sobre los IDs de región

En esta página se describe cómo llegan a la versión apropiada de un servicio las solicitudes HTTP de los usuarios. Las solicitudes se pueden enrutar de las siguientes formas:

Estas opciones solo se aplican a las aplicaciones implementadas. Cuando haces pruebas de forma local, el comportamiento de las rutas depende del tiempo de ejecución y del entorno de desarrollo que estés usando.

Enrutamiento con URLs

Una vez que tu aplicación se esté ejecutando en App Engine, podrás usar la siguiente URL para enviar solicitudes HTTP a la aplicación:

https://PROJECT_ID.REGION_ID.r.appspot.com

donde PROJECT_ID es el ID del Google Cloud proyecto que contiene la aplicación.

Esta URL envía solicitudes al servicio predeterminado de tu aplicación en la versión que hayas configurado para recibir tráfico.

URLs de servicios y versiones

Si creas más de un servicio en tu aplicación, cada uno tendrá su propia URL. Cada versión de un servicio también tiene su propia URL, por lo que puedes implementar y probar una nueva versión antes de configurarla para que reciba tráfico.

Las URLs de servicios y versiones específicos tienen el siguiente formato:

VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

Puedes omitir VERSION-dot- si no necesitas segmentar por una versión específica.

Para obtener los IDs de los servicios y las versiones de tu aplicación, puedes usar cualquiera de las siguientes herramientas:

Consola

En la Google Cloud consola, puedes ver las páginas correspondientes Instancias, Servicios y Versiones.

gcloud

Ejecuta el comando gcloud app instances list para enumerar los IDs de recursos de un proyecto Google Cloud específico.

API

Para obtener IDs de recursos de forma programática, consulta los métodos list de la API Admin.

URLs de ejemplo

A continuación, se muestran algunos ejemplos de URLs de App Engine, tanto del dominio appspot.comque App Engine asigna a tu aplicación como de un dominio personalizado, que puedes configurar para tu aplicación.

  • Envía la solicitud a una instancia disponible del servicio default:
    
https://PROJECT_ID.REGION_ID.r.appspot.com
https://CUSTOM_DOMAIN

    Las solicitudes las recibe cualquier versión configurada para el tráfico en el servicio default.

  • Envía una solicitud a una instancia disponible de un servicio específico:
    
https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://SERVICE_ID.CUSTOM_DOMAIN

    Las solicitudes las recibe cualquier versión configurada para el tráfico en el servicio de destino. Si el servicio al que te diriges no existe, la solicitud se enruta de forma flexible.

  • Envía una solicitud a una instancia disponible de una versión específica en el
    Servicio de default:
    
https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://VERSION_ID.CUSTOM_DOMAIN

    Cuando no se orienta a ningún servicio, las solicitudes se envían al servicio default.

Enrutamiento flexible

Si una solicitud coincide con la parte PROJECT_ID.REGION_ID.r.appspot.com del nombre de host, pero incluye un nombre de servicio, versión o instancia que no existe, la solicitud se dirige al servicio default. El enrutamiento flexible no se aplica a los dominios personalizados. Las solicitudes a estos dominios devolverán un código de estado HTTP 404 si el nombre de host no es válido.

Enrutamiento específico

Los siguientes patrones de URL alcanzan su objetivo si existen. Las solicitudes que no pasan por Cloud Load Balancing nunca se interceptan ni se redirigen mediante los patrones que hayas definido en tu archivo de configuración:

  • Envía la solicitud a una instancia disponible de un servicio y una versión específicos: 
    
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN

Enrutamiento con un archivo de envío

Puedes crear un archivo de envío para anular las reglas de enrutamiento basadas en URLs de App Engine y definir tus propias reglas de enrutamiento personalizadas. Con un archivo de distribución, puedes enviar solicitudes entrantes a un servicio específico en función de la ruta o el nombre de host de la URL de la solicitud.

Crear un archivo de envío

Para crear un archivo de envío:

  1. Crea un archivo llamado dispatch.yaml en la raíz del directorio de tu proyecto o en la raíz del directorio de tu servicio default.

  2. Define las reglas de enrutamiento en el archivo tal como se describe en la referencia de dispatch.yaml.

Ten en cuenta lo siguiente sobre las reglas de enrutamiento:

  • Puedes definir hasta 20 reglas de enrutamiento. Cada regla debe contener los elementos url y service.
  • Las reglas deben usar patrones de URL HTTP que incluyan la notación "." para separar los subdominios. No se admiten las URLs definidas con la notación HTTPS "-dot-".
  • Las reglas también se aplican a las URLs que defina en su archivo cron.yaml.

Por ejemplo, puedes crear un archivo de envío para dirigir solicitudes móviles como https://simple-sample.uc.r.appspot.com/mobile/ a un frontend móvil y solicitudes de trabajador como https://simple-sample.uc.r.appspot.com/work/ a un backend estático:

dispatch:
  # Send all mobile traffic to the mobile frontend.
  - url: "*/mobile/*"
    service: mobile-frontend

  # Send all work to the one static backend.
  - url: "*/work/*"
    service: static-backend

Desplegar el archivo de envío

Para implementar el archivo de configuración de envío con gcloud, ejecuta el siguiente comando:

gcloud app deploy dispatch.yaml

Enrutamiento con Cloud Load Balancing

Cloud Load Balancing es un producto independiente que permite configuraciones de red avanzadas para todas las aplicaciones que se ejecutan en Google Cloud.

Cuando el balanceo de carga HTTP y HTTPS está habilitado para aplicaciones sin servidor, puedes hacer lo siguiente:

  • Configura tu aplicación sin servidor para que sirva contenido desde una dirección IP IPv4 o IPv6 dedicada que no se comparta con otros servicios.

  • Reutiliza los mismos certificados SSL y claves privadas que usas en Compute Engine, Google Kubernetes Engine y Cloud Storage. De esta forma, no tendrás que gestionar certificados independientes para las aplicaciones sin servidor.

Si el NEG sin servidor especifica un servicio, una versión o una etiqueta, el balanceador de carga no interferirá ni interactuará con las reglas de enrutamiento de tu archivo dispatch.yaml. Las reglas dispatch.yaml no se evalúan hasta que un NEG sin servidor dirige el tráfico a App Engine. El enrutamiento específico falla cuando el NEG sin servidor no especifica un servicio, una versión o una etiqueta, y el enrutamiento se basa en las reglas que especifiques en el archivo dispatch.yaml.

Ten en cuenta lo siguiente:

  • Te recomendamos que uses controles de entrada para que tu aplicación solo reciba solicitudes enviadas desde el balanceador de carga (y la VPC, si la usas). De lo contrario, los usuarios podrán usar la URL de App Engine de tu aplicación para saltarse el balanceador de carga, las políticas de seguridad de Cloud Armor, los certificados SSL y las claves privadas que se transfieren a través del balanceador de carga.

Métricas incoherentes cuando el entorno flexible de App Engine usa Cloud Load Balancing

El panel de control del entorno flexible de App Engine muestra todas las métricas solo de las solicitudes que se han enrutado a través de un backend gestionado del entorno flexible. Si usas el entorno flexible de App Engine con Cloud Load Balancing, algunas métricas de la tabla de métricas de App Engine se registran como métricas de la tabla loadbalancing. Para obtener más información, consulta Registro y monitorización del balanceo de carga HTTP(S).

Acerca del ID de región en las URLs

El REGION_ID es un código abreviado que Google asigna en función de la región que selecciones al crear tu aplicación. El código no corresponde a un país o provincia, aunque algunos IDs de región pueden parecerse a los códigos de país y provincia que se usan habitualmente. En las aplicaciones creadas después de febrero del 2020, REGION_ID.r se incluye en las URLs de App Engine. En las aplicaciones creadas antes de esa fecha, el ID de región es opcional en la URL.

Puedes usar las siguientes herramientas para ver el ID de región de tu aplicación:

Consola

En la Google Cloud consola, puede ver las URLs de las instancias, los servicios y las versiones de su aplicación.

Todas estas URLs incluyen el ID de región.

gcloud

Cuando despliegues una aplicación o un servicio, el comando gcloud app deploy mostrará la URL después de que el despliegue se haya realizado correctamente. Esta URL incluye el ID de región.

Para ver la URL de un servicio que ya se ha implementado, sigue estos pasos:

  1. Introduce el comando gcloud app versions list para enumerar las versiones de un servicio específico. Por ejemplo, para enumerar las versiones del servicio predeterminado, introduce gcloud app versions list --service=default.

  2. Introduce el comando gcloud app versions describe. El resultado de ese comando incluye la URL de la versión con el ID de región de la aplicación. Por ejemplo, para describir la versión 20191023t101741 del servicio predeterminado, introduce gcloud app versions describe 20191023t101741 --service=default

El nombre de dominio se incluye en los datos de la solicitud

El nombre de dominio usado en la solicitud se incluye en los datos de la solicitud que se transfieren a tu aplicación. Por lo tanto, puedes usar los datos de la solicitud para controlar cómo responde tu aplicación en función del nombre de dominio de la solicitud. Por ejemplo, si quieres redirigir a un dominio oficial, puedes programar tu aplicación para que compruebe el encabezado de la solicitud Host y, a continuación, responda en función del nombre de dominio.