Azure App Services on Linux

In this post, I will discuss App Services on Linux, what this service is, how it differs to the Windows Server offering, and what you can do with the Linux alternative.
 

 

Background

In a previous post, I explained that Azure offers an alternative to the legacy way of deploying web applications on virtual machines. Instead, one can focus on the application by using Web Apps on Azure Application Services. Up until recently, this was a Windows Server-only offering. By that, I mean that the virtual machines, hidden away by Azure and completely managed by Microsoft, that made up your app service used Windows Server (today it is Windows Server 2016) as its guest OS and IIS as the web server. Every Web App that you deployed on an App Service plan (a deployment of Application Services) was an application pool on each load balanced instance.
However, not everyone wants to use Windows Server. Some people just prefer Linux and because of that, and a few other reasons that I’ll mention, Microsoft has offered a Linux option for customers that want to deploy Web Apps in Azure.

Web App for Containers

As I mentioned before, when you deploy an App Service plan for a Windows based Web App, you are getting one or more abstracted virtual machines that Microsoft will manage. The build and configuration of this virtual machine is completely managed by Microsoft.
If you choose to deploy a Linux-based App Service plan, then things change … quite a bit, actually. Instead of a virtual machine, your Linux-based App Service plan will be based on Docker containers. That’s the first big difference with the Linux option.
 

 
The second difference is that when you deploy your new App Service plan, via the wizard for creating a new web app, you can choose the Docker container image from the Microsoft-managed image repository.

The second difference, which you might notice above, is that Ruby is supported wit Linux web apps. This is not the case with Windows web apps.
The third difference that I will mention is customization. Let’s say that there is some framework that you like to develop on and that Microsoft does not offer with either the Windows or Linux options. You can build your own Docker container image, upload it, and deploy it as the basis for your Linux-based App Services plans.
The fourth difference is that you can change your container after deployment. In the Windows world, you get the stock Windows Server 2016 image and you are done. In the Linux world, you can jump from one container image to another, enabling rapid improvement of your environment as new plug-ins and frameworks arrive.
The next difference that you will notice, after deploying a web app, is that instead of getting the CMD-based console in the Azure Portal, Linux web apps are given an SSH-based shell in the Kudu environment.

What You Get

I searched Microsoft documentation for quite a while to discover what I would get in one of these containers, specifically the OS and the web server. I found that the web server was simply described as “Apache” in a Microsoft blog post. I couldn’t find the Linux version. It was like Microsoft didn’t want to talk about it. So I tried a series of distro-specific commands until I discovered that the container was based on Debian 8.8, codenamed “Jessie”.
I then tried to confirm that the web server was Apache but my extremely limited Linux skills got me nowhere; I tried a bunch of commands that I found online but none of them worked.

What You Don’t Get

Note that an App Service plan that is based on Linux can only host websites. If you need WebJobs (and server-less Functions are not an option), API or Mobile apps, then you should deploy those services on a Windows-based App Service plan. Other things that are missing from the Linux option today include:

• Authentication/Authorization
• Managed Service Identity
• Networking
• MySQL In App
• Change App Service Plan
• Clone App
• App Service Editor
• Extensions
• Alerts
• Log Stream
• Process Explorer

What Should I Use?

As you can see above, the Linux-based Web App for Containers is lacking a lot of functionality that is present in the Windows web app. Big things for me are the inability to:

• Use Microsoft or third-party authentication/authorization services
• Connect a web app to virtual networks or on-premises services with a static TCP port
• Move a web app between different App Service plans, for example, moving from a lower spec Basic plan to a higher spec Standard plan.

 
If, however, you need the customization and DevOps constant evolution that the containers can offer, then Web App for Containers might just be for you.