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 el método ModulesService.getVersionHostname.

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 el mismo directorio que los demás archivos de configuración, como app.yaml.

  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 configuración de dispatch sin modificar la versión que se está sirviendo, utiliza uno de los siguientes comandos en el directorio que contiene el archivo de dispatch, en función de tu entorno:

gcloud

gcloud app deploy dispatch.yaml

Maven

mvn appengine:deployDispatch dispatch.yaml

Gradle

gradle appengineDeployDispatch dispatch.yaml

IDE

Si usas IntelliJ o Eclipse, puedes seleccionar los archivos de configuración individuales que quieras implementar mediante el formulario de implementación.

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 al inicio. Ten en cuenta que, por el momento, no se admiten instancias de escalado básico en el servidor de desarrollo local. A cada instancia que se crea se le asigna su propio puerto. Las asignaciones de puertos aparecen en el flujo de mensajes de registro del servidor. Los clientes web pueden comunicarse con una instancia concreta dirigiéndose a su puerto. Solo se crea una instancia (y un puerto) para los servicios escalados automáticamente. En el registro del servidor, se muestra de la siguiente manera (ten en cuenta que los servicios se llamaban módulos anteriormente):

INFO: Module instance service-auto is running at http://localhost:37251/

Se asigna un puerto único a cada instancia de un servicio escalado manualmente:

INFO: Module instance service-manual instance 0 is running at http://localhost:43190/
INFO: Module instance service-manual instance 1 is running at http://localhost:52642/

Además, a cada servicio escalado manualmente se le asigna un puerto adicional para que los clientes puedan acceder al servicio sin especificar una instancia concreta. Las solicitudes a este puerto se enrutan automáticamente a una de las instancias configuradas:

INFO: Module instance service-manual is running at http://localhost:12361/

En la siguiente tabla se muestra cómo se pueden llamar a estos servicios en el servidor de desarrollo y en el entorno de App Engine:

Servicio Instancia Dirección del servidor de desarrollo Dirección de App Engine
service-auto (no se usa) http://localhost:37251/ https://v1-dot-service-auto-dot-PROJECT_ID.REGION_ID.r.appspot.com/
service-manual 0 http://localhost:43190/ https://0-dot-v1-dot-service-manual-dot-PROJECT_ID.REGION_ID.r.appspot.com/

lo usa el servidor de desarrollo local. Para obtener más información, consulta Apache Maven o Gradle.

Archivos de envío

Todos los archivos de envío se ignoran al ejecutar el servidor de desarrollo local. La única forma de orientar las instancias es a través de sus puertos.

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 <role-name>admin</role-name> a su restricción de seguridad.

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.