Cómo se enrutan las solicitudes

ID de región

El REGION_ID es un código que Google asigna en función de la región que selecciones cuando crees la app. Incluir REGION_ID.r en las URL de App Engine es opcional para las apps existentes y pronto será obligatorio para todas las apps nuevas.

A fin de garantizar una transición sin problemas, estamos actualizando App Engine con lentitud para usar los ID de región. Si aún no actualizamos tu proyecto de Google Cloud, no verás un ID de región para la app. Dado que el ID es opcional para las apps existentes, no necesitas actualizar las URL ni realizar otros cambios una vez que el ID de región esté disponible para las apps existentes.

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

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 del dominio.

  • También puedes usar un archivo de envío 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

Una vez que tu 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 la que PROJECT_ID es el ID del proyecto de Google Cloud que contiene la app.

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

Cada versión de la aplicación también tiene su propia URL. Esto 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 ID del proyecto, el ID de la región y el nombre de dominio appspot.com. Por ejemplo: https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

Subdominios

Los dominios appspot.com también admiten subdominios con el formato SUBDOMAIN-dot-PROJECT_ID.REGION_ID.r.appspot.com, donde SUBDOMAIN puede ser cualquier string permitida en una parte del nombre de dominio, sin incluir el carácter .. Las solicitudes que se envían de esta forma a cualquier subdominio se enrutan a tu aplicación.

También puedes usar subdominios con la URL específica de la versión:
https://SUBDOMAIN-dot-VERSION_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com.

Consulta Enruta mediante una URL para obtener más información y ejemplos.

Dominios personalizados

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 aplicación, consulta Protege dominios personalizados con SSL.

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 transmiten a la aplicación. Por lo tanto, puedes usar esos datos para controlar el modo en que la aplicación responde según el nombre de dominio en la solicitud. Por ejemplo, si deseas realizar un redireccionamiento a un dominio oficial, puedes codificar la aplicación para que verifique el encabezado de la solicitud Host y responda de manera acorde según el nombre de dominio.

ID de región

El REGION_ID es un código que Google asigna en función de la región que selecciones cuando crees la app. Incluir REGION_ID.r en las URL de App Engine es opcional para las apps existentes y pronto será obligatorio para todas las apps nuevas.

A fin de garantizar una transición sin problemas, estamos actualizando App Engine con lentitud para usar los ID de región. Si aún no actualizamos tu proyecto de Google Cloud, no verás un ID de región para la app. Dado que el ID es opcional para las apps existentes, no necesitas actualizar las URL ni realizar otros cambios una vez que el ID de región esté disponible para las apps existentes.

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

Console

En Cloud Console, puedes ver las URL para las Instancias, Servicios y Versiones de tu app.

Todas estas URL incluyen el ID de la región.

gcloud

Cuando implementas una app o un servicio, el comando de gcloud app deploy muestra la URL una vez que la implementación se realiza correctamente. Esta URL incluye el ID de la 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 de 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

Enruta mediante una URL

Puedes orientar una solicitud HTTP con diversos grados de especificidad. En los siguientes ejemplos, REGION_ID.r.appspot.com se puede reemplazar por el dominio personalizado de tu aplicación, si tienes uno. Cada una de las substrings de URL VERSION_ID,SERVICE_ID y PROJECT_ID, representa los ID de recursos de tu aplicación.

Puedes usar las herramientas siguientes para recuperar los ID de recursos de tu aplicación:

Console

En Cloud 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 Cloud 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 definiste en tu archivo de envío:

  • 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 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-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
    https://VERSION_ID.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 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, 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

Se garantiza que los siguientes patrones de URL alcanzarán sus objetivos, 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-PROJECT_ID.REGION_ID.r.appspot.com
    https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN

Servicio default

El servicio default se crea cuando implementas la versión inicial de tu aplicación 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 esas solicitudes. Puedes ver qué versiones están configuradas para el tráfico en la página Versiones de Cloud Console.

Ejemplo

Para ayudarte a mostrar los patrones de URL, supongamos que existe un proyecto de Cloud con ID requestsProject y que incluye una aplicación que ejecuta dos servicios y versiones. El servicio default de la aplicación del ejemplo incluye la versión vFrontend, y el segundo servicio service2 incluye la versión vBackend. Google asignó uc como ID de región para ambas apps.

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

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

        https://vFrontend-dot-default-dot-requestsProject.uc.r.appspot.com
        https://vFrontend-dot-requestsProject.uc.r.appspot.com
    

  2. Para orientar la versión vBackend mediante un dominio personalizado, puedes usar lo siguiente:

    https://vBackend.service2.example.net
    https://vBackend.example.net
    

    donde requestsProject.uc.r.appspot.com se asigna al dominio example.net.

Enruta 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 entrantes a un servicio específico según 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 envío, consulta la referencia de dispatch.yaml.

Crea un archivo de envío

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

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

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 envío

Para implementar el archivo de configuración de envío, ejecuta el siguiente comando:

gcloud

gcloud app deploy dispatch.yaml