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
When we talk about networking in the context of App Service you need to always keep in mind where your app sits in the network topology, that is, inbound versus outbound. Default inbound requests are to a shared IP address, so it is your unique app service URL that allows requests to be correctly routed. You can restrict which public IP addresses can access your app, or you can place your app within a private virtual network. By default, your app has access to the internet, but you can also give it access to private virtual network IP addresses. Hybrid connections allow you to access on-premise resources using an agent, so very simple to implement. You can deploy your app inside your virtual network using App Service Environment. Azure offers a wide range of networking options, but I want to drill into 2 that are have wide applicability and usefulness.
VNet integration allows you to connect your App Service to resources like a VM or Azure SQL server, within a virtual network. Setting up access is relatively easy as it no longer involves gateways. Let’s see how we would put the LorryLog database into a VNet and then have the API access it.
First, let’s make the database inaccessible to App Service by turning off “Allow Azure service to access this server”. I’ll make a request to the API to make sure it’s not connected, and sure enough, a 500 exception as it can no longer see the database. Ok, I’ll go back to the database server and add an existing virtual network with an endpoint enabled. Now I’ll go back to the app and add the VNet. Once that has been provisioned we can check if the database is now accessible - which it is. So very easy to implement a VNet connection.
Another cool feature of App Service networking is how easy it is to connect to on-premise resources. It is unlikely that a business will move all its resources to the cloud at once, so the ability to access on-premise data during a phased migration is important.
I’m going to switch the database my API connects to from the Azure SQL to SQL Server running locally on my computer. Azure uses connection manager software that I have previously downloaded. Before opening the connection manager you must create the hybrid connection in the portal. We need to give the connection a name and the name of the host, which is the name of the computer the connection manager software is running on. Next, the endpoint port which is 1433 for SQL Server. I’m going to create a new service bus namespace with a unique name. Once the connection has been created on the portal we can go to the locally installed connection manager and select our subscription, and then choose our predefined connection. Now that we are connected let’s change the database connection string server to that of the hybrid connection endpoint followed by a comma and the port number. After saving the connection string I’ll just test the web API, and that looks all good. To prove this is not all smoke and mirrors I’ll add a record to the local database and refresh the web page. And there it is.
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.