Descripción general de los mapas de URL

Google Cloud Los balanceadores de cargas de aplicaciones y Cloud Service Mesh usan un Google Cloud recurso de configuración llamado mapa de URL para enrutar solicitudes HTTP(S) a servicios de backend 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 :

Existen dos tipos de recursos de mapas de URL disponibles: global y regional.

  • Los urlMaps globales se utilizan en los balanceadores de cargas de aplicaciones externos globales, los balanceadores de cargas de aplicaciones clásicos, los balanceadores de cargas de aplicaciones internos entre regiones y Cloud Service Mesh.

  • regionUrlMaps se usan en los balanceadores de cargas de aplicaciones externos regionales, los balanceadores de cargas de aplicaciones internos regionales y Cloud Service Mesh.

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 Servicios de backend, buckets de backend
Balanceador de cargas de aplicaciones clásico EXTERNAL Global Servicios de backend, buckets de backend
Balanceador de cargas de aplicaciones externo regional EXTERNAL_MANAGED Regional Servicios de backend
Balanceador de cargas de aplicaciones interno entre regiones INTERNAL_MANAGED Global Servicios de backend
Balanceador de cargas de aplicaciones interno regional INTERNAL_MANAGED Regional Servicios de backend
Cloud Service Mesh INTERNAL_SELF_MANAGED Global Servicios de backend
Cloud Service Mesh INTERNAL_SELF_MANAGED Regional 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 aplicaciones de App Hub.

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 en general 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:

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

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

Nombres de los balanceadores de cargas

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

  • Google Cloud console Si creas un balanceador de cargas de aplicaciones con la consola deGoogle Cloud , el mapa de URL recibe automáticamente el mismo nombre que ingresaste para el balanceador de cargas.
  • Google Cloud CLI o API Si creas un balanceador de cargas de aplicaciones con la gcloud CLI o la API, ingresa el nombre que elijas cuando crees el mapa de URL. Luego, este nombre del mapa de URL se refleja en la consola deGoogle Cloud como el nombre del balanceador de cargas.

Para obtener información sobre cómo funciona la asignación de nombres para los balanceadores de cargas de red del proxy y los balanceadores de cargas de red de transferencia, consulta Descripción general de los servicios de backend: Asignación de nombres a los balanceadores de cargas.

Componentes del mapa de URL

Un mapa de URL es un conjunto de Google Cloud recursos de configuración que dirigen las solicitudes de URLs a servicios de backend 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 depósito 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 o coincide con expresiones regulares 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. Los diferentes balanceadores de cargas de aplicaciones controlan 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 se considera el nombre de host en la URL 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 depósito 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 queGoogle Cloud dirige las solicitudes de URLs cuyos nombres de host coinciden con una regla de host asociada al 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 mapean una ruta de URL a un solo servicio o bucket de backend.

      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), a través de una sintaxis de comodín. 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. Para obtener más información, consulta Comodines, expresiones regulares y URLs dinámicas en reglas de ruta de acceso.

      Si necesitas capacidades de enrutamiento más avanzadas, por ejemplo, si deseas dirigir el tráfico de una URL única a varios servicios, puedes usar reglas de enrutamiento en lugar de reglas de ruta de acceso.

    • Reglas de ruta. Las reglas de ruta se pueden usar como alternativa a las reglas de ruta de acceso cuando necesitas capacidades avanzadas de enrutamiento de tráfico, como el enrutamiento de tráfico basado en la ruta de URL, los encabezados HTTP y los parámetros de búsqueda.

      Puedes configurar reglas de rutas con operadores de coincidencia de patrones flexibles y variables con nombre. Estos operadores pueden ser útiles cuando necesitas enrutar el tráfico y ejecutar reescrituras en función de rutas de URL complejas. Para obtener más detalles, consulta Comodines y operadores de coincidencia de patrones en las plantillas de ruta de acceso para reglas de enrutamiento.

      También puedes configurar reglas de ruta para que coincidan con expresiones regulares que coincidan con la ruta, los parámetros de búsqueda o los encabezados de la solicitud entrante. Para obtener más información, consulta Expresiones regulares en reglas de rutas.

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.

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.

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 sola 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 búsqueda 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 predeterminado 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 URL 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).

