Azure App Service

Owned by Roger Cruz
Last updated: Feb 27, 2022
29 min read

 

Intro

Publishing a web app service

 

Documentation

 

Tips and Tidbits

  • A Web App is a web application that is hosted in an App Service.

  • The App Service is the managed service in Azure that enables you to deploy a web application and make it available to your customers on the Internet in a very short amount of time.

  • Azure App Service is an HTTP-based 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, or Python.

  • Applications run and scale with ease on both Windows and Linux-based environments.

  • Global scale with high availability - Scale up or out manually or automatically.

    • Host your apps anywhere in Microsoft's global datacenter infrastructure, and the App Service SLA promises high availability.

  • You can deploy your application to App Service as code or as a ready-to-run Docker image. 

  • Out-of-the-box continuous integration and deployment with Azure DevOps, GitHub, Bitbucket, FTP, or a local Git repository on your development machine.

    • Connect your web app with any of the above sources and App Service will do the rest for you by auto-syncing code and any future changes on the code into the web app

  • 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 is the ability to increase the number of machine instances that are running your web app.

    • In the Free and Shared tiers, an app receives CPU minutes on a shared VM instance and cannot scale out.

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

  • Websites unload if they sit idle for too long, which helps the system conserve resources. The new Always On setting (available for Standard tier websites) keeps your site up and running, which translates to higher availability and faster response times across the board.

  • App Service on Linux supports a number of language specific built-in images.

    •  

Deploy to App Service

  • Deploy to App Service

  • Azure supports automated deployment directly from:

    • Azure DevOps, GitHub, Bitbucket

  • Manual deployment via:

    • Git: App Service web apps feature a Git URL that you can add as a remote repository. Pushing to the remote repository will deploy your app.

    • CLI: webapp up is a feature of the az command-line interface that packages your app and deploys it.

    • Zip deploy: Use curl or a similar HTTP utility to send a ZIP of your application files to App Service.

    • FTP/S: FTP or FTPS is a traditional way of pushing your code to many hosting environments, including App Service.

 

 

Deployment Slots

  • Within a single Azure App Service web app, you can create multiple deployment slots.

  • Each slot is a separate instance of that web app, and it has a separate host name. You can deploy a different version of your web app into each slot.

  • Deployment slots are live apps with their own host names.

    • App content and configurations elements can be swapped between two deployment slots, including the production slot.

  • The traffic redirection is seamless, and no requests are dropped because of swap operations.

  • Deployment slots facilitate two common deployment patterns: blue/green and A/B testing.

    • Blue-green deployment involves deploying an update into a production environment that is separate from the live application.

      • After the deployment is validated, traffic routing is switched to the updated version.

    • A/B testing involves gradually routing some of the traffic to a staging site in order to test a new version of an app

  • Deployment slots are only available in the Standard, Premium or Isolated plan tiers

  • You can’t name a slot “Production”. It is reserved.

 

  • Examine slot swapping

  • Some configuration elements follow the content across a swap (not slot specific), whereas other configuration elements stay in the same slot after a swap (slot specific).

Settings that are swapped

Settings that aren't swapped

Settings that are swapped

Settings that aren't swapped

General settings, such as framework version, 32/64-bit, web sockets

Publishing endpoints

App settings (can be configured to stick to a slot)

Custom domain names

Connection strings (can be configured to stick to a slot)

Non-public certificates and TLS/SSL settings

Handler mappings

Scale settings

Public certificates

WebJobs schedulers

WebJobs content

IP restrictions

Hybrid connections *

Always On

Virtual network integration *

Diagnostic log settings

Service endpoints *

Cross-origin resource sharing (CORS)

