Descripción general de los mapas de URLs

Google Cloud Application Load Balancers y Cloud Service Mesh usan un Google Cloud recurso de configuración llamado mapa de URLs para enrutar solicitudes HTTP(S) a servicios de backend o a buckets de backend.

Por ejemplo, con un balanceador de carga de aplicaciones externo, puede usar un solo mapa de URLs para enrutar las solicitudes a diferentes destinos en función de las reglas configuradas en el mapa de URLs:

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

• Las solicitudes de https://example.com/images van a un segmento de backend de Cloud Storage.

• Las solicitudes de cualquier otra combinación de host y ruta se dirigen a un servicio backend predeterminado.

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

• Balanceador de carga de aplicación externo (modos global, regional y clásico)
• Balanceador de carga de aplicación interno (modos entre regiones y regional)
• Cloud Service Mesh, cuando se implementa con las APIs de balanceo de carga

Hay dos tipos de recursos de mapa de URLs disponibles: globales y regionales.

• Los urlMaps globales se usan en los balanceadores de carga de aplicación externos globales, los balanceadores de carga de aplicación clásicos, los balanceadores de carga de aplicación internos entre regiones y Cloud Service Mesh.

• Los regionUrlMaps se usan en los balanceadores de carga de aplicación externos regionales y en los balanceadores de carga de aplicación internos regionales.

El tipo de recurso que utilices dependerá del esquema de balanceo de carga del producto.

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

Cómo funcionan los mapas de URLs

Cuando llega una solicitud al balanceador de carga, este la enruta a un servicio de backend o a un segmento de backend concretos en función de las reglas definidas en el mapa de URLs.

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

En el caso de los balanceadores de carga de aplicaciones externos regionales, los balanceadores de carga 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 carga de aplicación externos globales admiten lo siguiente:

• Segmento de backend predeterminado
• Segmento de backend no predeterminado

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

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

Quieres que ocurra lo siguiente:

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

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

Si el balanceador de carga recibe una solicitud con /../ en la URL, la transforma eliminando el segmento de ruta anterior a .. y responde con la URL transformada. Por ejemplo, cuando se envía una solicitud para http://example.net/video/../abc, el balanceador de carga responde con una redirección 302 a http://example.net/abc. La mayoría de los clientes reaccionan enviando una solicitud a la URL devuelta por el balanceador de carga (en este caso, http://example.net/abc). Esta redirección 302 no se registra en Cloud Logging.

El mapa de URLs te permite configurar este tipo de enrutamiento basado en hosts y rutas.

Nombres de balanceadores de carga

En el caso de los balanceadores de carga de aplicaciones, el nombre del balanceador de carga siempre es el mismo que el del mapa de URLs. El comportamiento de cada Google Cloud interfaz es el siguiente:

• Google Cloud console. Si creas un balanceador de carga de aplicaciones mediante laGoogle Cloud consola, el mapa de URLs recibe automáticamente el mismo nombre que has introducido para el balanceador de carga.
• Google Cloud CLI o API. Si creas un balanceador de carga de aplicaciones con la CLI de gcloud o la API, debes introducir el nombre que quieras al crear el mapa de URLs. Este nombre de asignación de URL se refleja en la consolaGoogle Cloud como nombre del balanceador de carga.

Para obtener información sobre cómo se asignan los nombres a los balanceadores de carga de red de proxy y a los balanceadores de carga de red con paso a través, consulta el artículo Descripción general de los servicios de backend: asignación de nombres a los balanceadores de carga.

Componentes de mapas de URLs

Un mapa de URLs es un conjunto de Google Cloud recursos de configuración que dirige las solicitudes de URLs a servicios de backendo a buckets de backend. El mapa de URLs lo hace usando las partes nombre de host y ruta 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 de host de la URL http://example.net/video/hd es example.net.
• Una ruta es la parte de una URL que va después del nombre de host y del número de puerto opcional. Por ejemplo, la ruta de la URL http://example.net/video/hd es /video/hd.

En este diagrama se muestra la estructura de los objetos de configuración del balanceo de carga y su relación entre sí.

Puedes controlar qué servicios de backend o segmentos de backend reciben las solicitudes entrantes mediante los siguientes parámetros de configuración de mapas de URLs:

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

