Descripción general de los mapas de URL

Los balanceadores de cargas de Google Cloud y Cloud Service Mesh usan un recurso de configuración de Google Cloud llamado mapa de URL para enrutar solicitudes HTTP(S) a servicios o buckets de backend.

Por ejemplo, con un balanceador de cargas de aplicaciones externo, puedes usar un solo mapa de URLs para enrutar solicitudes a diferentes destinos según las reglas configuradas en aquel mapa:

Las solicitudes de https://example.com/video se envían a un servicio de backend.
Las solicitudes de https://example.com/audio se envían a un servicio de backend diferente.

Las solicitudes de https://example.com/images se envían a un depósito de backend de Cloud Storage.

Las solicitudes de cualquier otra combinación de host y ruta de acceso se envían a un servicio de backend predeterminado.

Los mapas de URL se usan con los siguientes productos de Google Cloud:

Balanceador de cargas de aplicaciones externo (modos globales, regionales y clásicos)
Balanceador de cargas de aplicaciones interno (modos entre regiones y regionales)
Cloud Service Mesh, cuando se implementa Cloud Service Mesh con las APIs de balanceo de cargas

Existen dos tipos de recursos de mapas de URL disponibles: global y regional. El tipo de recurso que debes usar depende del esquema de balanceo de cargas del producto.

Producto	Esquema de balanceo de cargas	Tipo de recurso de mapa de URL	Destinos admitidos
Balanceador de cargas de aplicaciones externo global	`EXTERNAL_MANAGED`	Global, externo	Servicios de backend, buckets de backend
Balanceador de cargas de aplicaciones clásico	`EXTERNAL`	Global, externo	Servicios de backend, buckets de backend
Balanceador de cargas de aplicaciones externo regional	`EXTERNAL_MANAGED`	Regional y externo	Servicios de backend
Balanceador de cargas de aplicaciones interno entre regiones	`INTERNAL_MANAGED`	Global, interno	Servicios de backend
Balanceador de cargas de aplicaciones interno regional	`INTERNAL_MANAGED`	Regional, interno	Servicios de backend
Cloud Service Mesh	`INTERNAL_SELF_MANAGED`	Global, interno	Servicios de backend

No todas las funciones de mapas de URL están disponibles para todos los productos. Los mapas de URL que se usan con balanceadores de cargas de aplicaciones externos, los balanceadores de cargas de aplicaciones externos regionales, los balanceadores de cargas de aplicaciones internos y Cloud Service Mesh también admiten varias funciones avanzadas de administración de tráfico. Para obtener más información sobre estas diferencias, consulta Comparación de funciones del balanceador de cargas: Administración de tráfico y enrutamiento. Además, los mapas de URL regionales pueden ser un recurso que se designa como servicio en App Hub, que está en versión preliminar.

Cómo funcionan los mapas de URL

Cuando una solicitud llega al balanceador de cargas, este la enruta a un servicio o bucket de backend en particular según las reglas definidas en el mapa de URL.

Un servicio de backend representa una colección de backends, que son instancias de una aplicación o un microservicio. Un bucket de backend es un bucket de Cloud Storage, que se usa frecuentemente para alojar contenido estático, como imágenes.

Para los balanceadores de cargas de aplicaciones externos regionales, los balanceadores de cargas de aplicaciones internos y Cloud Service Mesh, los destinos posibles son los siguientes:

Servicio de backend predeterminado
Servicio de backend no predeterminado

Además, los balanceadores de cargas de aplicaciones externos globales admiten lo siguiente:

Bucket de backend predeterminado
Bucket de backend no predeterminado

Por ejemplo, supón que tienes la siguiente configuración:

Una dirección IP:
- Todas las solicitudes a tu organización se envían a la misma dirección IP y al mismo balanceador de cargas.
- El tráfico se dirige a diferentes servicios de backend según la URL de la solicitud.
Dos dominios:
- example.net aloja videos de capacitación.
- example.org aloja el sitio web de la organización.
Cuatro conjuntos de servidores:
- Uno aloja el sitio web de la organización (servicio de backend: org-site).
- Uno aloja el sitio web general del video de capacitación (servicio de backend: video-site).
- Uno aloja videos de capacitación en alta definición (HD) (servicio de backend: video-hd).
- Uno aloja videos de capacitación en definición estándar (SD) (servicio de backend: video-sd).

Lo que debe ocurrir es lo siguiente:

Las solicitudes a example.org (o cualquier dominio que no sea example.net) deben dirigirse al servicio de backend org-site.
Solicitudes a example.net que no coinciden con rutas más específicas para ir al servicio de backend video-site.
Solicitudes a example.net/video/hd/* deben dirigirse al servicio de backend video-hd.
Solicitudes a example.net/video/sd/* deben dirigirse al servicio de backend video-sd.

Un --path-rule para /video/* coincide con los URI como /video/test1 y /video/test2. Sin embargo, esta regla de ruta de acceso no coincide con la ruta /video.

Si el balanceador de cargas recibe una solicitud con /../ en la URL, el balanceador de cargas transforma la URL mediante la eliminación del segmento de ruta antes de .. y responde con la URL transformada. Por ejemplo, cuando se envía una solicitud para http://example.net/video/../abc, el balanceador de cargas responde con un redireccionamiento 302 a http://example.net/abc. Luego, la mayoría de los clientes reaccionan mediante una solicitud a la URL que muestra el balanceador de cargas (en este caso, http://example.net/abc). Este redireccionamiento 302 no se registra en Cloud Logging.

El mapa de URL te permite configurar este tipo de enrutamiento basado en host y ruta de acceso.

Ejemplo de configuración del servicio de backend. — Ejemplo de configuración del servicio de backend (haz clic para ampliar).

Nombre

Cada mapa de URL tiene un nombre. Cuando creas un balanceador de cargas basado en HTTP(S) mediante la consola de Google Cloud, se asigna un nombre al mapa de URL. Este nombre es el mismo que el nombre del balanceador de cargas en la consola de Google Cloud. Si usas la API o la CLI de Google Cloud, puedes definir un nombre personalizado para el mapa de URL.

Componentes del mapa de URL

Un mapa de URL es un conjunto de recursos de configuración de Google Cloud que dirige las solicitudes de URLs a servicios o buckets de backend. Para hacerlo, el mapa de URL utiliza las partes nombre de host y ruta de acceso de cada URL que procesa:

Un nombre de host es la parte del nombre de dominio de una URL; por ejemplo, la parte del nombre del host de la URL http://example.net/video/hd es example.net.
Una ruta de acceso es la parte de una URL que sigue al nombre de host y el número de puerto opcional; por ejemplo, la parte de la ruta de acceso de la URL http://example.net/video/hd es /video/hd.

Configuración del balanceador de cargas con un mapa de URL básico. — Configuración del balanceador de cargas con un mapa de URL básico (haz clic para ampliar).

En este diagrama, se muestra la estructura de los objetos de configuración de balanceo de cargas y sus relaciones.

Para controlar qué servicios o buckets de backend reciben solicitudes entrantes, usa los siguientes parámetros de configuración del mapa de URL:

Servicio de backend predeterminado o bucket de backend predeterminado. Cuando creas un mapa de URL, debes especificar un servicio o un bucket de backend predeterminado, pero no ambos. Este valor predeterminado representa el servicio o bucket de backend al que Google Cloud dirige las solicitudes de URLs con cualquier nombre de host, a menos que exista una regla de host aplicable.

Regla de host (hostRules). Una regla de host dirige las solicitudes enviadas a uno o más nombres de host asociados a un solo comparador de ruta (pathMatchers). La parte del nombre de host de una URL coincide con exactitud con el conjunto de nombres de host configurados de la regla de host. En un host de asignación de URL y una regla de ruta de acceso, si omites el host, la regla coincide con cualquier host solicitado. Para dirigir las solicitudes de http://example.net/video/hd a un comparador de rutas de acceso, necesitas una sola regla de host que incluya, al menos, el nombre del host example.net. Esa misma regla de host también podría manejar solicitudes de otros nombres de host, pero los dirigiría al mismo comparador de rutas de acceso.

Si necesitas dirigir solicitudes a diferentes comparadores de rutas de acceso, debes usar reglas de host diferentes. Dos reglas de host en un mapa de URL no pueden tener el mismo nombre de host.

Es posible hacer coincidir todos los nombres de host si especificas el carácter comodín * en la regla de host. Por ejemplo, para las URL http://example.org, http://example.net/video/hd y http://example.com/audio, se puede hacer coincidir a los tres nombres de host example.org, example.net y example.com si se especifica * en la regla de host. También es posible hacer coincidir un nombre de host parcial si especificas el carácter comodín *. Por ejemplo, una regla de host *.example.net coincide con ambos nombres de host, news.example.net y finance.example.net.
- Número de puerto. Con los diferentes balanceadores de cargas de aplicaciones puedes controlar los números de puerto de manera diferente. En el caso del balanceador de cargas de aplicaciones interno, puedes usar el parámetro Regla de host para especificar un número de puerto. Por ejemplo, para dirigir las solicitudes example.net al puerto 8080, establece la regla de host en example.net:8080. En el caso del balanceador de cargas de aplicaciones clásico, solo el nombre de host en la URL se considera cuando se hace coincidir una regla de host. Por ejemplo, las solicitudes example.net para el puerto 8080 y el puerto 80 coinciden con la regla de host example.net.
Comparador de rutas de acceso (pathMatchers). Un comparador de rutas de acceso es el parámetro de configuración al que hace referencia una regla de host. Define la relación entre la parte de la ruta de acceso de una URL y el servicio o bucket de backend que debe entregar la solicitud. Un comparador de rutas de acceso consta de dos elementos:
- Servicio de backend predeterminado del comparador de rutas de acceso o bucket de backend predeterminado del comparador de rutas de acceso. Para cada comparador de rutas de acceso, debes especificar, al menos, un servicio o un bucket de backend predeterminado, pero no ambos. Este valor predeterminado representa el servicio o bucket de backend al que Google Cloud dirige las solicitudes de URLs cuyos nombres de host coinciden con una regla de host asociada a un comparador de rutas de acceso y cuyas rutas de URL no coinciden con ninguna regla de ruta de acceso en el comparador de rutas de acceso.
- Reglas de ruta de acceso Para cada comparador de rutas de acceso, puedes especificar una o más reglas de ruta de acceso, que son pares clave-valor que asignan una ruta de URL a un solo servicio o bucket de backend. La siguiente sección contiene más información sobre cómo funcionan las reglas de ruta de acceso.

Orden de las operaciones

Para un nombre de host y una ruta de acceso en una URL solicitada, Google Cloud usa el siguiente procedimiento a fin de dirigir la solicitud al servicio o bucket de backendcorrecto, como se configuró en el mapa de URL:

Si el mapa de URL no contiene una regla de host para el nombre del host de la URL, Google Cloud dirige las solicitudes al servicio o al bucket de backend predeterminado del mapa de URL, según cuál definiste.
Si el mapa de URL contiene una regla de host que incluye el nombre del host de la URL, se consulta el comparador de rutas de acceso al que hace referencia esa regla de host:
- Si el comparador de rutas de acceso contiene una regla de ruta que coincide con exactitud con la ruta de la URL, Google Cloud dirige las solicitudes al servicio o bucket de backend para esa regla de ruta.
- Si el comparador de rutas de acceso no contiene una regla de ruta que coincide con exactitud con la ruta de la URL, pero contiene una regla de ruta que termina en /*, cuyo prefijo coincide con la sección más larga de la ruta de la URL, Google Cloud dirigirá las solicitudes al servicio o bucket de backend para esa regla de ruta. Por ejemplo, para el mapa de URL que contiene dos reglas del comparador de rutas de acceso /video/hd/movie1 y /video/hd/*, si la URL contiene la ruta de acceso exacta /video/hd/movie1, se compara con esa regla de ruta.
- Si ninguna de las condiciones anteriores es verdadera, Google Cloud dirige las solicitudes al servicio o bucket de backend predeterminado del comparador de rutas de acceso, según el que hayas definido.

Restricciones del comparador de rutas

Los nombres de host, los comparadores de rutas de acceso y las reglas de ruta de acceso tienen restricciones.

Comodines, expresiones regulares y URL dinámicas en reglas de ruta de acceso

Una regla de ruta de acceso solo puede incluir un carácter comodín (*) después de un carácter de barra diagonal (/). Por ejemplo, /videos/* y /videos/hd/* son válidos para las reglas de ruta, pero /videos* y /videos/hd* no.
Las reglas de ruta de acceso no usan expresiones regulares ni coincidencias de substrings. PathTemplateMatch puede usar operadores de coincidencia de ruta de acceso simplificados. Por ejemplo, las reglas de ruta de acceso para /videos/hd o /videos/hd/* no se aplican a una URL con la ruta de acceso /video/hd-abcd. Sin embargo, una regla de ruta de acceso para /video/* sí se aplica a esa ruta.
Los comparadores de rutas de acceso (y los mapas de URL en general) no ofrecen características que funcionen como las directivas LocationMatch de Apache. Si tienes una aplicación con la que se generan rutas de acceso de URL dinámicas que tienen un prefijo común, como /videos/hd-abcd y /videos/hd-pqrs, y necesitas enviar solicitudes que se realizaron a esas rutas a servicios de backend diferentes, es posible que no puedas hacerlo con un mapa de URL. Para casos simples que contengan solo algunas posibles URL dinámicas, es posible que puedas crear un comparador de rutas de acceso con un conjunto limitado de reglas de ruta. Para casos más complejos, es necesario realizar coincidencias de expresiones regulares basadas en rutas de acceso en tus backends.

Comodines y operadores de coincidencia de patrones en las plantillas de ruta de acceso para reglas de enrutamiento

Con los operadores de coincidencia de patrones flexibles puedes generar coincidencias con varias partes de una ruta de URL, incluidas las URLs y los sufijos parciales (extensiones de archivo), mediante una sintaxis de comodín simple. Estos operadores pueden ser útiles cuando necesitas enrutar el tráfico y ejecutar reescrituras en función de rutas de URL complejas. También puedes asociar uno o más componentes de ruta de acceso con variables con nombre y, luego, hacer referencia a esas variables cuando reescribes la URL. Con las variables con nombre, puedes reordenar y quitar los componentes de la URL antes de enviar la solicitud a tu origen.

La coincidencia de patrones con comodines solo se admite para los siguientes productos:

Balanceador de cargas de aplicaciones externo global

Balanceador de cargas de aplicaciones externo regional
Balanceador de cargas de aplicaciones interno regional

Balanceador de cargas de aplicaciones interno entre regiones
Cloud Service Mesh

En el siguiente ejemplo, se enruta el tráfico de una aplicación de comercio electrónico que tiene servicios independientes para la información del carrito y la información del usuario. Puedes configurar routeRules con operadores de coincidencia de patrones flexibles y variables con nombre para enviar el ID único del usuario a una página de detalles de la cuenta de usuario y la información del carrito del usuario a un servicio de procesamiento del carrito después de reescribir la URL.

  pathMatchers:
    - name: cart-matcher
      routeRules:
        - description: CartService
          matchRules:
            - pathTemplateMatch: '/xyzwebservices/v2/xyz/users/{username=*}/carts/{cartid=**}'
          service: cart-backend
          priority: 1
          routeAction:
            urlRewrite:
              pathTemplateRewrite: '/{username}-{cartid}/'
    - name: user-matcher
      routeRules:
        - description: UserService
          matchRules:
            - pathTemplateMatch: '/xyzwebservices/v2/xyz/users/*/accountinfo/*'
          service: user-backend
          priority: 1

Esto es lo que sucede cuando un cliente solicita /xyzwebservices/v2/xyz/users/abc@xyz.com/carts/FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB, que tiene información del usuario y del carrito:

La ruta de acceso de la solicitud coincide con pathTemplateMatch dentro de pathMatcher de cart-matcher. La variable {username=*} coincide con abc@xyz.com y la variable {cartid=**} coincide con FL0001090004/entries/SJFI38u3401nms.
Los parámetros de consulta se separan de la ruta de acceso, la ruta de acceso se vuelve a escribir según pathTemplateRewrite y los parámetros de consulta se agregan a la ruta de acceso reescrita. Solo debemos usar las mismas variables que usamos para definir el pathTemplateMatch en nuestra pathTemplateRewrite.
La solicitud reescrita se envía a cart-backend con la ruta de URL reescrita: /abc@xyz.com-FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB.

Lo siguiente sucede cuando un cliente solicita /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234, que solo tiene información del usuario y de la cuenta:

La ruta de acceso de la solicitud coincide con pathTemplateMatch dentro de pathMatcher de user-matcher. El primer * coincide con abc%40xyz.com y el segundo * coincide con abc-1234.
La solicitud se envía a user-backend.

En la siguiente tabla, se describe la sintaxis para patrones de plantilla de ruta de acceso.

Operador	Coincidencias
*``**	Un solo segmento de ruta de acceso, sin incluir los caracteres `/` adyacentes que separan la ruta.
``**	Coincide con cero o más caracteres, incluido cualquier caracter `/` separador de ruta entre varios segmentos de ruta. Si se incluyen otros operadores, el operador `**` debe ser el último operador.
*`{name}` o `{name=}`**	Una variable con nombre que coincide con un segmento de ruta de acceso. Coincide con un solo segmento de ruta, sin incluir el separador de ruta `/`.
*`{name=news/}`**	Una variable con nombre que coincide de forma explícita con dos segmentos de ruta: `news` y un segmento comodín `*`.
*`{name=/news/}`*	Una variable con nombre que coincide con tres segmentos de ruta de acceso.
`{name=}`**	Una variable con nombre que coincide con cero o más caracteres. Si está presente, debe ser el último operador.

Cuando uses estos operadores para la coincidencia de patrones flexible, ten en cuenta estas consideraciones:

Se pueden combinar varios operadores en un solo patrón.
Los parámetros de consulta se separan de la ruta de acceso, la ruta de acceso se vuelve a escribir según pathTemplateRewrite y los parámetros de consulta se agregan a la ruta de acceso reescrita.
Las solicitudes no tienen una codificación de porcentaje normalizada. Por ejemplo, una URL con un carácter de barra codificado como porcentaje (%2F) no se decodifica en el formato sin codificación.
Cada nombre de variable, como {segment} o {region}, puede aparecer solo una vez en el mismo patrón. Las variables múltiples con el mismo nombre no son válidas y se rechazan.
Los nombres de las variables distinguen mayúsculas de minúsculas y deben ser identificadores válidos. Para verificar si un nombre de variable es válido, asegúrate de que coincida con la expresión regular ^[a-zA-Z][a-zA-Z0-9_]*$.
- {API}, {api} y {api_v1} son identificadores válidos. Identifican tres variables distintas.
- {1}, {_api} y {10alpha} no son identificadores válidos.
Existe un límite de cinco operadores por patrón de plantilla.

Para ejecutar una reescritura de URL opcional antes de enviar la solicitud al origen, puedes usar las mismas variables que definiste para capturar una ruta. Por ejemplo, puedes hacer referencia, reordenar o omitir variables en el campo pathTemplateRewrite cuando defines urlRewrite.

Cuando uses variables y operadores para la coincidencia de patrones flexible en las reescrituras de URL, ten en cuenta estas consideraciones:

Cuando reescribes una URL, puedes omitir variables si no son necesarias como parte de la URL reescrita.
Antes de cualquier reescritura, puedes identificar la URL que envió el cliente en tu origen mediante la inspección de los encabezados de respuesta. La URL del cliente original se propaga con el encabezado x-client-request-url y el encabezado x-envoy-original-path.

Relación entre el nombre de host y la regla de host

Un nombre de host solo puede hacer referencia a una única regla de host.
Una única regla de host puede procesar varios nombres de host.

La relación entre los nombres de host y las reglas de host. — La relación entre los nombres de host y las reglas de host (haz clic para ampliar).

Relación entre la regla de host y el comparador de rutas de acceso

Varias reglas de host pueden hacer referencia a un solo comparador de rutas de acceso.
Una regla de host solo puede hacer referencia a un único comparador de rutas de acceso.

En el siguiente diagrama, se ilustran estos puntos.

La relación entre las reglas de host y los comparadores de rutas de acceso. — La relación entre las reglas de host y los comparadores de rutas de acceso (haz clic para ampliar).

Relación entre la URL y el backend

Cada URL única se dirige a un solo servicio o bucket de backend. Por lo tanto, sucede lo siguiente:

Google Cloud usa la parte del nombre de host de una URL para seleccionar una única regla de host y el comparador de rutas de acceso al que hace referencia.
Cuando usas reglas de ruta de acceso en un comparador de rutas de acceso, no puedes crear más de una regla de ruta de acceso para la misma ruta de acceso. Por ejemplo, las solicitudes de /videos/hd no se pueden dirigir a más de un servicio o bucket de backend. Los servicios de backend pueden tener grupos de instancias de backend o grupos de extremos de red (NEG) de backend en diferentes zonas y regiones, y puedes crear buckets de backend que usen clases Multi-Regional Storage.

Para dirigir el tráfico de una URL única a varios servicios, puedes usar reglas de enrutamiento en lugar de reglas de ruta de acceso. Si configuras el comparador de rutas de acceso con reglas de enrutamiento para coincidencias de parámetros o encabezados, una URL única se puede dirigir a más de un servicio o bucket de backend, según el contenido de los encabezados o los parámetros de consulta en la URL.

De manera similar, para los balanceadores de cargas de aplicaciones externas regionales y Cloud Service Mesh, puedes dirigir la misma URL a varios servicios o buckets de backend con los servicios de backend ponderados en las acciones de ruta, según los pesos establecidos en el servicio de backend ponderado.

Protocolos y mapas de URL

Puede usar los mismos mapas de URL, reglas de host y comparadores de rutas de acceso para procesar las solicitudes HTTP y HTTPS que envían los clientes, siempre y cuando los proxies HTTP y HTTPS de destino hagan referencia al mapa de URL.

Mapa de URL más simple

El mapa de URL más simple solo tiene un servicio de backend o un bucket de backend predeterminado. No contiene reglas de host ni comparadores de rutas de acceso. El servicio o el bucket de backend predeterminado (el que hayas definido) administra todas las URLs solicitadas.

Si defines un servicio de backend predeterminado, Google Cloud dirige las solicitudes a sus grupos de instancias de backend o NEG de backend de acuerdo con la configuración del servicio de backend.

Mapa de URL sin reglas, excepto las predeterminadas. — Mapa de URL sin reglas, excepto las predeterminadas (haz clic para ampliar).

Ejemplo de flujo de trabajo de mapa de URL con un balanceador de cargas de aplicaciones externo

En el ejemplo siguiente, se ilustra el orden de las operaciones para un mapa de URL. En este ejemplo, solo se configura el mapa de URL para un balanceador de cargas de aplicaciones clásico existente. Por simplicidad conceptual, solo usa los servicios de backend. Sin embargo, puedes sustituirlos por buckets de backend. Para obtener información sobre cómo crear los demás componentes del balanceador de cargas, consulta Crea un balanceador de cargas de aplicaciones clásico.

Si deseas obtener más información para crear y configurar mapas de URL con comparadores de rutas de acceso y reglas de host, consulta la documentación de gcloud compute url-maps create.

Crea un mapa de URL para el balanceador de cargas y especifica un servicio de backend predeterminado. En este ejemplo, se crea un mapa de URL llamado video-org-url-map que hace referencia a un servicio de backend existente llamado org-site.
```
gcloud compute url-maps create video-org-url-map \
    --default-service=org-site
```
Crea un comparador de rutas de acceso llamado video-matcher con las siguientes características:
- El servicio de backend predeterminado es video-site, un servicio de backend existente.
- Agrega reglas de ruta de acceso que dirigen las solicitudes para la ruta de URL /video/hd exacta o el prefijo de ruta de URL /video/hd/* a un servicio de backend existente llamado video-hd.
- Agrega reglas de ruta de acceso que dirigen las solicitudes para la ruta de URL /video/sd exacta o el prefijo de ruta de URL /video/sd/* a un servicio de backend existente llamado video-sd.
```
gcloud compute url-maps add-path-matcher video-org-url-map \
    --path-matcher-name=video-matcher \
    --default-service=video-site \
    --path-rules=/video/hd=video-hd,/video/hd/*=video-hd,/video/sd=video-sd,/video/sd/*=video-sd
```

Crea una regla de host para el nombre de host example.net que hace referencia al comparador de rutas de acceso video-matcher.

gcloud compute url-maps add-host-rule video-org-url-map \
    --hosts=example.net \
    --path-matcher-name=video-matcher

La URL video-org-url-map debería verse de esta forma:

gcloud compute url-maps describe video-org-url-map

creationTimestamp: '2021-03-05T13:34:15.833-08:00'
defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/org-site
fingerprint: mfyJIT7Zurs=
hostRules:
- hosts:
  - '*'
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
id: '8886405179645041976'
kind: compute#urlMap
name: video-org-url-map
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-site
  name: video-matcher
  pathRules:
  - paths:
    - /video/hd
    - /video/hd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-hd
  - paths:
    - /video/sd
    - /video/sd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-sd
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/video-org-url-map

El mapa de URL video-org-url-map dirige las URL solicitadas a los backends de la siguiente manera.

Mapa de URL con una regla de ruta de acceso, comparadores de rutas de acceso y una regla de host. — Mapa de URL con una regla de ruta de acceso, comparadores de rutas de acceso y una regla de host (haz clic para ampliar).

En la siguiente tabla, se explica el procesamiento de solicitudes que se muestra en el diagrama anterior.

Nombre de host	Rutas de URL	Servicio de backend seleccionado	Motivo de la selección
Nombre de host: `example.org` y todos los demás nombres de host diferentes de `example.net`	todas las rutas	`org-site`	El nombre de host no figura en ninguna regla de host del mapa de URL, por lo que la solicitud se dirige al servicio de backend predeterminado del mapa de URL.
Nombre de host `example.net`	`/video` `/video/examples`	`video-site`	La solicitud se envía al servicio de backend predeterminado porque no hay una regla de ruta para `/video/` o `/video/*`. La regla de host para `example.net` hace referencia a un comparador de rutas de acceso, pero ese comparador no tiene ninguna regla de ruta que se aplique a estas rutas de acceso.
Nombre de host `example.net`	`/video/hd` `/video/hd/movie1` `/video/hd/movies/movie2` Otras URL que comienzan con `/video/hd/*`	`video-hd`	Una regla de host para `example.net` hace referencia a un comparador de rutas de acceso cuyas reglas de acceso envían solicitudes para rutas de URL que coinciden con exactitud con `/video/hd` o que comienzan con `/video/hd/*` al servicio de backend `video-hd`.
Nombre de host `example.net`	`/video/sd` `/video/sd/show1` `/video/sd/shows/show2` Otras URL que comienzan con `/video/sd/*`	`video-sd`	Una regla de host para `example.net` hace referencia a un comparador de rutas de acceso cuyas reglas de acceso envían solicitudes para rutas de URL que coinciden con exactitud con `/video/sd` o que comienzan con `/video/sd/*` al servicio de backend `video-sd`.

Redireccionamientos de URL

El redireccionamiento de URL redirecciona a los visitantes de tu dominio de una URL a otra.

Un redireccionamiento de URL predeterminado no está condicionado a la coincidencia de ningún patrón en particular en la solicitud entrante. Por ejemplo, es posible que desees usar un redireccionamiento de URL predeterminado para redireccionar cualquier nombre de host a un nombre de host que elijas.

Existen varias formas de crear un redireccionamiento de la URL, como se describe en la siguiente tabla.

Método	Configuración
Redireccionamiento predeterminado de URL del mapa de URL	TopLevel `defaultUrlRedirect`
El redireccionamiento predeterminado de una URL del comparador de rutas de acceso	`pathMatchers[].defaultUrlRedirect[]`
El redireccionamiento de URL de una regla de ruta de acceso de un comparador de rutas	`pathMatchers[].pathRules[].urlRedirect`
El redireccionamiento de la URL de la regla de enrutamiento de un comparador de rutas	`pathMatchers[].routeRules[].urlRedirect`

Dentro de un defaultUrlRedirect o urlRedirect, pathRedirect siempre funciona de la siguiente manera:

Toda la ruta de solicitud se reemplaza con la ruta de acceso que especifiques.

Dentro de un defaultUrlRedirect o urlRedirect, el funcionamiento de prefixRedirect depende de cómo lo uses:

Si usas un defaultUrlRedirect, prefixRedirect es, en efecto, un prefijo precedido por la ruta de acceso coincidente siempre es /.
Si usas un urlRedirect dentro de la regla de enrutamiento o la regla de ruta de un comparador de rutas de acceso, prefixRedirect es un reemplazo de prefijo según la coincidencia de la ruta de acceso solicitada como se define en la regla de ruta de acceso o la regla de enrutamiento.

Ejemplos de redireccionamientos

En la siguiente tabla, se proporcionan algunos ejemplos de configuraciones de redireccionamiento. En la columna de la derecha, se muestra la configuración de la API para un redireccionamiento de URL predeterminado.

Quieres	Logrado mediante un redireccionamiento predeterminado de URL.
Redireccionamiento HTTP a HTTPS Redireccionamiento http://host.name/path a https://host.name/path	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True
Redireccionamiento HTTP a HTTPS + Host Redireccionamiento http://any-host-name/path a https://www.example.com/path	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com"
Redireccionamiento HTTP a HTTPS + Host + Redireccionamiento de ruta de acceso completa Redireccionamiento http://any-host-name/path a https://www.example.com/newPath	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" pathRedirect: "/newPath"
Redireccionamiento HTTP a HTTPS + Host + Prefijo Redireccionamiento http://any-host-name/originalPath a https://www.example.com/newPrefix/originalPath	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" prefixRedirect: "/newPrefix"

En el siguiente fragmento parcial, se anota cada recurso de la API:

defaultUrlRedirect:
   redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
   httpsRedirect: True # True if you want https://, false if you want http://
   hostRedirect: "new-host-name.com" # Omit to keep the requested host
   pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
   prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
   stripQuery: False # True to omit everything in the URL after ?
   ...

¿Qué sigue?

Para agregar, validar, probar, enumerar o borrar un mapa de URL, consulta Usa mapas de URL.
Para obtener información sobre el enrutamiento de mapas de reglas con Cloud Service Mesh, consulta Descripción general de los mapas de reglas de enrutamiento de Cloud Service Mesh.