Azure Content Delivery Network *

 

  • When auto swap is enabled from a slot into production, every time you push your code changes to that slot, App Service automatically swaps the app into production after it's warmed up in the source slot.

    • Auto swap isn't currently supported in web apps on Linux.

  • Go to your app's resource page and select the deployment slot you want to configure to auto swap.

    • The setting is on the Configuration > General settings page.

    • Set Auto swap enabled to On. Then select the desired target slot for Auto swap deployment slot, and select Save on the command bar.



  • Specify custom warm-up

  • Some apps might require custom warm-up actions before the swap.

    • The applicationInitialization configuration element in web.config lets you specify custom initialization actions.

    • The swap operation waits for this custom warm-up to finish before swapping with the target slot. 

    • Most common deployment slot swap failures and how to fix them has a good explanation on appInit.

      • AppInit module uses the list of URL paths specified inside web.config file and makes internal HTTP requests to each of those.

        • All these requests are within the web app process.

  • If AppInit is not enabled then swap process just makes an HTTP request to the root path of the webapp on each web worker and as long as it receives some HTTP response it considers the warmup complete.

  • You can also customize the warm-up behavior with one or both of the following app settings:

    • WEBSITE_SWAP_WARMUP_PING_PATH: The path to ping to warm up your site..

    • WEBSITE_SWAP_WARMUP_PING_STATUSES: Valid HTTP response codes for the warm-up operation.

  • IIS 8.0 Application Initialization

  • Documentation on the IIS element Application Initialization <applicationInitialization>

    • The <applicationInitialization> element specifies that web application initialization is performed proactively before a request is received.

    • An application can start up more quickly if initialization sequences such as initializing connections, priming in-memory caches, running queries, and compiling page code are performed before the HTTP request is received.

    • Application Initialization can start the initialization process automatically whenever an application is started.

    • Application initialization also enables you to enhance the user experience during initialization by redirecting a request to static pages, such as a placeholder or splash screen.

    • Once the site is loaded, it will stop mapping the managed request to the static page, and will start serving the dynamic content.

    • How to script warm up of CloudService instances in Azure? Shows how to create an API Controller for doing additional initialization.

    • A hack to warm up functions: Application Initialization with Azure Functions in a dedicated plan only

    • Another hack to run a PHP script as part of the applicationInitialization workflow. It can be used to clear a local cache, for example.

    • Sitecore WarmUp Azure for Outscaling

    • Another hack to warm up other services when the web app restarts: Warming up your WCF Service on an Azure Cloud Service

 

 

  • Route traffic in App Service

  • By default, all client requests to the app's production URL (http://<app_name>.azurewebsites.net) are routed to the production slot.

    • You can route a portion of the traffic to another slot.

    • This feature is useful if you need user feedback for a new update, but you're not ready to release it to production.

       

    • After a client is automatically routed to a specific slot, it's "pinned" to that slot for the life of that client session.

      • On the client browser, you can see which slot your session is pinned to by looking at the x-ms-routing-name cookie in your HTTP headers.

      • A request that's routed to the "staging" slot has the cookie x-ms-routing-name=staging.

      • A request that's routed to the production slot has the cookie x-ms-routing-name=self.



         

      • To let users opt out of your beta app, for example, you can put this link on your webpage:

         

        <a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>





  • An app ( Web Apps, API Apps, or Mobile Apps) runs in an App Service plan.

    • An App Service plan defines a set of compute resources for a web app to run.

    • One or more apps can be configured to run on the same computing resources (or in the same App Service plan).

    • Every App Service web app you create must be assigned to a single App Service plan that runs it.

  • When the app runs, it runs on all the VM instances configured in the App Service 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. 

  • Deploy the app to the production slot

az webapp up --location eastus --name rogercruzapp --html

 

#!/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 STANDARD tier (minimum required by deployment slots). az appservice plan create --name $webappname --resource-group myResourceGroup --sku S1 # Create a web app. az webapp create --name $webappname --resource-group myResourceGroup \ --plan $webappname #Create a deployment slot with the name "staging". az webapp deployment slot create --name $webappname --resource-group myResourceGroup \ --slot staging # Deploy sample code to "staging" slot from GitHub. az webapp deployment source config --name $webappname --resource-group myResourceGroup \ --slot staging --repo-url $gitrepo --branch master --manual-integration # Copy the result of the following command into a browser to see the staging slot. echo http://$webappname-staging.azurewebsites.net # Swap the verified/warmed up staging slot into production. az webapp deployment slot swap --name $webappname --resource-group myResourceGroup \ --slot staging # Copy the result of the following command into a browser to see the web app in the production slot. echo http://$webappname.azurewebsites.net

 

