Creating an App Service

To be able to follow along with this demo, you will need to have an ASP.NET Core 6 project checked into a GitHub repository.

There is a button with a big + icon to create a new resource. This will once again bring up a page with some quick options for resource types but also a search to search through the extensive catalog of Azure services. It is important to know that not every service in the Azure services catalog is a Microsoft product. There are tons of third-party services in there as well. Some examples are MariaDB, SendGrid, several Linux distros for virtual machines, and many more. For this example, we need a web app. After we find it in the catalog and click Create, we enter into a setup wizard.

Make sure to select Web App, not Static Web App. Those are for the next section.

First we need to select a subscription. Being an Azure user means you have a subscription. Azure has a lot of free services, but depending on how much flexibility, scale, or redundancy you need, you will quickly get into paid territory. To track what you use, Microsoft requires you to have a subscription. You can have several subscription tied to the same email address. As a Visual Studio customer, you get monthly Azure credits that you can spend. The amount depends on the type of Visual Studio license you have.

A Resource Group is a functional group that you can place your services in. Resource Groups are mostly meant for customers to order their services. Azure resources in the same resource group share the same lifecycle, permissions, and policies. Click Create New and give your resource group a name.

Next step is configuring the resource itself. Most important is how you want to call this. This name needs to be unique across all Azure customers since the name will be used as a url. As an Azure Web App user, you get a free domain in the form of https://<your web app name>.azurewebsites.net. This makes your web application easily reachable across the Internet, and you can make use of the SSL certificate for *.azurewebsites.net free of charge. It is of course possible to attach your own domain name to a web app instance, but that also means that you are responsible for the SSL certificate.

After selecting a name, we can choose if we want to deploy our project as code or as a Docker container. Azure supports multiple ways of deploying containerized applications; this is one of the more basic versions. When deploying as a container, Azure assumes that the container contains a web application that exposes ports 80 (http) or 443 (https). Deploying as code means that we publish our generated binaries onto the file system and the web server interprets and serves the response, just like in a shared hosting with any hosting provider. For now, we will stick to deploy as code and we will get into Docker later on in this chapter.

The runtime stack is where we define the technology that we used for building our application. As mentioned in the start of this chapter, we have quite a lot of options. Since this book is about .NET 6, we will select .NET 6 (LTS) as runtime stack. Depending on the option you select in the runtime stack dropdown, the option for selecting an operating system might light up. That is because not all runtime stack options support both Linux and Windows, for example, classic ASP.NET 4.x can only run on Windows hosts. Ever since .NET Core, .NET became cross-platform so we can run on Linux as well. There are several differences between running an app service on Linux or Windows; most of them have to do with pricing. Running a Windows service is more expensive than running a Linux service. Figure 8-3 shows the difference using the Azure pricing calculator.

The pricing shown in Figure 8-3 is monthly cost calculated for a basic instance estimating 730 hours of usage. Looking at the pricing in the calculator, Windows is four times as expensive as Linux. However, Linux does not have a free tier in web app while Windows does. So there is more to it than just selecting the cheapest option. Make sure that you know very well what the different options are.

The next option is the region. Azure has datacenters across the world, but a region is not just one datacenter. A region is a collection of datacenters that are relatively close to each other. When you deploy a service to a region, you know that your application is running in one or more of the datacenters in that region but you do not know which one. The reason for this is redundancy; should one datacenter loose connection, one of the others in the same region can take over. There are several assurances of where data is stored and how data is transferred. These were put in place to comply to privacy regulations like GDPR in Europe. The list of regions is constantly extending as Azure is growing. At the time of writing, Azure has 33 regions. Do note that not every region supports every resource type. Newer resource types are usually available in US regions first and are gradually rolled out across the entire Azure network.

Final option to set is the App Service Plan. App Service Plans are another grouping method, but while resource groups go about lifecycle, permissions, and policies, App Service Plans are about location, features, cost, and resources. A service plan is tied to a region, so if you want all of your services in the same service plan, they also need to be in the same region. The SKU is the computing power you want this service to have. More power comes with a higher cost.

The selection screen groups the available SKUs according to workloads and immediately shows estimated monthly cost. The selected SKU can be adjusted later on, for example, when your application usage is on the rise. If you switch to the Dev/Test tab at the top, you can select the Free tier; this will be sufficient for the demo and will keep you from spending Azure credits. After selecting the right SKU for your project, we can advance to step 2 of the wizard: Deployment.

