The following is from Azure Developer Training lab for AZ-203

Web Apps Overview

Azure App Service web apps (or just Web Apps) is a service for hosting web applications, REST APIs, and mobile back ends. You can develop in your favorite language, be it .NET, .NET Core, Java, Ruby, Node.js, PHP, orPython. Applications run and scale with ease on Windows-based environments.

Web Apps 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, package management, staging environments, custom domain, and SSL certificates.

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

Key features of App Service Web Apps

Here are some key features of App Service Web Apps:

• Multiple languages and frameworks – Web Apps has first-class support for ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP, or Python. You can also run PowerShell and other scripts or executables as back ground services.
• DevOps optimization – Set up continuous integration and deployment with Visual Studio Team Services, GitHub, BitBucket, Docker Hub, orAzure Container Registry. Promote updates through test and staging environments. Manage your apps in Web Apps by using AzurePowerShell or the cross-platform command-line interface (CLI).
• Global scale with high availability – Scale up or out manually or automatically. Host your apps anywhere in Microsoft’s global data center infrastructure, and the App Service SLA promises high availability.
• Connections to SaaS platforms and on-premises data – Choose from more than 50 connectors for enterprise systems (such as SAP), SaaS services (such as Salesforce), and internet services (such as Facebook).Access on-premises data using Hybrid Connections and Azure VirtualNetworks.
• Security and compliance – App Service is ISO, SOC, and PCI compliant.Authenticate users with Azure Active Directory or with social login (Google, Facebook, Twitter, and Microsoft. Create IP address restrictions and manage service identities.
• Application templates – Choose from an extensive list of application templates in the Azure Marketplace, such as WordPress, Joomla, andDrupal.
• Visual Studio integration – Dedicated tools in Visual Studio streamline the work of creating, deploying, and debugging.
• API and mobile features – Web Apps provides turn-key CORS support for RESTful API scenarios, and simplifies mobile app scenarios by enabling authentication, offline data sync, push notifications, and more.
• Serverless code – Run a code snippet or script on-demand without having to explicitly provision or manage infrastructure, and pay only for the compute time your code actually uses.

Besides Web Apps in App Service, Azure offers other services that can be used for hosting websites and web applications. For most scenarios, Web Apps is the best choice. For microservice architecture, consider Service Fabric. If you need more control over the VMs that your code runs on, consider AzureVirtual Machines.

Azure App Service plans

In App Service, an app runs in an App Service plan. An App Service plan defines a set of compute resources for a web app to run. These computer e sources are analogous to the server farm in conventional web hosting. One or more apps can be configured to run on the same computing resources (orin the same App Service plan).

When you create an App Service plan in a certain region (for example, WestEurope), a set of compute resources is created for that plan in that region.Whatever apps you put into this App Service plan run on these computer resources as defined by your App Service plan. Each App Service plan defines:

• Region (West US, East US, etc.)
• Number of VM instances
• Size of VM instances (Small, Medium, Large)
• Pricing tier (Free, Shared, Basic, Standard, Premium, PremiumV2,Isolated, Consumption)

The pricing tier of an App Service plan determines what App Service features you get and how much you pay for the plan. There are a few categories of pricing tiers:

• Shared compute:Free and Shared, the two base tiers, runs an app on the same Azure VM as other App Service apps, including apps of other customers. These tiers allocate CPU quotas to each app that runs on the shared resources, and the resources cannot scale out.
• Dedicated compute: The Basic, Standard, Premium, and PremiumV2tiers run apps on dedicated Azure VMs. Only apps in the same AppService plan share the same compute resources. The higher the tier, the more VM instances are available to you for scale-out.
• Isolated: This tier runs dedicated Azure VMs on dedicated Azure VirtualNetworks, which provides network isolation on top of compute isolation to your apps. It provides the maximum scale-out capabilities.
• Consumption: This tier is only available to function apps. It scales the functions dynamically depending on workload.

Note: App Service Free and Shared (preview) hosting plans are base tiers that run on the same Azure VM as other App Service apps. Some apps may belong to other customers. These tiers are intended to be used only for development and testing purposes.

Each tier also provides a specific subset of App Service features. These features include custom domains and SSL certificates, autoscaling, deployment slots, backups, Traffic Manager integration, and more. The higher the tier, the more features are available. To find out which features are supported in each pricing tier, see App Service plan details.

How does my app run and scale?

In the Free and Shared tiers, an app receives CPU minutes on a shared VM instance and cannot scale out. In other tiers, an app runs and scales as follows.

When you create an app in App Service, it is put into an App Service plan.When the app runs, it runs on all the VM instances configured in the AppService plan. If multiple apps are in the same App Service plan, they all share the same VM instances. If you have multiple deployment slots for an app, all deployment slots also run on the same VM instances. If you enable diagnostic logs, perform backups, or run WebJobs, they also use CPU cycles and memory on these VM instances.

In this way, the App Service plan is the scale unit of the App Service apps. If the plan is configured to run five VM instances, then all apps in the plan run on all five instances. If the plan is configured for autoscaling, then all apps in the plan are scaled out together based on the autoscale settings.

What if my app needs more capabilities or features?

Your App Service plan can be scaled up and down at any time. It is as simple as changing the pricing tier of the plan. You can choose a lower pricing tier at first and scale up later when you need more App Service features.

For example, you can start testing your web app in a Free App Service plan and pay nothing. When you want to add your custom DNS name to the web app, just scale your plan up to Shared tier. Later, when you want to add a custom SSL certificate, scale your plan up to Basic tier. When you want to have staging environments, scale up to Standard tier. When you need more cores, memory, or storage, scale up to a bigger VM size in the same tier.

The same works in the reverse. When you feel you no longer need the capabilities or features of a higher tier, you can scale down to a lower tier, which saves you money.

If your app is in the same App Service plan with other apps, you may want to improve the app’s performance by isolating the compute resources. You can do it by moving the app into a separate App Service plan.

Should I put an app in a new plan or an existing plan?

Since you pay for the computing resources your App Service plan allocates, you can potentially save money by putting multiple apps into one App Service plan. You can continue to add apps to an existing plan as long as the plan has enough resources to handle the load. However, keep in mind that apps in the same App Service plan all share the same compute resources. To determine whether the new app has the necessary resources, you need to understand the capacity of the existing App Service plan, and the expected load for the new app. Overloading an App Service plan can potentially cause downtime for your new and existing apps.

Isolate your app into a new App Service plan when:

• The app is resource-intensive.
• You want to scale the app independently from the other apps the existing plan.
• The app needs resource in a different geographical region.

This way you can allocate a new set of resources for your app and gain greater control of your apps.

Authentication and authorization in Azure AppService

Azure App Service provides built-in authentication and authorization support, so you can sign in users and access data by writing minimal or no code in your web app, API, and mobile back end, and also Azure Functions.

Secure authentication and authorization require deep understanding of security, including federation, encryption, JSON web tokens (JWT)management, grant types, and so on. App Service provides these utilities sothat you can spend more time and energy on providing business value to your customer.

Note: You’re not required to use App Service for authentication and authorization. Many web frameworks are bundled with security features, and you can use them if you like. If you need more flexibility than App Service provides, you can also write your own utilities.

How it works

The authentication and authorization module runs in the same sandbox as your application code. When it’s enabled, every incoming HTTP request passes through it before being handled by your application code.

This module handles several things for your app:

• Authenticates users with the specified provider
• Validates, stores, and refreshes tokens
• Manages the authenticated session
• Injects identity information into request headers

The module runs separately from your application code and is configured using app settings. No SDKs, specific languages, or changes to your application code are required.

User claims

For all language frameworks, App Service makes the user’s claims available to your code by injecting them into the request headers. For ASP.NET 4.6apps, App Service populates ClaimsPrincipal.Current with the authenticated user’s claims, so you can follow the standard .NET code pattern, including the [Authorize] attribute. Similarly, for PHP apps,App Service populates the _SERVER[‘REMOTE_USER’] variable.

For Azure Functions, ClaimsPrincipal.Current is not hydrated for .NET code, but you can still find the user claims in the request headers.

For more information, see Access user claims.

Token store

App Service provides a built-in token store, which is a repository of tokens that are associated with the users of your web apps, APIs, or native mobile apps. When you enable authentication with any provider, this token store is immediately available to your app. If your application code needs to access data from these providers on the user’s behalf, such as:

• post to the authenticated user’s Facebook timeline
• read the user’s corporate data from the Azure Active Directory GraphAPI or even the Microsoft Graph

You typically must write code to collect, store, and refresh these tokens in your application. With the token store, you just retrieve the tokens when you need them and tell App Service to refresh them when they become invalid.

The id tokens, access tokens, and refresh tokens cached for the authenticated session, and they’re accessible only by the associated user.

If you don’t need to work with tokens in your app, you can disable the token store.

Logging and tracing

If you enable application logging, you will see authentication and authorization traces directly in your log files. If you see an authentication error that you didn’t expect, you can conveniently find all the details by looking in your existing application logs. If you enable failed request tracing, you can see exactly what role the authentication and authorization module may have played in a failed request. In the trace logs, look for references to a module named EasyAuthModule_32/64.

Identity providers

App Service uses federated identity, in which a third-party identity provider manages the user identities and authentication flow for you. Five identity providers are available by default:

When you enable authentication and authorization with one of these providers, its sign-in endpoint is available for user authentication and for validation of authentication tokens from the provider. You can provide your users with any number of these sign-in options with ease. You can also integrate another identity provider or your own custom identity solution.

Authentication flow

The authentication flow is the same for all providers, but differs depending on whether you want to sign in with the provider’s SDK:

• Without provider SDK: The application delegates federated sign-in toApp Service. This is typically the case with browser apps, which can present the provider’s login page to the user. The server code manages the sign-in process, so it is also called server-directed flow or serverflow. This case applies to web apps. It also applies to native apps that sign users in using the Mobile Apps client SDK because the SDK opens a web view to sign users in with App Service authentication.
• With provider SDK: The application signs users in to the provider manually and then submits the authentication token to App Service for validation. This is typically the case with browser-less apps, which can’t present the provider’s sign-in page to the user. The application codemanages the sign-in process, so it is also called client-directed flow orclient flow. This case applies to REST APIs, Azure Functions, andJavaScript browser clients, as well as web apps that need more flexibility in the sign-in process. It also applies to native mobile apps that sign users in using the provider’s SDK.

Note: Calls from a trusted browser app in App Service calls another RESTAPI in App Service or Azure Functions can be authenticated using the server-directed flow. For more information, see Customize authentication andauthorization in App Service.

The table below shows the steps of the authentication flow.

For client browsers, App Service can automatically direct all unauthenticated users to /.auth/login/<provider>. You can also present users with one or more /.auth/login/<provider> links to sign in to your app using their provider of choice.

Authorization behavior

In the Azure portal, you can configure App Service authorization with a number of behaviors.

Allow all requests (default)

Authentication and authorization are not managed by App Service (turned off).

Choose this option if you don’t need authentication and authorization, or if you want to write your own authentication and authorization code.

Allow only authenticated requests

The option is Log in with <provider>. App Service redirects all anonymous requests to /.auth/login/<provider> for the provider you choose. If the anonymous request comes from a native mobile app, the returned response is an HTTP 401 Unauthorized.

With this option, you don’t need to write any authentication code in your app.Finer authorization, such as role-specific authorization, can be handled by inspecting the user’s claims.

Allow all requests, but validate authenticated requests

The option is Allow Anonymous requests. This option turns on authentication and authorization in App Service, but defers authorization decisions to your application code. For authenticated requests, App Service also passes along authentication information in the HTTP headers.

This option provides more flexibility in handling anonymous requests. For example, it lets you present multiple sign-in providers to your users. However, you must write code.

OS and runtime patching in Azure App Service

App Service is a Platform-as-a-Service, which means that the OS and application stack are managed for you by Azure; you only manage your application and its data. More control over the OS and application stack is available you in Azure Virtual Machines. With that in mind, it is never the less helpful for you as an App Service user to know more information, such as:

• How and when are OS updates applied?
• How is App Service patched against significant vulnerabilities (such as zero-day)?
• Which OS and runtime versions are running your apps?

For security reasons, certain specifics of security information are not published. However, the article aims to alleviate concerns by maximizing transparency on the process, and how you can stay up-to-date on security-related announcements or runtime updates.

How and when are OS updates applied?

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, which aligns to the monthly Patch Tuesday schedule. These updates are applied automatically, in a way that guarantees the high-availability SLA of Azure services.

How does Azure deal with significant vulnerabilities?

When severe vulnerabilities require immediate patching, such as zero-day vulnerabilities, the high-priority updates are handled on a case-by-case basis.Stay current with critical security announcements in Azure by visiting AzureSecurity Blog.

When are supported language runtimes updated, added, or deprecated?

New stable versions of supported language runtimes (major, minor, or patch)are periodically added to App Service instances. Some updates overwrite the existing installation, while others are installed side by side with existing versions. An overwrite installation means that your app automatically runs on the updated runtime. A side-by-side installation means you must manually migrate your app to take advantage of a new runtime version. For more information, see one of the subsections below.

Runtime updates and deprecations are announced here:

• https://azure.microsoft.com/updates/?product=app-service
• https://github.com/Azure/app-service-announcements/issues

Note: Information here applies to language runtimes that are built into anApp Service app. A custom runtime you upload to App Service, for example, remains unchanged unless you manually upgrade it.

New patch updates

Patch updates to .NET, PHP, Java SDK, or Tomcat/Jetty version are applied automatically by overwriting the existing installation with the new version. Node.js patch updates are installed side by side with the existing versions (similar to major and minor versions in the next section). New Python patch versions can be installed manually through site extensions), side by side with the built-in Python installations.

