Ops / IT Pro
Please note: An updated version of this course is available here.
There's a lot of effort that goes into keeping our applications available, and secure. That's why so many cloud vendors offer platforms for hosting web-based applications. If you're building web apps, APIs, mobile backends, or business processes then you should consider looking into App Service! App Service has a lot of functionality. It meets compliance standards from around the world, it's highly scalable, it supports multiple languages and makes it easy to get your code deployed.
This Getting Started with Azure App Service course it's basically an intro, but for developers and IT Pros. In this course, you'll learn about the features of App Service at a high level as well as for each component. Then you'll learn about each of the 4 components of App Service through some demos. If you're a developer or IT Pro working with Azure, but new to App Service, this course is for you.
This course will help get you up-to-speed on App Service so that you can start developing / managing apps.
Getting Started With Azure App Service: What You'll Learn
|Lecture||What you'll learn|
|Course Intro||What to expect from this course|
|App Service Overview||A high-level overview of App Service|
|Web, Mobile, API App Overview||A high-level overview of Web, Mobile, API Apps|
|Logic App Overview||A high-level overview of Logic Apps|
|Mobile Apps: Easy Tables||How to use Easy Tables as a "no-code" option|
|Mobile Apps: Client||Running the client code from an iOS simulator|
|Mobile Apps: .NET Backend||Using a .NET backend|
|Mobile Apps: Auth||Using authentication with App Service|
|API Apps||Creating API Apps|
|Logic Apps||Automating business processes|
|Web Apps||Authentication and remote debugging|
|Deployments||Deployment slots and GitHub based deployments|
|Monitoring and Logging||Monitoring and logging options|
|Scaling||Scaling up and out|
|Next Steps||What's next|
Welcome back! In this lesson we’ll be looking at Web Apps. The great thing about App Service, to me, is that I can use the same tools that I’m familiar with to create web based apps, and then deploy them to App Service. Web Apps support .NET, Python, PHP, Java and Node.js, which means you have a lot of options regarding which tools you use.
Since so much of the value of App Service revolves around non-development tasks, a lot of the topics such as backups, scaling, deployment, etc, will be covered in the coming lessons. However, in this lesson we’ll cover what App Service has to offer developers when creating Web Apps.
So we’ll cover: Authentication, Extensions, and Live Debugging, in no particular order. These don’t cover everything there is to know about developing web apps themselves, however the goal for this lesson isn’t to teach you to develop web apps, rather to show you some of the ways App Service will make developing and debugging easier.
Let’s kick this off by creating a new Web App in the portal. There are a few ways to do it in general, however, I’ll click on App Service, and then Add.
And I’ll select the Web App option for this demo, and then click create.
Okay, here we are on the Web App blade, so as with everything, we need a name. I’ll call this web-app-demo.
And then we need a resource group, and I’ll create one for this...and before creating this, I want to enable Application Insights.
Great, let’s create this, and fast forward to once it’s complete.
Here we are with our newly created Web App. All that’s deployed at the moment is the default placeholder app.
Let’s switch over to Visual Studio to get an app created. Let’s start with a new project template, and I’ll filter by Web templates. And let’s use the ASP.NET web application template, and give it a name of web_app_demo. I’m not going to enable Web API for this demo, however it’s an option. And I’ll leave authentication disabled, though again you could handle it here in the application. I’m leaving it disabled because App Service will handle auth for us, allowing us the use of common social identity providers, or custom options. So, this is one of the ways App Service speeds up development, because we get to focus on business logic, and not things that are solved problems, such as auth.
Once this is complete, you’ll see a likely all too familiar MVC app. There’s nothing new or exciting about this app, it’s a vanilla MVC app. And in a way, that’s kind of the cool part about App Service. For many of our apps, we can deploy them to App Service without code changes. So, let’s deploy this app to the Web App that we created in the portal.
Like the previous projects, we’ll right click and use Web Deploy to publish this. Let’s click select existing and then click publish. The web deployment needs to know which App Service app we’re going to deploy to, so let’s select our web app.
This doesn’t usually take too long, however I’ll jump forward to once it’s deployed...and there it is.
So this is now running as an App Service app. Clicking through the links shows they all render pretty quickly, and everything seems to be working.
We talked about authentication in previous lessons, let’s check it out again in the context of Web Apps. App Service allows you to easily enable authentication for an entire application, and we’ve seen that in action. However you can also require users to be authenticated at the controller or route level. So let’s check that out.
Let’s require users to authenticate in order to view the about us page...which seems useless, and kind of mean...however in a demo, we developers make the rules! So...where do we start?
There are a few things that need to be done before this will work we need authentication enabled, a provider configured, the route method decorated with the authorize attribute, and a redirect URL added to the web.config.
So, let’s start off and see what happens if we add the Authorize attribute. With that added, let’s run this locally and see what happens when we click on the about page...so this will take a moment to add...I’ll speed this up with some video editing magic...and there the page is loaded.
And if I click on About...it throws a 401 error. Let’s publish this and see if it does the same thing inside App Service. Let’s fast forward...and there it is in the browser, and if I click on about...it’s a less helpful 401 error.
So, our code is saying that it requires a user to be authenticated to view this route...however we don’t have any providers configured. So let’s do that next.
Inside the portal if you click on Authentication / Authorization we can enable auth, and then let’s use Azure AD. We’ll use the express mode, and have it create a new AD app, since I don’t have any currently.
With that done we can save this. Before we test anything out, notice that the option towards the top of this blade indicates that no action will be taken if the user isn’t authenticated. That means that by default the app is anonymous. However we do have some routes we want locked down, so next we need our code to know what to do if a user hits a route that requires auth. For that, we can set the redirect value in the web.config.
I’m going to paste in some XML here that sets the redirection for unauthenticated users to /.auth/login/aad and deploy this to Azure.
Notice that the home page loaded, which is what we’d expect. However if I click on the About page, it should prompt us for credentials...and there it goes.
So if I add my creds, then it kind of completes the process, in this case, we’d need to make some adjustments to clean up the redirection process. However, if we go back to the site and try to view the About page, you can see that it loads successfully.
Now, let’s imagine you were experiencing some issues with this page, maybe the username is supposed to be displayed, and it isn’t, but it’s only happening from inside app service. This is where live debugging will help us out. One of the things I’ve always loved about developing with Microsoft technologies is that they have some of the best developer tools! And this is no exception! So let’s expand the server explorer. If you have an Azure account, and haven’t already signed in, you’ll need to do that first. Once you’re logged in, you’ll need to expand the App Service and then the resource group your app is in, and then right click on the app and choose Attach Debugger.
Because our deployments are using the Release build, they don’t have the debug symbols. So we can still use the breakpoints by selecting “Disable Just My Code and continue.” Let’s set a breakpoint inside the About method.
And if we click the about link...there it is. So now we can gain some level of insight into what’s happening. We can explore some of the values in the locals window…
And if we wanted to start inspecting variables in the immediate window, you’re going to see we’re about to hit a wall with what we can do when debugging a release build. So while this would be useful in some situations, it’s not going to allow full access to all the code. So let’s publish this again, only with a debug build.
To do that we right click the project and select publish like normal, only this time click the settings option, from there click the settings tab, and select Debug, and then save.
Now back at the publish screen, we can click publish.
And if we re-attach the debugger to the live app, we can try this again. Okay, let’s click on the About link, and see what happens. The breakpoint stops, and in the immediate window we can start evaluating things a bit more. You can see that we are an authenticated user.
If we look at the User.Identity you can see where the user data is stored. So if we were debugging an issue like I mentioned earlier where we wanted to display the logged in user’s name, then we now know where it is.
Since this is live debugging we can make changes here to variables and see how they’ll impact the site. For example, let’s change the value in this ViewBag message….
Let’s change it do “Changed in the debugger”
And let’s have the code continue...and there it is in the browser.
Debugging a web app probably isn’t new to you, but it’s always good to know how to debug remote instances of an app.
Let’s switch gears to the last thing I wanted to cover, which is extensions. If you scroll down to the extensions tab, and open the blade, you’ll see that currently we don’t have anything enabled. However, by clicking add we can see what sort of functionality they provide.
At the top are extensions for application monitoring, log browsing, encryption, and so much more! Extensions will provide you with new functionality, sometimes in the form of installed admin dashboards, or it could be in the form of build tools. You can use these here from the marketplace, or even create your own. Enabling them is usually a simple process of agreeing to the end user agreement, and then they’re ready to use.
Alright, let’s wrap up this lesson here. In the next lessons we’ll look at the operational side of App Service. We’ll talk about deployments, scalability, monitoring and more. So if you’re ready to see the other side of the coin...then let’s get started in the coming lessons!
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.