• Regla de host (hostRules): dirige las solicitudes enviadas a uno o varios nombres de host asociados a un solo comparador de rutas (pathMatchers). La parte del nombre de host de una URL coincide exactamente con el conjunto de nombres de host configurados de la regla de host. En una regla de host y ruta de un mapa de URLs, si omite el host, la regla coincidirá con cualquier host solicitado. Para dirigir las solicitudes de http://example.net/video/hd a un comparador de rutas, necesitas una sola regla de host que incluya al menos el nombre de host example.net. La misma regla de host también podría gestionar solicitudes de otros nombres de host, pero las dirigiría al mismo matcher de ruta.

  Si necesitas dirigir las solicitudes a diferentes matchers de ruta, debes usar reglas de host diferentes. Dos reglas de host de un mapa de URLs no pueden incluir el mismo nombre de host.

  Es posible hacer coincidir todos los nombres de host especificando el carácter comodín * en la regla de host. Por ejemplo, en las URLs http://example.org, http://example.net/video/hd y http://example.com/audio, los tres nombres de host example.org, example.net y example.com se pueden asociar especificando * en la regla de host. También es posible buscar coincidencias con un nombre de host parcial especificando el comodín *. Por ejemplo, una regla de host *.example.net se compara con los nombres de host news.example.net y finance.example.net.

  • Número de puerto. Los distintos balanceadores de carga de aplicaciones gestionan los números de puerto de forma diferente. En el caso del balanceador de carga de aplicación interno, puede usar el parámetro Regla de host para especificar un número de puerto. Por ejemplo, para dirigir las solicitudes example.net del puerto 8080, defina la regla de host como example.net:8080. En el caso del balanceador de carga de aplicaciones clásico, solo se tiene en cuenta el nombre de host de la URL al buscar una regla de host. Por ejemplo, las example.net solicitudes de los puertos 8080 y 80 coinciden con la regla de host example.net.

• Comparador de rutas (pathMatchers): 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 una URL y el servicio de backend o el segmento de backend que debe atender la solicitud. Un comparador de rutas consta de dos elementos:

  • Servicio de backend predeterminado del comparador de rutas o segmento de backend predeterminado del comparador de rutas. En cada comparador de rutas, debes especificar al menos un servicio de backend predeterminado o un segmento de backend predeterminado, pero no ambos.Este valor predeterminado representa el servicio de backend o el segmento de backend al que Google Cloud dirige las solicitudes de URLs cuyos nombres de host coinciden con una regla de host asociada al comparador de rutas y cuyas rutas de URL no coinciden con ninguna regla de ruta del comparador de rutas.

  • Reglas de ruta. En cada comparador de rutas, puede especificar una o varias reglas de ruta, que son pares clave-valor que asignan una ruta de URL a un único servicio de backend o a un único bucket de backend. En la siguiente sección, se incluye más información sobre cómo funcionan las reglas de ruta.

Orden de las operaciones

Para un nombre de host y una ruta determinados en una URL solicitada, Google Cloud sigue este procedimiento para dirigir la solicitud al servicio de backend correcto o al segmento de backend, tal como se haya configurado en tu mapa de URLs:

• Si el mapa de URLs no contiene una regla de host para el nombre de host de la URL, Google Cloud dirige las solicitudes al servicio backend predeterminado del mapa de URLs o al bucket backend predeterminado, en función de cuál hayas definido.