New major and minor versions

When a new major or minor version is added, it is installed side by side with the existing versions. You can 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 with 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, as shown in the following examples:

az webapp config set --net-framework-version v4.7 --resource-group <groupname> --name <appname> az webapp config set --php-version 7.0 --resource-group <groupname> --name <appname> az webapp config appsettings set --settings WEBSITE_NODE_DEFAULT_VERSION=8.9.3 --resource-group <groupname> --name <appname> az webapp config set --python-version 3.4 --resource-group <groupname> --name <appname> az webapp config set --java-version 1.8 --java-container Tomcat --java-container-version 9.0 --resource-group <groupname> --name <appname>

Deprecated versions

When an older version is deprecated, the removal date is announced so that you can plan your runtime version upgrade accordingly.

How can I query OS and runtime update status on my instances?

While critical OS information is locked down from access, the Kudu console enables you to query your App Service instance regarding the OS version and runtime versions.

The following table shows how to the versions of Windows and of the language runtime that are running your apps:

Note: Access to registry locationHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ComponentBased Servicing\Packages, where information on “KB” patches is stored, is locked down.

This document has been edited with the instant web content composer. The online instant HTML editor tools make a great resource that will help you a lot in your work. Save this link or add it to your bookmarks.

Inbound and outbound IP addresses in Azure AppService

