Create Azure App Service Web Apps

Create Azure App Service Web Apps is part of Develop Azure compute solutions topics. The total weight of this in the exam will be 25-30%. This training post is designed to help and provide readers with a better understanding of the topic mentioned.

Disclaimer: This is not a training article to help complete the Microsoft Azure AZ-204, but it provides a good insight into the areas within these topics. Labs and hands-on work are essential to passing most Microsoft Azure exams.

Create Azure App Service Web Apps:
Create an Azure App Service Web App

App Service

Azure App Service not only adds the power of Microsoft Azure to your application, such as security, load balancing, autoscaling, and automated management. You can also take advantage of its DevOps capabilities, such as continuous deployment from VSTS, GitHub, Docker Hub, and other sources; and package management, staging environments, custom domain, and SSL certificates.

With App Service, you pay for the Azure compute resources that you use. The compute resources you use are determined by the App Service plan that you run your apps on.

Scalable hosting for web applications:

  • Provides a quick way to host your web application in the cloud
  • Allows you to scale your web app without being required to redesign for scalability
  • Integrates with Visual Studio
  • Provides an open platform for many different programming languages

Advantages:

  • Near instant deployment
  • SSL and Custom Domain Names available in some tiers
  • WebJobs provide background processing for independent scaling
  • Can scale to larger machines without redeploying applications

Creating a Web App with Azure PowerShell

CommandNotes
New-AzResourceGroupCreates a resource group in which all resources are stored
New-AzAppServicePlanCreates an App Service plan
New-AzWebAppCreates an Azure Web App
Set-AzResourceModifies a resource in a resource group

Creating a Web App with Azure PowerShell

Creating an App Service plan with Azure PowerShell

Creating an App Service plan with Azure PowerShell

Create Azure App Service Web Apps:
enable diagnostics logging

Diagnostic Log

View article from Microsoft with full breakdown on how to create a diagnostic log

Create Azure App Service Web Apps:
configure web app settings including SSL, API, and connection strings

App Service settings

For ASP.NET developers, configuring app settings in App Service is similar to configuring them in <appSettings> in Web.config or appsettings.json. The difference is that the values in App Service override the values in Web.config or appsettings.json. You can keep development settings in Web.config or appsettings.json (for example, local MySQL password), but keeping production secrets (such as Azure MySQL database password) in App Service is ideal. This is because the same code uses your development settings when you debug locally, and it uses your production secrets when deployed to Azure.

žYou can configure:

Path mappings

žWindows: ž

  • Custom IIS handler mappings
  • žVirtual applications/directories

žContainerized: ž

  • Custom-mounted storage

Updating app runtimes

When adding a new version (major or minor), it installs side-by-side with existing versions. You can also manually upgrade your app to the new version. If you configured the runtime version in a configuration file (such as web.config and package.json), you need to upgrade by using the same method. If you used an App Service setting to configure your runtime version, you can change it in the Azure portal or by running an Azure CLI command in the Cloud Shell.

To update the application runtime, use the az webapp config set command with the appropriate parameter for your runtime.

OS and runtime patching

App Service is a platform as a service (PaaS), which means that the OS and application stack are managed for you by Azure; you only manage your application and its data.

Azure manages OS patching on two levels, the physical servers and the guest virtual machines (VMs) that run the App Service resources. Both are updated monthly. These updates are applied automatically, in a way that guarantees the high availability SLA of Azure services.

Inbound and outbound IP addresses

Each app has a single inbound IP address:

  • Regardless of scale-out quantity

Inbound IP address can change:

  • Delete an app and re-create it in a new resource group
  • Delete the last app in a resource group + region combination and re-create it
  • Delete an existing SSL binding

You can opt to use a state inbound IP

Each app has a set number of outbound IP addresses:

  • The set and quantity changes as you scale your app between tiers

When IP addresses change

Regardless of the number of scaled-out instances, each app has a single inbound IP address.

The inbound IP address might change when you perform one of the following actions:

  • Delete an app and recreate it in a different resource group.
  • Delete the last app in a resource group and region combination and recreate it.
  • Delete an existing SSL binding, such as during certificate renewal

Find outbound IP addresses

Create Azure App Service Web Apps:
Implement autoscaling rules, including scheduled autoscaling, and scaling by operational or system metrics

Autoscale

Autoscale is a built-in feature of Azure Cloud Services, Mobile Services, Virtual Machines, and websites that helps applications perform their best when demand changes. Of course, performance means different things for different applications. Some apps are CPU bound, others memory bound. For example, you could have a web app that handles millions of requests during the day and none at night. Autoscale can scale your service by any of these—or by a custom metric you define.

Autoscale metrics

MetricMetric identifierDescription
CPUCpuPercentageThe average amount of CPU time used across all instances of the plan
MemoryMemoryPercentageThe average amount of memory used across all instances of the plan
Data inBytesReceivedThe average incoming bandwidth used across all instances of the plan
Data outBytesSentThe average outgoing bandwidth used across all instances of the plan
HTTP queueHttpQueueLengthThe average number of both read and write requests that were queued on storage. A high disk queue length is an indication of an application that might be slowing down due to excessive disk I/O.
Disk queueDiskQueueLengthThe average number of HTTP requests that had to sit in the queue before being fulfilled. A high or increasing HTTP queue length is a symptom of a plan under a heavy load.

Autoscale patterns

  • žScale based on CPU ž
  • Scale differently on weekdays vs. weekends
  • žScale differently during holidays ž
  • Scale based on custom metrics

Autoscale concepts

Each resource can have one autoscale setting:

  • Autoscale settings can have one-to-many profiles
  • Profiles can have one-to-many rules

Autoscale increases instances horizontally within bounds:

  • Bounds are set by using the minimum, maximum, and default values

Thresholds are calculated at an instance level

  • Autoscale successful actions and failures are logged to the Activity Log

Autoscale workflow

1.Metrics are measured for a resource

2.When conditions are met (threshold surpassed), autoscale triggers:

a.Perform scale actions

b.Send notifications (alerts)

c.Send messages to webhooks for external automation

More topics on Develop Azure compute solutions:

Implement Iaas Solutions

Implement Azure functions

Microsoft Azure AZ-204 exam topics:

If you have covered the current topics in Develop Azure compute solutions then you can have a look at the other topic areas:

View full documentation Microsoft Azure: AZ-204 exam content from Microsoft

Leave a Reply