Azure App Services can integrate with GitHub Actions to automatically set up a CI/CD pipeline. With CI/CD, we can automatically build and deploy our application. Connect the Azure portal to the GitHub account that has access to the GitHub repository we mentioned in the beginning of this section. Once connected, you can select the right organization, repository, and branch.

Setting this up will generate a YAML file that is added to the code repository for a GitHub action. That action can automatically build and deploy your application to the newly created Azure Web App. A preview of the YAML file can be seen here in the Azure portal before it is added to your repository on GitHub. For more information on setting up the connection between Azure and GitHub Action, go checkout the documentation https://docs.microsoft.com/en-us/azure/app-service/deploy-github-actions?tabs=applevel.

The next step in setting up an Azure App Service instance is Monitoring.

Application Insights is another Azure service that provides extensive logging and monitoring capabilities. Enabling it here will provide error and crash logging; for further logging, you will need to add the Application Insights SDK to your project.

The final step in the wizard allows for tagging your resources. With these tags, you can create categories for your services to allow for easier filtering when searching through your Azure services.

Right before the Azure resource is created, you will get a final overview of all the selected options. If everything looks okay, we can click Create and Azure will work its magic.

Azure will keep you informed about the deployment status. You are free to leave this page and come back later; deployment will continue just fine.

For this demo, I have checked in the ASP.NET MVC demo project from the previous chapter. I have selected the GitHub repository and branch that point to this project. Now that Azure is creating the resource, it will also deploy our project. After a few minutes, we get the result shown in Figure 8-9.

To summarize, the following things just happened. Azure created an App Service instance to host our .NET 6 web application. Azure also generated a YAML file for a GitHub Build/Deploy pipeline. GitHub Actions compiled our application and deployed it to the newly generated Azure App Service. From now on, whenever new changes are committed to the main branch of the GitHub repository, the GitHub Action will compile and deploy a new version.

On the portal side of things, we get a dashboard with some analytics, if we kept Application Insights enabled.

From here we can stop, start, or restart our application server, look into our application logs, change the configuration, change service plans, and so on.

We can also download a publish profile that we can import in Visual Studio to deploy directly from the IDE to the cloud. The publish profile is a configuration file that we can import in Visual Studio from the Deploy option that we will use in a minute. In the Deploy wizard, we can either create a new publish profile or import a downloaded one.

To summarize, we have created an Azure App Service instance to host our .NET 6-based web application. We deploy this code directly from GitHub using its built-in CI/CD pipeline (more about CI/CD in the architecture chapter). Deploying directly from GitHub is optional; we can deploy directly from Visual Studio using publishing profiles or connect to Azure using the Visual Studio right-click on a project ➤ publish tooling. In the publish wizard, we select publish to Azure and an Azure App Service.

Very different files that serve the same function. The reason these are different is that the publishing profile from the Azure portal is catered especially to cloud deployments, while the version from Visual Studio is more generic and can do deploys to other endpoints like the Windows filesystem, Docker, or any IIS server, for example.

Azure Web Apps or App Service is a great resource for publishing web-based applications. But there might be a better option if your application is pure HTML, CSS, and JavaScript based.

Docker

Docker is a set of tools build upon the containerd runtime to create containerized applications. Containers are basically an evolution of virtual machines. Virtual machines emulate full hardware devices where containers are on the operating system level. A container bundles software, libraries, and configuration for running on a specific operating system. This means that a container is a fully isolated, self-configured unit of work that runs on top of the underlying operating system of the Docker host. This means that containers have less overhead than virtual machines, allowing more containers to run on one physical device than virtual machines.

The Docker registry is needed as this is where Docker runners pull their images from. Let’s try to dockerize our MVC demo application.

First thing we need is to install Docker Desktop on our system. The installer can be downloaded from their website https://hub.docker.com/editions/community/docker-ce-desktop-windows. The installer will guide you through the process of installing WSL2 and making sure the right updates are installed, after which Docker and Docker Desktop will be installed. Docker Desktop is the Windows version of Docker. It provides a UI to configure Docker and a CLI. Most importantly, it connects the Docker engine to Visual Studio for debugging.