Azure App Service is a multi-tenant service, except for App ServiceEnvironments. Apps that are not in an App Service environment (not in theIsolated tier) share network infrastructure with other apps. As a result, the inbound and outbound IP addresses of an app can be different, and can even change in certain situations.

App Service Environments use dedicated network infrastructures, so apps running in an App Service environment get static, dedicated IP addresses both for inbound and outbound connections.

When inbound IP changes

Regardless of the number of scaled-out instances, each app has a single inbound IP address. The inbound IP address may 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.

Get static inbound IP

Sometimes you might want a dedicated, static IP address for your app. To get a static inbound IP address, you need to configure an IP-based SSL binding.If you don’t actually need SSL functionality to secure your app, you can even upload a self-signed certificate for this binding. In an IP-based SSL binding, the certificate is bound to the IP address itself, so App Service provisions astatic IP address to make it happen.

When outbound IPs change

Regardless of the number of scaled-out instances, each app has a set number of outbound IP addresses at any given time. Any outbound connection from the App Service app, such as to a back-end database, uses one of the outbound IP addresses as the origin IP address. You can’t know before hand which IP address a given app instance will use to make the outbound connection, so your back-end service must open its firewall to all the outbound IP addresses of your app.

The set of outbound IP addresses for your app changes when you scale your app between the lower tiers (Basic, Standard, and Premium) and the Premium V2 tier.

