Azure | App Gateway - Tutorial de implantação e configuração

Neste tutorial vou-me focar apenas no Azure Aplication Gateway (App GW). Vou reaproveitar os backends criados neste tutorial - backend01 e backend02.

Para implantar o Azure Application Gateway há alguns componentes obrigatórios de configurar como os assinalados na figura seguinte:

Backend pools - Os anfitriões de backend para onde será encaminhado/balanceado o tráfego.

Backend settings - Configurações de acesso aos backend, por exemplo, o porto de rede, ssl (se tiver), etc.

Frontend IP configurations - O IP de entrada (inbound) do App Gw. Pode ser público ou não.

Listeners - Aceitam ligação de entrada com base no IP, porta de rede, e protocolo, direccionando estas ligações para o backend apropriado.

Rules - São regras que combinam os listeners e as configurações de backend de forma a encaminhar o trafego para o backendpool certo.

Health probes - É um mecanismo que verifica periodicamente o estado dos backends através de consultas http/https. O encaminhamento para cada um destes endpoints é feito tendo em conta o estado de saúde de cada um.

Ainda como requisito obrigatórios, a App GW precisa de uma subnet própria só para este efeito e um front end IP (publico, privado ou ambos),

Nas figuras seguintes podemos os vários passos do assistente de configuração do Application Gateway.

1. Configurações básicas

2. Configuração/criação do Frontend IP

3. Escolher o conjunto de backends que vão responder

Nota: Neste caso um pouco hipotético por ser um lab de testes, criei 2 backend pools apenas com uma VM cada.

 3.1. Figura já com os 2 backend adicionados.

4. Criar a regra de encaminhamento

Ao verificar a a figura abaixo, neste momento já temos o Frontend IP e os Backend pool. Falta adicionar uma regra de encaminhamento. Vamos criar a regra rule01 e rule02.

Durante a criação da regra temos de seleccionar ou criar um Listener para cada cada encaminhamento que se pretende fazer. Neste caso prático, criei 2 listeners no porto 80 para escutar o tráfego vindo para site1.20-238-134-187.nip.io e site2.20-238-134-187.nip.io. Portanto, iremos esperar tráfego destes dois sub-sites ou sub-dominios de 20-238-134-187.nip.io.

Nota: O nip.io é um serviço disponível na Internet em que podem usar o vosso IP público como se fosse um endereço de DNS. O IP público é convertido para um nome substituindo os pontos por traços (20.238.134.187 -> 20-238-134-187). É muito útil para fazer testes em laboratório, como este.

Continuando na regra que estamos a criar (por exemplo rule01), temos ainda de combinar qual o Backend pool (Backend target) que a regra vai usar. Para a rule01 usamos o backendpool01 e rule02 o backendpool02.

De notar que existem variadas configurações que podem fazer desde Multisite, encaminhar para um caminho (/site1 ou /site2), especificar um url para o caso de erros específicos como 502 ou 403, etc.

Depois de criar o App GW é testar se tudo funciona. Se estão a fazer testes no Azure, não se esquecem de eliminar todos os Resources depois de acabarem os testes, caso contrário vão ficar a consumir e a conta vai-vos chegar ao fim do mês :).

Caso encontrem algum erro, não se acanhem, comentem! :D