Azure Architect AZ-303 Lab - Application Load Balancing with Azure Application Gateways

 

Application Load Balancing with Azure Application Gateways

Introduction

Application Gateway Background

Azure Application Gateways are HTTP/HTTPS load balancing solutions, compared to Azure Load Balancers which are TCP/UDP load balancing solutions. Similar to Azure Load Balancers, Application Gateways can be configured with internet-facing IP addresses or with internal load balancer endpoints making them inaccessible via the internet. Application Gateways are ideal when you require:

• Web-based traffic in any of HTTP, HTTPS, or WebSocket protocols
• TLS/SSL offloading to improve utilization of backend by offloading encrypt/decrypt operations to the load balancer
• Built-in web application firewall (requires medium Application Gateway type or larger)
• Cookie affinity for sticky sessions

Azure application gateways can be configured using a variety of backends including plain VMs, Azure Web Apps, Azure Kubernetes Service (AKS), and Virtual Machine Scale Sets (VMSS).

Lab Scenario

In this Lab, you will use the Azure CLI to configure an application gateway to load balance traffic to a VMSS that you will deploy a web application to. VMSSs are sets of identically configured virtual machines (VM) referred to as instances in the VMSS. VMSSs can automatically scale the number of instances based on a variety of metrics. Instances are distributed across availability zones to provide fault tolerance in case of a major failure of a zone within a region. The Cloud Academy Lab environment includes several resources that you will need to learn about before configuring the Application Gateway. That is the purpose of the following instructions in this Lab Step. Although the Lab emphasizes the Azure CLI, feel free to explore the resources in the Portal whenever you like.

 

Instructions

1. List the virtual networks in the environment:

Copy code
# Set default location to WestUS2 where Lab resources are located
az configure --defaults location=westus2
az network vnet list --output table

There is a single virtual network named app that hosts web application resources. There is a single subnet that you will inspect next.

 

2. List the subnet in the app virtual network:

Copy code
resource_group=$(az group list --query [].name --output tsv)
az network vnet subnet list --resource-group $resource_group --vnet-name app --output table

The web contains the VMSS that will host the web application.

 

3. Query the subnet's network security group (NSG) ID:

Copy code
az network vnet subnet list --resource-group $resource_group --vnet-name app --query [].networkSecurityGroup.id --output tsv

The output will confirms that an NSG is associated with the subnet and that the NSG is named website-vmssnsg.

 

4. List the rules in the website-vmssnsg NSG:

Copy code
az network nsg rule list --resource-group $resource_group --nsg-name website-vmssnsg --output jsonc

The NSG has a single (non-default) rule that allows HTTP (Tcp destination port 80).

 

4. Page through the output of the VMSS by pressing spacebar after entering:

Copy code
az vmss list --output jsonc | more

The website-vmss has a capacity of 2 meaning that two VM instances are in the VMSS. Other properties to note are:

• "publicIpAddressConfiguration": null (meaning the instances cannot be reached via the internet)
• "networkSecurityGroup": null (meaning there is no additional NSG besides the one associated with the subnet)
• "offer": "CentOS" (meaning instances are running the CentOS distribution of Linux)
• "zones": ["1", "2"] (meaning the instances are spread across two availability zones in the region)

The instances are not currently running any web application. You will deploy one later.

 

Summary

In this Lab Step, you understood the challenges that an Application Gateway can solve. You also inspected the Lab environment to see the resources that were created when you started the Lab. The Lab environment resembles the following diagram:

You will configure an Application Gateway to load balance application traffic destined for the VMSS.

Introduction

Application Gateway Configuration

You will create all of the resources needed to load balance the VMSS traffic using an Application Gateway in this Lab Step. As Microsoft explains, an Application Gateway can be described by five configuration settings:

1. Backend server pool: The list of IP addresses of the backend servers. The IP addresses listed should either belong to the virtual network, but in a different subnet for the application gateway, or should be a public IP/VIP.
2. Backend server pool settings: Every pool has settings like port, protocol, and cookie-based affinity. These settings are tied to a pool and are applied to all servers within the pool.
3. Frontend port: This port is the public port that is opened on the application gateway. Traffic hits this port, and then gets redirected to one of the backend servers.
4. Listener: The listener has a frontend port, a protocol (HTTP or HTTPS), and the SSL certificate name (if configuring SSL offload).
5. Rule: The rule binds the listener and the backend server pool and defines which backend server pool the traffic should be directed to when it hits a particular listener. The rule can be either basic (round-robin) or path-based

When you first create an Application Gateway it includes an empty default backend pool for you to add addresses to. An Application Gateway must always have at least one backend pool.

Requirements

Assume that you have the following requirement for this Lab:

