1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Design and Implement Web Apps for Azure 70-532 Certification

Configuring Web Apps

play-arrow
Start course
Overview
DifficultyIntermediate
Duration1h 39m
Students658

Description

Course Description

This course will show you how to design and create web applications using the Azure App Service. 

Course Objectives

By the end of this course, you'll have gained a firm understanding of the key components that comprise the Azure App Service. Ideally, you will achieve the following learning objectives:

  • A solid understanding of the foundations of Azure web app development and deployment. 
  • The use cases of Azure Web Jobs and how to implement them. 
  • How to design and scale your applications and achieve consistent resiliency. 

Intended Audience

This course is intended for individuals who wish to pursue the Azure 70-532 certification.

Prerequisites

You should have work experience with Azure and general cloud computing knowledge.

This Course Includes

  • 1 hour and 35 minutes of high-definition video.
  • Expert-led instruction and exploration of important concepts surrounding Azure Web Apps.

What You Will Learn

  • How to deploy and configure Azure web apps.
  • How to implement Azure Web Jobs.
  • Scaling and resilience with Azure web apps. 

Transcript

This section will discuss the various configuration options available to adjust the environment in which a web app runs. Azure allows you to separate your code from the configuration, and also allows the deployment environment to override configuration settings. This ensures that the environment is using the resources appropriate to that deployment without having to worry about a subsequent web app deployment breaking those settings. For example, your testing environment can override the database connection strings that ensures your web app will always pick up the connection string that points it to the testing database. And following a subsequent deployment there's no danger of your testing application suddenly using your production database as the environment will override any connection string bundled with their deployment.

We will cover the topics of application settings, and connection strings. We'll discuss request handlers that ensure requests to your web app are handled by the appropriate process. We'll also cover virtual directories and application. Setting up custom domain names as well as certificates and SSL bindings for securing your web app. Lastly, we'll briefly discuss the various tools available for managing your web app.

Application settings are name value pairs made available to your application. Accessed by their name or key they provide the corresponding value. Accessing application settings in Azure depends on the web app technology you are using. For .NET applications you can access application settings in the same way that you access app settings in the web.config. For other platforms, such as Node.js, PHP, Phython, Java and others, application settings are exposed as environment variables.

Connection strings are very similar to application settings in that they are name value pairs. Just like application settings, accessing connection strings is also dependent on the web app technology used, .NET apps can access them as if they were in the web.config while for other technologies the connection strings are exposed in the environment variables. However, connection strings differ from application settings in that they typically describe access to a resource, such as an SQL database. This means that the values of these name value pairs will often contain secrets such as passwords. Connection strings are therefore given special treatment in the Azure portal. They have their own section and their values are not shown by default extra effort is required to display and edit these often sensitive values by the portal user.

Let's go to the Azure portal now and see how app settings and connection strings work now. I'm here on the Azure portal and we're gonna click on the new website that we created, NewAppCa. And when we click on App settings on the menu on the right, under General, and we go down the page we can see there's a setting called App Settings and a setting called Connection Strings here. We can add a key so we could add a key for say the ApiEndpoint for example, and the ApiEndpoint could be anything that we want it could be api.google.com, and we can tick it or un-tick it. If we tick it, it means it's going to be a sticky setting which means when we swap slots this setting will retain the value that we've given it now it won't change to the swapped value.

We can do the same for a connection string, so we can say, create a connection string called conn and here we'd have the connection string. And the thing to know about the connection string is once you've saved this connection string it won't be viewable without having to do extra clicks to try and uncover the value stored within the connection string. 'Cause it may contain passwords for example. And they all adhere to the same principles as the app setting if you tick the slot setting it makes it sticky so it won't change when you swap the slots. But to see that in action let's click Save.

Now you can see the message to say that it's been completed and if we close this panel and the re-load it by clicking Application Settings again scrolling down to the configuration section you can see that it says it's hidden for security reasons. If you click on it you can then get access to the value that was stored in there. This concludes the app settings and connection strings demonstration.

Accessing app settings and connection strings from .NET is identical to accessing them from the app.config or web.config. We use the standard configuration manager Api corresponding to app settings and connection strings as per this exactly.

Request handlers allow us to instruct web apps on how to handle certain requests. A request handler can be configured to map files with a certain extension. For example, to a specific executable when a request handler is invoked the request is not received by ASP.NET in the case of .NET we apps it is instead passed through the specified handler which is typically an executable such as a PHP runtime or FastCGI handler for Phython.

It's worth noting that Azure web apps have built-in support for PHP that you wouldn't typically have to create a handler for PHP unless you wanted to use a specific self-supplied PHP runtime. Azure support for various other frameworks is growing and changing frequently meaning that custom handlers shouldn't be a common scenario when deploying web apps using mainstream technologies.

Just below the App Settings in Connection Strings you'll find the Handler mappings section, configuring a request handler requires you to supply a matching expression as per this example where we are matching all files ending with a .py. The second argument is the full path to the request handler which is typically inexecutable, in this case we would want to provide the path to our custom Python FastCGI handler. The last parameter is an optional set of arguments that should be past the handler, in our case we have left this blank. That's all it takes to setup a request handler.