Networking

 

  • Discover App Service networking features

  • By default, apps hosted in App Service are accessible directly through the internet and can reach only internet-hosted endpoints.

  • But for many applications, you need to control the inbound and outbound network traffic.

  • There are two main deployment types for Azure App Service.

    • The multitenant public service hosts App Service plans in the Free, Shared, Basic, Standard, Premium, PremiumV2, and PremiumV3 pricing SKUs.

    • There is also the single-tenant App Service Environment (ASE) hosts Isolated SKU App Service plans directly in your Azure virtual network.

 

 

App Service has two variations:

  • The dedicated compute pricing tiers, which include the Basic, Standard, Premium, Premium v2, and Premium v3.

  • The App Service Environment (ASE), which deploys directly into your virtual network with dedicated supporting infrastructure and is using the Isolated and Isolated v2 pricing tiers.

  • The VNet integration feature is used in Azure App Service dedicated compute pricing tiers.

  • If your app is in an App Service Environment, it's already in a virtual network and doesn't require use of the VNet integration feature to reach resources in the same virtual network. 

 

  • Because there are many different customers in the same App Service scale unit, you can't connect the App Service network directly to your network.

  • Instead of connecting the networks, you need features to handle the various aspects of application communication.

MULTITENANT APP SERVICE NETWORKING FEATURES

 

Inbound features

Outbound features

App-assigned address

Hybrid Connections

Access restrictions

Gateway-required VNet Integration

Service endpoints

VNet Integration

Private endpoints

 

 

VNET Integration

  • Integrate your App Service with Azure virtual networks

  • Integrating Azure services to an Azure virtual network enables private access to the service from virtual machines or compute resources in the virtual network.

  • You can integrate Azure services in your virtual network with the following options:

    • Deploying dedicated instances of the service into a virtual network. The services can then be privately accessed within the virtual network and from on-premises networks.

    • Using Private Link to access privately a specific instance of the service from your virtual network and from on-premises networks.

    • You can also access the service using public endpoints by extending a virtual network to the service, through Service Endpoints.

      • Service Endpoints allow service resources to be secured to the virtual network.

  • Gateway-required virtual network integration

  • Gateway-required virtual network integration supports connecting to a virtual network in another region or to a classic virtual network.

    • Cross region vnet integration requires a vpn gateway and a point to site vpn connection.

  • Service endpoint is for regional or same region virtual network integration.

 

 

  • Virtual Network Integration supports only one virtual interface per worker.

  • One virtual interface per worker means one regional virtual network integration per App Service plan.

    • All the apps in the same App Service plan can use the same virtual network integration.

  • Apps in App Service are hosted on worker roles.

    • Regional virtual network integration works by mounting virtual interfaces to the worker roles with addresses in the delegated subnet.

    • Because the from address is in your virtual network, it can access most things in or through your virtual network like a VM in your virtual network would.

    • Virtual network integration doesn't enable your web apps to be accessed privately from a VM in the integration vnet

    • When regional virtual network integration is enabled, your app makes outbound calls through your virtual network.

      • The outbound addresses that are listed in the app properties portal are the addresses still used by your app.

      • However, if your outbound call is to a virtual machine or private endpoint in the integration virtual network or peered virtual network, the outbound address will be an address from the integration subnet.

App Settings

 

 

 

App Service General Configuration

  • Configure general settings

  • ARR affinity: In a multi-instance deployment, ensure that the client is routed to the same instance for the life of the session. You can set this option to Off for stateless applications.

 

  • Always On: Keep the app loaded even when there's no traffic.

    • By default, Always On is not enabled and the app is unloaded after 20 minutes without any incoming requests.

    • It's required for continuous WebJobs or for WebJobs that are triggered using a CRON expression.

  • Incoming client certificates: require client certificates in mutual authentication.

    • Check to make sure that your web app is not in the F1 or D1 tier as Custom SSL is not supported in the F1 or D1 tier.

 

