Quizás es un servicio que de primeras pueda pasar desapercibido para los desarrolladores pero en realidad es uno de los necesarios una vez que tenemos el OK para salir a producción. Tal y como su nombre indica, Azure Application Gateway, se trata de un gateway o pasarela entre el usuario y tu aplicación y que te tiene diferentes cometidos:

1. Permite gestionar el tráfico a diferentes servidores de tu backend. Este servicio puede gestionar hasta 20 aplicaciones bajo un mismo DNS, con lo que puedes configurar a cuál de ellos quieres que se dirija basándose en reglas que tu definas.
2. También es un Web Application Firewall, con las opciones de detección o prevención dependiendo en la fase en la que estés.
3. Terminador SSL, para que puedas cifrar las peticiones antes de que lleguen a tu backend y descifrarlas cuando vuelvan al usuario, haciendo que App Gateway sea el que soporte la carga del cifrado y descifrado.
4. Redireccionador de peticiones. Comúnmente se utiliza para redireccionar de HTTP a HTTPs pero es posible cualquier redireccionamiento.
5. Afinidad de sesión con el servidor.
6. Compatibilidad nativa con HTTP2 y Websocket.

Como ves, Application Gateway tiene diferentes opciones con las que puedes gestionar y proteger tus aplicaciones. Estas pueden estar en máquinas virtuales, App Service, detrás de un FQN o incluso una IP, por lo que no te limita a un escenario concreto.

Antes de empezar es importante tener en cuenta algunos puntos:

• Application Gateway tiene que estar obligatoriamente en una virtual network.
• Lo ideal es que los servicios a los que se accede a través de Application Gateway deben formar parte de dicha virtual network para que nuestro gateway sea el único punto de entrada a nuestras aplicaciones.

Para crear el servicio basta con acceder al portal de Azure (también es posible generarlo a través de PowerShell y CLI, pero para empezar creo que siempre es más sencillo el portal) y seleccionar Create a resource y escribir en la búsqueda Application Gateway.

Necesitarás un nombre para tu servicio (en este caso lo he llamado App-Gateway), un grupo de recursos y una ubicación. El siguiente paso será crear o elegir la red virtual en la que se alojará y algunos valores que serán suficientes con los que vienen por defecto por ahora. Para que sea más sencillo para ti, elige un DNS name label para formar la URL de acceso a App Gateway.

La creación tardará unos minutos. Una vez terminado aparecerá el blade de App Gateway con algunas secciones nuevas para ti (Backend pools, HTTP Settings, Listeners y Rules), por lo que es importante conocer bien estos conceptos y el rol de cada uno de ellos:

• Backend pools: se trata de los conjuntos de servidores a los que vamos a redirigir el tráfico si se cumple alguna de las reglas establecidas o bien si el WAF lo permite.
• HTTP settings: Se trata de la configuración que va a permitir acceder a un servidor, o conjunto de servidores, del backend pool. Básicamente se utiliza para saber cuál es el puerto que mi aplicación tiene abierto para la comunicación y la ruta de la misma.
• Listeners: a diferencia del anterior nos va a permitir definir cuál es el puerto y la ruta a la que debemos acceder de App Gateway para verificar una regla en concreto.
• Rules: son las reglas que determinan a qué backend pool (a qué aplicación) se va a acceder siempre y cuando se cumpla.

Podríamos pintar la relación entre los diferentes conceptos de la siguiente manera:

Para verlo con un ejemplo vamos a crear una VM que nos haga de servidor web a través del puerto 80 y que desde Application Gateway accedamos a ella según la secuencia anterior.

Antes de crear tu VM necesitas añadir una nueva subnet dentro de la virtual network que se generó cuando creaste tu Application Gateway:

No puede estar en la misma subnet que el Application Gateway por lo que crearemos una nueva llamada backend.

Ahora haz clic en New y selecciona Window Server 2016 VM:

No olvides incluir dicha máquina en la subnet backend creada anteriormente. Habilita también el puerto de RDP para poder acceder después a ella.

Una vez finalizada la creación podemos comprobar que tanto App Gateway como la nueva máquina virtual están en la misma VNet, pero en diferentes subnets, en el servicio virtual network creado dentro del grupo de recursos:

