Configurar o Gateway de Aplicativo do Azure
um Gateway de Aplicativo do pool de back-end tem uma série de componentes que se combinam a fim de rotear solicitações para um pool de servidores Web e verificar a integridade deles.
Configuração de front-end
Você pode configurar o gateway de aplicativo para ter um endereço IP público, um endereço IP privado ou ambos. Um endereço IP público é necessário quando você hospeda um back-end que os clientes precisam acessar pela Internet por meio de um IP virtual voltado para a Internet.
Configuração de back-end
O pool de back-end é usado para encaminhar solicitações aos servidores back-end que atendem à solicitação. Você pode criar um pool de back-end vazio com o gateway de aplicativo e, depois, adicionar destinos de back-end a esse pool. Os destinos podem incluir NICs, endereços IP públicos e privados e conjuntos de dimensionamento de máquinas virtuais.
Configurar investigações da integridade
Por padrão, o Gateway de Aplicativo do Azure monitora a integridade de todos os recursos em seu pool de back-end e remove automaticamente qualquer recurso do pool que não for considerado íntegro. O Gateway de Aplicativo continua monitorando as instâncias não íntegras e as adiciona de volta ao pool de back-end íntegro depois que elas se tornarem disponíveis e responderem a investigações de integridade. Por padrão, o gateway de aplicativo envia as investigações de integridade na mesma porta que é definida nas configurações de HTTP do back-end. Uma porta de investigação personalizada pode ser configurada usando uma investigação de integridade personalizada.
O endereço IP de origem que o Gateway de Aplicativo usa para investigações de integridade depende do pool de back-end:
- Se o endereço do servidor no pool de back-end for um ponto de extremidade público, o endereço de origem será o endereço IP público de front-end do gateway de aplicativo.
- Se o endereço do servidor no pool de back-end for um ponto de extremidade privado, o endereço IP de origem será do espaço de endereço IP privado da sub-rede do gateway de aplicativo.
Investigação de integridade padrão
Um Gateway de Aplicativo configura automaticamente uma investigação de integridade padrão quando você não define nenhuma configuração de investigação personalizada. O comportamento de monitoramento funciona fazendo uma solicitação HTTP GET para os endereços IP ou FQDN configurados no pool de back-end. Para investigações padrão, se as configurações de HTTP de back-end estão configuradas para HTTPS, a investigação usa HTTPS para testar a integridade dos servidores back-end.
Por exemplo: Configure seu Application Gateway para usar os servidores de back-end A, B e C para receber o tráfego de rede HTTP na porta 80. O monitoramento de integridade padrão testa os três servidores a cada 30 segundos para concluir se uma resposta HTTP está íntegra com um tempo limite de 30 segundos para cada solicitação. Uma resposta de HTTP íntegra tem um código de status entre 200 e 399. Nesse caso, a solicitação HTTP GET para a investigação de integridade se parece com http://127.0.0.1/.
Se a investigação de verificação padrão falhar para o servidor A, o gateway de aplicativo para de encaminhar solicitações a esse servidor. A investigação padrão continua a verificar o Servidor A a cada 30 segundos. Quando o servidor A responde com êxito a uma solicitação de uma investigação de integridade padrão, o gateway de aplicativo começa a encaminhar as solicitações para o servidor novamente.
Configurações da investigação de integridade padrão
A tabela a seguir lista as configurações padrão da investigação de integridade:
| Propriedades da investigação | Valor | Descrição |
|---|---|---|
| URL de investigação | <protocol>://127.0.0.1:<port>/ |
O protocolo e a porta são herdados das configurações HTTP de back-end às quais a investigação está associada |
| Intervalo | 30 | A quantidade de tempo em segundos a esperar antes da próxima investigação de integridade é enviada. |
| Tempo limite | 30 | A quantidade de tempo em segundos o gateway de aplicativo aguarda uma resposta de investigação antes da marcação da investigação como não íntegro. Se uma investigação é retornada como íntegra, o back-end correspondente será imediatamente marcado como íntegro. |
| Limite não íntegro | 3 | Controla quantas investigações enviar caso ocorra uma falha da investigação de integridade regular. No SKU v2, as investigações de integridade aguardam pelo intervalo de tempo da investigação antes de verificar novamente. O servidor de back-end é marcado como inacessível após o número de falhas de investigações consecutivas atingir o limite de não integro. |
Intervalos de investigação
Todas as instâncias do Gateway de Aplicativo investiga o back-end independente um do outro. A mesma configuração de investigação se aplica a cada instância de Gateway de Aplicativo. Por exemplo, se a configuração de investigação é enviar as investigações de integridade a cada 30 segundos e o gateway de aplicativo tem duas instâncias, em seguida, ambas as instâncias de enviam a investigação de integridade a cada 30 segundos.
Se houver vários ouvintes, cada um investigará o back-end de modo independente dos outros.
Investigação de integridade personalizada
Investigações personalizadas fornecem um controle mais granular sobre o monitoramento de integridade. Ao usar investigações personalizadas, você pode configurar um nome do host personalizado, caminho de URL, intervalo de investigação e quantas respostas com falha devem ser aceitas antes de marcar a instância do pool de back-end como não íntegra.
Configurações da investigação de integridade personalizada
A tabela a seguir fornece definições para as propriedades de uma investigação de integridade personalizada.
| Propriedades da investigação | Descrição |
|---|---|
| Nome | O nome da investigação. Esse é o nome usado para identificar e se referir à investigação nas configurações de HTTP de back-end. |
| Protocolo | O protocolo usado para enviar a investigação. Essa propriedade precisa corresponder ao protocolo definido nas configurações de HTTP do back-end. |
| Host | O nome do host para enviar a investigação. |
| Caminho | O caminho relativo da investigação. Um caminho válido começa com "/." |
| Porta | Se definida, a propriedade será usada como a porta de destino. Caso contrário, ele usará a mesma porta que as configurações HTTP às quais está associado. Essa propriedade só está disponível no SKU v2. |
| Intervalo | Intervalo de investigação em segundos. Este valor é o intervalo de tempo entre duas investigações consecutivas |
| Tempo limite | Tempo limite da investigação em segundos. Se uma resposta válida não for recebida nesse período limite, a investigação será marcada como com falha. |
| Limite não íntegro | Contagem de repetições da investigação. O servidor de back-end é marcado após a contagem de falhas de investigação consecutivas atingir o limite de não íntegro. |
Correspondência de investigação
Por padrão, uma resposta HTTP(S) com código de status entre 200 e 399 é considerada íntegra. As investigações de integridade personalizadas também fornecem suporte a dois critérios correspondentes. Critérios de correspondência podem ser utilizados para, opcionalmente, mudar a interpretação padrão do que constitui uma resposta íntegra.
A seguir estão os critérios de correspondência:
- Correspondência de código de status de resposta HTTP - Critério de correspondência de teste para aceitar o código de resposta HTTP ou intervalos de códigos de resposta especificados pelo usuário. Códigos de status de resposta separados por vírgulas individuais ou um intervalo de código de status têm suporte.
- Correspondência do corpo da resposta HTTP - Critério de correspondência da análise que examina o corpo da resposta HTTP e corresponde a uma cadeia de caracteres especificada pelo usuário. A correspondência procura apenas a presença de uma cadeia de caracteres especificada pelo usuário no corpo da resposta e não é uma correspondência de expressão regular completa.
Os critérios de correspondência podem ser especificados usando o cmdlet New-AzApplicationGatewayProbeHealthResponseMatch.
Configurar ouvintes
Um ouvinte é uma entidade lógica que verifica as solicitações de conexão de entrada usando porta, protocolo, host e endereço IP. Ao configurar um ouvinte, você deverá inserir valores que correspondam aos valores na solicitação de entrada no gateway.
Ao criar um gateway de aplicativo usando o portal do Azure, você também escolhe o protocolo e a porta para criar um ouvinte padrão. Você pode escolher se deseja habilitar o suporte a HTTP2 no ouvinte. Depois de criar o Gateway de Aplicativo, você pode editar as configurações desse ouvinte padrão (appGatewayHttpListener) ou criar novos ouvintes.
Tipo de ouvinte
Ao criar um novo ouvinte, você deve escolher entre básico e multissite.
- Básico: Todas as solicitações são aceitas e encaminhadas para pools de back-end.
- Multissite: encaminhe solicitações para diferentes pools de back-end com base no cabeçalho de host ou nos nomes do host. Você deve especificar um nome de host que corresponda à solicitação de entrada.
Ordem de ouvintes de processamento
Para a SKU v1, a correspondência das solicitações são feitas de acordo com a ordem das regras e o tipo de ouvinte. Para a SKU v2, os ouvintes multissite são processados antes dos ouvintes básicos.
Endereço IP de front-end
Escolha o endereço IP de front-end que você planeja associar a este ouvinte. O ouvinte escuta as solicitações recebidas nesse endereço IP.
Porta de front-end
Escolha a porta de front-end. Selecione uma porta existente ou crie uma. Escolha qualquer valor do intervalo permitido de portas. Você pode usar não apenas portas bem conhecidas, como 80 e 443, mas qualquer porta personalizada que seja adequada. Uma porta pode ser usada para ouvintes voltados para o público ou para ouvintes de face privada.
Protocolo
Escolha HTTP ou HTTPS:
- HTTP: o tráfego entre o cliente e o Gateway de Aplicativo é não criptografado.
- HTTPS: habilita a terminação TLS ou a criptografia TLS de ponta a ponta. A conexão TLS é encerrada no gateway de aplicativo. O tráfego entre o cliente e o gateway de aplicativo é criptografado. Para habilitar a criptografia TLS de ponta a ponta, escolha HTTPS e defina a configuração de HTTP de back-end.
Para configurar a terminação TLS e criptografia TLS de ponta a ponta, você deve adicionar um certificado ao ouvinte para permitir que o Gateway de Aplicativo derive uma chave simétrica. A chave simétrica é usada para criptografar e descriptografar o tráfego do gateway. O certificado do gateway deve estar no formato PFX (Troca de Informações Pessoais). Esse formato permite exportar a chave privada que o gateway usa para criptografar e descriptografar o tráfego.
Visão geral do redirecionamento
Você pode usar o gateway de aplicativo para redirecionar o tráfego. O gateway tem um mecanismo de redirecionamento genérico que permite redirecionar o tráfego recebido em um ouvinte para outro ouvinte ou para um site externo. O redirecionamento simplifica a configuração do aplicativo e otimiza o uso de recursos. Os seguintes tipos de redirecionamento têm suporte:
- 301 Redirecionamento Permanente
- 302 Encontrado
- 303 Ver Outro
- 307 Redirecionamento Temporário
O suporte a redirecionamento do Gateway de Aplicativo oferece os seguintes recursos:
- Redirecionamento global: redireciona de um ouvinte para outro no gateway. Isso habilita o redirecionamento de HTTP para HTTPS em um site.
- Redirecionamento baseado em caminho: habilita o redirecionamento de HTTP para HTTPS somente em uma área de site específica, por exemplo, uma área de carrinho de compras indicada por /cart/*.
- Redirecionar para o site externo: requer um novo objeto de configuração de redirecionamento, que especifica o ouvinte ou o site externo de destino ao qual o redirecionamento é desejado. O elemento de configuração também dá suporte a opções para habilitar o acréscimo da cadeia de consulta e do caminho de URI à URL redirecionada. A configuração de redirecionamento é anexada ao ouvinte de origem por meio de uma nova regra.
Para obter mais informações sobre como configurar o redirecionamento no Gateway de Aplicativo, confira Redirecionamento baseado no caminho URL usando o PowerShell – Gateway de Aplicativo do Azure | Microsoft Learn.
Regras de roteamento de solicitação do Gateway de Aplicativo
Uma regra de roteamento de solicitação é um componente-chave de um gateway de aplicativo, pois determina como rotear o tráfego no ouvinte. A regra associa o ouvinte, o pool de servidores de back-end e as configurações de HTTP de backend.
Quando um ouvinte aceita uma solicitação, a regra de roteamento de solicitação encaminha a solicitação para o back-end ou a redireciona em outro lugar. Se a solicitação for encaminhada para o back-end, a regra de roteamento de solicitação define o pool de servidores back-end para o qual encaminhá-lo. A regra de roteamento de solicitação também determina se os cabeçalhos na solicitação devem ser reescritos. Um ouvinte pode ser anexado a uma regra.
Há dois tipos de solicitação de regra de roteamento:
Básico: Todas as solicitações no ouvinte associado (por exemplo, blog.contoso.com/*) são encaminhadas para o pool de back-end associado usando a configuração HTTP associada.
Com base no caminho: Essa regra de roteamento permite rotear as solicitações no ouvinte associado para um pool de back-end específico, com base na URL na solicitação. Se o caminho da URL em uma solicitação corresponder ao padrão de caminho em uma regra com base em caminho, a regra roteará essa solicitação. Ele aplica o padrão de caminho somente ao caminho da URL, não aos seus parâmetros de consulta. Se o caminho da URL em uma solicitação de ouvinte não corresponder a nenhuma das regras com base no caminho, ele roteia a solicitação para o pool de back-end padrão e as configurações de HTTP.
Configurações de HTTP
Um gateway de aplicativo roteia o tráfego para os servidores de back-end (especificados na regra de roteamento de solicitação que inclui as configurações de HTTP) usando o número da porta, o protocolo e outras configurações detalhadas neste componente.
A porta e o protocolo usados nas configurações de HTTP determinam se o tráfego entre o gateway de aplicativo e os servidores de back-end é criptografado (fornecendo TLS de ponta a ponta) ou não criptografado.
Esse componente também é usado para:
Determine se uma sessão de usuário deve ser mantida no mesmo servidor usando a afinidade de sessão baseada em cookie.
Remova normalmente os membros do pool de back-end usando o descarregamento de conexão.
Associe uma investigação personalizada para monitorar a integridade do back-end, defina o intervalo de tempo limite da solicitação, substitua o nome do host e o caminho na solicitação e forneça a facilidade de uma única seleção para especificar as configurações para o back-end do Serviço de Aplicativo.