You can find the set of all possible outbound IP addresses your app can use, regardless of pricing tiers, by looking for the possible OutboundIPAddresses property.

Find outbound IPs

To find the outbound IP addresses currently used by your app in the Azure portal, click Properties in your app’s left-hand navigation.

You can find the same information by running the following command in theCloud Shell.

az webapp show --resource-group <group_name> --name <app_name> --query outboundIpAddresses --output tsv

To find all possible outbound IP addresses for your app, regardless of pricingtiers, run the following command in the Cloud Shell.

az webapp show --resource-group <group_name> --name <app_name> --query possibleOutboundIpAddresses --output tsv

Azure App Service Hybrid Connections

Hybrid Connections is both a service in Azure and a feature in Azure AppService. As a service, it has uses and capabilities beyond those that are used in App Service. To learn more about Hybrid Connections and their usage outside App Service, see Azure Relay Hybrid Connections.

Within App Service, Hybrid Connections can be used to access application resources in other networks. It provides access from your app to an application endpoint. It does not enable an alternate capability to access your application. As used in App Service, each Hybrid Connection correlates to a single TCP host and port combination. This means that the HybridConnection endpoint can be on any operating system and any application, provided you are accessing a TCP listening port. The Hybrid Connections feature does not know or care what the application protocol is, or what you are accessing. It is simply providing network access.

How it works

The Hybrid Connections feature consists of two outbound calls to AzureService Bus Relay. There is a connection from a library on the host where your app is running in App Service. There is also a connection from theHybrid Connection Manager (HCM) to Service Bus Relay. The HCM is a relay service that you deploy within the network hosting the resource you are trying to access.

Through the two joined connections, your app has a TCP tunnel to a fixed host:port combination on the other side of the HCM. The connection uses TLS1.2 for security and shared access signature (SAS) keys for authentication and authorization.

When your app makes a DNS request that matches a configured HybridConnection endpoint, the outbound TCP traffic will be redirected through theHybrid Connection.

Note: This means that you should try to always use a DNS name for yourHybrid Connection. Some client software does not do a DNS lookup if the endpoint uses an IP address instead.

App Service Hybrid Connection benefits

There are a number of benefits to the Hybrid Connections capability, including:

• Apps can access on-premises systems and services securely.
• The feature does not require an internet-accessible endpoint.
• It is quick and easy to set up.
• Each Hybrid Connection matches to a single host:port combination, helpful for security.
• It normally does not require firewall holes. The connections are all outbound over standard web ports.
• Because the feature is network level, it is agnostic to the language used by your app and the technology used by the endpoint.
• It can be used to provide access in multiple networks from a single app.

Things you cannot do with Hybrid Connections

Things you cannot do with Hybrid Connections include:

• Mount a drive.
• Use UDP.
• Access TCP-based services that use dynamic ports, such as FTP PassiveMode or Extended Passive Mode.
• Support LDAP, because it can require UDP.
• Support Active Directory, because you cannot domain join an AppService worker.

Controlling App Service traffic by using AzureTraffic Manager

You can use Azure Traffic Manager to control how requests from web clients are distributed to apps in Azure App Service. When App Service endpoints are added to an Azure Traffic Manager profile, Azure Traffic Manager keeps track of the status of your App Service apps (running, stopped, or deleted) so that it can decide which of those endpoints should receive traffic.

Routing methods

Azure Traffic Manager uses four different routing methods. These methods are described in the following list as they pertain to Azure App Service.

• Priority: use a primary app for all traffic, and provide backups in case the primary or the backup apps are unavailable.
• Weighted: distribute traffic across a set of apps, either evenly or according to weights, which you define.
• Performance: when you have apps in different geographic locations, use the “closest” app in terms of the lowest network latency.
• Geographic: direct users to specific apps based on which geographic location their DNS query originates from.

For more information, see Traffic Manager routing methods.

App Service and Traffic Manager Profiles

To configure the control of App Service app traffic, you create a profile in Azure Traffic Manager that uses one of the three load balancing methods described previously, and then add the endpoints (in this case, App Service)for which you want to control traffic to the profile. Your app status (running, stopped, or deleted) is regularly communicated to the profile so that AzureTraffic Manager can direct traffic accordingly.

When using Azure Traffic Manager with Azure, keep in mind the following points:

• For app only deployments within the same region, App Service already provides failover and round-robin functionality without regard to app mode.
• For deployments in the same region that use App Service in conjunction with another Azure cloud service, you can combine both types of endpoints to enable hybrid scenarios.
• You can only specify one App Service endpoint per region in a profile.When you select an app as an endpoint for one region, the remaining apps in that region become unavailable for selection for that profile.
• The App Service endpoints that you specify in an Azure Traffic Manager profile appears under the Domain Names section on the Configure page for the app in the profile, but is not configurable there.
• After you add an app to a profile, the Site URL on the Dashboard of the app’s portal page displays the custom domain URL of the app if you have set one up. Otherwise, it displays the Traffic Manager profile URL (for example, contoso.trafficmanager.net). Both the direct domain name of the app and the Traffic Manager URL are visible on the app’s Configure page under the Domain Names section.
• Your custom domain names work as expected, but in addition to adding them to your apps, you must also configure your DNS map to point to theTraffic Manager URL.
• You can only add apps that are in standard or premium mode to an AzureTraffic Manager profile.

Azure App Service Local Cache overview

Note: Local cache is not supported in Function apps or containerized AppService apps, such as on App Service on Linux.

Azure web app content is stored on Azure Storage and is surfaced up in a durable manner as a content share. This design is intended to work with a variety of apps and has the following attributes:

• The content is shared across multiple virtual machine (VM) instances of the web app.
• The content is durable and can be modified by running web apps.
• Log files and diagnostic data files are available under the same shared content folder.
• Publishing new content directly updates the content folder. You can immediately view the same content through the SCM website and the running web app (typically some technologies such as ASP.NET do initiate a web app restart on some file changes to get the latest content).

While many web apps use one or all of these features, some web apps just need a high-performance, read-only content store that they can run from with high availability. These apps can benefit from a VM instance of a specific local cache.

The Azure App Service Local Cache feature provides a web role view of your content. This content is a write-but-discard cache of your storage content that is created asynchronously on-site startup. When the cache is ready, the site is switched to run against the cached content. Web apps that run on LocalCache have the following benefits:

• They are immune to latencies that occur when they access content onAzure Storage.
• They are immune to the planned upgrades or unplanned downtimes and any other disruptions with Azure Storage that occur on servers that serve the content share.
• They have fewer app restarts due to storage share changes.

How the local cache changes the behavior of AppService

• D:\home points to the local cache, which is created on the VM instance when the app starts up. D:\local continues to point to the temporary VM-specific storage.
• The local cache contains a one-time copy of the /site and /siteextensionsfolders of the shared content store, at D:\home\site andD:\home\siteextensions, respectively. The files are copied to the localcache when the app starts up. The size of the two folders for each app islimited to 300 MB by default, but you can increase it up to 2 GB.
• The local cache is read-write. However, any modification is discardedwhen the app moves virtual machines or gets restarted. Do not use thelocal cache for apps that store mission-critical data in the content store.
• D:\home\LogFiles and D:\home\Data contain log files and app data.The two subfolders are stored locally on the VM instance, and are copiedto the shared content store periodically. Apps can persist log files anddata by writing them to these folders. However, the copy to the sharedcontent store is best-effort, so it is possible for log files and data to belost due to a sudden crash of a VM instance.
• Log streaming is affected by the best-effort copy. You could observe up toa one-minute delay in the streamed logs.
• In the shared content store, there is a change in the folder structure ofthe LogFiles and Data folders for apps that use the local cache. Thereare now subfolders in them that follow the naming pattern of “uniqueidentifier” + time stamp. Each of the subfolders corresponds to a VMinstance where the app is running or has run.
• Other folders in D:\home remain in the local cache and are not copied tothe shared content store.
• App deployment through any supported method publishes directly to thedurable shared content store. To refresh the D:\home\site andD:\home\siteextensions folders in the local cache, the app needs to berestarted.
• The default content view of the SCM site continues to be that of theshared content store.

