Introduction & Overview
Creating an App Service Web App
Creating Web Service Containers
Configuring a Web App
The course is part of these learning pathsSee 2 more
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
Visual 2019 with .NET Core 3.1 was used for the demonstrations in this course.
Now that we’ve scaled up to a production plan lets have a look at configuration settings. This menu has 4 tabs which are:
- Application settings that apply to your web app
- General settings that apply to the environment your web app runs in
- Default documents the same setting as you would find in IIS and other web servers.
- Path mappings to map extension handlers and virtual directories
First, let’s look at application settings. Creating an application setting is reasonably straightforward. I’m going to add a setting called model_app_setting to the LorryLogAdmin web app. This setting will be substituted in place of the vehicle model whenever the details method is called on the vehicles controller. So I’m just going to add that setting to appsettings.json with an informal expression of ignorance and add the appropriate code to the controller to get the setting. When I run this locally and view details I get exactly what I expect. On the live site I want to replicate the functionality but with more appropriate text. Unlike connection strings, these settings won’t automatically appear in your App Service. You need to create the setting manually. You can use the Advanced edit feature and copy JSON formatted values into application settings. Don’t worry about the deployment slot setting, I’ll be coming back to that later. After saving the setting in the App Service I’ll republish LorryLogAdmin and go and have a look at a vehicle’s details to see that the setting has been substituted.
On the subject of application settings, I did come across an issue or bug with Visual Studio web deploy that’s been around for about a year. When I was publishing the LorryLogApi app I started to get this unusual deployment error about not being able to find App_Offline.htm on the remote computer.
The solution or workaround is to remove the WEBSITE_RUN_FROM_PACKAGE setting.
Under general settings, we have stack settings that determine which language or framework your app is written in. Next, there is platform or bitness, which will correspond to platform target on the build tab of your Visual Studio project properties. Managed pipeline version is integrated or classic as you would have in IIS. You can specify whether to allow FTP deployment or not.
Turn on web sockets if your app is using SignalR or Socket.io push technology.
Always on keeps your app loaded even when not active. While this might seem like a good feature to improve responsiveness, it’s actually required for WebJobs that aren’t manually triggered.
ARR (application request routing) affinity is an interesting setting that works when your app is scaled out to multiple instances. The idea is that when a client establishes a session with a particular instance, ARR assigns them an affinity cookie (as in that client has an affinity with that particular instance) and that instance will service the client until the session has ended. Enabling this feature could potentially interfere with load balancing, and isn’t necessary when your app is completely stateless.
Turning on remote debugging will allow you to connect to your app from your integrated development environment if you have deployed a debug version. For those forgetful developers remote debugging will automatically switch off after 48 hours.
And finally, for added security, you can require incoming TLS/SSL requests to be accompanied by a valid client certificate.
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.