Cómo se enrutan las solicitudes

En esta página, se detalla cómo llegan las solicitudes HTTP de los usuarios 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 de dominio.

  • También es posible usar un archivo de despacho que enrute patrones de URL específicos según las reglas que definas.

Estas opciones se aplican solamente a las aplicaciones implementadas. Si realizas pruebas a nivel local, el comportamiento de enrutamiento depende del entorno de ejecución y el entorno de programación específicos que uses.

Solicitudes y dominios

App Engine usa el nombre del dominio de la solicitud para determinar si una solicitud nueva 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.

Los dominios appspot.com también son compatibles con los subdominios con el formato [SUBDOMAIN]-dot-[YOUR_PROJECT_ID].appspot.com, en el que[SUBDOMAIN]puede ser cualquier string permitida en una parte del nombre de dominio, sin 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 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 para 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, appspot.com puede reemplazarse con el dominio personalizado de tu app, si tienes uno. Cada una de las substrings de URL[VERSION_ID],[SERVICE_ID]y[MY_PROJECT_ID] representa los ID de recursos de tu app.

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

Console

En GCP Console, puedes ver las páginas de Instancias, Servicios y Versiones correspondientes.

gcloud

Ejecuta el comando de 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 despacho:

  • Envía la solicitud a una instancia disponible del servicio default:
    https://[MY_PROJECT_ID].appspot.com
    http://[MY_CUSTOM_DOMAIN]

    Cualquier solicitud 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 la 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 despacho 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]

Servicio default

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 Versiones de GCP Console, puedes ver qué versiones se configuraron para tráfico.

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 despacho

En el caso de las URL que usan los patrones antes detallados, puedes crear un archivo de despacho para anular las reglas de enrutamiento de App Engine y definir tus propias reglas. Mediante un archivo de despacho, 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 cómo crear un archivo de despacho, consulta la referencia de dispatch.yaml.

Crea un archivo de despacho

El archivo de despacho se debe ubicar en la raíz del directorio del proyecto o en el directorio raíz del servicio default. Puedes definir hasta 20 reglas de enrutamiento en el archivo de despacho y cada regla debe contener los elementos service y url.

Por ejemplo, puedes crear un archivo de despacho 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

Para implementar el archivo de configuración de despacho, ejecuta el siguiente comando:

gcloud

gcloud app deploy dispatch.yaml
¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Entorno flexible de App Engine para Go