Web Traffic Load Balancer - Create and configure an Application Gateway

To be continue…. from part-1

https://medium.com/@vijayyadavcloud/azure-application-gateway-9823b4e83f90

8. Demo

Exercise — Create and configure an Application Gateway

Application Gateway listens on an endpoint for incoming requests, and forwards these requests to one of the web servers in its back-end pool. You provide the configuration that describes how Application Gateway directs traffic, and how to load balance requests across web servers.

In the motor vehicle department system, you need to configure Application Gateway to load balance incoming requests across the web servers hosting the vehicle registration web app. You also need to configure Application Gateway to detect when either of the web servers has failed, so it can redirect traffic to a working server. Additionally, you need to configure path-based routing to send requests for the vehicle registration and license renewal sites to the proper back-end web services.

In this exercise, you’ll create an instance of Application Gateway with a back-end pool of web servers. You’ll verify that Application Gateway is configured with the correct listener to handle incoming HTTP requests, and routes these requests to a functioning web server.

1) Create Resource Group

RG=Demo-rg
az group create — name $RG — location southeastasia

If you need to find the location name, you can use the following command

az account list-locations -o table

2) Create Vnet and Subnet

az network vnet create
 — resource-group $RG
 — name vehicleAppVnet
 — address-prefixes 10.0.0.0/16
 — subnet-name webServerSubnet
 — subnet-prefixes 10.0.1.0/24

3) To download the script that creates the virtual machines, run the following command

git clone https://github.com/MicrosoftDocs/mslearn-load-balance-web-traffic-with-application-gateway module-files

4) To create and configure the virtual machines for the web servers, run the following commands. The virtual machines are called webServer1 and webServer2. Each virtual machine runs Ubuntu Server. An administrative user account is created for each virtual machine, with the login name azureuser. Each virtual machine has the vehicle registration web app installed.

The first command runs asynchronously to enable both virtual machines to be created simultaneously.

az vm create
 — resource-group $RG
 — name webServer1
 — image UbuntuLTS
 — admin-username azureuser
 — generate-ssh-keys
 — vnet-name vehicleAppVnet
 — subnet webServerSubnet
 — public-ip-address “”
 — nsg “”
 — custom-data module-files/scripts/vmconfig.sh
 — no-wait
az vm create
 — resource-group $RG
 — name webServer2
 — image UbuntuLTS
 — admin-username azureuser
 — generate-ssh-keys
 — vnet-name vehicleAppVnet
 — subnet webServerSubnet
 — public-ip-address “”
 — nsg “”
 — custom-data module-files/scripts/vmconfig.sh

5) To confirm both virtual machines were created successfully, run the following command.##

az vm list
 — resource-group $RG
 — show-details
 — output table

6) Create App Service and deploy the license renewal site

To start, to generate a unique name for the website, run the following command

APPSERVICE=”licenserenewal$RANDOM”

7) Next, to create the App Service plan the web app will use, run the following command.

az appservice plan create
 — resource-group $RG
 — name vehicleAppServicePlan
 — sku S1

8) Lastly, create the web app and deploy the license renewal site

az webapp create
 — resource-group $RG
 — name $APPSERVICE
 — plan vehicleAppServicePlan
 — deployment-source-url https://github.com/MicrosoftDocs/mslearn-load-balance-web-traffic-with-application-gateway
 — deployment-source-branch appService — runtime “DOTNETCORE|2.1”

9) Configure the network for Application Gateway

To create the private subnet required by Application Gateway, run the following command. The subnet is named appGatewaySubnet, in the vehicleAppVnet virtual network that you created in the previous exercise.

az network vnet subnet create
 — resource-group $RG
 — vnet-name vehicleAppVnet
 — name appGatewaySubnet
 — address-prefixes 10.0.0.0/24

To create a public IP address and DNS label for Application Gateway, run the following command. The DNS label must be globally unique. To generate a label, the following code uses the $RANDOM function.

az network public-ip create
 — resource-group ParseError: KaTeX parse error: Undefined control sequence: \ at position 4: RG \̲ ̲ — name appGat…{RANDOM}

10)Create an application gateway

Create an application gateway named vehicleAppGateway with the following configuration. A back-end pool containing the IP addresses of the web server virtual machines. A firewall that blocks malicious requests, such as those used by SQL Injection and Cross-Site Scripting attacks. A temporary listener that listens to port 8080, this will be replaced in a later step but is required for Application Gateway creation. A rule that routes (and load balances) these requests to the web servers in the back-end pool.

az network application-gateway create
 — resource-group $RG
 — name vehicleAppGateway
 — sku WAF_v2
 — capacity 2
 — vnet-name vehicleAppVnet
 — subnet appGatewaySubnet
 — public-ip-address appGatewayPublicIp
 — http-settings-protocol Http
 — http-settings-port 8080
 — private-ip-address 10.0.0.4
 — frontend-port 8080

Note

This command can take several minutes to complete

11) To find the private IP addresses of webServer1 and webServer2, run the following commands. You will save these to variables to use in the next command.

az vm list-ip-addresses
 — resource-group $RG
 — name webServer1
 — query [0].virtualMachine.network.privateIpAddresses[0]
 — output tsv

10.0.1.4

az vm list-ip-addresses
 — resource-group $RG
 — name webserver2
 — query [0].virtualMachine.network.privateIpAddresses[0]
 — output tsv

10.0.1.5

12) Next, we’ll add the back-end pools for each web site. First, create the back-end pool for the vehicle registration site running on virtual machines. Make sure that the IP addresses in the command below match the IP addresses that were output from the previous commands.

az network application-gateway address-pool create
 — gateway-name vehicleAppGateway
 — resource-group $RG
 — name vmPool
 — servers 10.0.1.4 10.0.1.5

