In Chapter 3, we covered all the platform as a service (PaaS) offerings. As you saw, there are many PaaS workloads in Azure, spanning different types of services. In future chapters, we explore data science and machine learning, specifically PaaS, network PaaS, and database PaaS. We repeat several times in this book that PaaS should be adopted whenever possible because of better service-level agreements, lower overhead in management, and ease in deployment.
In this chapter, we look at Azure Web Apps, one of the most common and extensively used PaaS and one of the earliest PaaS workloads in Azure.
What Are Web Apps?
The best way to describe Azure Web Apps is that it is hosted on an Internet Information Services (IIS) server or an Apache server. When you create a website or a web-based application like a .NET app, you need to publish it to an IIS server or an Apache server that is public facing. Once the website or application is published, users can see the site via URL.
The IIS or Apache server is responsible for running the published applications and responding to requests from users. There is often more than one application per IIS or Apache server, so the requests need to be routed to the right applications.
The IIS or Apache server also needs to handle user authentication for applications hosted on the server. When problems arise, the server administrators may need to troubleshoot or restart the IIS or Apache service. In IIS, server administrators may restart the application service pool to limit affecting all the other applications.
The management work involving IIS or Apache is moot if web apps are used.
Hands-on: Deploying a Web App
- 1.
Sign in to your Azure portal to create two web apps in two different geographical regions.
- 2.
In Azure Home view, go to New ➤ Web App, and click Create.
- 3.
Create a new resource group for testing. Select the runtime stack (ASP.NET v4.7 because it has Azure analytics support) and the Central US region, as shown in Figure 12-1.
- 4.
Name this web app soh-cope.
- 5.
Click Next : Monitoring.
- 6.
Validate that Application Insight is enabled, select the default location, and click Next : Tags.
- 7.
Tags are an easy method for identifying Azure services for different projects and billing purposes. Enter a name and a value and limit the resource to Web App. Click Next : Review + create.
- 8.
Review the information on the Summary page, as shown in Figure 12-2, and then click Create.
- 9.
Wait for the web app to be created. When done, you are notified and given the option to go to the resource, as shown in Figure 12-3. Click Go to resource.
- 10.
In the Overview pane, click Get publish profile, as shown in Figure 12-4.
- 11.
Take note of the URL for this web app, as shown in Figure 12-5. The URL is <Web_App_Name>.azurewebsites.net. This is a routable and live website on the Internet, which is why the name of the web app has to be globally unique.
- 12.
Open another browser or browser tab and go to the web app’s URL. You should see a page indicating that the site is properly configured and ready. Keep this tab open for now; you return to it after you publish your application to this web app.
You have successfully deployed a Windows-based web app, which is essentially a hosted IIS.
Self-Guided Exercise
Repeat the preceding exercise to create a second web app. This is good practice, but more importantly, we use these two web apps in the next chapter, so this exercise is not optional. In Chapter 13, we deploy the Azure Front Door service in front of these two web apps. Azure Front Door is a hosted load balancer, content delivery network (CDN), and web application firewall (WAF) service. In fact, Azure Front Door is a network PaaS.
Information for Second Web App
Configuration | Value |
---|---|
Web app name | soh-puca |
Resource group | (New) azure-v3-rg |
App service | ASP.NET v4.7 |
Content Management Systems on Web Apps
Aside from web applications, Azure Web Apps can host traditional websites. Content from websites is updated and managed via a content management system (CMS) , such as WordPress, Drupal, and Joomla, which are the most popular.
A CMS uses a database to store content for websites. Therefore, the general requirements are to deploy a database (preferably PaaS), deploy a web app, then initiate the installation process that targets the base URL of the website. If your website is a web app, this is the web app’s URL.
Alternatively, you can pick a deployment that includes the CMS already installed. On the Azure Marketplace, we found several CMSs that are ready to be deployed as a PaaS. The important thing is to make sure that the deployment is a web app, as shown in Figure 12-8, and not as a CMS on a virtual machine, as shown in Figure 12-9.
Using Azure Web Apps
Deploying an application to a web app, also known as publishing, remains the same for application developers and webmasters.
You can deploy applications directly from Visual Studio by publishing the application, or via FTP. If you are updating content in a CMS, you use the CMS’s interface.
For the next hands-on exercise, we publish a .NET web application to a web app. In later chapters, we continue using this web app for other exercises as we make modifications to the .NET web application.
Hands-on: Publishing to a Web App
- 1.
Go to the Azure portal.
- 2.
Launch Visual Studio and select Create a new project.
- 3.
Type ASP.NET in the search box. Select the ASP.NET web application (.NET Framework) from the results, and then click Next.
- 4.
Provide a name for the project. Use .NET Framework 4.7.2. Click Create.
- 5.
After the project has been created, publish it to the web app. Click Build from the Visual Studio menu and select Publish.
- 6.
Click Import Profile.
- 7.
Browse and select the publish profile that you downloaded in the previous exercise.
- 8.
Click Publish.
- 9.
After the web app is published, go to the browser or tab that you used to visit the site previously (<Web_App_Name>.azurewebsites.net) and click Refresh. You should see the ASP.NET application that you just published.
You can use the azurewebsites.net for your web application, but generally, you want to use a custom domain name. In this next exercise, we associate a custom domain to our website and look at other settings.
Hands-on: Adding a Custom Domain to a Web App
- 1.
In the Azure portal and with your web app selected, under Settings, click Custom Domains.
- 2.
In the Customs Domains pane, you see the IP address that has been assigned to this web app, and whether you want to enforce HTTPS traffic only. Take note of the IP address.
- 3.
Go to your DNS service provider, or use Azure DNS, and create an A record for the custom domain name. Azure DNS was covered in Chapter 3, so if you are using Azure DNS, please refer to Chapter 3 if necessary. If you do not have a custom domain yet, you can purchase one through the portal by selecting Buy Domain at the bottom of the pane.
Note Alternatively, you can also use a CNAME record and point the custom domain to the <Web_App_name>.azurewebsites.net URL.
- 4.
Click Add custom domain.
- 5.
Enter the custom domain name and click Validate. The portal resolves the DNS for the custom domain name to confirm that it is pointing to the web app via an A or CNAME record.
- 6.
If DNS is set up correctly, the type of record (A or CNAME) is automatically detected, and you are allowed to add the custom domain, as shown in Figure 12-10.
- 7.
Click Add custom domain.
- 8.
Once the custom domain is added, it shows up as an assigned domain without an SSL, as shown in Figure 12-11.
- 9.
Open another browser tab and navigate to the custom domain name. It resolves to this web app.
Hands-on: Monitoring a Web App
- 1.
Click Performance on the Azure portal, and then click Turn on Application Insights.
- 2.
Select Enable to enable Application Insights. Select Create a new resource to capture performance statistics, as shown in Figure 12-12.
- 3.
When Application Insights is turned on, click View Application Insights data, as shown in Figure 12-13.
When you refresh the page, or the next time you visit the portal and click Performance, you see the Performance dashboard instead of the screen shown in Figure 12-13.
- 4.
Unless you were porting over a high-traffic website, you would not see any statistics yet. Come back later or generate test traffic with a loading tool like open source k6 (see https://github.com/loadimpact/k6).
- 5.
Once a load test is done, refresh the Applications Insights pane and look at the statistics, as shown in Figure 12-14.
Hands-on: Self-Guided Exercises
Explore the other configuration options for Azure Web Apps and Applications Insights. Drill down to reports and add more metrics and filters. You can also create your own custom reports.
Look at the Authentication/Authorization pane and try out the different authentication methods if you need to secure your web app with login credentials.
Backup is another important topic that you can explore on your own. You can create periodic snapshots of your web apps and backups.
Securing your web app with TLS certificates is an important topic. We did not cover this topic in this chapter because it will be discussed in Azure Front Door in the next chapter. Communication between Azure Front Door and the web application pools containing web apps do not need to communicate over TLS.
Summary
This chapter introduced Azure Web Apps, which is the most common and widely deployed PaaS. Azure Web Apps is the platform that hosts many other services, not just websites. It is also a core developer tool and can be integrated with DevOps and CI/CD. Although we are ending the Azure Web Apps chapter here, we see it come up again in later chapters. In Chapter 13, we integrate Azure Front Door with Azure Web Apps. In Chapter 20, we explore CI/CD and slots and how Azure Web Apps allow developers to quickly deploy and manage applications. The full documentation for Azure Web Apps is on our GitHub repo at https://github.com/harris-soh-copeland-puca/azure-docs/tree/master/articles/app-service.