Para instalar Internet Information Services la forma más sencilla es lanzando el siguiente comando desde el Cloud Shell:

Set-AzureRmVMExtension `
  -ResourceGroupName Blog-App-Gateway `
  -ExtensionName IIS `
  -VMName webserver `
  -Publisher Microsoft.Compute `
  -ExtensionType CustomScriptExtension `
  -TypeHandlerVersion 1.4 `
  -SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server; powershell Add-Content -Path \"C:\\inetpub\\wwwroot\\Default.htm\" -Value $($env:computername)"}' `
  -Location "North Europe"

Una vez que tenemos desplegada la VM e instalado IIS, ya que no tenemos habilitado el puerto 80 en el firewall de Azure (y no debemos, que sino pierde toda la gracia ;)), podemos acceder a ella a través de RDP para asegurarnos que nuestro servidor web está funcionando correctamente.

Si copiamos la IP de la máquina virtual en el navegador comprobaremos que no tenemos acceso a la aplicación web, ya que no está expuesto el puerto 80 a través de la pestaña Networking.

Ahora vamos a configurar Application Gateway para que nos permita el acceso a dicha web.

Añadir la máquina virtual a un backend pool

El primer paso es añadir dicha máquina virtual a un backend pool. Ya tenemos creado uno por defecto, appGatewayBackendPool en la sección backend pools. Hacemos clic sobre el mismo y utilizamos la opción virtual machines para elegir nuestra máquina y guardamos los cambios.

HTTP Setting

En el apartado HTTP Settings no es necesario modificar nada ya que el valor que viene por defecto apunta al puerto 80, que es donde está escuchando nuestro servidor web. Imagina que tienes diferentes aplicaciones dentro del mismo servidor y tu aplicación está escuchando por el puerto 8090. En ese caso el HTTP Setting asociado debería de utilizar dicho puerto para poder comunicarse con la aplicación que se pretende servir.

Si accedemos a la configuración de appGatewayBackendHttpSettings veremos que tenemos diferentes opciones a configurar:

• Cookie based affinity para poder habilitar la afinidad con el servidor del backend ya que podemos tener más de un servidor en un backend pool.
• Connection draining nos permite que las conexiones que estén activas se completen antes de que el servidor sea retirado del backend pool, pero no permite que se realicen nuevas conexiones con este.
• Protocol: Podemos elegir el protocolo, que en este caso lo dejaremos en HTTP,
• Port: El puerto que es el 80
• Use custom probe: podemos incluso especificar una sonda personalizada que verifique que el backend está funcionando correctamente.
• Request timeout: tiempo de respuesta del backend máximo antes de que sea timeout.

Los valores por defecto son suficientes para este ejemplo.

HTTP Listener

Accedemos ahora al apartado Listeners donde debemos indicar cómo vas a acceder a tu web desde tu Application Gateway. Existen dos tipos de listener: basic y multi-site. El basic simplemente te permite indicar por qué puerto vas a acceder al backend pool. Para este ejemplo mantendremos el listener generado durante la creación del Application Gateway (appGatewayHttpListener) que utiliza el puerto 80 del servicio para la escucha.

El multi-site se utiliza cuando queremos configurar dominios desde los cuales podemos acceder también al gateway. Como ves, en el listener aparece asociada una regla, rule1, la cual se indica en el último apartado: Rules.

Definir la regla

Para finalizar, es necesario definir una regla que puede ser de dos tipos: basic o path base.

Ya existe una regla por defecto llamada rule1 que es de tipo básica, que únicamente conecta el listener del apartado anterior con el backend pool generado por defecto, además del http setting que especifíca cómo debe acceder a dicho backend pool:

Para cada regla debe existir un listener disponible, es decir que no esté mapeado con ninguna otra regla.

Esta es la configuración más sencilla que puedes tener en Application Gateway, pero sirve para comprender cada una de sus piezas y cómo se conectan unas con otras.

Para comprobar el resultado, accede al apartado Overview y copia el DNS asignado a tu Application Gateway (en mi caso my-appgw.northeurope.cloudapp.azure.com):

Si todo ha sido configurado correctamente deberías poder ver el sitio web, a través de Azure Application Gateway.

¡Saludos!