To create a back-end pool for the license renewal site running on App Service, run the following command.

az network application-gateway frontend-port create
 — resource-group $RG
 — gateway-name vehicleAppGateway
 — name port80
 — port 80

For port 80, create a front-end port.

az network application-gateway frontend-port create
 — resource-group $RG
 — gateway-name vehicleAppGateway
 — name port80
 — port 80

To handle requests on port 80, create the listener.

az network application-gateway http-listener create
 — resource-group $RG
 — name vehicleListener
 — frontend-port port80
 — frontend-ip appGatewayFrontendIP
 — gateway-name vehicleAppGateway

13) Add a health probe

Create a health probe that tests the availability of a web server. The health probe runs every 15 seconds ( — interval 15), and sends an HTTP GET request to the root path of the web app. If the web app doesn’t respond within 10 seconds ( — timeout 10), the probe times out. The web server is marked as unhealthy if the probe fails three times in succession ( — threshold 3).

Because you’re using App Service as one of our back-ends, you will set the host header to the name of the App Service. Without this setting, the App Service won’t respond and will not show as healthy.

az network application-gateway probe create
 — resource-group $RG
 — gateway-name vehicleAppGateway
 — name customProbe
 — path /
 — interval 15
 — threshold 3
 — timeout 10
 — protocol Http
 — host-name-from-http-settings true

Next, to use the health probe you created, create the HTTP Settings for the gateway.

az network application-gateway http-settings create
 — resource-group $RG
 — gateway-name vehicleAppGateway
 — name appGatewayBackendHttpSettings
 — host-name-from-backend-pool true
 — port 80
 — probe customProbe

Configure path-baed routing

Now we need to configure path-based routing for our Application gateway. We’ll route requests to /VehicleRegistration/ to the vmPool and requests to /LicenseRenewal/ to the appServicePool. Any requests without any URL context will be routed to the vmPool as a default.

To create the path map for the vmPool, run the following command.

az network application-gateway url-path-map create
 — resource-group $RG
 — gateway-name vehicleAppGateway
 — name urlPathMap
 — paths /VehicleRegistration/*
 — http-settings appGatewayBackendHttpSettings
 — address-pool vmPool

To create the path map rule for the appServicePool, run the following command.

az network application-gateway rule create
 — resource-group $RG
 — gateway-name vehicleAppGateway
 — name appServiceRule
 — http-listener vehicleListener
 — rule-type PathBasedRouting
 — address-pool appServicePool
 — url-path-map urlPathMap

Now, create a new routing rule using the path map you created.

az network application-gateway rule create
 — resource-group $RG
 — gateway-name vehicleAppGateway
 — name appServiceRule
 — http-listener vehicleListener
 — rule-type PathBasedRouting
 — address-pool appServicePool
 — url-path-map urlPathMap

The last piece of configuration is to delete the rule that was created when we initially deployed the Application Gateway. With your custom rule in place, you no longer need it.

az network application-gateway rule delete
 — resource-group $RG
 — gateway-name vehicleAppGateway
 — name rule1

With everything set up, it’s time to test it out.

Test your Application Gateway

The final step is to test the application gateway and verify that it implements load balancing, and won’t attempt to direct traffic to a web server that is unavailable. We also want to ensure that our path-based routing is working correctly.

Test load balancing for the vehicle registration web app

In the Cloud Shell, run the following command to generate the root URL your Application Gateway.

echo http://$(az network public-ip show
 — resource-group $RG
 — name appGatewayPublicIp
 — query dnsSettings.fqdn
 — output tsv)
http://vehicleapp20796.southeastasia.cloudapp.azure.com

Using a web browser, navigate to the web site at the URL returned by the previous command. This is the address of your application gateway. Verify that the home page of the vehicle registration web app appears. Note the name of the web server that you’re using as shown in the footer (webServer1 or webServer2).

Click Refresh in the address bar of the web browser. Notice that your session should now be connected to a different web server. In this configuration, Application Gateway uses round-robin load balancing.

Click Register a Vehicle, enter the details of a vehicle, and then click Register.

Click Refresh a few more times. The requests should oscillate between servers.

Test the resilience of Application Gateway to a failed server##

In the Cloud Shell, run the following command to stop and deallocate the virtual machine for webServer1:

az vm deallocate
 — resource-group $RG
 — name webServer1

Return to the application in the web browser and click Refresh several times. Notice that the web browser now only connects to webServer2.

In the Cloud Shell window on the right, restart the webServer1 instance:

az vm start
 — resource-group $RG
 — name webServer1

Return to the web application in the web browser and click Refresh several times. You should see that the requests are now distributed across both web servers again.

[ Test path-based routing]

Now let’s test out the path-based routing. Recall that URLs to the root of the site and with /VehicleRegistration/ will be routed to the vmPool containing our VMs, and requests to /LicenseRenewal/ will be routed to the appServicePool containing our App Service.

You just confirmed that routing to the root page works, as you were able to pull up the vehicle registration page. Let’s try the other routes to confirm they work.

Now click Register a Vehicle in the web browser of the application gateway page. This should bring up the Vehicle Registration page for the vehicle registration site. With /VehicleRegistration/ in the URL, this routes to the vmPool where our vehicle registration site is running.

Now visit http:///LicenseRenewal/Create. This should take you to the license renewal page running on App Service. With /LicenseRenewal/ in the URL, this routes to the appServicePool where our license renewal site is running.

With this configuration, we can direct all users for both sites through our Application Gateway, giving them one root URL to remember. We can add additional sites as we expand our web presence.

Web application firewall We’ve also enabled the WAF on our Application Gateway. By doing this, we’ve automatically added security protection to both web sites. This provides a solid layer of protection from common vulnerabilities and helps protect our infrastructure and data.