Introduction & Overview
Creating an App Service Web App
Creating Web Service Containers
Configuring a Web App
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 firstname.lastname@example.org.
- 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
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
.NET 5.0 demo code
.NET Core 3.1 demo code
In this first demonstration, I want to create the most rudimentary web app possible using the Azure portal. Let's start by logging into the portal and in the top search bar, type App Service, and select App Services with the little blue globe. I currently have no app services running, so I'll click the Create app service button.
Manually creating an app service through the portal follows a similar procedure to creating most other types of resources. We need to select our subscription; if there is more than one, then associate the resource with a group. We have the opportunity to create a new resource group if one doesn't already exist or the app isn't going to be associated with any current resource groups. I'll create a new group appropriately named NewWebApp.
A detailed explanation of Resource Groups is beyond the scope of this lecture but as the name suggests, it allows you to associate Azure resources like apps, databases, storage, and the like that share a joint function or purpose and lifecycle, even if those resources are provisioned in different regions. Before Resource Groups, Azure didn't allow you to group and manage resources from different regions as one. While you can have resources from different regions in one group, you should set up different development, test, and production resource groups.
Next, we're going to specify the name of our web app, which will be its unique URL within the azurewebsites.net domain. As you type, the app name will be checked for uniqueness. The publish option code means hosting the app traditionally, as in the application files are deployed directly to the webserver environment. The Docker container option requires that your app be deployed as a container image.
Next, we select our runtime stack or framework - in this case, it will be .Net 5, and I'm just going to publish to the Windows operating system. .NET 5, the successor to .NET core 3.1, is a cross-platform framework, so you could publish to Linux if you want. Select the region where you want the app hosted, which typically should be geographically close to the app's primary user base - for me, that's Australia Southeast. So far, so good.
An App Service Plan determines what kind of computing resources your app has available to it, and by extension, what those resources will cost. As I have no existing app service plan, an automatically created plan with the Standard S1 SKU serves as the default. The change size link lets you choose the type and size of the App Service plan. The cost isn't an issue for a free plan, but you are currently limited to 10 apps per plan, and hardware features are limited. Within the Dev/Test workloads, you get progressively more features and compute power as the price increases. Within the Production workload, the standard plan is limited to 100 apps, and all other plans don't limit the number of apps you can have in a plan. Having said that, the apps in a plan all share the same resources, so you could potentially save money by putting lots of apps in one plan, but there are no free lunches, so performance may become an issue as compute and infrastructure resources are shared between many apps. Another consideration is that not all features are available to all plans. For example, Deployment Slots are only available in standard or above plans. As performance isn't a consideration for this demo, I'm going to select the free plan.
I'll leave continuous deployment disabled and enable Application Insights monitoring. Application Insights is a monitoring and reporting service providing in-depth details of your app's performance. Tags get populated into the Azure billing statement, so it can be a useful way of tracking project costs, but as this is a free plan, I'm not going to bother with tags. After Azure validates my web app parameters as OK, I can hit the create button. After a few seconds, the web app is created, and I can go to the app service management page. The overview page displays important web app metrics like server errors, data in and out, the number of requests, and response times. The menu on the left allows you to configure an extensive range of settings, some of which we shall look at later. If you need more compute power or more features, you can seamlessly scale up the app service from here. The URL link at the top right takes us to the public-facing or home page of your web app.
I think it's fair to say we haven't actually created a web app but a place for our web app to be hosted. So, the next step is to get our code running instead of the default placeholder page.
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.