After Docker Desktop is installed, we can open our solution, right-click the project we want to containerize, and select Add > Docker Support. Note that you can already generate the file without installing Docker first, but you won’t be able to run your containerized application.

Selecting this will ask if we want a Linux- or Windows-based container. Select Linux and continue. Visual Studio will generate a Docker file. This file contains all the instructions needed to build and run our .NET 6-based application in a container.

After adding the Docker file, Visual Studio will show Docker as a new debug target. If Docker is selected as debug target, Visual Studio will take the Dockerfile into account and follow its instructions to build the application whenever we launch the Build command. When we launch the app in debug, a container will spin up in Docker Desktop and a debugger will attach to that container. The first time you do this you might see some command line windows pop up. These are the Docker tooling downloading the correct images for this type of project.

Visual Studio provides us with a container pane showing us all running containers and their environment configuration.

To be able to use this container for deployment, we first need to upload it to a container repository. Docker has a public repository where we can upload containers called Docker Hub, but Azure also has a service that allows us to create private container registries. This service is called the Azure Container Registry, or ACR.

An ACR instance can be created through the portal, similar to web apps.

Creating an ACR instance is quite easy; the most important thing is the name. We need the <hostname>.azurecr.io domain in our commands to upload our containers to the correct registry.

The next step would be to use the Docker CLI to buildour container; unfortunately, if we try to do this with the Dockerfile that was generated by Visual Studio, we get an error.

The reason is that this Dockerfile is used by the Visual Studio tooling to enable debugging and integrations. The Docker tooling internally uses different relative paths, assuming that the Docker file is on solution level, but Visual Studio places it on project level. The fastest solution is to copy the Docker file and duplicate it on solution level. In this way, both the Visual Studio tooling and Docker CLI tooling will work.

The Docker build command takes a path, which we define relatively by “.”; it will look for a Docker file and build according to the info in that file. The tag, or t, command is what you want to tag the container image as. A tag is in the form of repositoryname:tag.

We now have successfully created our container image; it is fully ready to be uploaded to our Azure Container Registry. However, since the ACR instance is private, we need to authenticate to Azure and ACR first. Make sure to have the Azure CLI installed for authenticating with the cloud platform. The CLI can be found at https://docs.microsoft.com/en-us/cli/azure/install-azure-cli.

We are not explicitly setting a tag so our image will automatically be tagged with :latest.

After upload we can inspect our image on the Azure portal in the ACR instance by going to Repositories, selecting the repository and the correcting tag.

The final step is creating a new Azure Web Apps instance and selecting Docker instead of code. The second step of the wizard will be the Docker setup.

The wizard can connect to our ACR instance and read the list of images and tags. Azure will create a new instance, pull in the image from ACR, and create a container. Note that browsing to a Docker-based web app might take time; the container needs to be generated and spun up on first browse.

I have shown you the manual steps involved in building and deploying a Docker-based application. A next step would be to automate this entire process in your CI/CD pipeline.

Deploying Azure Functions

Finally we need to get these Functions in the cloud. We can do this straight from Visual Studio 2022 by right-clicking the project and selecting Publish . In the first step of the wizard, we specify that we want to publish to Azure. In the second step, we can choose if we want to create an Azure Function running on Windows or Linux or in a container.

For this demo, we will choose a Windows-based Function, but other options work just as well. In the next step of the wizard, we can click the + sign to start creating a new Function. The Function Name we choose here needs to be unique across Azure. The Plan Type has three options, Consumption, Premium, and Dedicated (App Service). What you choose here has an impact on scaling, resources per instance, and support for advanced functionality such as virtual network connectivity. More information on the different plan types is found at https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale. Azure Functions also require a Storage account because they rely on storage for managing Triggers and logging.

After the function is created, we can go to the API Management step. This is an option to integrate Functions into an API management resource, but that goes beyond the scope of this book, so we can safely skip this step by selecting the Skip this step option that will enable the Create button. Once all steps are done, we can hit the Publish button and Visual Studio will work its magic creating Azure resources and pushing our Function to it.

Looking at the Azure Portal, we can find our newly created Azure Functions resource, with the three Functions that we defined in code.

Opening the details of a function gives us the option to copy the url. The url is more than the route we defined in code; it needs to include a code for security reasons.

Executing a GET request to this URL using Postman gives the result in Figure 8-32.