Compartilhar via

Regras de roteamento de solicitação do Gateway de Aplicativo

  • Artigo

Ao criar um gateway de aplicativo usando o portal do Azure, você criará uma regra padrão (rule1). Essa regra associa o ouvinte padrão (appGatewayHttpListener) ao pool de back-end padrão (appGatewayBackendPool) e às configurações HTTP do back-end padrão (appGatewayBackendHttpSettings). Depois de criar o gateway, você poderá editar as configurações da regra padrão ou criar novas regras.

Tipo de regra

Ao criar uma regra, você escolherá entre básica e baseada em caminho.

  • Escolha Básico se desejar encaminhar todas as solicitações no ouvinte associado (por exemplo, blog.contoso.com/*) para um só pool de back-end.
  • Escolha "Baseado em caminho" se desejar rotear as solicitações de caminhos de URL específicos para pools de back-end específicos. O padrão de caminho é aplicado somente ao caminho da URL, não aos seus parâmetros de consulta.

Ordem das regras de processamento

Para a SKU v1 e v2, a correspondência de padrões de solicitações de entrada é processada na ordem em que os caminhos são listados no mapa de caminho de URL da regra com base no caminho. Se uma solicitação corresponder ao padrão em dois ou mais caminhos no mapa de caminho, o caminho listado primeiro será correspondido. A solicitação é encaminhada para o back-end associado a esse caminho.

Se você tiver vários ouvintes, é ainda mais importante que as regras sejam processadas na ordem correta para que o tráfego do cliente seja recebido pelo ouvinte correto. Para obter mais informações sobre a ordem de avaliação de regras, consulte Ordem de avaliação de regras de roteamento de solicitação.

Ouvinte associado

Associe um ouvinte à regra para que a regra de roteamento de solicitação associada ao ouvinte seja avaliada para determinar o pool de back-ends para o qual a solicitação será roteada.

Pool de back-end associado

Associe à regra o pool de back-end que contém os destinos de back-end que atendem às solicitações recebidas pelo ouvinte.

  • Para uma regra básica, apenas um pool de back-end é permitido. Todas as solicitações no ouvinte associado são encaminhadas para esse pool de back-end.

  • Para uma regra baseada em caminho, adicione vários pools de back-end que correspondem a cada caminho de URL. As solicitações que correspondem ao caminho de URL inserido são encaminhadas para o pool de back-end correspondente. Além disso, adicione um pool de back-end padrão. As solicitações que não correspondem a nenhum caminho de URL na regra são encaminhadas para esse pool.

Configuração de HTTP de back-end associado

Adicione uma configuração de HTTP de back-end para cada regra. As solicitações são roteadas do gateway de aplicativo para os destinos de back-end usando o número da porta, o protocolo e outras informações especificadas na configuração.

Para uma regra básica, apenas uma configuração de HTTP de back-end é permitida. Todas as solicitações no ouvinte associado são encaminhadas para os destinos de back-end correspondentes usando essa configuração de HTTP.

Para uma regra baseada em caminho, adicione várias configurações de HTTP de back-end que correspondem a cada caminho de URL. As solicitações que correspondem ao caminho da URL nessa configuração são encaminhadas para os destinos de back-end correspondentes usando as configurações de HTTP que correspondem a cada caminho de URL. Além disso, adicione uma configuração de HTTP padrão. As solicitações que não correspondem a nenhum caminho de URL nessa regra são encaminhadas para o pool de back-end padrão usando a configuração de HTTP padrão.

Configuração de redirecionamento

Se o redirecionamento estiver configurado para uma regra básica, todas as solicitações no ouvinte associado serão redirecionadas para o destino. Esse é o redirecionamento global. Se o redirecionamento estiver configurado para uma regra baseada em caminho, somente as solicitações em uma área específica do site serão redirecionadas. Um exemplo é uma área de carrinho de compras que é denotada por /cart/*. Esse é o redirecionamento baseado em caminho.

Confira mais informações sobre redirecionamentos em Visão geral de redirecionamento do Gateway de Aplicativo.

Tipo de redirecionamento

Escolha o tipo de redirecionamento necessário: Permanente(301), Temporário(307), Encontrado(302) ou Consulte outro(303).

Destino de redirecionamento

Escolha outro ouvinte ou um site externo como destino de redirecionamento.

Ouvinte

Escolha o ouvinte como o destino de redirecionamento para redirecionar o tráfego de um ouvinte para outro no gateway. Essa configuração é necessária quando você deseja habilitar o redirecionamento de HTTP para HTTPS. Ele redireciona o tráfego do ouvinte de origem que verifica as solicitações HTTP de entrada para o ouvinte de destino que verifica as solicitações HTTPS de entrada. Você também pode optar por incluir a cadeia de caracteres de consulta e o caminho da solicitação original na solicitação que é encaminhada para o destino de redirecionamento.

Application Gateway components dialog box

Confira mais informações sobre o redirecionamento de HTTP para HTTPS em:

Site externo

Escolha site externo quando quiser redirecionar o tráfego no ouvinte associado a essa regra a um site externo. Você pode optar por incluir a cadeia de caracteres de consulta da solicitação original na solicitação que é encaminhada para o destino de redirecionamento. Não é possível encaminhar o caminho para o site externo que estava na solicitação original.

Confira mais informações sobre redirecionamento em:

Reescrever cabeçalhos HTTP e URL

Usando regras de reescrita, você pode adicionar, remover ou atualizar os cabeçalhos de solicitação e resposta HTTP(S), bem como o caminho da URL e os parâmetros da cadeia de caracteres de consulta, pois os pacotes de solicitação e resposta são movidos entre o cliente e os pools de back-end por meio do gateway de aplicativo.

Os cabeçalhos e os parâmetros de URL podem ser definidos para valores estáticos ou para outros cabeçalhos e variáveis de servidor. Isso ajuda com casos de uso importantes, como extração de endereços IP do cliente, remoção de informações confidenciais sobre o back-end, adição de mais segurança e assim por diante. Para saber mais, veja:

Próximas etapas