Cómo se enrutan las solicitudes

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 dos maneras:

  • Las reglas predeterminadas de enrutamiento de App Engine se aplican a las solicitudes con una URL que finaliza en el nivel del dominio.

  • También puedes usar un archivo de envío que enrute patrones de URL específicos según las reglas que definas.

Si pruebas tu app con el servidor de desarrollo local, las características de enrutamiento y despacho disponibles son algo distintas. Para crear URL de manera programática que funcionen con los servidores de producción y desarrollo, usa el método ModulesService.getVersionHostname.

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

Solicitudes y dominios

App Engine usa el nombre de dominio de la solicitud para determinar si una solicitud entrante está destinada a la app. Una solicitud con el nombre de dominio http://[YOUR_PROJECT_ID].appspot.com se enruta a la app con el ID [YOUR_PROJECT_ID]. Cada app obtiene un nombre de dominio appspot.com de forma gratuita.

El dominio appspot.com también admite los subdominios con el formato [SUBDOMAIN]-dot-[YOUR_PROJECT_ID].appspot.com, en el que [SUBDOMAIN] es cualquier string admitida en una parte de un nombre de dominio, sin incluir el carácter .. Las solicitudes que se envían de esta forma a cualquier subdominio se enrutan a tu app.

Puedes configurar un dominio personalizado de nivel superior con G Suite y, a continuación, asignar subdominios a varias aplicaciones, como Google Mail o Sites. También puedes asociar una app de App Engine a un subdominio. Para obtener más información sobre cómo asignar un dominio personalizado a tu app, consulta cómo proteger dominios personalizados con SSL.

Las solicitudes de estas URL se dirigen todas a la versión de la app que configuraste para recibir tráfico. Cada versión de la app también tiene su propia URL, lo que te permite implementar y probar una versión nueva antes de configurarla para recibir tráfico. La URL específica de la versión usa el ID de una versión específica además del nombre de dominio appspot.com, por ejemplo: http://[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com. También puedes usar subdominios con la URL específica de la versión: http://[SUBDOMAIN]-dot-[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com. Consulta cómo enrutar mediante una URL para obtener más información y ejemplos.

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

Enrutamiento mediante una URL

Puedes orientar una solicitud HTTP con diversos grados de especificidad. En los siguientes ejemplos, se puede reemplazar appspot.com por el dominio personalizado de tu app, si tienes uno. Las substrings de URL [VERSION_ID], [SERVICE_ID] y [MY_PROJECT_ID] representan los ID de recursos de la app.

Sugerencia: Puedes usar las siguientes herramientas para recuperar los ID de recursos de tu app:

Console

En GCP Console, 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 GCP específico.

API

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

Enrutamiento predeterminado

Los siguientes patrones de URL tienen un comportamiento de enrutamiento predeterminado. Ten en cuenta que el enrutamiento predeterminado se anula si existe una coincidencia con un patrón que hayas definido en tu archivo de envío:

  • Envía la solicitud a una instancia disponible del servicio default:
    https://[MY_PROJECT_ID].appspot.com
    http://[MY_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-[MY_PROJECT_ID].appspot.com
    http://[SERVICE_ID].[MY_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 mediante el enrutamiento secundario.

  • Envía una solicitud a una instancia disponible de una versión específica en el
    servicio default:
    https://[VERSION_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[VERSION_ID].[MY_CUSTOM_DOMAIN]

    Cuando un servicio no está orientado, las solicitudes se envían al servicio default.

Enrutamiento secundario

Si una solicitud coincide con la parte [YOUR_PROJECT_ID].appspot.com del nombre de host, pero incluye el nombre de un servicio, de una versión o de una instancia que no existe, 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 de una versión específicos:
    https://[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[VERSION_ID].[SERVICE_ID].[MY_PROJECT_ID].[MY_CUSTOM_DOMAIN]
  • Si usas servicios escalados de forma manual, puedes orientar y enviar una solicitud a una instancia si incluyes el ID de instancia. El ID de instancia es un número entero entre 0 y la cantidad total de instancias que se ejecutan; puede especificarse de la siguiente manera:

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

    https://[INSTANCE_ID]-dot-[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[INSTANCE_ID].[VERSION_ID].[SERVICE_ID].[MY_CUSTOM_DOMAIN]

Servicio predeterminado

El servicio default se crea cuando implementas la versión inicial de tu app en App Engine. Las solicitudes que no especifican un servicio o que tienen un servicio no válido, se enrutan al servicio default. Luego, las versiones que configuraste para recibir tráfico en el servicio default controlan estas solicitudes. En la página de Versiones de GCP Console, puedes ver qué versiones están configuradas para el tráfico.

Restringe el acceso a un servicio

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

Ejemplo

Para ayudar a demostrar los patrones de URL, supongamos que existe un proyecto de GCP con ID requestsProject y que incluye una app que ejecuta dos servicios y versiones. El ejemplo del servicio default de la app incluye la versión vFrontend, y el segundo servicio, service2, incluye la versión vBackend.

Para orientar servicios y versiones específicos, puedes usar los patrones de URL siguientes:

  1. Para orientar la versión en el servicio default con HTTPS, puedes usar estos patrones:

    https://vFrontend-dot-default-dot-requestsProject.appspot.com
    https://vFrontend-dot-requestsProject.appspot.com
    
  2. Para orientar la versión vBackend con un dominio personalizado sin HTTPS, puedes usar estos patrones:

    http://vBackend.service2.example.net
    http://vBackend.example.net
    

    donde requestsProject.appspot.com se asigna al domino example.net.

Enrutamiento con un archivo de envío

En el caso de las URL que usan los patrones antes detallados, puedes crear un archivo de envío para anular las reglas de enrutamiento de App Engine y definir tus propias reglas. Mediante un archivo de envío, puedes enviar las solicitudes con contenido nuevo a un servicio específico de acuerdo con el nombre de la ruta o del host en la URL de la solicitud.

Para obtener más información sobre la creación de un archivo de envío, consulta la referencia de dispatch.yaml.

Crea un archivo de envío

El archivo de envío debe almacenarse en el mismo directorio que los demás archivos de configuración, como app.yaml. Puedes definir hasta 20 reglas de enrutamiento en el archivo de despacho y cada una de ellas debe contener los elementos service y url.

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

Para obtener más información sobre cómo definir el archivo dispatch.yaml, consulta la documentación de referencia de dispatch.yaml.

Implementa el archivo de despacho

El archivo dispatch.yaml puede estar en cualquier parte del directorio del código fuente.

Para implementar el archivo de configuración dispatch sin alterar la versión de entrega actual, usa uno de los siguientes comandos en el directorio que contiene tu archivo dispatch, 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.

Enrutamiento 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/ http://v1.service-auto.[PROJECT_ID].appspot.com/
service-manual 0 http://localhost:43190/ http://0.v1.service-manual.[PROJECT_ID].appspot.com/
service-manual 1 http://localhost:52642/ http://1.v1.service-manual.[PROJECT_ID].appspot.com/
service-manual No utilizado http://localhost:12361/ http://v1.service-manual.[PROJECT_ID].appspot.com/

Si usas los complementos de Maven o Gradle, puedes asignar que número de puerto usa el servidor de desarrollo local. Para obtener más información, consulta Apache Maven, Apache Maven (basado en el SDK de Cloud) o Gradle.

Archivos de despacho

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.
¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Entorno estándar de App Engine para Java 8