• Si el mapa de URLs contiene una regla de host que incluye el nombre de host de la URL, se consulta el elemento de coincidencia de ruta al que hace referencia esa regla de host:

  • Si el comparador de rutas contiene una regla de ruta que coincide exactamente con la ruta de la URL, Google Cloud dirige las solicitudes al servicio de backend o al segmento de backend de esa regla de ruta.

  • Si el comparador de rutas no contiene una regla de ruta que coincida exactamente con la ruta de la URL, pero sí 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 Clouddirige las solicitudes al servicio de backend o al segmento de backend de esa regla de ruta. Por ejemplo, en el caso de un mapa de URLs que contenga dos reglas de coincidencia de ruta, /video/hd/movie1 y /video/hd/*, si la URL contiene la ruta exacta /video/hd/movie1, se comparará con esa regla de ruta.

  • Si no se cumple ninguna de las condiciones anteriores, Google Cloud dirige las solicitudes al servicio de backend predeterminado del comparador de rutas o al segmento de backend predeterminado, en función de cuál hayas definido.

Restricciones del comparador de rutas

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

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

• Una regla de ruta solo puede incluir un carácter comodín (*) después de una barra diagonal (/). Por ejemplo, /videos/* y /videos/hd/* son válidas para las reglas de ruta, pero /videos* y /videos/hd* no lo son.

• Las reglas de ruta no usan expresiones regulares ni coincidencia de subcadenas. PathTemplateMatch puede usar operadores de coincidencia de ruta simplificados. Por ejemplo, las reglas de ruta de /videos/hd o /videos/hd/* no se aplican a una URL con la ruta /video/hd-abcd. Sin embargo, una regla de ruta para /video/* sí se aplica a esa ruta.

• Los matchers de ruta (y los mapas de URLs en general) no ofrecen funciones que funcionen como las directivas LocationMatch de Apache. Si tienes una aplicación que genera rutas de URL dinámicas que tienen un prefijo común, como /videos/hd-abcd y /videos/hd-pqrs, y necesitas enviar solicitudes realizadas a esas rutas a diferentes servicios de backend, es posible que no puedas hacerlo con un mapa de URLs. En los casos en los que solo haya unas pocas URLs dinámicas posibles, quizá puedas crear un buscador de rutas con un conjunto limitado de reglas de ruta. En casos más complejos, debe hacer coincidir expresiones regulares basadas en rutas en sus back-ends.

Comodines y operadores de coincidencia de patrones en plantillas de ruta para reglas de ruta

Los operadores de coincidencia de patrones flexibles te permiten buscar coincidencias con varias partes de una ruta de URL, incluidas URLs parciales y sufijos (extensiones de archivo), mediante la sintaxis de comodines. Estos operadores pueden ser útiles cuando necesites enrutar tráfico y ejecutar reescrituras basadas en rutas de URL complejas. También puede asociar uno o varios componentes de ruta con variables con nombre y, a continuación, hacer referencia a esas variables al reescribir la URL. Con las variables con nombre, puedes reordenar y quitar componentes de la URL antes de que se envíe la solicitud a tu origen.

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

• Balanceador de carga de aplicación externo global

• Balanceador de carga de aplicación externo regional
• Balanceador de carga de aplicación interno regional

• Balanceador de carga de aplicación interno entre regiones
• Cloud Service Mesh

En el siguiente ejemplo se dirige 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 ocurre cuando un cliente solicita /xyzwebservices/v2/xyz/users/abc@xyz.com/carts/FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB, que contiene información del usuario y del carrito:

1. La ruta de la solicitud coincide con pathTemplateMatch en cart-matcher pathMatcher. La variable {username=*} coincide con abc@xyz.com y la variable {cartid=**} coincide con FL0001090004/entries/SJFI38u3401nms.
2. Los parámetros de consulta se separan de la ruta, la ruta se reescribe en función de pathTemplateRewrite y los parámetros de consulta se añaden a la ruta reescrita. Solo debemos usar las mismas variables que hemos usado para definir el pathTemplateMatch en nuestro pathTemplateRewrite.
3. 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.

Cuando un cliente solicita /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234 en su lugar, que solo contiene información de usuario y de cuenta, ocurre lo siguiente:

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

En la siguiente tabla se describe la sintaxis de los patrones de plantilla de ruta.

Cuando uses estos operadores para la coincidencia de patrones flexible, ten en cuenta lo siguiente:

• Se pueden combinar varios operadores en un solo patrón.
• Los parámetros de consulta se separan de la ruta, la ruta se reescribe en función de pathTemplateRewrite y los parámetros de consulta se añaden a la ruta reescrita.
• Las solicitudes no se normalizan con codificación de porcentaje. Por ejemplo, una URL con una barra codificada con porcentaje (%2F) no se decodifica en la forma sin codificar.
• Cada nombre de variable, como {segment} o {region}, solo puede aparecer una vez en el mismo patrón. No se pueden usar varias variables con el mismo nombre, por lo que se rechazarán.
• Los nombres de las variables distinguen entre mayúsculas y minúsculas, y deben ser identificadores válidos. Para comprobar 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.
• Hay un límite de cinco operadores por patrón de plantilla.

Para ejecutar una reescritura de URL opcional antes de que la solicitud se envíe al origen, puede usar las mismas variables que ha definido para capturar una ruta. Por ejemplo, puedes hacer referencia a variables, reordenarlas u omitirlas en el campo pathTemplateRewrite al definir urlRewrite.

Cuando uses variables y operadores para la coincidencia de patrones flexible en la reescritura de URLs, ten en cuenta lo siguiente:

• Al reescribir una URL, puede omitir variables si no son necesarias como parte de la URL reescrita.
• Antes de reescribir nada, puedes identificar la URL que ha enviado el cliente a tu origen inspeccionando los encabezados de respuesta. La URL del cliente original se rellena 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 regla de host.

• Una sola regla de host puede procesar varios nombres de host.

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

• Varias reglas de host pueden hacer referencia a un solo comparador de rutas.

• Una regla de host solo puede hacer referencia a un único elemento de coincidencia de ruta.

En el siguiente diagrama se ilustran estos puntos.

Relación entre la URL y el backend

Cada URL único se dirige a un solo servicio de backend o a un solo segmento de backend. Por lo tanto:

• Google Cloud usa la parte del nombre de host de una URL para seleccionar una sola regla de host y su matcher de ruta referenciado.

• Cuando usas reglas de ruta en un comparador de rutas, no puedes crear más de una regla de ruta para la misma ruta. Por ejemplo, las solicitudes de /videos/hd no se pueden dirigir a más de un servicio de backend o un segmento de backend. Los servicios de backend pueden tener grupos de instancias de backend o grupos de puntos finales de red (NEGs) de backend en diferentes zonas y regiones, y puedes crear segmentos de backend que usen clases de almacenamiento multirregionales.

  Para dirigir el tráfico de una URL única a varios servicios, puedes usar reglas de ruta en lugar de reglas de ruta. Si configura el buscador de rutas con reglas de ruta para las coincidencias de encabezado o de parámetro, se puede dirigir una URL única a más de un servicio backend o a un bucket, en función del contenido de los encabezados o de los parámetros de consulta de la URL.

  Del mismo modo, en el caso de los balanceadores de carga de aplicaciones externos regionales y Cloud Service Mesh, los servicios de backend ponderados de las acciones de ruta pueden dirigir la misma URL a varios servicios de backend o segmentos, en función de los pesos definidos en el servicio de backend ponderado.

Mapas y protocolos de URLs

Puede usar el mismo mapa de URLs, las mismas reglas de host y los mismos matchers de ruta para procesar las solicitudes HTTP y HTTPS enviadas por los clientes, siempre que tanto un proxy HTTP de destino como un proxy HTTPS de destino hagan referencia al mapa de URLs.

Mapa de URLs más sencillo

El mapa de URLs más sencillo solo tiene un servicio de backend predeterminado o un segmento de backend predeterminado. No contiene reglas de host ni comparadores de rutas. El servicio de backend predeterminado o el segmento de backend predeterminado (el que hayas definido) gestiona todas las URLs solicitadas.

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

Ejemplo de flujo de trabajo de un mapa de URLs con un balanceador de carga de aplicación externo

En el siguiente ejemplo se muestra el orden de las operaciones de un mapa de URLs. En este ejemplo, solo se configura el mapa de URLs de un balanceador de carga de aplicación clásico. Para simplificar los conceptos, solo usa servicios de backend, pero puedes sustituirlos por backend buckets. Para saber cómo crear los demás componentes del balanceador de carga, consulta Crear un balanceador de carga de aplicación clásico.

Para obtener más información sobre cómo crear y configurar mapas de URLs con matchers de ruta y reglas de host, consulta la gcloud compute url-maps create documentación.

1. Crea un mapa de URLs para el balanceador de carga y especifica un servicio de backend predeterminado. En este ejemplo se crea un mapa de URLs llamado video-org-url-map que hace referencia a un servicio de backend llamado org-site.

   gcloud compute url-maps create video-org-url-map \
       --default-service=org-site
   

2. Crea un comparador de rutas llamado video-matcher con las siguientes características:

   • El servicio de backend predeterminado es video-site, un servicio de backend que ya existe.
   • Añade reglas de ruta que dirijan las solicitudes de la ruta de URL exacta /video/hd o del prefijo de ruta de URL /video/hd/* a un servicio de backend llamado video-hd.
   • Añade reglas de ruta que dirijan las solicitudes de la ruta de URL exacta /video/sd o del prefijo de ruta de URL /video/sd/* a un servicio de backend 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
   

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

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

El mapa de URLs de video-org-url-map debería tener este aspecto:

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 URLs video-org-url-map dirige las URLs solicitadas a los back-ends de la siguiente manera.

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

Redirecciones de URL

Una redirección de URL redirige a los visitantes de tu dominio de una URL a otra.

Una redirección de URL predeterminada no depende de que se cumpla ningún patrón concreto en la solicitud entrante. Por ejemplo, puede usar una redirección de URL predeterminada para redirigir cualquier nombre de host al nombre de host que elija.

Hay varias formas de crear una redirección de URL, como se indica en la siguiente tabla.

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

• Toda la ruta de la solicitud se sustituye por la ruta que especifiques.

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

• Si usas defaultUrlRedirect, prefixRedirect es, en realidad, un prefijo que se añade al principio, ya que la ruta coincidente siempre es /.
• Si usas urlRedirect en una regla de ruta o una regla de ruta de acceso de un matcher de ruta de acceso, prefixRedirect es un prefijo de sustitución basado en cómo se ha encontrado la ruta de acceso solicitada tal como se define en la regla de ruta de acceso o en la regla de ruta.

Ejemplos de redirecciones

En la siguiente tabla se muestran algunos ejemplos de configuraciones de redirección. En la columna de la derecha se muestra la configuración de la API para una redirección de URL predeterminada.

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
           

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
          

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              pathRedirect: "/newPath"
           

            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 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 ?
   ...

Siguientes pasos

• Para añadir, validar, probar, enumerar o eliminar un mapa de URLs, consulta Usar mapas de URLs.

• Para obtener información sobre los mapas de reglas de enrutamiento con Cloud Service Mesh, consulta la información general sobre los mapas de reglas de enrutamiento de Cloud Service Mesh.