About App Service Environments

Overview

The Azure App Service Environment is an Azure App Service feature that provides a fully isolated and dedicated environment for securely running AppService apps at high scale. This capability can host your:

• Windows web apps
• Linux web apps (in Preview)
• Docker containers (in Preview)
• Mobile apps
• Functions

App Service environments (ASEs) are appropriate for application workloads that require:

• Very high scale
• Isolation and secure network access
• High memory utilization

Customers can create multiple ASEs within a single Azure region or across multiple Azure regions. This flexibility makes ASEs ideal for horizontally scaling stateless application tiers in support of high RPS workloads.

ASEs are isolated to running only a single customer’s applications and are always deployed into a virtual network. Customers have fine-grained control over inbound and outbound application network traffic. Applications can establish high-speed secure connections over VPNs to on-premises corporate resources.

• ASE comes with its own pricing tier, learn how the Isolated offering helps drive hyper-scale and security.
• App Service Environments v2 provide a surrounding to safeguard your apps in a subnet of your network and provides your own private deployment of Azure App Service.
• Multiple ASEs can be used to scale horizontally.
• ASEs can be used to configure security architecture, as shown in theAzureCon Deep Dive. To see how the security architecture shown in theAzureCon Deep Dive was configured, see the article on how to implement a layered security architecture with App Service environments.
• Apps running on ASEs can have their access gated by upstream devices, such as web application firewalls (WAFs).

Dedicated environment

An ASE is dedicated exclusively to a single subscription and can host 100 App Service Plan instances. The range can span 100 instances in a singleApp Service plan to 100 single-instance App Service plans, and everything in between.

An ASE is composed of front ends and workers. Front ends are responsible for HTTP/HTTPS termination and automatic load balancing of app requests within an ASE. Front ends are automatically added as the App Service plans in the ASE are scaled out.

Workers are roles that host customer apps. Workers are available in three fixed sizes:

• One vCPU/3.5 GB RAM
• Two vCPU/7 GB RAM
• Four vCPU/14 GB RAM

Customers do not need to manage front ends and workers. All infrastructure is automatically added as customers scale out their App Service plans. AsApp Service plans are created or scaled in an ASE, the required infrastructure is added or removed as appropriate.

There is a flat monthly rate for an ASE that pays for the infrastructure and doesn’t change with the size of the ASE. In addition, there is a cost per AppService plan vCPU. All apps hosted in an ASE are in the Isolated pricingSKU. For information on pricing for an ASE, see the App Service pricing page and review the available options for ASEs.

Creating App Service Web App

Using shell commands to create an App ServiceWeb App

Using scripts to deploy, configure, and manage Web Apps can make developing and testing Web Apps faster and more efficient. Below are some of the current options for a shell-based experience.

Azure Cloud Shell

Azure Cloud Shell is an interactive, browser-accessible shell for managingAzure resources. It provides the flexibility of choosing the shell experience that best suits the way you work. Linux users can opt for a Bash experience, while Windows users can opt for PowerShell.

Cloud Shell enables access to a browser-based command-line experience built with Azure management tasks in mind. Leverage Cloud Shell to work untethered from a local machine in a way only the cloud can provide.

Cloud Shell is managed by Microsoft so it comes with popular command-line tools and language support. Cloud Shell also securely authenticates automatically for instant access to your resources through the Azure CLI 2.0or Azure PowerShell cmdlets.

View the full list of tools installed in Cloud Shell.

Azure CLI

The Azure CLI 2.0 is Microsoft’s cross-platform command line experience for managing Azure resources. You can use it in your browser with Azure CloudShell, or install it on macOS, Linux, or Windows and run it from the command line.

Azure CLI 2.0 is optimized for managing and administering Azure resources from the command line, and for building automation scripts that work against the Azure Resource Manager. Using the Azure CLI 2.0, you can create VMs within Azure as easily as typing the following command:

Use the Cloud Shell to run the CLI in your browser, or install it on macOS,Linux, or Windows. Read the Get Started article to begin using the CLI. For information about the latest release, see the release notes.

A detailed reference is also available that documents how to use each individual Azure CLI 2.0 command.

Azure PowerShell

Azure PowerShell provides a set of cmdlets that use the Azure ResourceManager model for managing your Azure resources. You can use it in your browser with Azure Cloud Shell, or you can install it on your local machine and use it in any PowerShell session.