Virtual directories enable us to decouple the logical hierarchy of folders from the physical structure on disk. A virtual directory can for example, simplify a deeply nested directory hierarchy or can be used to expose existing directories with different names. For example, an image subdirectory at your web app route might actually exist on the D drive under content\site\static\images, completely separate from the rest of your web app content.

Another benefit of virtual directories is that you can change the physical storage locations without having to worry about the impact on the web app. Simply updating the virtual directory mappings to reflect the new locations. A virtual application allows us to isolate a specific virtual directory in its own worker process by marking it as a virtual application. In a typical scenario you might have a web app route with multiple virtual directories such as a website, blog, and shop. Each of these might contain individual applications a blog platform, a separate shop application, and an application that serves your main website content. Each of these virtual directories can be separated out into their own processes as separate applications by marking them as virtual applications.

Let's go to the Azure portal and see this in action now. I'm here on the Azure portal and we're gonna select our web app and on the Settings Menu we want to select Application Settings under General. And if we move the Application Settings panel into view what we want to do is we want to scroll down go to the Virtual Applications and Directories right at the bottom of this panel. And what we can do is we can create a virtual application for a blog and shop and then we'll create a directory for the website.

So first of all blog, and then that will be directed from site\wwwroot\blog and we tick the box so that we know that it's going to be a virtual application. And we can do the same for shop, this will be site\app\shop may be different for the applications that you set up. And then finally we'll do the directory. And the directory is for the website and that will be d:\web\root\ and we don't need to tick the box for this one. And we can also delete an option just by clicking on the ellipses at the right of one of these options and clicking delete. Let's add that back in again, and this concludes the demo for setting up the virtual applications and directories.

After the initial creation every web app is accessible by the URL web app name.azurewebsites.net This works fine but no doubt you'll want your web app available under a specific domain name that you own or are about to acquire. In order to do this we need to setup a custom domain name. There are two ways to associate your web app with a custom domain, firstly you can update your DNS records and change the address record known as the A record to point to the IP address of your web app. Secondly, you create an alias record known as a CNAME to map a subdomain of your custom domain to the Canonical Name of your website.

The key difference to note between A records and CNAME records is that an A record allows you to map the top-level or root of your domain to the a web app. As an example say you were in mydomain.com you can map mydomain.com directly to your web app. You can also map all subdomains such as www.mydomain.com to your web app using a wildcard entry. However, a CNAME record can only map a subdomain such as www. It's also worth noting that custom domain names are not supported on the Free App Service plan.

Finally, it should be noted that the IP address of your web app can change in certain circumstances. This can happen in a variety of situations such as if you delete or recreate your app service plan, move to the free tier, or enable IP based SSL. It can also happen in an unintentional scenario such as reaching your spending limit when your web app will be automatically changed to the free tier app service plan. In all these scenarios if you're using an A record to map your domain name to your web app you'll need to update the A record value to the new IP address.

Let's go to the web portal and see how all of this works in practice. I'm here on the Azure portal and we're gonna find out where we can locate the IP address for our app. So let's click on our app and we have the Settings Menu on the right, if we scroll down we can find a setting on the Routing which says Custom Domains and SSL, click on that option. And what we want to do is we want to bring in an external domain so there's an option at the top here that says Bring External Domain we click on that one and it says, "Custom domains cannot be added to the Free plan." If you're on the free plan and you want to be able to change your domain you'll have to be on a non-free plan. So we can change our plan by clicking on Change App Service Plan under App Service Plan and we can select the Standard Plan. So we've got the standard plan now which is non-free and now that that's been updated we can go back to the Custom Domains and SSL under Routing and then we can attempt to bring in an external domain. It gives us access to the IP address that we can use when we want to configure our A record. So we need to save this information somewhere so that we can use it when we go to our DNS providers domain name management page.

This table is a simple example of an external DNS configuration. The details are specific to individual DNS providers. If you wish to use HTTPS to secure communications between your web app and the user using transport layer security or TLS standard you will require a certificate. There are multiple types of certificates and the primary criteria for choosing between them is the number of domains or subdomains you wish to cover. A basic certificate for example only applies to one full or qualified domain name, while others can apply to an unlimited number of subdomains for a given domain name.

Why should we go to the trouble of using HTTPS and arranging certificates to do so? Firstly, HTTPS prevents intruders from tampering with communications between your users and your web app. This is especially important when transmitting sensitive information such as credit card data, medical information, or simply the user's identify info. A definition of what is and isn't sensitive varies greatly. HTTPS can help protect your users privacy and security. Lastly, certificates and HTTPS help your users identify your web app seeing the trusted connection information in the browser improves the level of trust users will have toward your web app.

