Cómo enrutar solicitudes

ID de región

REGION_ID es un código abreviado que Google asigna en función de la región que eliges cuando creas la app. El código no corresponde a un país ni a una provincia, aunque algunos ID de región puedan parecer similares a los códigos de país y provincia que se suelen usar. En el caso de las apps creadas después de febrero de 2020, REGION_ID.r se incluye en las URL de App Engine. En el caso de las apps existentes creadas antes de esta fecha, el ID de región es opcional en la URL.

Obtén más información acerca de los ID de región.

Aceptar

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

• Enrutamiento con URLs

• Enrutamiento con un archivo de envío

• Enrutamiento con Cloud Load Balancing

Si pruebas tu app mediante el servidor de desarrollo local, las características de enrutamiento y envío disponibles varían un poco. Para crear URL de manera programática que funcionen con servidores de producción y de desarrollo, usa el método ModulesService.getVersionHostname.

Consulta Enruta en el servidor de desarrollo para obtener más información.

Enrutamiento con URL

Una vez que la app se esté ejecutando en App Engine, puedes usar la siguiente URL para enviar solicitudes HTTP a la app:
https://PROJECT_ID.REGION_ID.r.appspot.com

En el ejemplo anterior, PROJECT_ID es el ID del proyecto de Google Cloud que contiene la app.

Esta URL envía solicitudes al servicio predeterminado de la app en la versión que configuraste para recibir tráfico.

Nota: Recomendamos usar el protocolo HTTPS para enviar solicitudes a la app. Las solicitudes HTTPS enviadas a REGION_ID.r.appspot.com deben usar la cadena “-dot-” en lugar de “.” para separar subdominios. Puedes usar la notación de URL simple “.” con tus propios dominios personalizados y con solicitudes HTTP.

URL para servicios y versiones

Si creas más de un servicio en la app, cada servicio tiene su propia URL. Cada versión de un servicio también tiene su propia URL. Esto te permite implementar y probar una versión nueva antes de configurarla para recibir tráfico.

Las URL de servicios y versiones en particular tienen el siguiente formato:

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

Puedes omitir VERSION-dot- si no necesitas establecer como destino una versión específica.

Para recuperar los ID de los servicios y las versiones de la app, puedes usar cualquiera de las siguientes herramientas:

Console

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

gcloud

Ejecuta el comando gcloud app instances list para ver la lista de los ID de recursos de un proyecto de Google Cloud específico.

API

Para recuperar los ID de recursos de manera programática, consulta los métodos list en la API de Administrador.

URL de ejemplo

Estos son algunos ejemplos de URL para App Engine que muestran el dominio appspot.com que App Engine asigna a la app y un dominio personalizado que puedes configurar para la app.

• Se envía la solicitud a una instancia disponible del servicio default:

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

  Cualquier versión que esté configurada para el tráfico en el servicio default recibe las solicitudes.

• 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

  Cualquier versión que esté configurada para el tráfico en el servicio orientado recibe las solicitudes. Si el servicio no existe, la solicitud se realiza a través del enrutamiento secundario.

• Se envía una solicitud a una instancia disponible de una versión específica en el

  servicio default:

  
  https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
  https://VERSION_ID.CUSTOM_DOMAIN

  Cuando no se establece un servicio como destino, las solicitudes se envían al servicio default.

Enrutamiento secundario

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

Enrutamiento dirigido

Los siguientes patrones de URL alcanzarán su objetivo, si existen. Los patrones que defines en el archivo de envío nunca interceptan ni vuelven a enrutar estas solicitudes:

• 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 escalados de forma manual, puedes orientar y enviar una solicitud a una instancia si incluyes el ID de esta. El ID de la instancia es un número entero entre 0 y la cantidad total de instancias que se ejecutan, y puede especificarse de la siguiente manera:

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

  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

  Nota: No se admite la orientación de una instancia en servicios configurados para el ajuste de escala automático o básico. El ID de instancia debe ser un número entero entre 0 y la cantidad total de instancias que se ejecutan. Sin importar el tipo de escalamiento o la clase de instancia, no es posible enviar una solicitud a una instancia específica sin establecer como destino un servicio o una versión dentro de esa instancia.

Enrutamiento con un archivo de envío

Puedes crear un archivo de envío para anular las reglas de enrutamiento basadas en URL de App Engine y definir tus propias reglas de enrutamiento personalizadas. A través de un archivo de envío, puedes enviar las solicitudes entrantes a un servicio específico según el nombre de host o la ruta en la URL de la solicitud.

Crea un archivo de envío

Para crear un archivo de envío, sigue estos pasos:

1. Crea un archivo llamado dispatch.yaml en el mismo directorio que se usa para los otros archivos de configuración, como app.yaml.

