Cómo se dirigen las peticiones

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:

Si pruebas tu aplicación con el servidor de desarrollo local, las funciones de enrutamiento y envío disponibles serán ligeramente diferentes. Para crear URLs de forma programática que funcionen tanto con servidores de producción como de desarrollo, usa la variable $_SERVER['HTTP_HOST'].

Consulta más información sobre el enrutamiento en el servidor de desarrollo.

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

Se garantiza que los siguientes patrones de URL llegarán a su destino si existen. Estas solicitudes nunca se interceptan ni se redirigen mediante los patrones que has definido en tu archivo de envío:

  • 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

  • Si usas servicios con escalado manual, puedes orientar y enviar una solicitud a una instancia incluyendo su ID. El ID de instancia es un número entero comprendido entre 0 y el número total de instancias que se están ejecutando. Se puede especificar de la siguiente manera:

    Envía una solicitud a un servicio y una versión específicos de una instancia concreta: 

    https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://INSTANCE_ID.VERSION_ID.SERVICE_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.

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 desplegar el archivo de envío, 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.

El balanceador de carga no interfiere ni interactúa con las reglas de enrutamiento de tu archivo dispatch.yaml. Las reglas de dispatch.yaml no se evalúan hasta que un NEG sin servidor dirige el tráfico a App Engine.

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.

Enrutamiento en el servidor de desarrollo

Descubrir direcciones de instancias

El servidor de desarrollo local crea todas las instancias de escalado manual al iniciarse. Las instancias de los servicios de escalado automático y básico se gestionan de forma dinámica. El servidor asigna un puerto a cada servicio y los clientes pueden depender del servidor para equilibrar la carga y seleccionar una instancia automáticamente. Las asignaciones de puertos para dirigirse a cada servicio aparecen en el flujo de mensajes de registro del servidor. Estos son los puertos de una aplicación que define tres servicios (el tipo de escalado de cada servicio no es relevante):

INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083

Cuando usas la dirección de un servicio (por ejemplo, http://localhost:8082/), el servidor selecciona (o crea) una instancia del servicio y envía la solicitud a esa instancia.

El servidor asigna puertos únicos a cada instancia de un servicio. Para descubrir estos puertos, debes usar el servidor de administración. Hay un puerto único para el servidor de administración, que aparece en el registro de mensajes:

INFO Starting admin server at: http://localhost:8000

Esta dirección te lleva a la consola del servidor de administración. Desde ahí, puedes hacer clic en Instancias para ver el estado dinámico de las instancias de tu aplicación:

Captura de pantalla de la consola de administración de dev_appserver

Aparecerá una entrada independiente para cada instancia manual y básica. Los números de instancia son enlaces con direcciones de puerto únicas para cada instancia. Puedes colocar el cursor sobre un enlace para ver el puerto asignado a esa instancia o hacer clic en el enlace para enviar una solicitud directamente a esa instancia.

Archivos de envío

Si tu aplicación incluye un archivo dispatch.yaml, el flujo de mensajes de registro incluirá un puerto de distribuidor:

INFO Starting dispatcher running at: http://localhost:8080

Las solicitudes a este puerto se enrutan según las reglas del archivo de envío. El servidor no admite reglas de archivos dispatch.yaml que incluyan nombres de host (por ejemplo, url: "customer1.myapp.com/*"). Las reglas con patrones de ruta relativa (url: "*/fun") funcionarán, por lo que puede usar URLs como http://localhost/fun/mobile para acceder a las instancias. El servidor registrará un error en el flujo de registro si intentas iniciar una aplicación con un archivo dispatch.yaml que contenga reglas basadas en el host.

Restringir el acceso a un servicio

Todos los servicios son públicos de forma predeterminada. Si quieres restringir el acceso a un servicio, añade el elemento login: admin a sus controladores.

Detalles adicionales sobre las URLs de App Engine

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.