Orden de las operaciones

Para un nombre de host y una ruta de acceso en una URL solicitada, Google Cloud usa el siguiente procedimiento para dirigir la solicitud al servicio o bucket de backend correcto, 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 de backend predeterminado del mapa de URL o al bucket de backend predeterminado, 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 coincida 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 Clouddirige 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 de backend predeterminado o al bucket de backend predeterminado del comparador de rutas de acceso, según el que hayas definido.

Restricciones de configuración del mapa de URL

En las siguientes secciones, se describen ciertas restricciones de configuración para los componentes del mapa de URL.

Comparadores de expresiones regulares en reglas de host y de ruta

Las reglas de host te permiten hacer coincidir la parte del nombre de host de una URL con el conjunto de nombres de host configurados de la regla de host. Puedes usar un nombre de host específico o un comodín * en el campo hostRules[].hosts[] para que coincida con el nombre de host de la solicitud entrante.

Las reglas de ruta te permiten definir reglas de coincidencia que pueden coincidir con una expresión regular en la ruta de acceso, en la cadena de consulta o en un encabezado de la solicitud entrante. Las reglas de ruta admiten el uso de expresiones regulares para los siguientes campos del mapa de URL:

  • pathMatchers[].routeRules[].matchRules[].regexMatch: Es una expresión regular que se usa para hacer coincidir la ruta de acceso de la solicitud entrante.
  • pathMatchers[].routeRules[].matchRules[].headerMatches[].regexMatch: Es una expresión regular que contiene un predicado que coincide con un encabezado de la solicitud entrante.
  • pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].regexMatch: Es una expresión regular que contiene un predicado que coincide con un parámetro de consulta de la solicitud entrante.

Se considera que una solicitud coincide con una routeRule cuando se cumple alguna de las matchRules. Sin embargo, los predicados dentro de un matchRule determinado tienen semántica de AND. Es decir, todos los predicados dentro de una matchRule deben coincidir para que la solicitud coincida con la regla.

Notas de uso adicionales:

  • Las expresiones regulares solo se admiten para los siguientes productos:

    • Balanceadores de cargas de aplicaciones internos regionales
    • Balanceadores de cargas de aplicaciones internos entre regiones
    • Balanceadores de cargas de aplicaciones regionales externos

    Los balanceadores de cargas de aplicaciones globales y clásicos no admiten expresiones regulares.

  • Debes usar la sintaxis RE2 para crear tus expresiones regulares. Para obtener la lista completa de limitaciones y operadores permitidos en los mapas de URL, consulta las especificaciones de RE2 para los mapas de URL.

  • La coincidencia de expresiones regulares es costosa en términos de consumo de memoria y latencias de procesamiento de solicitudes. Si eliges usar la coincidencia de expresiones regulares, debes tener en cuenta la degradación del rendimiento cuando planifiques tu implementación. Por ejemplo, si tienes un mapa de URL con una sola expresión regular, puedes esperar que la latencia del balanceador de cargas aumente en 100 microsegundos por solicitud. Si tu mapa de URL tiene 5 expresiones regulares que deben coincidir, puedes esperar que la latencia aumente en 200 microsegundos por solicitud.

Ejemplo 1: Usa una expresión regular para que coincida con la ruta

La ruta se considera una coincidencia si coincide con la expresión regular especificada por regexMatch después de quitar los parámetros de consulta y los anclajes proporcionados con la URL original. Por ejemplo, en los siguientes mapas de URL de muestra, la expresión regular de la regla de ruta, /videos/hd.*, se aplicaría a una URL con la ruta /videos/hd-abcd?key=245.

defaultService: projects/example-project/global/backendServices/org-site
name: rule-match-url-map
hostRules:
- hosts:
  - '*' # Match any host
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
pathMatchers:
- name: video-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/global/backendServices/video-site
  routeRules:
  - priority: 100000
    matchRules:
    - regexMatch: /videos/hd.*
    routeAction:
      weightedBackendServices:
      - backendService: projects/example-project/global/backendServices/video-hd
        weight: 100