App Configuration

 

 

Configure path mappings

 

  • Configure path mappings

  • By default, App Service starts your app from the root directory of your app code.

    • But certain web frameworks don't start in the root directory.

    • For example, Laravel starts in the public subdirectory.

      • Such an app would be accessible at http://contoso.com/public, for example, but you typically want to direct http://contoso.com to the public directory instead. 

  • For Windows apps, you can customize the IIS handler mappings and virtual applications and directories.

  • Handler mappings let you add custom script processors to handle requests for specific file extensions.

 

  • You can add custom storage for your containerized app.

  • Containerized apps include all Linux apps and also the Windows and Linux custom containers running on App Service.

    • Storage type: Azure Blobs or Azure Files. Windows container apps only support Azure Files.



 

Alerts and Action Groups

 

Diagnostics Logging

  • Enable diagnostics logging for apps in Azure App Service

  • Enable diagnostic logging

  • Application Logging allows you to store application logs in the Windows or Linux filesystem. For Windows VMs, they can also be sent to a blob.

    • The messages can be generated by the web framework you choose, or from your application code directly using the standard logging pattern of your language.

    • Each message is assigned one of the following categories: Critical, Error, Warning, Info, Debug, and Trace

    •  Application Logging (Filesystem) or Application Logging (Blob), or both.

      • The Filesystem option is for temporary debugging purposes, and turns itself off in 12 hours.

      • The Blob option is for long-term logging, and needs a blob storage container to write logs to.

  • Detailed Error Messaging can only be written to the local filesystem on Windows.

    • Copies of the .htm error pages that would have been sent to the client browser.

  • Failed Request tracing can only be written to the local filesystem on Windows.

    • Detailed tracing information on failed requests, including a trace of the IIS components used to process the request and the time taken in each component

  • WebServer logging can only be enabled for Windows machines.

    • It stores the IIS logs in the local file system or blob.

    • Raw HTTP request data in the W3C extended log file format.

    • Each log message includes data such as the HTTP method, resource URI, client IP, client port, user agent, response code, and so on.

  • Deployment logging for Windows and Linux on the local file system only.

    • Logs for when you publish content to an app. Deployment logging happens automatically and there are no configurable settings for deployment logging. 

 

 

  • ASP.NET applications can use the System.Diagnostics.Trace class to log information to the application diagnostics log.

  • System.Diagnostics.Trace.TraceError("If you're seeing this, something bad happened");

 

Configure Logging Via Azure AZ CLI

 

az webapp log

  • Configure logging for container (Configure gathering STDOUT and STDERR output from container.)

 

 

WebJobs

 

 

WebJob types

The following table describes the differences between continuous and triggered WebJobs.

Continuous

Triggered

Continuous

Triggered

Starts immediately when the WebJob is created. To keep the job from ending, the program or script typically does its work inside an endless loop. If the job does end, you can restart it. Typically used with WebJobs SDK.

Starts only when triggered manually or on a schedule.

Runs on all instances that the web app runs on. You can optionally restrict the WebJob to a single instance.

Runs on a single instance that Azure selects for load balancing.

Supports remote debugging.

Doesn't support remote debugging.

Code is deployed under \site\wwwroot\app_data\Jobs\Continuous.

Code is deployed under \site\wwwroot\app_data\Jobs\Triggered.

 

 

 

 

App Service On Linux

 

  • Run a custom container in Azure

  • App Service on Linux

  • App Service on Linux provides pre-defined application stacks on Linux with support for languages such as .NET, PHP, Node.js and others.

  • You can also use a custom Docker image to run your web app on an application stack that is not already defined in Azure.

  • Supported languages include: Node.js, Java (JRE 8 & JRE 11), PHP, Python, .NET Core, and Ruby.

  • If the runtime your application requires is not supported in the built-in images, you can deploy it with a custom container.

  • App Service on Linux is not supported on Shared pricing tier.

  • Outdated after January 21, 2021: You can't mix Windows and Linux apps in the same App Service plan.

  • You can get a list of new runtimes with az webapp list-runtimes --linux

 

  • Linux and Windows App Service plans can now share resource groups.

    • This limitation has been lifted from the platform and existing resource groups have been updated to support this.

    • In the past, you needed a different resource group for Linux and Windows.

  • App Service on Linux is not supported on Shared pricing tier.

Use persistent shared storage

  • Configure a custom container for Azure App Service

  • You can use the /home directory in your custom container file system to persist files across restarts and share them across instances.

    • The /home directory is provided to enable your custom container to access persistent storage.

    • When persistent storage is disabled, then writes to the /home directory are not persisted across app restarts or across multiple instances.

    • When persistent storage is enabled, all writes to the /home directory are persisted and can be accessed by all instances of a scaled-out app.

    • Additionally, any contents inside the /home directory of the container are overwritten by any existing files already present on the persistent storage when the container starts.

    • By default, persistent storage is disabled on custom containers and the setting is exposed in the app settings. To enable it, set the WEBSITES_ENABLE_APP_SERVICE_STORAGE app setting value to true

    • For Windows containers, the mount point is C:\home

 

 

App Service And Containers

 

 

az webapp create

Create a web app with an image from a private Azure Container Registry.


az webapp config container set

  • Set an existing web app's container settings

    • --docker-registry-server-password: The container registry server password.

    • --docker-registry-server-url: The container registry server url.

    • --docker-registry-server-user: The container registry server username.

 

Blocking Access To App

 

Using Your Custom Domain With Your App

 

TLS Mutual Auth

 

  • A certificate uploaded into an app is stored in a deployment unit that is bound to the app service plan's resource group and region combination (internally called a webspace).

    • This makes the certificate accessible to other apps in the same resource group and region combination.

  • Configure TLS mutual authentication for Azure App Service

  • In App Service, TLS termination of the request happens at the frontend load balancer.

  • When forwarding the request to your app code with client certificates enabled, App Service injects an X-ARR-ClientCert request header with the client certificate.

  • App Service does not do anything with this client certificate other than forwarding it to your app.

  • Your app code is responsible for validating the client certificate.

    • For ASP.NET apps only, the client certificate is available through the HttpRequest.ClientCertificate property.

    • For other application stacks (Node.js, PHP, etc.), the client cert is available in your app through a base64 encoded value in the X-ARR-ClientCert request header.

    • Access client certificate

 

Option

Description

Option

Description

Create a free App Service managed certificate

A private certificate that's free of charge and easy to use if you just need to secure your custom domain in App Service.

Purchase an App Service certificate

A private certificate that's managed by Azure. It combines the simplicity of automated certificate management and the flexibility of renewal and export options.

Import a certificate from Key Vault

Useful if you use Azure Key Vault to manage your certificates.

Upload a private certificate

If you already have a private certificate from a third-party provider, you can upload it.

Upload a public certificate

Public certificates are not used to secure custom domains, but you can load them into your code if you need them to access remote resources.

 

  • If you want to use a private certificate in App Service, your certificate must meet the following requirements:

    • Exported as a password-protected PFX file, encrypted using triple DES.

    • Contains private key at least 2048 bits long

    • Contains all intermediate certificates in the certificate chain

  • To secure a custom domain in a TLS binding, the certificate has additional requirements:

    • Contains an Extended Key Usage for server authentication (OID = 1.3.6.1.5.5.7.3.1)

    • Signed by a trusted certificate authority

 

  • To create custom TLS/SSL bindings or enable client certificates for your App Service app, your App Service plan must be in the Basic, Standard, Premium, or Isolated tier.

    • Custom SSL is not supported in the F1 or D1 tier.

  • The free App Service managed certificate is a turn-key solution for securing your custom DNS name in App Service.

    • It's a TLS/SSL server certificate that's fully managed by App Service and renewed continuously and automatically in six-month increments, 45 days before expiration.

  • If your certificate authority gives you multiple certificates in the certificate chain, you need to merge the certificates in order.

  • To export your certificate to PFX, run the following command.

    • Replace the placeholders <private-key-file> and <merged-certificate-file> with the paths to your private key and your merged certificate file.

 

  • When you enable mutual auth for your application, all paths under the root of your app require a client certificate for access.

    • To remove this requirement for certain paths, define exclusion paths as part of your application configuration.

 

  • If you visit the slot’s URL, you will get a Browser popup to specify the client certificate

 

Authentication

  • Authentication and authorization in Azure App Service and Azure Functions

  • Explore authentication and authorization in App Service

  • 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.

  • Azure App Service provides built-in authentication and authorization capabilities (sometimes referred to as "Easy Auth"), so you can sign in users and access data by writing minimal or no code in your web app, RESTful API, and mobile back end, and also Azure Functions. 

  • You're not required to use this feature for authentication and authorization.

    • You can use the bundled security features in your web framework of choice, or you can write your own utilities.

  • Azure App Service allows you to integrate a variety of auth capabilities into your web app or API without implementing them yourself.

  • It’s built directly into the platform and doesn’t require any particular language, SDK, security expertise, or even any code to utilize.

  • You can integrate with multiple login providers. For example, Azure AD, Facebook, Google, Twitter.

    • 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.

 

  • App Service uses federated identity, in which a third-party identity provider manages the user identities and authentication flow for you.

  • Enabling this feature will cause all requests to your application to be automatically redirected to HTTPS, regardless of the App Service configuration setting to enforce HTTPS.

  • The authentication and authorization middleware component is a feature of the platform that runs on the same VM as your application. When it's enabled, every incoming HTTP request passes through it before being handled by your application.

  • 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 and clients with the specified identity provider(s)

      • Validates, stores, and refreshes OAuth tokens issued by the configured identity provider(s)

      • Manages the authenticated session

      • Injects identity information into HTTP request headers

 

The table below shows the steps of the authentication flow.

Step

Without provider SDK

With provider SDK

Step

Without provider SDK

With provider SDK

Sign user in

Redirects client to /.auth/login/<provider>.

Client code signs user in directly with provider's SDK and receives an authentication token. For information, see the provider's documentation.

Post-authentication

Provider redirects client to /.auth/login/<provider>/callback.

Client code posts token from provider to /.auth/login/<provider> for validation.

Establish authenticated session

App Service adds authenticated cookie to response.

App Service returns its own authentication token to client code.

Serve authenticated content

Client includes authentication cookie in subsequent requests (automatically handled by browser).

Client code presents authentication token in X-ZUMO-AUTH header (automatically handled by Mobile Apps client SDKs).

  • 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.



  • Allow unauthenticated requests

    • This option defers authorization of unauthenticated traffic 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.

 

Quickstart: Add sign-in with Microsoft to a web app

  • Register your application

  • Add https://localhost:44368/ in Redirect URI, and select Register.

  • Under Manage, select Authentication.

  • In the Implicit grant and hybrid flows section, select ID tokens.

  • Edit Web.config and replace the parameters ClientId, Tenant, and redirectUri with:

Integrated Windows Authentication

  • Integrated Windows Authentication

  • If your desktop or mobile application runs on Windows, and on a machine connected to a Windows domain - AD or AAD joined - it is possible to use the Integrated Windows Authentication (IWA) to acquire a token silently.

  • No UI is required when using the application.

 

 



Single Sign-On (SSO) for Web App

 

  • You plan to deploy an Azure web app named App1 that will use Azure Active Directory (Azure AD) authentication.

    • App1 will be accessed from the internet by the users at your company.

    • All the users have computers that run Windows 10 and are joined to Azure AD.

    • Provide solution to ensure that the users can connect to App1 without being prompted for authentication and can access App1 only from company-owned computers.

    • See Using azure active directory authentication in your web application

      • Register your app with Azure AD Tenant and turn on SSO with conditional access

 