2. Define las reglas de enrutamiento en el archivo 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. Las URL definidas con la notación “-dot-” de HTTPS no son compatibles.
• Las reglas también se aplican a las URL que defines en el archivo cron.

Por ejemplo, puedes crear un archivo de envío para enrutar solicitudes móviles, como https://simple-sample.uc.r.appspot.com/mobile/, a un frontend móvil y enrutar 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

Implementa el archivo de envío

Para implementar el archivo de envío de configuración sin modificar la versión actual, usa uno de los siguientes comandos en el directorio que contiene tu archivo de envío, según 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, debes usar el formulario de implementación para seleccionar los archivos de configuración individuales que se implementarán.

Enruta con Cloud Load Balancing

Cloud Load Balancing es un producto independiente que habilita las opciones de configuración avanzada de red para todas las aplicaciones que se ejecutan en Google Cloud.

Cuando el balanceo de cargas de HTTP(S) está habilitado para apps sin servidores, puedes hacer lo siguiente:

• Configurar la app sin servidores para entregar contenido desde una dirección IP IPv4 o IPv6 dedicada que no se comparta con otros servicios

• Volver a usar los mismos certificados SSL y claves privadas que usas para Compute Engine, Google Kubernetes Engine y Cloud Storage. Esto quita la necesidad de administrar certificados separados para las apps sin servidores

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

Ten en cuenta lo siguiente:

• Te recomendamos usar controles de entrada para que la app solo reciba solicitudes enviadas desde el balanceador de cargas (y la VPC, si la usas). De lo contrario, los usuarios pueden usar la URL de App Engine de tu app para omitir el balanceador de cargas, las políticas de seguridad de Google Cloud Armor, los certificados SSL y las claves privadas que se pasan a través del balanceador de cargas.

Enruta en el servidor de desarrollo

Descubre direcciones de instancias

El servidor de desarrollo local crea todas las instancias en el inicio. Ten en cuenta que, en este momento, las instancias de escalamiento básico no son compatibles con 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 se pueden comunicar con una instancia en particular mediante la orientación de sus puertos. Solo se crea una instancia (y puerto) para los servicios con ajuste de escala automático. Se ve así en el registro de servidor (ten en cuenta que los servicios solían llamarse módulos):

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

Se asigna un puerto único a cada instancia de un servicio de escalamiento manual:

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 de escalamiento manual se le asigna un puerto adicional para que los clientes puedan acceder a este sin especificar una instancia precisa. Las solicitudes para este puerto se enrutan de forma automática a una de las instancias configuradas:

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

La siguiente tabla 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 utilizado)	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/

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

Archivos de envío

Todos los archivos de despacho se ignoran cuando se ejecuta el servidor de desarrollo local. La única forma de orientar las instancias es a través de sus puertos.

Restringe el acceso a un servicio

Todos los servicios son públicos de forma predeterminada. Si deseas restringir el acceso a un servicio, agrega el elemento <role-name>admin</role-name> a su restricción de seguridad.

Detalles adicionales sobre las URL de App Engine

Información sobre el ID de región en las URL

REGION_ID es un código abreviado que Google asigna en función de la región que seleccionas cuando creas la app. El código no corresponde a un país ni a una provincia, aunque algunos ID de región puedan parecer similares a los códigos de país y provincia que se suelen usar. En el caso de las apps creadas después de febrero de 2020, REGION_ID.r se incluye en las URL de App Engine. En el caso de las apps existentes creadas antes de esta fecha, el ID de región es opcional en la URL.

Puedes usar las siguientes herramientas para ver el ID de región de la app:

Console

En la consola de Google Cloud, puedes ver las URLs de Instancias, Servicios y Versiones de la app.

Todas estas URL incluyen el ID de región.

gcloud

Cuando implementas una app o un servicio, el comando gcloud app deploy muestra la URL una vez que la implementación se realiza de forma correcta. Esta URL incluye el ID de región.

Para ver la URL de un servicio que ya está implementado, haz lo siguiente:

1. Ingresa el comando gcloud app versions list para ver una lista de las versiones de un servicio específico. Por ejemplo, para ver las versiones del servicio predeterminado, ingresa gcloud app versions list --service=default.

2. Ingresa 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 app. Por ejemplo, para describir la versión 20191023t101741 del servicio predeterminado, ingresa gcloud app versions describe 20191023t101741 --service=default.

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

El nombre de dominio que se usa para la solicitud se incluye en los datos de la solicitud que se pasan a la app. Por lo tanto, puedes usar esos datos para controlar el modo en que la app responde según el nombre de dominio en la solicitud. Por ejemplo, si deseas realizar un redireccionamiento a un dominio oficial, puedes codificar la app para que compruebe el encabezado de la solicitud Host y responda de manera acorde según el nombre de dominio.