1. The web application must be accessible via the internet.
2. The web application uses HTTP and must be accessible on port 80.
3. The load balancing should not use sticky sessions/cookie-based affinity to promote equal load distribution to web application servers. (The web application is stateless meaning there is no benefit to sticky sessions.)
4. There is no need for a web application firewall (WAF).

Solution to Implement

The following bullets help explain the resources that need to be created to meet the requirements in the instructions of this Lab Step:

• The web application uses HTTP making Application Gateway preferred over Azure Load Balancers
• A public IP address is required for the Application Gateway's frontend to be accessible via the internet
• The VMSS instances do not have public IP addresses. This means that the Application Gateway must be in the same virtual network as the VMSS to reach it. However, the Application Gateway must be in a different subnet than the VMSS. Application Gateways always need to be in a subnet of their own.
• The requirements related to listener settings, such as listening on port 80, and backend pool settings, such as disabling cookie-based affinity, can be satisfied by setting appropriate options when creating the Application Gateway
• Because no WAF is required, the Application Gateway can be a standard small type to minimize costs. Medium size or greater is required for WAF types.

 

Instructions

1. Create a subnet in the app virtual network:

Copy code
az network vnet subnet create --resource-group $resource_group --vnet-name app \
                              --name app-gw --address-prefix 10.0.100.0/24

The output displays the JSON specification of the subnet. The address prefix is chosen to not overlap with the web subnet (10.0.0.0/24).

 

2. Create a public IP address for the Application Gateway frontend:

Copy code
az network public-ip create --resource-group $resource_group --name app-gw-ip \
                            --allocation-method Dynamic

The dynamic allocation method means that an IP address will be assigned when the public IP is associated with a resource. Static allocation can be used to reserve an address that won't change when it is not associated with a resource, for a cost. Currently the public IP is not associated so the ipAddress is null.

 

3. Read through the available configuration options for creating an Application Gateway and consider what options are needed to meet the requirements, pressing spacebar to advance the output:

Copy code
az network application-gateway create -h

The --cert-file and --cert-password options can be used to configure SSL offloading. In the description for the --sku option, there are Standard and WAF SKUs:

The v2 tiers support availability zones. Availability zones are a good idea for production, along with a --capacity of at least two to ensure a failure of one Application Gateway instance can be tolerated. For this Lab, a single small instance is sufficient.

 

4. Create an Application Gateway the satisfies the requirements:

Copy code
az network application-gateway create --resource-group $resource_group --vnet-name app --subnet app-gw \
                                      --name app-gw --capacity 1 --frontend-port 80 \
                                      --http-settings-cookie-based-affinity Disabled \
                                      --http-settings-port 80 --http-settings-protocol Http \
                                      --public-ip-address app-gw-ip --sku Standard_Small

The http-settings-port is the port that the Application Gateway uses to communicate with the backend pool. It also automatically sends probes on that port to monitor the health of backend pool instances, removing any that don't provide a healthy response to the probe.

Note that the --servers option is not used. Although you could specify a list of IP addresses it is better to separately configure the VMSS so that when the VMSS scales up or down, the Application Gateway will automatically be updated to include/exclude added/removed VMSS instances. You will do this in the next Lab Step.

The command takes around 17 minutes to complete. Please wait until this is completed to be able to pass the check and proceed with the next lab step.

 

Summary

In this Lab Step, you created several resources necessary to create an Application Gateway. The Application Gateway takes a long time to create, but once it is finished the Lab environment will resemble the following diagram:

Introduction

The VMSS is not running any web application yet. In this Lab Step, you will deploy a web application by running a custom script on the VMSS instances using a VMSS extension. Extensions are small applications that automate tasks on running instances. You will use a custom script extension that allows you to run an arbitrary script on the VMSS instances. The script you will use will install Docker and deploy an application that is packaged in a Docker image.

 

Instructions

1. Run a custom script that deploys a web application on the VMSS instances using an extension:

Copy code
az vmss extension set --vmss-name website-vmss --name customScript --resource-group $resource_group --version 2.0 --publisher Microsoft.azure.extensions --settings '{"fileUris": ["https://raw.githubusercontent.com/cloudacademy/azure-lab-provisioners/master/app-gw/deploy.sh"], "commandToExecute": "./deploy.sh"}'

Once the command finishes in a few minutes, it outputs the JSON specification of the VMSS. It includes the extension in the virtualMachineProfile.extensionProfile property:

The deploy script started a web application on the instances on port 80. The content of the script is below:

Copy code
#!/usr/bin/env bash
# Install and start Docker
yum install -y yum-utils device-mapper-persistent-data lvm2
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
yum install -y docker-ce-18.06.1.ce-3.el7
systemctl enable docker
systemctl start docker
# Run the web application and set the hostname environment variable
docker run -e hostname=$(hostname) -p 80:80 --restart always -d lrakai/tetris:hostname

