Archivo de configuración dispatch.yaml

ID de región

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.

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

dispatch.yaml te permite anular las reglas de enrutamiento. Puedes usar dispatch.yaml para enviar solicitudes entrantes a un servicio específico (antes conocido como módulos) según la ruta o el nombre de host en la URL.

Para obtener más información, consulta Cómo se enrutan las solicitudes.

Una app solo puede tener un archivo dispatch.yaml, y las reglas de enrutamiento de ese archivo se aplican a todos los servicios y las versiones de la app. Las reglas de enrutamiento también se aplican a las URL que se usan en un archivo cron o una configuración de lista de tareas en cola.

Implementa el archivo de envío

El archivo dispatch.yaml puede residir en cualquier lugar de tu código fuente.

Para implementar el archivo de configuración de envío sin alterar la versión en funcionamiento en la actualidad, 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.

Para obtener más información sobre los comandos de implementación, consulta Implementa una app de Java 8.

Sintaxis

El elemento raíz en el archivo dispatch.yaml es dispatch: y contiene una lista de definiciones de enrutamiento que se especifican mediante los siguientes subelementos.

En las reglas que defines en el archivo de envío, debes 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 de envío dependen del orden, y solo se aplicará la primera regla que coincida con una URL.

Elemento Descripción
service

Especifica el nombre del servicio que procesará las solicitudes que coinciden con el patrón de url. Ten en cuenta que los servicios antes se denominaban “módulos”.

url

En el elemento url, defines el patrón de URL, que puede incluir el nombre de host y la ruta de URL con 100 caracteres o menos. Para el elemento service, especifica el nombre del servicio que deseas que controle cualquier solicitud entrante que coincida con el patrón de URL del elemento url.

Sugerencia: Puedes incluir patrones glob, como el carácter comodín * en el elemento url. Sin embargo, esos patrones solo pueden usarse antes del nombre de host y al final de la ruta de URL.

Un patrón de URL que puede incluir el nombre de host y la ruta de URL. Los caracteres glob se pueden usar para hacer coincidir patrones. Los caracteres glob se pueden especificar solo al principio y al final del patrón. Especifica el patrón de URL entre comillas.

El archivo de envío no enruta las rutas de URL que comienzan con /_ah/.

Ejemplo

El siguiente es un archivo de envío de muestra que enruta solicitudes a https://simple-sample.uc.r.appspot.com y solicitudes como https://simple-sample.uc.r.appspot.com/favicon.ico al servicio default. Todo el contenido estático se entrega desde el servicio default. Las solicitudes para dispositivos móviles, como https://simple-sample.uc.r.appspot.com/mobile/, se enrutan a un frontend de dispositivo móvil, y las solicitudes de trabajador, como https://simple-sample.uc.r.appspot.com/work/, se enrutan a un backend estático.

dispatch:
  # Default service serves the typical web resources and all static resources.
  - url: "*/favicon.ico"
    service: default

  # Default service serves simple hostname request.
  - url: "simple-sample.uc.r.appspot.com/"
    service: default

  # 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

Si prefieres reglas de enrutamiento generales que coincidan con la mayor cantidad de solicitudes posible, puedes definir reglas con alcances más amplios. Por ejemplo:

# Send any path that begins with “simple-sample.uc.r.appspot.com/mobile” to the mobile-frontend service.
- url: "simple-sample.uc.r.appspot.com/mobile*"
  service: mobile-frontend

# Send any domain/sub-domain with a path that starts with “work” to the static backend service.
- url: "*/work*"
  service: static-backend

También puedes escribir expresiones que sean más estrictas:

# Matches the path "/fun", but not "/fun2" or "/fun/other"
- url: "*/fun"
  service: mobile-frontend

# Matches the hostname 'customer1.myapp.com', but not '1.customer1.myapp.com.
- url: "customer1.myapp.com/*"
  service: static-backend

Límites

El archivo de envío puede contener hasta 20 reglas de enrutamiento. Cuando se especifica la string de la URL, ni el nombre de host ni la ruta pueden tener más de 100 caracteres.

Borra todas las reglas de envío

Para borrar todas las reglas de envío, sigue estos pasos:

  1. Edita el contenido del archivo dispatch.yaml de la siguiente manera: 

    dispatch: []

  2. Implementa el archivo dispatch.yaml en App Engine.