Componentes do Gateway de Aplicação
Um gateway de aplicativo serve como o único ponto de contato para os clientes. Ele distribui o tráfego de entrada de aplicativos em vários pools de back-end, que incluem VMs do Azure, conjuntos de dimensionamento de máquinas virtuais, Serviço de Aplicativo do Azure e servidores locais/externos. Para distribuir o tráfego, um gateway de aplicativo usa vários componentes descritos neste artigo.
Endereços IP frontend
Um endereço IP frontend é o endereço IP associado a um gateway de aplicativo. Você pode configurar um gateway de aplicativo para ter um endereço IP público, um endereço IP privado ou ambos. Um gateway de aplicativo suporta um endereço IP público ou privado. A rede virtual e o endereço IP público devem estar no mesmo local que o gateway de aplicativo. Depois de criado, um endereço IP frontend é associado a um ouvinte.
Endereço IP público estático versus dinâmico
O SKU do Gateway de Aplicativo do Azure V2 pode ser configurado para dar suporte ao endereço IP interno estático e ao endereço IP público estático ou apenas ao endereço IP público estático. Não pode ser configurado para suportar apenas o endereço IP interno estático.
O SKU V1 pode ser configurado para suportar endereço IP interno estático ou dinâmico e endereço IP público dinâmico. O endereço IP dinâmico do Application Gateway não é alterado em um gateway em execução. Ele pode mudar somente quando você parar ou iniciar o Gateway. Ele não muda em falhas do sistema, atualizações, atualizações de host do Azure, etc.
O nome DNS associado a um gateway de aplicativo não é alterado ao longo do ciclo de vida do gateway. Como resultado, você deve usar um alias CNAME e apontá-lo para o endereço DNS do gateway de aplicativo.
Serviços de escuta
Um ouvinte é uma entidade lógica que verifica se há solicitações de conexão de entrada. Um ouvinte aceita uma solicitação se o protocolo, a porta, o nome do host e o endereço IP associados à solicitação corresponderem aos mesmos elementos associados à configuração do ouvinte.
Antes de usar um gateway de aplicativo, você deve adicionar pelo menos um ouvinte. Pode haver vários ouvintes conectados a um gateway de aplicativo e eles podem ser usados para o mesmo protocolo.
Depois que um ouvinte deteta solicitações de entrada de clientes, o gateway de aplicativo roteia essas solicitações para membros no pool de back-end configurado na regra.
Os ouvintes suportam as seguintes portas e protocolos.
Portas
Uma porta é onde um ouvinte escuta a solicitação do cliente. Você pode configurar portas para SKUs v1 e v2 conforme abaixo.
| SKU | Intervalo de portas suportado | Exceção(ões) |
|---|---|---|
| V2 | 1 a 64999 | 22 |
| V1 | 1 a 65502 | 3389 |
Protocolos
O Application Gateway suporta protocolos Web HTTP, HTTPS, HTTP/2 e WebSocket com seu proxy de Camada 7. Os protocolos TLS e TCP são suportados com seu proxy de camada 4 (visualização) e podem ser configurados no mesmo recurso.
Nota
O suporte ao protocolo HTTP/2 está disponível apenas para clientes que se conectam a ouvintes do gateway de aplicativo. A comunicação com pools de servidores back-end é sempre via HTTP/1.1. Por padrão, o suporte a HTTP/2 está desativado. Você pode optar por ativá-lo.
- Escolha entre os protocolos HTTP, HTTPS, TLS ou TCP na configuração do ouvinte.
- O suporte para WebSockets e protocolos HTTP/2 é fornecido nativamente, e o suporte a WebSocket é habilitado por padrão. Não existe qualquer definição configurável pelo utilizador para ativar ou desativar seletivamente o suporte de WebSocket. Use WebSockets com ouvintes HTTP e HTTPS.
Use um ouvinte HTTPS ou TLS para terminação TLS. Um ouvinte HTTPS/TLS descarrega o trabalho de criptografia e descriptografia para seu gateway de aplicativo, para que seus servidores não sejam sobrecarregados pela sobrecarga de computação.
Páginas de erros personalizadas
O Application Gateway permite criar páginas de erro personalizadas em vez de exibir páginas de erro padrão. Pode utilizar a sua própria imagem e esquema corporativos através de uma página de erro personalizada. O Application Gateway exibe uma página de erro personalizada quando uma solicitação não consegue chegar ao back-end.
Para obter mais informações, consulte Páginas de erro personalizadas para seu gateway de aplicativo.
Tipos de ouvintes
Existem dois tipos de ouvintes:
Basic. Esse tipo de ouvinte escuta um único site de domínio, onde tem um único mapeamento DNS para o endereço IP do gateway de aplicativo. Essa configuração de ouvinte é necessária quando você hospeda um único site atrás de um gateway de aplicativo.
Multi-site. Essa configuração de ouvinte é necessária quando você deseja configurar o roteamento com base no nome do host ou nome de domínio para mais de um aplicativo Web no mesmo gateway de aplicativo. Permite-lhe configurar uma topologia mais eficiente para as implementações ao adicionar até 100 sites a um gateway de aplicação. Cada site pode ser direcionado para o seu próprio agrupamento de back-end. Por exemplo, três domínios, contoso.com, fabrikam.com e adatum.com, apontam para o endereço IP do gateway de aplicação. Você criaria três ouvintes multissite e configuraria cada ouvinte para a respetiva configuração de porta e protocolo.
Além disso, pode definir nomes de anfitrião de caráter universal num serviço de escuta com vários sites e até cinco nomes de anfitrião por serviço de escuta. Para saber mais, consulte Nomes de host curinga no ouvinte.
Para obter mais informações sobre como configurar um ouvinte multissite, consulte Hospedagem de vários sites no Gateway de Aplicativo usando o portal do Azure.
Depois de criar um ouvinte, associe-o a uma regra de roteamento de solicitação. Esta regra determina como a solicitação recebida no ouvinte deve ser roteada para o back-end. A regra de roteamento de solicitação também contém o pool de back-end a ser roteado e a configuração HTTP onde a porta de back-end, protocolo, etc. são mencionados.
Pedir regras de encaminhamento
Uma regra de roteamento de solicitação é um componente fundamental de um gateway de aplicativo porque determina como rotear o tráfego no ouvinte. A regra vincula o ouvinte, o pool de servidores de back-end e as configurações HTTP de back-end.
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 para outro lugar. Se a solicitação for encaminhada para o back-end, a regra de roteamento de solicitação definirá para qual pool de servidores back-end encaminhá-la. A regra de roteamento de solicitação também determina se os cabeçalhos na solicitação devem ser reescritos. Um ouvinte pode ser ligado a uma regra.
Há dois tipos de regras de roteamento de solicitação:
Basic. 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.
Baseado em 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 da solicitação. Se o caminho da URL em uma solicitação corresponder ao padrão de caminho em uma regra baseada em caminho, a regra roteia 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 baseadas em caminho, ele roteia a solicitação para o pool de back-end padrão e as configurações HTTP.
Para obter mais informações, consulte Roteamento baseado em URL.
Suporte de redirecionamento
A regra de roteamento de solicitação também permite redirecionar o tráfego no gateway de aplicativo. Este é um mecanismo de redirecionamento genérico, para que você possa redirecionar de e para qualquer porta definida usando regras.
Você pode escolher o destino de redirecionamento para ser outro ouvinte (o que pode ajudar a habilitar o redirecionamento automático de HTTP para HTTPS) ou um site externo. Você também pode optar por fazer com que o redirecionamento seja temporário ou permanente, ou acrescentar o caminho do URI e a cadeia de caracteres de consulta à URL redirecionada.
Para obter mais informações, consulte Redirecionar o tráfego no gateway de aplicativo.
Rescrever cabeçalhos HTTP e URL
Usando regras de reescrita, você pode adicionar, remover ou atualizar cabeçalhos de solicitação e resposta HTTP(S), bem como parâmetros de caminho de URL e cadeia de caracteres de consulta à medida que os pacotes de solicitação e resposta se movem entre o cliente e os pools de back-end por meio do gateway de aplicativo.
Os cabeçalhos e parâmetros de URL podem ser definidos como valores estáticos ou para outros cabeçalhos e variáveis de servidor. Isso ajuda em casos de uso importantes, como extrair endereços IP de clientes, remover informações confidenciais sobre o back-end, adicionar mais segurança e assim por diante.
Para obter mais informações, consulte Reescrever cabeçalhos HTTP e URL no gateway de aplicativo.
Definições de HTTP
Um gateway de aplicativo roteia o tráfego para os servidores back-end (especificados na regra de roteamento de solicitação que incluem configurações 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 HTTP determinam se o tráfego entre o gateway de aplicativo e os servidores back-end é criptografado (fornecendo TLS de ponta a ponta) ou não criptografado.
Este 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 a drenagem de conexão.
Associe uma sonda 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 facilidade com um clique para especificar configurações para o back-end do Serviço de Aplicativo.
Conjuntos de back end
Um pool de back-end roteia a solicitação para servidores back-end, que atendem à solicitação. Os pools de back-end podem conter:
- NICs
- Conjuntos de dimensionamento de máquinas virtuais
- Endereços IP públicos
- Endereços IP internos
- FQDN
- Back-ends multilocatários (como o Serviço de Aplicativo)
Os membros do pool de back-end do Application Gateway não estão vinculados a um conjunto de disponibilidade. Um gateway de aplicativo pode se comunicar com instâncias fora da rede virtual em que está. Como resultado, os membros dos pools de back-end podem estar entre clusters, datacenters ou fora do Azure, desde que haja conectividade IP.
Se você usar IPs internos como membros do pool de back-end, deverá usar o emparelhamento de rede virtual ou um gateway VPN. O emparelhamento de rede virtual é suportado e benéfico para o tráfego de balanceamento de carga em outras redes virtuais.
Um gateway de aplicativo também pode se comunicar com servidores locais quando eles estão conectados por túneis do Azure ExpressRoute ou VPN, se o tráfego for permitido.
Você pode criar diferentes pools de back-end para diferentes tipos de solicitações. Por exemplo, crie um pool de back-end para solicitações gerais e, em seguida, outro pool de back-end para solicitações aos microsserviços de seu aplicativo.
Depois de adicionar conjuntos de dimensionamento de máquina virtual como um membro do pool de back-end, você precisa atualizar instâncias de conjuntos de dimensionamento de máquina virtual. Até que você atualize as instâncias dos conjuntos de escala, o back-end não estará íntegro.
Sondas do estado de funcionamento
Por padrão, um gateway de aplicativo monitora a integridade de todos os recursos em seu pool de back-end e remove automaticamente os não íntegros. Em seguida, ele monitora instâncias não íntegras e as adiciona de volta ao pool de back-end íntegro quando elas ficam disponíveis e respondem a testes de integridade.
Além de usar o monitoramento de teste de integridade padrão, você também pode personalizar o teste de integridade para atender aos requisitos do seu aplicativo. As sondas personalizadas permitem um controle mais granular sobre o monitoramento de integridade. Ao usar testes personalizados, você pode configurar um nome de host personalizado, caminho de URL, intervalo de teste e quantas respostas com falha aceitar antes de marcar a instância do pool de back-end como não íntegra, códigos de status personalizados e correspondência de corpo de resposta, etc. Recomendamos que você configure testes personalizados para monitorar a integridade de cada pool de back-end.
Para obter mais informações, consulte Monitorar a integridade do gateway de aplicativo.
Próximos passos
Crie um gateway de aplicativo: