Tag: App Service

Video

Create Azure Web App in the Azure Portal

Here’s a short video introduction to creating an Azure Web App within the Azure Portal. It also shows how to select the pricing tier to specify the CPU and Memory resources for the App Service Plan that hosts the Web App, as well as explaining a little about the different pricing tiers; including the Free and Shared pricing tiers.

This is one of the first videos I’ve published to the Build Azure YouTube Channel where I’m starting to build out video content to accompany this site. Enjoy!

Infrastructure

Hosting Azure Web App on Linux

Since the introduction of Azure App Service and Azure Web Apps in early 2015, as well as the Azure Websites feature even earlier, the only option has been to use a Windows VM underneath to host Web Apps. That was until recently! Microsoft recently released a new feature into Preview that allows Azure Web Apps to be hosted on a Linux VM under the covers. With the availability of the Azure Web App on Linux Preview it’s now possible to choose either Windows or Linux as the host OS for the underlying VM Web Apps are deployed to.

With the availability of the Azure Web App on Linux Preview it’s now possible to choose either Windows or Linux as the host OS for the underlying VM Web Apps are deployed to.

Provisioning an Azure Web App on Linux

Once logged into the Azure Portal (http://portal.azure.com), the “Web App on Linux” option is available within the Azure Marketplace when choosing what resource(s) to provision in an Azure Subscription.

Clicking on “+NEW” in the portal will reveal Web App on Linux under the “Web + mobile” section of the Marketplace, or by typing in “Web App on Linux” in the marketplace search.

azureportal_new_webapponlinux

azureportal_webapponlinux_provisioningOnce the Web App on Linux resource is chosen, the prompt to choose the settings for creating a new “Web App on Linux” deployment is almost identical to the options when creating a standard “Web App” deployment that uses the Windows OS. The App name, Resource Group, and App Service Plan are still required just the same, as well as the option to turn App Insights On or Off.

However, there is an additional option to specify. The additional option is the Runtime Stack. The Runtime Stack configuration is a required field that specifies the specific version of either Node.js or PHP that is necessary for the chosen deployment.

The available options (at least in the current Preview state of the service) for Node.js version are:

  • Node.js 6.6.0
  • Node.js 6.2.2
  • Node.js 4.5.0
  • Node.js 4.4.7

The available options (at least in the current Preview state of the service) for PHP version are:

  • PHP 7.0.8
  • PHP 5.6.23

It’s worth noting that even though the PHP or Node.js version needs to be specified when creating a new Web App on Linux resource, the version can be changed later on within the Application settings for the Web App. It is also possible to switch the configuration from Node.js to PHP or the other way on an existing Web App on Linux resource as well.

Supported Regions

Since the Web App on Linux service is currently in Preview, it’s not supported to be deployed out to all Azure regions just yet. This is part of the standard way with how Azure Preview services are rolled out and eventually deployed across the Microsoft Azure Platform. First, Preview services are rolled out to only 1 or a few Azure regions / locations. Then, later on, once the service reached General Availability (GA) the service will be rolled out to be supported across the rest of the Microsoft Azure regions / locations.

It the current Preview state of the Web App on Linux support, the service is available in the following 3 regions:

  • West Europe
  • Southeast Asia
  • West US

Pricing Plans

While it’s expected that Web Apps on LInux will eventually receive the same App Service plan Pricing tier support once the service reached General Availability (GA), the current Preview doesn’t support all the same pricing tiers just yet. Currently, it supports a few of the Pricing tiers for the smaller Instance Sizes which still give plenty of options to use this new Preview service.

Here’s the list of the currently supported Pricing tiers for the Web App on Linux Preview service:

  • Standard S1 (1 Core, 1.75 GB RAM)
  • Standard S2 (2 Cores, 3.5 GB RAM)
  • Standard S3 (4 Cores, 7 GB RAM)
  • Basic B1 (1 Core, 1.75 GB RAM)
  • Basic B2 (2 Cores, 3.5 GB RAM)
  • Basic B3 (4 Cores, 7 GB RAM)

webapponlinux_preview_pricingtiers

As can be seen in the above screenshot of the Pricing tier options, there are many standard features of Azure Web Apps supported.

  • Up to 50 GB Storage
  • Custom domains
  • SSL Support
  • Up to 10 instances
  • Daily backup
  • Up to 5 Deployment Slots

Each of the Azure App Service Pricing tiers for the Web App on Linux Preview service also shows a listing of “Preview Pricing” for both the Standard and Basic pricing tiers. This indicates that the pricing of the Web App on Linux service while it’s in Preview is actually charged at a 50% discount of the prices shown. The price displayed for the Standard S2 tier is $89.29 USD, so with the 50% discount, the price you’ll pay to use a Standard S2 instance with the Web App on Linux Preview will actually be $44.65 USD.

Linux App Service Plan

When provisioning a Azure Web App, whether a “standard” Web App or a Web App on Linux, there needs to be an Azure App Service Plan provisioned. The App Service Plan is what determines the Pricing tier and each App Service Plan can be used to host 1 or more Web Apps. There is however a difference between the App Service Plans.

An App Service Plan for a Web App for Linux resource can only be used to host other Linux based Web Apps, and an App Service Plan for a “standard” Web App resource can only be used to host Windows based Web Apps.

While a Web App or a Web App on Linux can be provisioned, the starting point you use (which of these that’s chosen to start provisioning) will determine the NEW App Service Plan that gets created. A Web App, as it’s hosted on a Windows VM underneath, will have a Windows based App Service Plan provisioned. A Web App on Linux, as it’s hosted on a Linux VM underneath, will have a Linux based App Service Place provisioned.

However, there’s one thing to be aware of when provisioning a new Web App if there are already both Windows based and Linux based App Service Plans running on an Azure Subscription. When a new Web App is created, although it will create NEW App Service Plans that support Windows, if an existing Linxed based App Service Plan is chosen as the App Service Plan to use for hosting the Web App, the resulting Web App that gets provisioned, since it’s configured to use a Linux App Service Plan, will in fact be a Web App on Linux instead. This is a seemingly small detail that needs to be kept in mind when provisioning both Web App and Web App on Linux resources within an Azure Subscription.

What distribution of Linux?

Since Azure Web Apps are a Platform as a Service (PaaS) service in the cloud, it does fully abstract away the underlying Virtual Machine (VM) and Operating System (OS) that is hosting the Web App. However, there are times when it’s useful to know what OS and Version is hosting something, and using the Kudu portal (which is available to all Azure Web Apps) it’s possible to gleam into what OS, Web Server, and other System Information of the underlying OS.

The OS that Web App on Linux resources / instances are running on is: Debian GNU/Linux 8 (jessie)

webapponlinux_prev_releaseinfo

Also, the web server running on the Web App on Linux resource / instances is: Apache/2.4.10

Here is some additional Environment / System information about the Linux VM underneath Web App on Linux instances.

System info

  • System up time: 3.17:07:04.9990000
  • OS version: Unix 4.4.0.38
  • 64 bit system: True
  • 64 bit process: True
  • Processor count: 1
  • Machine name: fc53b9b63c6f
  • Instance id: fc53b9b63c6f
  • Short instance id: fc53b9
  • CLR version: 4.0.30319.42000
  • System directory:
  • Current working directory: /
  • IIS command line: /usr/lib/mono/4.5/mod-mono-server4.exe –filename /tmp/mod_mono_server_default –applications /:/opt/Kudu –nonstop

Environment variables

  • APACHE_LOCK_DIR = /var/lock/apache2
  • APACHE_LOG_DIR = /var/log/apache2
  • APACHE_PID_FILE = /var/run/apache2/apache2.pid
  • APACHE_RUN_DIR = /var/run/apache2
  • APACHE_RUN_GROUP = www-data
  • APACHE_RUN_USER = www-data
  • APPDATA = /opt/Kudu/local
  • APPSETTING_SCM_USE_LIBGIT2SHARP_REPOSITORY = 0
  • APPSETTING_ScmType = None
  • APPSETTING_WEBSITE_AUTH_ENABLED = False
  • APPSETTING_WEBSITE_NODE_DEFAULT_VERSION = 4.4.7
  • APPSETTING_WEBSITE_SITE_NAME = linuxwebapp42
  • DEBIAN_FRONTEND = noninteractive
  • DOTNET_SKIP_FIRST_TIME_EXPERIENCE = true
  • HOME = /home
  • HOSTNAME = fc53b9b63c6f
  • HTTP_HOST = linuxwebapp42.scm.azurewebsites.net
  • KUDU_APPPATH = /opt/Kudu
  • KUDU_MSBUILD = /usr/bin/xbuild
  • KUDU_RUN_USER = 31c21a883af01a04cb9bd231
  • LANG = C
  • MONO_IOMAP = all
  • MONO_SHARED_DIR = /tmp
  • NUGET_XMLDOC_MODE = skip
  • PATH = /home/site/deployments/tools;/opt/Kudu/bin/Scripts;/usr/bin;/usr/bin;;;Microsoft SDKs/F#/3.1/Framework/v4.0;/usr/bin;/usr/share/npm;/usr/local/bin;/usr/local/bin;/usr/local/bin;/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/nodejs/4.5.0/bin
  • PWD = /
  • SCM_BIN_PATH = /opt/Kudu/bin
  • ScmType = None
  • SITE_BITNESS = AMD64
  • WEBSITE_AUTH_ENABLED = False
  • WEBSITE_NODE_DEFAULT_VERSION = 4.5.0
  • WEBSITE_SITE_NAME = linuxwebapp42

It’s worth nothing that anywhere the value “linuxwebapp42” is shown in the above settings / information that this is the Name of the Web App on Linux that was created and subsequently used to access all this information.

If you’re curious how the above Environment / System information was obtained, it was retrieved by using the Kudu portal. Kudu is the engine used behind the scenes for git/hg deployments, WebJobs, and various other features of Azure Web Apps. Every instance of Azure Web Apps (both Windows and Linux) have an instance of Kudu running that can be accessed through the Azure Portal or directly via its HTTP endpoint.

ArchitectureInfrastructure

Manage Azure App Service Deployments with Deployment Slots

Every App Service resource in Azure has the ability to have multiple deployment slots configure. These deployments slots are a feature than can greatly help with the implementation of streamlined testing, staging, and deployment process. Along with the ability to configure multiple hosting environments, the use of Deployment Slots enables zero downtime when deploying application changes, or even rolling back a failed deployment.

Creating Deployment Slots

Deployment slots are a feature of Azure App Service Plans. As a result, every App Service resource (Web App, Web API, Mobile App) in Microsoft Azure has the ability to create up to 4 additional deployment slots with the Standard tiers, and up to 20 deployment slots with the Premium tiers.

Each App Service (in Standard tiers) can have up to 4 additional Deployment Slots in addition to the Production slot.

Each Deployment Slot allows for a separate instance of the application to be hosted in isolation from the other deployment slots and production slot of the App Service. The VM behind each Deployment Slot is the same VM Instance that hosts the production deployment slot. This means that the App Service and 4 additional Deployment Slots will all be hosted in and share the same VM Instance and resources.

To create App Service Deployment Slots in the Azure Portal, just navigate to the App Service, select the Deployment slots section and click the Add Slot button to create a new Deployment Slot.

azureappservice_portal_deploymentslots

Additionally, in order to use the Deployment Slots feature of Azure App Service, the pricing tier must be either Standard or Premium. The Free, Shared, and Basic pricing tiers do not support deployment slots.

It’s important to keep in mind that all Deployment Slots share the same VM Instance and server resources.

Deployment Slot URL / Endpoint

Azure App Service applications get a unique URL that is made up of the App Service Name as the subdomain of the azurewebsites.net domain. In the above screen shot, the App Service Name is “testapp2063” which means the URL / endpoint for the Production slot of the App Service is located at testapp2063.azurewebsites.net.

When creating Deployment Slots each slot gets it’s own URL / Endpoint. The endpoint for each deployment slot derives from the endpoint for the Production slot by appending the name of the deployment slot with a hyphen.

With an App Service named “testapp2063” the URL / Endpoint for the following deployment slots will have the following values:

  • dev => testapp2063-dev.azurewebsites.net
  • test => testapp2063-test.azurewebsites.net
  • stage => testapp2063-stage.azurewebsites.net

azureappservice_portal_deploymentsloturl

Deployment Slot Swapping

Swapping Deployment Slots is the method of copying the currently deployed application code and settings of one deployment slot and swapping it with another. Swapping allows for the deployment of application code to be done from one environment to another very quickly. It also allows for a couple new deployment techniques that didn’t exist in traditional server hosting.

To swap Deployment Slots from the Azure Portal, just navigate to the list of Deployment Slots for an App Service or navigate to the specific Deployment Slot that needs to be swapped. Then, click the Swap button and specify which Deployment Slot to swap with. See the above screenshots for reference of where the Swap button is located within the Azure Portal.

When an application is deployed using Deployment Slot swapping, there is zero downtime

When an application is deployed using Deployment Slot swapping, there is zero downtime of the application. The way this is implemented is by just rerouting the Deployment Slot Endpoint between the Deployment Slots being swapped. Both deployment slots remain running and actively responding to client requests throughout the swap.

Staged Deployment

The technique of performing a Staged Deployment allows for application code to be deployed to a non-production deployment slot (such as one named stage) to test or verify functionality is working as expected. Then once everything has been verified, the Stage deployment slot can be swapped with Production making the staged application deployment the new Production instance of the application.

Incremental Deployment

There are times when deploying application changes might require additional changes other than just deploying the latest code. These requirements could be running SQL scripts or some other post deployment step necessary to fully deploy the latest code. Deploying to a Stage deployment slot can allow for these Incremental steps to be performed after the code is deployed in a way that can be tested and verified before deploying to production.

Rollback Deployment

Every once in awhile a deployment fails for some reason. Maybe files end up corrupt, a major bug is found, or some other reason for failure. In these cases, it’s necessary to rollback a deployment. Using Deployment Slots, a deployment can be rolled back easily buy just swapping the Deployment Slots back.

Basically, swap Stage with Production to deploy new changes. When a major bug is found that requires a rollback, then the Production and Stage Deployment Slots can be swapped back. This allows for the old application code to be rolled back into Production in a matter of minutes. This leads to greatly decreased downtime in the event of a deployment failure.