You don't need to understand the details. Just know that Docker is being installed and a web application is being run using the docker run command on the last line.

 

Summary

In this Lab Step, you used a VMSS extension to deploy a web application to the instances. The Lab environment currently resembles the following diagram:

The instances are not accessible via the internet so you cannot access the application yet. In the next Lab Step, you will configure the VMSS to be in the backend pool of the Application Gateway. You will then be able to access the VMSS through the Application Gateway and have traffic load-balanced across VMSS instances.

Introduction

The Application Gateway currently has an empty backend pool. To access the web application through the Application Gateway you need to configure the VMSS to be in the backend pool. You will do that in this Lab Step. The configuration change actually needs to take place on the VMSS rather than the Application Gateway. This makes sense considering the VMSS knows when it scales up or down and can keep the backend pool up to date.

Note: You should wait until the Application Gateway has finished creating before moving on to the instructions of this Lab Step. You can wait until the Application Gateway provisioning completes by issuing

Copy code
az network application-gateway wait --resource-group $resource_group --name app-gw --created

The command prompt will be returned to you when the provisioning completes. While you wait, it is a good opportunity to explore the metrics and settings of the VMSS and the Application Gateway in the Azure Portal.

 

Instructions

1. In the Cloud Shell, Click PowerShell at the top left to expand the menu, then click Bash.

 

2. Click Confirm.

 

3. Inspect the network interface configuration of the VMSS:

Copy code
az configure --defaults location=westus2
resource_group=$(az group list --query [].name --output tsv)
az vmss show --resource-group $resource_group --name website-vmss \
             --query virtualMachineProfile.networkProfile.networkInterfaceConfigurations

The main properties to note are applicationGatewayBackendAddressPools and loadBalancerBackendAddressPools which are used to configure the VMSS in a backend pool for an Application Gateway or an Azure Load Balancer, respectively. As the property names suggest, there can be more than one of each type of backend pool. Because of this, the property values are lists. The elements in the lists are objects containing the ID of the backend pool.

 

4. Review the properties of the Application Gateway focusing on relevant backend address pool values:

Copy code
az network application-gateway show --resource-group $resource_group --name app-gw | more

The backendAddressPools[0].id is what you need to configure the VMSS backend pool.

 

5. Extract the backend pool ID and store it in a variable:

Copy code
backend_pool_id=$(az network application-gateway show --resource-group $resource_group --name app-gw --query backendAddressPools[0].id)

Now that you have the ID, it's a good time to review the different options available for updating with the Azure CLI. With the Azure CLI, when you need to update a property you can use the --set option with the following pattern --set property=value. The value can be an entire list when the property is a list type. For changes involving lists, you can also use --add and --remove to modify the list elements. If the elements are JSON objects, you specify the JSON string as the parameter to the --add or --remove option. In the case of updating the VMSS backend pool property, you could use either set or add because there is no risk of overwriting other pools when the value is currently null.

 

6. Update the VMSS backend pool configuration to reference the Application Gateway's default backend pool by ID:

Copy code
az vmss update --resource-group $resource_group --name website-vmss \
  --add virtualMachineProfile.networkProfile.networkInterfaceConfigurations[0].ipConfigurations[0].applicationGatewayBackendAddressPools "{'id':$backend_pool_id}"

The command uses --add to add an element to the (empty) list. The element is a JSON object with only an id property. The pattern for --add and --remove updates is --add/--remove property value.

The command outputs the latest JSON specification for the VMSS. You can verify that the applicationGatewayBackendAddressPools field is a list with the object you just added.

 

7. Get the public IP address associated with the Application Gateway frontend:

Copy code
az network public-ip show --resource-group $resource_group --name app-gw-ip --query ipAddress --output tsv

The output is the IP address.

 

8. Open a new web browser tab and navigate to the IP address:

The web application is displayed. Press spacebar if you'd like to test it out. The host line gives the name of the VMSS instance that is serving your HTTP request. In the image above the hostname is website-v000000.

 

9. Refresh your browser until you see the host website-v line change:

This confirms that the Application Gateway is load balancing traffic to the VMSS instances that are serving the web application.

Note: Your browser may cache the application for short periods causing the same host to appear. If you don't observe a change in the host after refreshing several times, you can try a different browser or private/incognito mode of your browser and refreshing with a few seconds delay between refreshes.

 

Summary

In this Lab Step, you configured the Application Gateway backend pool property of the VMSS to refer to the Application Gateway's default backend pool. This completed the requirements to enable the Application Gateway to load balance application traffic served by the VMSS. The Lab environment now resembles the following:

Note: It is possible to create a VMSS and Application Gateway in a single step. However, it is instructive to configure the backend pool after the VMSS is created to understand more about how it works and how to use the Azure CLI.