1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Getting Started with Azure App Service

Creating a Linux Container


Introduction & Overview
Creating Web Service Containers
API Documentation
Mobile Apps
Deployment Slots
Course Summary
2m 29s

The course is part of these learning paths

Microsoft Azure for Solution Architects
AZ-303 Exam Preparation: Technologies for Microsoft Azure Architects
AZ-104 Exam Preparation: Microsoft Azure Administrator
more_horizSee 2 more
Start course
1h 12m

You’ve got an idea for a great web app, or maybe you’ve already started building it. The next question is how are you going to get it out there on the Internet?

In this course, you will learn how you can quickly and easily set up a website and publish your app to the world with Azure App Service. Of course, web apps are a lot more complex and varied than just HTML pages and we will see how App Service supports a range of programming languages, frameworks, and even operating systems. We will explore features that greatly simplify application deployment and management, as well as those that will increase your app’s functionality like authentication and accessing on-premise data. App Service as with other Azure products has a raft of tools for monitoring and logging so you can make sure your app is performing optimally.

For any feedback, queries, or suggestions relating to this course, please contact us at support@cloudacademy.com.

Learning Objectives

  • Deploy apps using the Azure App Service
  • Create a web app using the Azure Portal
  • Create a web app using Visual Studio
  • Understand the configuration and diagnostic capabilities available from Azure App Service
  • Understand the advanced features of the service such as container deployment and deployment slots

Intended Audience

This is a beginner level course suited developers or anyone wanting to know how to deploy web apps to the Azure cloud.


To get the most from this course, you should have a basic understanding of the software development lifecycle, while knowing how to code would be a plus.

Course source code

Visual 2019 with .NET Core 3.1 was used for the demonstrations in this course.






Let's start by creating an Azure Container Registry to store our container image. In the portal, create a new container resource of type container registry. This resource creation process is similar to that we have seen already where we assign a resource group, give our resource, in this case, a registry, a name, and specify the location. Next, I will assign it a SKU of basic; this is similar to service level tier. For this demo, there is nothing to do in the way of networking or encryption, so I will just review and create the resource. When I go into the resource and look under repositories, as you would expect, there is nothing there as we have not deployed our container image yet. Before we leave the registry, we need to enable admin access so that our app service will be able to get access to and pull the image from the container registry.

Creating a docker image from within the Microsoft Azure ecosystem has been made relatively easy. You need to have Docker Desktop installed on your PC. For a standard Windows installation, you will also need to have hyper-v enabled through Windows features and settings. Once installed, you will have the docker desktop service running as a VM. As far as Visual Studio goes, it is simply a case of enabling docker support and then choosing the container operating system at the time of project creation. When you go to run the application locally, select Docker, that now appears in your run target drop-down list. Here I have another web API application that I prepared earlier that is targeting a Linux docker container. The pickup controller is pulling information from the pickup table in the Azure SQL database that we deployed earlier. If I run the app locally, this is the result I get. Now, let’s publish the app to the Azure container registry we’ve just set up. This is an Azure container registry, not the docker container registry, even though it is a docker container. We see here the specific target is the Azure container registry. When we click next, we are presented with the available container registries based on our subscription. As we have seen in previous app deployments we have the ability to create a new Azure container registry at this point, if one does not already exist. Now, we just click the publish button. This process will take a little while as it is not just the application being built, but the whole docker image is being constructed and then pushed up to our registry. At the bottom of the output window, we can see that the image has been successfully pushed with the tag latest. A tag is a text label that you can use to specify a particular docker image when it comes to deployment. This tag defaults to latest. Going back to the portal and hitting refresh on repositories, we can see the new image. Drilling into that image, we can see the single instance of latest and its manifest.

Now I need to create the app service that will run my Linux docker image. As before, I’ll create a web app, select a resource group, and give it a name. However, this time I’m not going to publish code I’m going to publish a docker container. Because the container is a completely self-sufficient instance of my application, including all the supporting libraries, I don’t need to specify a runtime stack. I’ll select my region and then change the SKU and size to F1-free. Under Docker, we tell the app service where to get the container image from. So, it’s a single container, and the source is the Azure container registry. This is the message you get if you have not enabled admin access to your container registry. As you can see, we only have one image, and the tag has defaulted to latest. OK, with that all set up, I will create the app service. If I go now to the new Linux lorry container app service and look in container settings, I can see in logs that we are pulling the lorry mobile API image with tag latest. The last two lines show us that the container has been deployed with a warmup request to minimize the response time for the first time a real user requests the app service. If I now go to the Linux lorry container URL and interrogate the pickups controller we get the data correctly returned from the database.

As we saw when publishing the Docker image, Azure container registry was not the only target, and when setting up the app service it was not the only image source. I’ve made a small change to the pickups controller to return a hard-coded value not found in the database. This time I will publish the image to the Docker Hub repository. One thing to note here is that "Publish to a personal repository" is not the same as publishing to a private repository. With a free Docker account, you get 1 private repository, but by default repositories are public. This subtle difference can be confusing when creating the App Service. I’ll go back to the portal and create a new web app in the same resource group and call it from docker. Before we move on this is as good a place as any to draw your attention to some of the current limitations associated with Linux app service. App Service on Linux isn’t supported on shared pricing tier.  You are not able to mix Windows and Linux apps in the same App Service plan. You can’t mix Windows and Linux apps in the same region within the same resource group. OK, back to the setup. This time select Docker hub as the image source. Next is the access type which will be public, and not private, which as I said before it is not the same as personal. Next, I’ll specify the image and tag. That will be my login or username to docker Hub followed by “/” and the name of the image, then “:” and the tag name, which is latest. From here it is the same process as before. If we go into the from docker container settings we can see our image name with tag and that is it is in fact pulling the image from there. Going to the deployed app service we can see there is still the connection to the database, but it is also the new app image as shown by the get ID path.

About the Author
Hallam Webber
Software Architect
Learning Paths

Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a  Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.