Vista geral dos mapas de URLs

Trusted Cloud by S3NS Os balanceadores de carga de aplicações e a malha de serviços na nuvem usam um Trusted Cloud recurso de configuração denominado mapa de URLs para encaminhar pedidos HTTP(S) para serviços de back-end ou contentores de back-end.

Por exemplo, com um balanceador de carga da aplicação externo, pode usar um único mapa de URLs para encaminhar pedidos para diferentes destinos com base nas regras configuradas no mapa de URLs:

• Os pedidos de https://example.com/video são encaminhados para um serviço de back-end.
• Os pedidos de https://example.com/audio são encaminhados para um serviço de back-end diferente.

• Os pedidos de qualquer outra combinação de anfitrião e caminho são encaminhados para um serviço de back-end predefinido.

Os mapas de URLs são usados com os seguintes Trusted Cloud produtos:

• Balanceador de carga de aplicações externo (modo regional)
• Balanceador de carga de aplicações interno (modo regional)

O mapa de URLs regional que usa depende do esquema de balanceamento de carga do produto.

Nem todas as funcionalidades do mapa de URLs estão disponíveis para todos os produtos. Os mapas de URLs usados com balanceadores de carga de aplicações externos regionais e balanceadores de carga de aplicações internos também suportam várias funcionalidades avançadas de gestão de tráfego. Para mais informações acerca destas diferenças, consulte o artigo Comparação de funcionalidades do equilibrador de carga: encaminhamento e gestão de tráfego.

Como funcionam os mapas de URLs

Quando um pedido chega ao balanceador de carga, este encaminha o pedido para um serviço de back-end específico.

Um serviço de back-end representa uma coleção de back-ends, que são instâncias de uma aplicação ou um microsserviço.

Para balanceadores de carga de aplicações externos regionais e balanceadores de carga de aplicações internos, os destinos possíveis são os seguintes:

• Serviço de back-end predefinido
• Serviço de back-end não predefinido

Por exemplo, suponha que tem a seguinte configuração:

• Um endereço IP:
  • Todos os pedidos à sua organização são enviados para o mesmo endereço IP e o mesmo equilibrador de carga.
  • O tráfego é direcionado para diferentes serviços de back-end com base no URL do pedido.
• Dois domínios:
  • example.net aloja vídeos de formação.
  • example.org aloja o Website da sua organização.
• Quatro conjuntos de servidores:
  • Um aloja o Website da sua organização (serviço de back-end: org-site).
  • Um aloja o Website de vídeo de formação geral (serviço de back-end: video-site).
  • Um aloja vídeos de formação em alta definição (HD) (serviço de back-end: video-hd).
  • Um aloja vídeos de formação em definição padrão (SD) (serviço de back-end: video-sd).

Quer que aconteça o seguinte:

• Pedidos para example.org (ou qualquer domínio que não seja example.net) para aceder ao serviço de back-end org-site.
• Pedidos para example.net que não correspondem a caminhos mais específicos para aceder ao serviço de back-end video-site.
• Pedidos para example.net/video/hd/* para aceder ao serviço de back-end video-hd.
• Pedidos para example.net/video/sd/* para aceder ao serviço de back-end video-sd.

Um --path-rule para /video/* corresponde a URIs como /video/test1 e /video/test2. No entanto, esta regra de caminho não corresponde ao caminho /video.

Se o balanceador de carga receber um pedido com /../ no URL, o balanceador de carga transforma o URL removendo o segmento do caminho antes de .. e responde com o URL transformado. Por exemplo, quando é enviado um pedido para http://example.net/video/../abc, o equilibrador de carga responde com um redirecionamento 302 para http://example.net/abc. Em seguida, a maioria dos clientes reage emitindo um pedido para o URL devolvido pelo balanceador de carga (neste caso, http://example.net/abc). Este redirecionamento 302 não é registado no Cloud Logging.

O mapa de URLs permite-lhe configurar este tipo de encaminhamento com base no anfitrião e no caminho.

Nomenclatura do balanceador de carga

Para balanceadores de carga de aplicações, o nome do balanceador de carga é sempre igual ao nome do mapa de URLs. O comportamento de cada Trusted Cloud interface é o seguinte:

• Trusted Cloud consola. Se criar um Application Load Balancer através da Trusted Cloud consola, o mapa de URLs é automaticamente atribuído ao mesmo nome que introduziu para o nome do balanceador de carga.
• CLI do Google Cloud ou API. Se criar um balanceador de carga de aplicações através da CLI gcloud ou da API, introduz um nome à sua escolha ao criar o mapa de URLs. Em seguida, este nome do mapa de URLs é refletido na consola doTrusted Cloud como o nome do balanceador de carga.

Para saber como funciona a nomenclatura dos balanceadores de carga de rede de proxy e dos balanceadores de carga de rede de passagem, consulte o artigo Vista geral dos serviços de back-end: nomenclatura do balanceador de carga.

Componentes do mapa de URLs

Um mapa de URLs é um conjunto de Trusted Cloud recursos de configuração que direcionam pedidos de URLs para serviços de back-end. O mapa de URLs faz isso através das partes hostname e path para cada URL que processa:

• Um nome do anfitrião é a parte do nome do domínio de um URL. Por exemplo, a parte do nome do anfitrião do URL http://example.net/video/hd é example.net.
• Um caminho é a parte de um URL que segue o nome do anfitrião e o número da porta opcional; por exemplo, a parte do caminho do URL http://example.net/video/hd é /video/hd.

Este diagrama mostra a estrutura dos objetos de configuração do equilíbrio de carga em relação uns aos outros.

Controla que serviços de back-end recebem pedidos recebidos através dos seguintes parâmetros de configuração do mapa de URLs:

• Serviço de back-end predefinido. Quando cria um mapa de URLs, tem de especificar um serviço de back-end predefinido. Esta predefinição representa o serviço de back-end para o qual Trusted Cloud direciona pedidos de URLs com qualquer nome de anfitrião, a menos que exista uma regra de anfitrião aplicável.

• Regra de anfitrião (hostRules). Uma regra de anfitrião direciona as solicitações enviadas para um ou mais nomes de anfitrião associados para um único localizador de caminhos (pathMatchers). A parte do URL referente ao nome de anfitrião é exatamente correspondida com o conjunto de nomes de anfitrião configurados da regra de anfitrião. Numa regra de anfitrião e caminho do mapa de URLs, se omitir o anfitrião, a regra corresponde a qualquer anfitrião pedido. Para direcionar pedidos para http://example.net/video/hd para um correspondente de caminhos, precisa de uma única regra de anfitrião que inclua, pelo menos, o nome do anfitrião example.net. Essa mesma regra de anfitrião também pode processar pedidos de outros nomes de anfitriões, mas direciona-os para o mesmo correspondente de caminho.

  Se precisar de direcionar pedidos para diferentes correspondências de caminhos, tem de usar regras de anfitriões diferentes. Duas regras de anfitrião num mapa de URLs não podem incluir o mesmo nome de anfitrião.

  É possível fazer corresponder todos os nomes de anfitrião especificando o caráter universal * na regra de anfitrião. Por exemplo, para os URLs http://example.org, http://example.net/video/hd e http://example.com/audio, todos os três nomes de anfitrião example.org, example.net e example.com podem ser correspondidos especificando * na regra de anfitrião. Também é possível fazer corresponder um nome de anfitrião parcial especificando o caráter universal *. Por exemplo, uma regra de anfitrião *.example.net é correspondida com os nomes de anfitrião news.example.net e finance.example.net.

  • Número da porta. Os diferentes equilibradores de carga de aplicações processam os números de porta de forma diferente. No caso do Application Load Balancer interno, pode usar o parâmetro Regra de anfitrião para especificar um número de porta. Por exemplo, para direcionar pedidos para a porta 8080, defina a regra de anfitrião como example.net:8080.

• Correspondência de caminhos (pathMatchers). Uma correspondência de caminhos é o parâmetro de configuração referenciado por uma regra de anfitrião. Define a relação entre a parte do caminho de um URL e o serviço de back-end que deve publicar o pedido. Um correspondente de caminho é composto por dois elementos:

  • Serviço de back-end predefinido do Path Matcher. Para cada correspondência de caminho, tem de especificar, pelo menos, um serviço de back-end predefinido. Esta predefinição representa o serviço de back-end para o qual Trusted Cloud direciona pedidos de URLs cujos nomes de anfitrião correspondem a uma regra de anfitrião associada ao matcher de caminhos e cujos caminhos de URL não correspondem a nenhuma regra de caminho no matcher de caminhos.

  • Regras do caminho. Para cada correspondência de caminho, pode especificar uma ou mais regras de caminho, que são pares de chave/valor que mapeiam um caminho de URL para um único serviço de back-end. A secção seguinte contém mais informações sobre o funcionamento das regras de caminho.

Ordem das operações

Para um determinado nome de anfitrião e caminho num URL pedido, Trusted Cloud usa o seguinte procedimento para direcionar o pedido para o serviço de back-end correto , conforme configurado no seu mapa de URLs:

• Se o mapa de URLs não contiver uma regra de anfitrião para o nome de anfitrião do URL, Trusted Cloud direciona os pedidos para o serviço de back-end predefinido do mapa de URLs , consoante o que tiver definido.

• Se o mapa de URLs contiver uma regra de anfitrião que inclua o nome do anfitrião do URL, consulta-se o localizador de caminhos referenciado por essa regra de anfitrião:

  • Se o matcher de caminhos contiver uma regra de caminho que corresponda exatamente ao caminho do URL, Trusted Cloud direciona os pedidos para o serviço de back-end para essa regra de caminho.

  • Se o matcher de caminhos não contiver uma regra de caminho que corresponda exatamente ao caminho do URL, mas contiver uma regra de caminho que termine em /* cujo prefixo corresponda à secção mais longa do caminho do URL, o Trusted Clouddireciona os pedidos para o serviço de back-end para essa regra de caminho. Por exemplo, para o mapa de URLs que contém duas regras de correspondência de caminhos /video/hd/movie1 e /video/hd/*, se o URL contiver o caminho exato /video/hd/movie1, é feita a correspondência com essa regra de caminho.

  • Se nenhuma das condições anteriores for verdadeira, Trusted Cloud direciona as solicitações para o serviço de back-end predefinido do Path Matcherpredefinido, consoante o que tiver definido.

Restrições do localizador de caminhos

Os nomes de anfitrião, os localizadores de caminhos e as regras de caminhos têm restrições.

Carateres universais, expressões regulares e URLs dinâmicos em regras de caminho

• Uma regra de caminho só pode incluir um caráter universal (*) após um caráter de barra invertida (/). Por exemplo, /videos/* e /videos/hd/* são válidos para regras de caminho, mas /videos* e /videos/hd* não são.

• As regras de caminho não usam expressões regulares nem correspondência de substring. PathTemplateMatch pode usar operadores de correspondência de caminhos simplificados. Por exemplo, as regras de caminho para /videos/hd ou /videos/hd/* não se aplicam a um URL com o caminho /video/hd-abcd. No entanto, uma regra do caminho para /video/* aplica-se a esse caminho.

• Os correspondentes de caminhos (e os mapas de URLs em geral) não oferecem funcionalidades que funcionam como as diretivas do Apache LocationMatch. Se tiver uma aplicação que gere caminhos de URL dinâmicos com um prefixo comum, como /videos/hd-abcd e /videos/hd-pqrs, e precisar de enviar pedidos feitos a esses caminhos para diferentes serviços de back-end, pode não conseguir fazê-lo com um mapa de URLs. Para casos que contenham apenas alguns URLs dinâmicos possíveis, pode criar um correspondente de caminho com um conjunto limitado de regras de caminho. Para casos mais complexos, tem de fazer a correspondência de expressões regulares baseada no caminho nos seus back-ends.

Carateres universais e operadores de correspondência de padrões em modelos de caminhos para regras de encaminhamento

Os operadores de correspondência de padrões flexíveis permitem-lhe fazer corresponder várias partes de um caminho de URL, incluindo URLs parciais e sufixos (extensões de ficheiros), através da sintaxe de carateres universais. Estes operadores podem ser úteis quando precisa de encaminhar tráfego e executar reescritas com base em caminhos de URL complexos. Também pode associar um ou mais componentes do caminho a variáveis com nomes e, em seguida, referir-se a essas variáveis ao reescrever o URL. Com as variáveis com nome, pode reordenar e remover componentes do URL antes de o pedido ser enviado para a sua origem.

A correspondência de padrões com carateres universais só é suportada para os seguintes produtos:

• Balanceador de carga de aplicações externo regional
• Balanceador de carga de aplicações interno regional

O exemplo seguinte encaminha o tráfego para uma aplicação de comércio eletrónico que tem serviços separados para informações do carrinho e informações do utilizador. Pode configurar routeRules com operadores de correspondência de padrões flexíveis e variáveis com nomes para enviar o ID exclusivo do utilizador para uma página de detalhes da conta de utilizador e as informações do carrinho do utilizador para um serviço de processamento de carrinhos após reescrever o 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

Veja o que acontece quando um cliente pede /xyzwebservices/v2/xyz/users/abc@xyz.com/carts/FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB, que tem informações do utilizador e informações do carrinho:

1. O caminho do pedido corresponde ao pathTemplateMatch no cart-matcher pathMatcher. A variável {username=*} corresponde a abc@xyz.com e a variável {cartid=**} corresponde a FL0001090004/entries/SJFI38u3401nms.
2. Os parâmetros de consulta são separados do caminho, o caminho é reescrito com base em pathTemplateRewrite e os parâmetros de consulta são anexados ao caminho reescrito. Só podemos usar as mesmas variáveis que usámos para definir o pathTemplateMatch no nosso pathTemplateRewrite.
3. O pedido reescrito é enviado para cart-backend com o caminho do URL reescrito: /abc@xyz.com-FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB.

Quando um cliente pede /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234, que tem apenas informações do utilizador e da conta, acontece o seguinte:

1. O caminho do pedido corresponde ao pathTemplateMatch no user-matcher pathMatcher. O primeiro * corresponde a abc%40xyz.com e o segundo * corresponde a abc-1234.
2. O pedido é enviado para user-backend.

A tabela seguinte descreve a sintaxe dos padrões de modelos de caminhos.

Quando usa estes operadores para a correspondência de padrões flexível, tenha em atenção as seguintes considerações:

• É possível combinar vários operadores num único padrão.
• Os parâmetros de consulta são separados do caminho, o caminho é reescrito com base em pathTemplateRewrite e os parâmetros de consulta são anexados ao caminho reescrito.
• Os pedidos não são normalizados com codificação em percentagem. Por exemplo, um URL com um caráter de barra invertida codificado em percentagem (%2F) não é descodificado para o formato não codificado.
• Cada nome de variável, como {segment} ou {region}, só pode aparecer uma vez no mesmo padrão. As variáveis múltiplas com o mesmo nome são inválidas e são rejeitadas.
• Os nomes das variáveis são sensíveis a maiúsculas e minúsculas e têm de ser identificadores válidos. Para verificar se um nome de variável é válido, certifique-se de que corresponde à expressão regular ^[a-zA-Z][a-zA-Z0-9_]*$.
  • {API}, {api} e {api_v1} são todos identificadores válidos. Identificam três variáveis distintas.
  • {1}, {_api} e {10alpha} não são identificadores válidos.
• Existe um limite de cinco operadores por padrão de modelo.

Para executar uma reescrita de URL opcional antes de o pedido ser enviado para a origem, pode usar as mesmas variáveis que definiu para capturar um caminho. Por exemplo, pode fazer referência, reordenar ou omitir variáveis no campo pathTemplateRewrite ao definir urlRewrite.

Quando usa variáveis e operadores para a correspondência de padrões flexível para reescritas de URLs, tenha em atenção estas considerações:

• Ao reescrever um URL, pode omitir variáveis se não forem necessárias como parte do URL reescrito.
• Antes de qualquer reescrita, pode identificar o URL enviado pelo cliente na sua origem inspecionando os cabeçalhos de resposta. O URL do cliente original é preenchido com o cabeçalho x-client-request-url e o cabeçalho x-envoy-original-path.

Relação entre o nome do anfitrião e a regra do anfitrião

• Um nome de anfitrião só pode referenciar uma regra de anfitrião.

• Uma única regra de anfitrião pode processar vários nomes de anfitriões.

Relação entre a regra de anfitrião e o correspondente de caminhos

• Várias regras de anfitrião podem fazer referência a um único localizador de caminhos.

• Uma regra de anfitrião só pode referenciar um único correspondente de caminho.

O diagrama seguinte ilustra estes pontos.

Relação entre o URL e o back-end

Cada URL exclusivo é direcionado para apenas um serviço de back-end. Consequentemente:

• Trusted Cloud usa a parte do nome do anfitrião de um URL para selecionar uma única regra de anfitrião e o respetivo correspondente de caminho referenciado.

• Quando usa regras de caminho num correspondente de caminho, não pode criar mais do que uma regra de caminho para o mesmo caminho. Por exemplo, os pedidos de /videos/hd não podem ser direcionados para mais do que um serviço de back-end. Os serviços de back-end podem ter grupos de instâncias de back-end ou grupos de pontos finais de rede (NEGs) de back-end em diferentes zonas e regiões.

  Para direcionar o tráfego de um URL exclusivo para vários serviços, pode usar regras de encaminhamento em vez de regras de caminho. Se configurar a correspondência de caminhos com regras de encaminhamento para correspondências de cabeçalhos ou parâmetros, um URL exclusivo pode ser direcionado para mais do que um serviço de back-end, com base no conteúdo dos cabeçalhos ou dos parâmetros de consulta no URL.

  Da mesma forma, para os Application Load Balancers externos regionais, os serviços de back-end ponderados nas ações de encaminhamento podem direcionar o mesmo URL para vários serviços de back-end, consoante as ponderações definidas no serviço de back-end ponderado.

Mapas de URLs e protocolos

Pode usar o mesmo mapa de URLs, regras de anfitriões e correspondências de caminhos para processar pedidos HTTP e HTTPS enviados pelos clientes, desde que um proxy HTTP de destino e um proxy HTTPS de destino referenciem o mapa de URLs.

Mapa de URL mais simples

O mapa de URLs mais simples tem apenas um serviço de back-end predefinido. Não contém regras de anfitrião nem correspondências de caminhos. O serviço de back-end ou o contentor de back-end predefinido(conforme o que definiu) processa todos os URLs pedidos.

Se definir um serviço de back-end predefinido, Trusted Cloud direciona os pedidos para os respetivos grupos de instâncias de back-end ou NEGs de back-end de acordo com a configuração do serviço de back-end.

Redirecionamentos de URL

Um redirecionamento de URL redireciona os visitantes do seu domínio de um URL para outro.

Um redirecionamento de URL predefinido não está condicionado à correspondência de nenhum padrão específico no pedido recebido. Por exemplo, é recomendável usar um redirecionamento de URL predefinido para redirecionar qualquer nome do anfitrião para um nome do anfitrião à sua escolha.

Existem várias formas de criar um redirecionamento de URL, conforme descrito na tabela seguinte.

Dentro de um defaultUrlRedirect ou urlRedirect, pathRedirect funciona sempre da seguinte forma:

• Todo o caminho do pedido é substituído pelo caminho que especificar.

Dentro de um defaultUrlRedirect ou urlRedirect, o funcionamento do prefixRedirect depende da forma como o usa:

• Se usar um defaultUrlRedirect, prefixRedirect é efetivamente um prefixo adicionado porque o caminho correspondente é sempre /.
• Se usar um urlRedirect numa regra de trajeto ou numa regra de caminho de um matcher de caminhos, prefixRedirect é uma substituição de prefixo com base na forma como o caminho pedido foi correspondido conforme definido na regra de caminho ou na regra de trajeto.

Exemplos de redirecionamentos

A tabela seguinte apresenta alguns exemplos de configurações de redirecionamento. A coluna do lado direito mostra a configuração da API para um redirecionamento de URL predefinido.

            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"
            

O fragmento parcial seguinte anota cada recurso da 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 ?
   ...

O que se segue?

• Para adicionar, validar, testar, listar ou eliminar um mapa de URLs, consulte o artigo Use mapas de URLs.