The azurewebsites.net domain provides a wildcard SSL certificate meaning that all of the web apps accessible under this domain are covered by this certificate. However, if you are planning on hosting your web app under your own custom domain you'll need to acquire a certificate from an authorized third party. In practice the wildcard is a SSL certificate for azuerwebsites.net means that your web app is accessible securely through HTTPS as soon as you deploy it. Try it for yourself by prefixing your web app's azurewebsites.net web app address with HTTPS, as an exercise you can inspect the certificate in your browser.

There are two vulnerabilities worth mentioning for anyone thinking of relying on the Azure websites domain name and SSL certificate. Firstly, every web app under this domain uses the same certificate it therefore makes it easier to impersonate a web app because the web app still looks properly secure to the user. Therefore the certificate cannot be relied on for ensuring that the web app being accessed is truly the web app the user is trying to access. Secondly, if an attack was ever to compromise the azurewebsites.net wildcard certificate it would be able to decrypt all traffic to all of the web apps hosted under this domain.

Generally speaking relying on the Azure website's domain and certificate is considered fine for development and non-public applications. But a custom domain with a custom certificate is best practice. So let's see how we can achieve this. I've opened an administrator command prompt. And the first step we'll need to do is to create a certificate for our custom domain. There are a number of tools for us to choose from, but we'll go ahead and use certreq.exe which is available on many Windows machines. We'll need an ini file that we can pass in as one of the items for the request and it happens that I have one here which is called CaCertRequest.ini if we open that in notepad we can see the contents of this file.

This is just the sample certificate request configuration we won't get into too much detail here but as you can see the key element here is a subject that defines the domain that we wish to create a certificate for. We'll now run the CertReq tool which will take our request and generate the certificate request. And we need to specify an output which will have the extension of csr. Now we've done that our certificate should be ready to be used. And now you can see that there's been a new csr file created let's open that in notepad and see the contents.

So here is the request this is the data that we'll need to supply a third party certificate service once we've supplied that to them they'll supply a certificate to us in return. Once we've received that certificate we can go ahead and upgrade it to Azure to use with our custom domain.

Let's go to the Azure portal to our web app and see where we can apply this certificate. I'm here on the portal let's click our web app on the Settings Menu let's go down to the Custom Domains and SSL, and we can click on the More option at the top right and upload certificates. And here we're prompted to upload a PFX file and provide the associated password. We won't be uploading the certificate at this time but following this we'll be ready to bind this certificate to our host name. So this will conclude the demonstration for how you can upload your PFX file once you've received it from your SSL supplier.

Configuring SSL bindings is the act of associating the certificate we uploaded to Azure with the custom domain we're using for our web app. Binding enables Azure web apps to associate a user request with the correct certificate. Binding our existing SSL certificate is straightforward. Let's go ahead and jump into the custom domain and SSL blade of our web app.

I'm here back on the Azure portal, we're gonna select our web app, and let's go back down to the SSL section. We first need to select a host name, which will be this drop down list. The host name that we're gonna use to bind this certificate to followed by the certificate we're gonna use. We don't have a certificate yet so we can't put one in there, and then lastly the certificate type. And this is based on the type of certificate we issued. And that's all that's required to associate the certificate without the main in Azure.

Server name indication commonly known as SNI an extension of the TLS standard. SNI enables secure access to multiple websites residing in the same server using the same IP address. Prior to SNI setting up an SSL enabled web app required acquiring a dedicated IP address with SNI that requirement is gone. SNI enables a greater density of web apps per server and removes the need for a dedicated IP address. Reducing the burden of setting up a web app and reducing the strain on the available IPv4 address space.

In addition to configuring web apps for the Azure portal web apps can also be managed for a variety of other tools. Azure exposes a service management REST API this is a platform agnostic API that enables a client to perform many of the actions available in the portal by sending REST requests. Also known as MAML the Microsoft Azure Management Libraries for .NET enabled convenient programmatic access to the REST API from any .NET app.

Azure PowerShell cmdlets are another tool that enables script-based access for Windows user to create, manage and monitor web apps using PowerShell. Lastly, the cross-platform command line interface often known as the xplat-cli is an open source software development kit that provides a command line interface for script-based access to the Azure Management REST API for those using MAC OSX or Linux.

In this section we covered the topics of application settings and connection strings and how these are managed and exposed to web apps on the Azure platform. We briefly discussed request handlers and how these enable mapping between file types and their execution handlers. We covered custom domain names, the Azure websites .NET domain, as well as securing your web apps with certificates and SSL binding.

Lastly, we touched on the topic of web app management tools having covered the topics of deployment and configuration which have given us the key knowledge to comfortably deploy and configure our web apps. We can now move on to the topic of monitoring these applications for the various diagnostics and analytics available in Azure.

In the upcoming video we will be configuring diagnostics, monitoring and analytics so stay tuned for more.

About the Author

Isaac has been using Microsoft Azure for several years now, working across the various aspects of the service for a variety of customers and systems. He’s a Microsoft MVP and a Microsoft Azure Insider, as well as a proponent of functional programming, in particular F#. As a software developer by trade, he’s a big fan of platform services that allow developers to focus on delivering business value.