A continuación, se incluye una explicación de cada campo del mapa de URL de ejemplo:

  • defaultService: Especifica el servicio de backend predeterminado que se usará si ninguna otra regla del mapa de URL coincide con la solicitud entrante.
  • name: Asigna el nombre rule-match-url-map a esta configuración del mapa de URL.
  • hostRules: Define una lista de reglas para hacer coincidir el encabezado del host de las solicitudes entrantes. La primera regla coincide con cualquier host (*) y dirige el tráfico al comparador de rutas de acceso pathMatcher llamado video-matcher. La segunda regla coincide específicamente con el host example.net y también dirige el tráfico al comparador de rutas de acceso llamado video-matcher.
  • pathMatchers: Define una lista de comparadores de rutas de acceso con nombre.
  • name: Define un comparador de rutas de acceso llamado video-matcher.
  • defaultService: Establece el servicio predeterminado para este comparador de rutas de acceso. Este servicio se usa si una solicitud coincide con las reglas de host que apuntan a video-matcher, pero no coincide con ninguno de los routeRules que contiene.
  • routeRules: Contiene una lista de reglas para hacer coincidir la ruta de URL.
  • priority: Establece la prioridad de esta regla en 100,000. Las reglas se evalúan en orden, desde el número de prioridad más bajo hasta el más alto.
  • matchRules: Contiene las condiciones para que coincida esta regla de ruta.
  • regexMatch: Esta condición verifica si la ruta de URL coincide con la expresión regular /videos/hd.* (por ejemplo, "/videos/hd" y "/videos/hd-caching").
  • routeAction: Especifica la acción que se debe realizar si se cumplen todas las condiciones en matchRules.
  • weightedBackendServices: Distribuye el tráfico entre una lista de servicios de backend según los pesos.
  • backendService: Especifica el servicio de backend al que se debe enrutar el tráfico.
  • weight: Asigna un peso de 100 a este servicio de backend. Como es el único servicio de la lista, recibirá el 100% del tráfico que coincida con este routeRule.

El siguiente mapa de URL muestra un ejemplo similar sin usar un routeAction.

defaultService: projects/example-project/global/backendServices/video-site
name: path-matcher-videos
routeRules:
  matchRules:
  - regexMatch: /videos/hd.*
  priority: 100000
  service: projects/example-project/global/backendServices/video-hd

Ejemplo 2: Usa una expresión regular para que coincida con los encabezados

El encabezado se considera una coincidencia si su valor coincide con la expresión regular especificada por regexMatch. Por ejemplo, en el siguiente mapa de URL de muestra, la expresión regular del nombre del encabezado, .*Android.*-hd, se aplicaría a una solicitud con el encabezado User-Agent:123Androidabc-hd.

defaultService: projects/example-project/regions/us-central1/backendServices/default-backend-service
name: header-match-url-map
hostRules:
- hosts:
  - '*'  # Match any host
  pathMatcher: header-matcher
pathMatchers:
- name: header-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/regions/us-central1/backendServices/default-backend-service
  routeRules:
  - priority: 1
    matchRules:
    - headerMatches:
      - headerName: User-Agent
        regexMatch: .*Android.*-hd
    # This prefix match applies to the path part of the URL
    - prefixMatch: /video/
    # service: can be used instead of routeAction if no other actions are needed
    service: projects/example-project/regions/us-central1/backendServices/video-backend-service
    # Alternatively, use routeAction to specify the service:
    # routeAction:
    #   weightedBackendServices:
    #   - backendService: projects/example-project/regions/us-central1/backendServices/video-backend-service
    #     weight: 100

A continuación, se incluye una explicación de cada campo del mapa de URL de ejemplo:

  • defaultService: Especifica el servicio de backend predeterminado que se usará si ninguna otra regla del mapa de URL coincide con la solicitud entrante.
  • name: Asigna el nombre header-match-url-map a esta configuración del mapa de URL.
  • hostRules: Define una lista de reglas para hacer coincidir el encabezado del host de las solicitudes entrantes. La regla coincide con cualquier host ("*") y dirige el tráfico al comparador de encabezados llamado pathMatcher.
  • pathMatchers: Define una lista de comparadores de rutas de acceso con nombre.
  • name: Define un comparador de rutas de acceso llamado header-matcher.
  • defaultService: Establece el servicio predeterminado para este comparador de rutas de acceso. Este servicio se usa si una solicitud coincide con la regla de host, pero no con ninguno de los routeRules dentro de este comparador de rutas de acceso.
  • routeRules: Contiene una lista de reglas para hacer coincidir las solicitudes entrantes según los encabezados y las rutas de acceso.
  • priority: Establece la prioridad de esta regla en 1. Las reglas se evalúan en orden, desde el número de prioridad más bajo hasta el más alto.
  • matchRules: Contiene una lista de condiciones que deben ser verdaderas para que la regla coincida.
  • headerMatches: Especifica condiciones basadas en los encabezados de la solicitud.
  • headerName: Busca el encabezado User-Agent.
  • regexMatch: Verifica si el valor del encabezado User-Agent coincide con la expresión regular .*Android.*-hd. Esto coincidiría con los User-Agents que indican un dispositivo Android, con una cadena que contiene "-hd".
  • prefixMatch: Si se establece en /video/, esta condición verifica si la ruta de URL comienza con "/video/".
  • service: Si se cumplen todas las condiciones de matchRules, el tráfico se dirige a este servicio de backend.
  • La sección routeAction comentada muestra una forma alternativa de especificar el servicio de backend, lo que sería necesario si tuvieras que configurar otras acciones de ruta, como reescrituras de URL, transformaciones de encabezado o servicios de backend ponderados.

Ejemplo 3: Usa una expresión regular para que coincida con los parámetros de búsqueda

El parámetro de consulta se considera una coincidencia si el valor de la ruta de acceso con los parámetros de consulta coincide con la expresión regular especificada por regexMatch. Por ejemplo, en el siguiente mapa de URLs de ejemplo, la expresión regular del parámetro de consulta, /im.*/.*.html, se aplicaría a una URL con parámetros de consulta como /images/random_page.html?param1=param_value_123abc-hd.

defaultService: projects/example-project/regions/us-central1/backendServices/sample-bs
name: query-match-url-map
hostRules:
- hosts:
  - '*'  # Match any host
  pathMatcher: query-matcher
pathMatchers:
- name: query-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/regions/us-central1/backendServices/sample-bs
  routeRules:
  - priority: 1
    matchRules:
    - queryParameterMatches:
      - name: param1   #parameter name in query
        regexMatch: param_value_.*-hd
    # This regexMatch applies to the path part of the URL
    - regexMatch: /im.*/.*.html
    # Directs traffic to this service if all conditions in matchRules are met
    service: projects/example-project/regions/us-central1/backendServices/sample-images-bs

A continuación, se incluye una explicación de cada campo del mapa de URL de ejemplo:

  • hostRules: Agrega una regla para que coincida con todos los hosts (*) y dirige el tráfico al pathMatcher llamado query-matcher.
  • pathMatchers: Define un comparador de rutas de acceso llamado query-matcher.
  • routeRules: Coloca el bloque routeRules proporcionado dentro de query-matcher.
  • priority: Establece la prioridad de esta regla en 1. Las reglas se evalúan en orden, desde el número de prioridad más bajo hasta el más alto.
  • matchRules: Contiene las condiciones para el routeRules.
  • queryParameterMatches: Verifica si el parámetro de búsqueda llamado "param1" coincide con la expresión regular param_value_.*-hd.
  • regexMatch: La expresión regular /im.*/.*.html se aplica a la ruta de acceso de la URL (por ejemplo, /images/random_page.html), antes de la cadena de consulta.
  • service: Especifica el servicio de backend que se usará si se cumplen todas las condiciones dentro de matchRules.

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

  • Una regla de ruta (pathMatchers[].pathRules[]) 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.

  • Una coincidencia de prefijo (pathMatchers[].routeRules[].matchRules[].prefixMatch) no trata * como un carácter comodín, sino como un carácter literal.

  • Los comparadores de rutas de acceso (y los mapas de URL en general) no ofrecen características que funcionen como la directiva <LocationMatch> de Apache. Si tienes una aplicación que genera 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:

  1. 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.
  2. 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.
  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.

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:

  1. 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.
  2. 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.

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. Si deseas obtener información para crear los demás componentes del balanceador de cargas, consulta Crea un balanceador de cargas de aplicaciones clásico.

Para obtener más información sobre cómo 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.

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

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

  3. 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, comparadores de rutas 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?