Componentes do Gateway de Aplicativo

Um gateway de aplicativo serve como o único ponto de contato para clientes. Ele distribui o tráfego de aplicativo de entrada entre 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 de front-end

Um endereço IP de front-end é 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. Há suporte para um único endereço IP público ou privado em um Gateway de Aplicativo. Sua 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 de front-end é associado a um ouvinte.

Endereço IP público estático versus dinâmico

A SKU do Gateway de Aplicativo do Azure V2 pode ser configurado para dar suporte tanto ao endereço IP interno estático quanto ao endereço IP público estático ou somente ao endereço IP público estático. Ele não pode ser configurado para dar suporte apenas ao endereço IP interno estático.

A SKU v1 pode ser configurada para dar suporte ao endereço IP interno estático ou dinâmico e ao endereço IP público dinâmico. O endereço IP dinâmico do Gateway de Aplicativo do Azure não é alterado em um gateway em execução. Ele pode ser alterado somente quando você parar ou iniciar o gateway. Ele não é alterado 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 o nome DNS não muda, é recomendado usar um alias do CNAME e apontá-lo para o endereço DNS do Gateway de Aplicativo.

Ouvintes

Um ouvinte é uma entidade lógica que verifica as solicitações de conexão de entrada. Um ouvinte aceitará 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 anexados a um gateway de aplicativo e eles podem ser usados para o mesmo protocolo.

Depois que um ouvinte detecta 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 dão suporte às portas e aos protocolos a seguir.

Portas

Uma porta é onde um ouvinte escuta a solicitação do cliente. Você pode configurar portas para SKUs v1 e v2, conforme mostrado abaixo.

Protocolos

O Gateway de Aplicativo dá suporte aos protocolos Web HTTP, HTTPS, HTTP/2 e WebSocket com seu proxy de Camada 7. Os protocolos TLS e TCP têm suporte com seu proxy de Camada 4 (versão prévia) e podem ser configurados no mesmo recurso.

• Escolha entre os protocolos HTTP, HTTPS, TLS ou TCP na configuração do ouvinte.
• O suporte para os protocolos WebSockets e http/2 é fornecido nativamente, e o suporte ao WebSocket está habilitado por padrão. Não há nenhuma configuração configurável pelo usuário para habilitar ou desabilitar seletivamente o suporte ao WebSocket. Use Websockets com ouvintes HTTP e HTTPS.

Use um ouvinte HTTPS ou TLS para terminação de TLS. Um ouvinte HTTPS/TLS descarrega o trabalho de criptografia e descriptografia para o gateway de aplicativo, para que os servidores não sejam afetados pela sobrecarga de computação.

Páginas de erro personalizadas

O Gateway de Aplicativo permite que você crie páginas de erro personalizadas em vez de exibir páginas de erro padrão. Você pode usar sua própria identidade visual e layout em uma página de erro personalizada. O Gateway de Aplicativo do Azure exibirá uma página de erro personalizada quando uma solicitação não puder acessar o back-end.

Para obter mais informações, confira Páginas de erro personalizadas para o seu gateway de aplicativo.

Tipos de ouvintes

Há dois tipos de ouvintes:

• Básico. Esse tipo de ouvinte escuta um único site de domínio, em que ele tem um único mapeamento de DNS para o endereço IP do gateway de aplicativo. Essa configuração de ouvinte é necessária quando você hospeda um único site por trás de um gateway de aplicativo.

• Vários sites. A configuração desse ouvinte é necessária quando você deseja configurar o roteamento com base no nome do host ou no nome de domínio para mais de um aplicativo Web no mesmo gateway de aplicativo. Permite que você configure a topologia mais eficiente para suas implantações adicionando até mais de 100 sites a um gateway de aplicativo. Cada site pode ser direcionado para seu próprio pool 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 aplicativo. Você criaria três ouvintes com vários sites e configuraria cada ouvinte para as respectivas configurações de porta e protocolo.

  Você também pode definir nomes do host curinga em um ouvinte com vários sites e até cinco nomes do host por ouvinte. Para saber mais, confira nomes do host curinga em ouvinte.

  Para obter mais informações sobre como configurar um ouvinte multissite, consulte Hospedagem de vários sites no gateway de aplicativo usando portal do Azure.

Depois de criar um ouvinte, você o associa a uma regra de roteamento de solicitação. Essa 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 em que a porta de back-end, o protocolo, etc. são mencionados.

Regras de roteamento de solicitação

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 de HTTP associada.

• Com base 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 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.

Para obter mais informações, consulte Roteamento com base em URL.

Suporte a redirecionamento

A regra de roteamento de solicitação também permite que você redirecione o tráfego no gateway de aplicativo. Esse é um mecanismo de redirecionamento genérico; portanto, você pode redirecionar bidirecionalmente em qualquer porta definida usando regras.

Você pode escolher o destino de redirecionamento para outro ouvinte (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 Tráfego de redirecionamento com o seu gateway de aplicativo.

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 obter mais informações, confira Regravar cabeçalhos HTTP e URL em seu gateway de aplicativo.

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.

• Associar uma investigação personalizada para monitorar a integridade do back-end, definir o intervalo de tempo limite da solicitação, substituir o nome do host e o caminho na solicitação e fornecer uma facilidade de clique para especificar as configurações para o back-end do serviço de aplicativo.

Pools de back-end

Um pool de back-end roteia a solicitação para servidores de back-end, que atendem à solicitação. Os pools de back-end podem conter:

• NICs
• conjuntos de escala de máquina virtual
• Endereços IP públicos
• Endereço IP interno
• FQDN
• Back-ends de vários locatários (como o serviço de aplicativo)

Membros do pool de back-end do Gateway de Aplicativo 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, em data centers ou fora do Azure, contanto que haja conectividade IP.

Se você usa IPs internos como membros de pool de back-end, será necessário usar o emparelhamento de rede virtual ou um gateway de VPN. Emparelhamento VNet tem suporte e útil para o balanceamento de carga de tráfego em outras redes virtuais.

Um gateway de aplicativo também pode se comunicar com servidores locais quando eles estiverem conectados por túneis de VPN ou Azure ExpressRoute se o tráfego for permitido.

Você pode criar pools de back-end diferentes 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 para os microsserviços para seu aplicativo.

Depois de adicionar conjuntos de dimensionamento de máquinas virtuais como um membro do pool de back-end, será necessário atualizar instâncias de conjuntos de dimensionamento de máquinas virtuais. O back-end não estará íntegro até que você atualize instâncias de conjuntos de dimensionamento.

Investigações de integridade

Por padrão, um gateway de aplicativo monitora a integridade de todos os recursos em seu pool de back-end e remove automaticamente aqueles não íntegros. Em seguida, ele monitora instâncias não íntegras e as adiciona novamente ao pool de back-end íntegro quando elas se tornam disponíveis e respondem a investigações de integridade.

Além de usar o monitoramento da investigação de integridade padrão, você também pode personalizar a investigação de integridade para atender às necessidades do seu aplicativo. Investigações personalizadas permitem um controle mais granular sobre o monitoramento de integridade. Ao usar investigações personalizadas, você pode configurar um nome de host personalizado, caminho de URL, intervalo de investigação 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 investigações personalizadas para monitorar a integridade de cada pool de back-end.

Para obter mais informações, consulte monitorar a integridade do seu gateway de aplicativo.

Próximas etapas

Criar um Application Gateway:

• No portal do Azure
• Usando o Azure PowerShell
• Usando a CLI do Azure