Highly available multi-region web application

 

 

  • Primary and secondary regions. This architecture uses two regions to achieve higher availability. The application is deployed to each region. During normal operations, network traffic is routed to the primary region. If the primary region becomes unavailable, traffic is routed to the secondary region.

  • Front Door. Front Door routes incoming requests to the primary region. If the application running that region becomes unavailable, Front Door fails over to the secondary region.

  • Geo-replication of SQL Database and/or Cosmos DB.

 

Scale

Manage app features

  • Manage app features

  • Feature management overview

  • Feature management is a modern software-development practice that decouples feature release from code deployment and enables quick changes to feature availability on demand.

  • It uses a technique called feature flags (also known as feature toggles, feature switches, and so on) to dynamically administer a feature's lifecycle.

  • To use feature flags effectively, you need to externalize all the feature flags used in an application.

    • This approach allows you to change feature flag states without modifying and redeploying the application itself.

  • Azure App Configuration is designed to be a centralized repository for feature flags.

    • You can use it to define different kinds of feature flags and manipulate their states quickly and confidently.

 

Step-By-Step Guide



These commands come from Microsoft's "Store application data with Azure Blob storage"

Azure CLI Commands



 

 

  • future deployments are synced with "az webapp deployment source sync..."

 

Continuous Delivery with GitHub. Example:
Create a GitHub personal access token (PAT):

 

 

 

Continuous Deployment

 

Runtime

Root directory files

Runtime

Root directory files

ASP.NET (Windows only)

*.sln, *.csproj, or default.aspx

ASP.NET Core

*.sln or *.csproj

PHP

index.php

Ruby (Linux only)

Gemfile

Node.js

server.js, app.js, or package.json with a start script

Python

*.py, requirements.txt, or runtime.txt

HTML

default.htm, default.html, default.asp, index.htm, index.html, or iisstart.htm

WebJobs

<job_name>/run.<extension> under App_Data/jobs/continuous for continuous WebJobs, or App_Data/jobs/triggered for triggered WebJobs. For more information, see

Kudu WebJobs documentation

.

Functions