Use the Cloud Shell to run the Azure PowerShell in your browser, or install it on own computer. Then read the Get Started article to begin using it. For information about the latest release, see the release notes.

Creating a Web App with Azure CLI

Creating an Azure Services Web App with Azure CLI follows a consistent pattern:

1. Create the resource group
2. Create the App Service Plan
3. Create the web app
4. Deploy the app

The command for the last step will change depending on the whether you are deploying with FTP, GitHub, or some other source. There may be additional commands that are needed if you need to, for example, set the credentials fora local Git repository.

Sample script

Below is a sample script for creating a web app with a source deploymentfrom GitHub. For more samples please see the Azure CLI Samples page.

#!/bin/bash # Replace the following URL with a public GitHub repo URL gitrepo=https://github.com/Azure-Samples/php-docs-hello-world webappname=mywebapp$RANDOM # Create a resource group. az group create --location westeurope --name myResourceGroup # Create an App Service plan in `FREE` tier. az appservice plan create --name $webappname --resource-group myResourceGroup --sku FREE # Create a web app. az webapp create --name $webappname --resource-group myResourceGroup --plan $webappname # Deploy code from a public GitHub repository. az webapp deployment source config --name $webappname --resource-group myResourceGroup \ --repo-url $gitrepo --branch master --manual-integration # Copy the result of the following command into a browser to see the web app. echo http://$webappname.azurewebsites.net

Clean up deployment

After the sample script has been run, the following command can be used toremove the resource group and all resources associated with it.

az group delete --name myResourceGroup

Creating a Web App with Azure PowerShell

Creating an Azure Services Web App with Azure PowerShell follows aconsistent pattern:

1. Create the resource group
2. Create the App Service Plan
3. Create the web app
4. Deploy the app

The command for the last step will change depending on the whether you are deploying with FTP, GitHub, or some other source. There may be additional commands that are needed if you need to, for example, set the credentials fora local Git repository.

Sample script

Below is a sample script for creating a web app with a source deployment from GitHub. For more samples please see the Azure PowerShell Samples page.

# Replace the following URL with a public GitHub repo URL $gitrepo="https://github.com/Azure-Samples/app-service-web-dotnet-get-started.git" $webappname="mywebapp$(Get-Random)" $location="West Europe" # Create a resource group. New-AzureRmResourceGroup -Name myResourceGroup -Location $location # Create an App Service plan in Free tier. New-AzureRmAppServicePlan -Name $webappname -Location $location -ResourceGroupName myResourceGroup -Tier Free # Create a web app. New-AzureRmWebApp -Name $webappname -Location $location -AppServicePlan $webappname -ResourceGroupName myResourceGroup # Configure GitHub deployment from your GitHub repo and deploy once. $PropertiesObject = @{ repoUrl = "$gitrepo"; branch = "master"; isManualIntegration = "true"; } Set-AzureRmResource -PropertyObject $PropertiesObject -ResourceGroupName myResourceGroup -ResourceType Microsoft.Web/sites/sourcecontrols -ResourceName $webappname/web -ApiVersion 2015-08-01 -Force

Clean up deployment

After the script sample has been run, the following command can be used to remove the resource group, web app, and all related resources.

Create a Web App by using the Azure Portal

There are several ways you can create a web app. You can use the Azure portal, the Azure CLI, a script, or an IDE. Here, we are going to use the portal because it’s a graphical experience, which makes it a great learning tool. The portal helps you discover available features, add additional resources, and customize existing resources.

How to create a web app

When it’s time to host your own app, you visit the Azure portal and create a Web App. By creating a Web App in the Azure portal, you are actually creating a set of hosting resources in App Service, which you can use to host any web-based application that is supported by Azure, whether it be ASP.NETCore, Node.js, PHP, etc. The figure below shows how easy it is to configure the framework/language used by the app.

The Azure portal provides a template to create a web app. This template requires the following fields:

• App name: The name of the web app.
• Subscription: A valid and active subscription.
• Resource groupa: A valid resource group. The sections below explain in detail what a resource group is.
• OS: The operating system. The options are: Windows, Linux, and Docker containers. On Windows, you can host any type of application from a variety of technologies. The same applies to Linux hosting, though onLinux, any ASP.NET apps must be ASP.Net Core on the .NET Core framework. The final option is Docker containers, where you can deploy your containers directly over containers hosted and maintained byAzure.
• App Service plan/location: A valid Azure App Service plan. The sections below explain in detail what an App Service plan is.
• Applications Insights: You can turn on the Azure Application Insights option and benefit from the monitoring and metric tools that the Azure portal offers to help you keep an eye on the performance of your apps.

The Azure portal gives you the upper hand in managing, monitoring, and controlling your web app through the many available tools.

Deployment slots

