09 - Hands-on Labs¶

The goal of these labs will be to tie together concepts from the earlier sections as they would relate to deploying a functional cloud-first application in Azure. The application will be a weather app that displays information about a city's weather. It will do this by doing an API call to a weather service.

Warning

While an effort has been made to ensure the resources suggested in these labs are no cost or zero cost, there will be cases were some do cost money to run. Ensure that resources are destroyed when not in use, and be aware of the cost implications of what is provisioned

Lab Architecture¶

This lab will deploy a 2-tier application (web layer and API layer) with private networking. This is a common design pattern and will cover areas such as:

Configuring a network that can support private networking
Configuring resources for private networking
Using Managed Identity for inter-resource access
Configure monitoring and observability using Azure-native tools

Lab 00 - Resource Group¶

Create a Resource Group in a Subscription that will contain the lab resources

Lab 01 - Monitoring¶

Log Analytics Workspaces are the resource designed for storing logs generated by other resources. Application Insights is a visualisation resource that consumes this log data and displays information to assist troubleshooting an application.

Create a Log Analytics Workspace

Cost Implication

Log Analytics Workspaces have a consumption based cost model. Consumption is based on logs that are ingested, with Analytic logs being the most expensive at $4.85AUD/GB. The volume of logging from this lab should be only a few megabytes

Create an Application Insights instance that uses the Log Analytics Workspace previously created

Lab 02 - Networking¶

Create a virtual network and subnets
The default address space will be 10.0.0.0/16. Typically ranges will be much smaller. For this lab, set it to a /24 range
The lab will require two subnets - one for private endpoints and one for virtual network integration
The smallest allowed subnet size for private endpoints is /28. Likewise, virtual network integration requires a subnet size of at least /27

Subnet Calculators

There are numerous online calculators that can assist with designing subnets. https://visualsubnetcalc.com/ supports both Azure and AWS subnetting

Private subnet by default

Subnets created after 31 March 2026 will default to being a private subnet. This means they will not have default outbound access. The API subnet will require outbound access so this private subnet setting should not be used

Lab 03 - Key Vault¶

There are some values that need to be made available to the application such as the API key for the weather service. While this could be added as an environment variable directly on the application, it would be more appropriate to store it in Key Vault

Create a Key vault resource
Configure the Key Vault for a private endpoint
Add the API key value

Lab 04 - Compute & Storage¶

The application will have an API component and a web component. The lab will follow a standard pattern of using an Azure Function App for the API and an App Service for the website
Both Function Apps and App Services need an App Service Plan to provide compute capacity to run.

Create App Service Plan¶

Create an App Service Plan with the Operating System set to Linux and Plan set to Basic B1

Cost Implications

While there is a free plan option (Free F1) it doesn't support vNet integration. The Basic B1 plan is the cheapest option that supports this feature. It has a cost of $13.14USD per month. The Operating System selection can also affect prices, Windows App Service Plans typically cost twice that of Linux plans

Create Function App Storage¶

Function Apps are a server-less hosting option. Because they are server-less, they have no default storage and require a separate Storage Account.
The Storage Account type needs to support Blob, Queue and Table storage
To ensure the Storage Account meets the priate networking requirement, it will have to be configured with private endpoints. Each Storage service will need an endpoint, so there will be 4 in total

Storage Account Naming

Storage Accounts have different naming rules compared to other Azure resources. The most important of these are names can only have letters and numbers (no hyphens), be between 3 and 24 characters and be unique across all subscriptions. This means common names are often used

Create Function App¶

The new wizard experience for creating a Function App via the portal will start with a prompt listing several types. To be able to use the App Service Plan created earlier, select the App Service option
A Function App can use Windows or Linux as it's Operating System. To use the App Service Plan created earlier, select Linux
The Runtime Stack should align with the type of code that will be deployed. In this lab, the application will be in Python so select Python
In the Network tab, it's possibly to configure private networking at provisioning time, or this can be configured after
On the Monitoring tab, select the Application Insights instance that was previously created
In the Authentication tab, set the Authentication type to Managed Identity

Create App Service¶

The Basic settings for creating an App Service are similar to Function Apps
On the Network tab, it's possible to configure private networking. For the App Service, Virtual Network Integration needs to be configured
On the Monitoring tab, configure the App Service to use the Application Insights instance that's already been created

Lab 05 - DevOps¶

In this lab, Azure DevOps will be used to store and deploy code.

Create a Service Connection¶

A Service Connection is an authenticated link between Azure DevOps and another service, such as Azure resources, Github etc. In this case of this lab, to be able to deploy the code to the Function App and App Service, an appropriate Service Connection needs to be used.

Create a new project in Azure DevOps (name it azure-lab or something similar)
Initialise the default repo in the project
Go to Project Settings -> Service Connections
Click on the Create Service Connection button
Select Azure Resource Manager and click Next

Service Connection Identity Naming

If you set the Identity type to App Registration (automatic) the name of the App Registration will be auto-generated using the DevOps Organisation name and Project name. This can lead to duplicate names if multiple Service Connections are created. For this lab, this shouldn't be an issue

Set the Subscription and Resource Group to match the lab environment, give it a name and click Save

Add Code to Repo¶

Create a Build/Test Pipeline¶

While it's possible to deploy code directly off the main branch, this is generally a bad practice. This is because the main branch is a moving target, changing with every merged pull request. It is generally better to have a pipeline that vets code (thorugh checks like linting, tests, etc) and then publishes the verified files as a versioned artifact. The versioned artifact represents a definitive point in time for the code being deployed and makes it easy to roll back to a previous working version.

Azure DevOps has two forms that this sort of pipeline can take - Classic Pipelines that use a graphical editor to add stages and YAML-based. YAML is the newer and generally more common approach.

Create a Release Pipeline¶

The Release pipeline performs the actual code deployment tasks. These can be created with a Classic editor or using YAML. It should be noted that Classic Release Pipelines appear in the Pipelines -> Releases interface, while YAML release pipelines appear in the main Pipelines interface. There are some differences between capabilities on the two types, which are detailed here. YAML pipelines are considered the more modern option