See Continuous deployment for Azure Functions.

  • Uses Kudu

  • By default, Kudu executes the build steps for your .NET application (dotnet build).

  • To customize your deployment, include a .deployment file in the repository root. For more information, see Customize deployments and Custom deployment script

    • Deployment configuration files let you override the default heuristics of deployment by allowing you to specify a project or folder to be deployed.

    • It has to be at the root of the repository and it's in .ini format. Here are some examples:

      •  

      • this command can be just running a script (batch file) that has all that is required for your deployment, like copying files from the repository to the web root directory for example.

  • Custom Deployment Scripts For Microsoft Azure Web Apps (Websites) Using Git Deployment

    • For example for an MVC web app it'll find the solution file and determine which project is the actual web app project and with those it'll msbuild that project, the artifacts from the build will be placed in a temporary folder and only the files that were changed will be copied to the wwwroot location for the actual deployment.

    • The nice thing is that files that were removed will also be removed on the wwwroot location but only if they were actually deployed the previous time (so files that are generated on the fly on the wwwroot directory won't be removed).

  • If you use Visual Studio, let Visual Studio create a repository for you. Your project will immediately be ready for deployment via Git.

  • Visual Studio add pre-build event that always runs (C# project)

Run From Package

  • Run From Package is an exciting new feature which lets you run a Web App or Function App by simply pointing it to a zip file containing your files.

  • To use it, just add an Azure App Setting called WEBSITE_RUN_FROM_PACKAGE, and point it to your zip (typically using a storage SAS URL), e.g.

Check out this short video which demonstrates using this

  • Run your Azure Functions from a package file

    • In Azure, you can run your functions directly from a deployment package file in your function app.

    • The other option is to deploy your files in the d:\home\site\wwwroot directory of your function app.

 

Assigning A Managed Identity To App

You can assigned a "managed identity" to app via the following command

 

Assigning Managed Identity



The principalId is the app's new identity in Azure Active Directory 

JSON Returned Value

App Registration

  • See

 

 

Storing Web App Session State And HTTP Responses

 

  • In Azure, you can store ASP.NET Session State in a SQL database, Azure Table Storage or an in-memory distributed cache such as REDIS

    • A SQL database isn’t ideal for storing session state.

      • Relational databases were never really designed for Blob storage, and an ASP.NET Session State object is stored as a Blob.

      • This can cause performance issues and become a scalability bottleneck.

    • Similarly, Azure Table Storage isn’t ideal for Blob storage.

      • It’s intended for storing structured entities.

      • Although it’s more scalable than a SQL database, it’s still not ideal for storing ASP.NET Session State.

    • Using in-memory distributed cache in Azure also helps with ASP.NET Session State, ASP.NET View State and ASP.NET Output Cache.

      • An in-memory distributed cache is better suited for storing ASP.NET Session State in Azure.

      • It’s faster and more scalable than the other two options.

      • It also replicates sessions so there’s no data loss if a cache server goes down.

      • If you store sessions in a separate dedicated caching tier, then Web roles and Web server VMs become stateless, which is good because you can bring them down without losing any session data.

      • While running ASP.NET Session State in cache is ideal from a performance standpoint, if the cache goes down, your entire app will go down.

        • And, of course, whatever is in your session would also be gone.

        • The new Redis Cache for Azure session state provider will have a way you can know when these types of issues happen and at least display them to the user in a clean way.

  • This is where an in-memory distributed cache can be helpful. It lets you cache as much data as you want.

    • It can reduce expensive database reads by as much as 90 percent.

 

Use a TLS/SSL certificate in your code in Azure App Service

  • Use a TLS/SSL certificate in your code in Azure App Service

  • In your application code, you can access the public or private certificates you add to App Service.

  • Your app code may act as a client and access an external service that requires certificate authentication, or it may need to perform cryptographic tasks.

  • This how-to guide shows how to use public or private certificates in your application code.

  • select App Services > <app-name>.

    • From the left navigation of your app, select TLS/SSL settings, then select Private Key Certificates (.pfx) or Public Key Certificates (.cer).

    • Find the certificate you want to use and copy the thumbprint.

  • To access a certificate in your app code, add its thumbprint to the WEBSITE_LOAD_CERTIFICATES app setting, by running the following command:

  • The WEBSITE_LOAD_CERTIFICATES app setting makes the specified certificates accessible to your Windows hosted app in the Windows certificate store, in Current User\My.

  • In C# code, you access the certificate by the certificate thumbprint

Load certificate from file

  • If you need to load a certificate file that you upload manually.

  • ASP.NET and ASP.NET Core on Windows must access the certificate store even if you load a certificate from a file.

  • To load a certificate file in a Windows .NET app, load the current user profile with the following command

Load certificate in Linux/Windows containers

  • The WEBSITE_LOAD_CERTIFICATES app settings makes the specified certificates accessible to your Windows or Linux custom containers (including built-in Linux containers) as files.

  • The files are found under the following directories:

Container platform

Public certificates

Private certificates

Container platform

Public certificates

Private certificates

Windows container

C:\appservice\certificates\public

C:\appservice\certificates\private

Linux container

/var/ssl/certs

/var/ssl/private

  • The certificate file names are the certificate thumbprints.

  • App Service inject the certificate paths into Windows containers as the following environment variables WEBSITE_PRIVATE_CERTS_PATH, WEBSITE_INTERMEDIATE_CERTS_PATH, WEBSITE_PUBLIC_CERTS_PATH, and WEBSITE_ROOT_CERTS_PATH.

  • It's better to reference the certificate path with the environment variables instead of hardcoding the certificate path, in case the certificate paths change in the future.

  • A nice tutorial: Loading certificate in Azure App Service for Linux

 

Cross Origin Resource Sharing (CORS)

  • Tutorial: Host a RESTful API with CORS in Azure App Service <== TODO

  • Cross-Origin Resource Sharing (CORS)

    • Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources.

  • Specifying AllowAnyOrigin and AllowCredentials is an insecure configuration and can result in cross-site request forgery.

    • The CORS service returns an invalid CORS response when an app is configured with both methods.

  • enable CORS to your client's URL by using the az webapp cors add command.