Using the Azure portal, you can easily add deployment slots to an AppService web app. For instance, you can create a staging deployment slot where you can push your code to test on Azure. Once you are happy with your code, you can easily swap the staging deployment slot with the production slot. You do all this with a few simple mouse clicks in the Azure portal.

Continuous integration/deployment support

The Azure portal provides out-of-the-box continuous integration and deployment with Visual Studio Team Services, GitHub, Bitbucket, Dropbox, OneDrive, or a local Git repository on your development machine. You connect your web app with any of the above sources and App Service will dothe rest for you by auto-syncing code and any future changes on the code into the web app. Furthermore, with Visual Studio Team Services, you can define your own build and release process that ends up compiling your source code, running the tests, building a release, and finally pushing the release into a web app every time you commit the code. All that happens implicitly without any need to intervene.

Integrated Visual Studio publishing and FTP publishing

In addition to being able to set up continuous integration/deployment for your web app, you can always benefit from the tight integration with Visual Studio to publish your web app to Azure via Web Deploy technology. Also, Azure supports FTP, although you are better off not using FTP for publishing because it lacks some capability in Web Deploy to pick and choose only those files that were changed or added, and not just publish everything to Azure!Built-in auto scale support (automatic scale-out based on real-world load)

Baked into the web app is the ability to scale up/down or scale out.Depending on the usage of the web app, you can scale your app up/down by increasing/decreasing the resources of the underlying machine that is hosting your web app. Resources can be number of cores or the amount of RAM available.

Scaling out, on the other hand, is the ability to increase the number of machine instances that are running your web app.

What is a resource group?

A resource group is a method of grouping interdependent resources and services such as virtual machines, web apps, databases, and more for a given application and environment. Think of it as a folder, a place to group elements of your app.

Resource groups allow you to easily manage and delete resources. They also provide a way to monitor, control access, provision, and manage billing for collections of resources that are required to run an application or are used by a client.

App Service Web Jobs

Overview of WebJobs

WebJobs is a feature of Azure App Service that enables you to run a program or script in the same context as a web app, API app, or mobile app. There is no additional cost to use WebJobs.

The Azure WebJobs SDK can be used with WebJobs to simplify many programming tasks. Azure Functions provides another way to run programs and scripts. For a comparison between WebJobs and Functions, see Choose between Flow, Logic Apps, Functions, and WebJobs.

WebJob Types

There are two types of WebJobs, continuous and triggered. The following table describes the differences.

Note: A web app can time out after 20 minutes of inactivity. Only requests to the scm (deployment) site or to the web app’s pages in the portal reset the timer. Requests to the actual site don’t reset the timer. If your app runs continuous or scheduled WebJobs, enable Always On to ensure that theWebJobs run reliably. This feature is available only in the Basic, Standard, and Premium pricing tiers.

Supported file types for scripts or programs

The following file types are supported:

• .cmd, .bat, .exe (using Windows cmd)
• .ps1 (using PowerShell)
• .sh (using Bash)
• .php (using PHP)
• .py (using Python)
• .js (using Node.js)
• .jar (using Java)

Creating a continuous WebJob

1. In the Azure portal, go to the App Service page of your App Service webapp, API app, or mobile app.
2. Select WebJobs.
3. 
4. In the WebJobs page, select Add.
5. 
6. Use the Add WebJob settings as specified in the table .
7. 
   

   Setting	Sample Value	Description
   Name	myContinuousWebJob	A name that is unique within anApp Service app. Must start with a letter or a number and cannot contain special characters other than “-” and “_”.
   FileUpload	ConsoleApp.zip	A .zip file that contains your executable or script file as well as any supporting files needed to run the program or script. The supported executable or script filetypes are listed in Overview of Webjobs section of this course.
   Type	Continuous	Choose the type of of WebJob you want to create, this example uses continuous
   Scale	Multi instance	Available only for ContinuousWebJobs. Determines whether the program or script runs on all instances or just one instance. The option to run on multiple instances doesn’t apply to the Free or Sharedpricing tiers.

8. Click OK.The new WebJob appears on the WebJobs page.
9. 

Creating a manually triggered WebJob

1. In the Azure portal, go to the App Service page of your App Service webapp, API app, or mobile app.
2. Select WebJobs.
3. 
4. In the WebJobs page, select Add.
5. 
6. Use the Add WebJob settings as specified in the table
7. 
   

   Setting	Sample Value	Description
   Name	myContinuousWebJob	A name that is unique within anApp Service app. Must start witha letter or a number and cannotcontain special characters otherthan “-” and “_”.
   FileUpload	ConsoleApp.zip	A .zip file that contains yourexecutable or script file as well asany supporting files needed torun the program or script. Thesupported executable or scriptfile types are listed in Overview ofWebjobs section of this course.
   Type	Triggered	Choose the type of of WebJob youwant to create, this example usesTriggered.
   Triggers	Manual

8. Click OK.The new WebJob appears on the WebJobs page.
9. 

References