Azure Web Apps is a Platform as a Services (PaaS) offering for delivering modern enterprise applications across cloud and mobile devices. The service, which originally started as Azure Websites, has seen considerable transformation through the constant addition of features and integrations. As such, Web Apps are delivered as an integrated offering that delivers features and capabilities from a number of Existing Azure Services.
When considering the various options for migrating a web application or an API to the cloud, Azure Web Apps tends to be the best choice because:
- It can support any type of web app, from a simple static site to enterprise grade solutions with seamless scalability and disaster recovery features
- It’s a fully managed platform (PaaS) which means that developers can focus on creating solutions that add business value instead of trying to work out the infrastructure requirements or the overhead that comes with them
- It’s offers high productivity development with full CI/CD support and minimal overhead
The following picture gives a neat overview of the Azure App Service and the types of solutions and applications supported to run on top of the service
Azure Web Apps for Linux
Although the standard Web Apps offering (which runs on top of Windows VMs) is perfectly capable of supporting a large number of programming languages and frameworks (.NET, Node, Ruby, Python, PHP etc), there are times when customers may want to use a Linux VM as the underlying fabric to run a web application. This could be for several different reasons, such as continuity of a hybrid cloud solution with the previous environment, or even because a certain language or framework is better supported or runs better under Linux. Finally, there’s a financial incentive for using Web Apps on Linux in that the cost of running is cut by 50%. For a large solution this can make a considerable difference.
To accommodate this, there is now an option for running Azure Web Apps under Linux. The current service goes one step further in that it provides a dual mode of deployment and operation to better accommodate your needs.
- Deploy and run an application on one of the hosted/managed containers
- Deploy and run your own, custom container
This dual mode of operation means that teams with different experience and knowledge around the topic of containers can get off the ground quickly, using the appropriate model. The abstraction of the containerisation means that developers don’t have to worry about underlying VM/Container infrastructure or about learning how to configure and maintain orchestration services. And, depending on the team’s maturity, a team can “crawl, walk or run” to full Container-based architecture.
The ‘Azure Web Apps for Linux’ service makes it easy and painless to get started with containers, while embracing recommended practices such as CI/CD and release management. The following table shows the supported languages and versions for deploying code directly into the platform managed (built-in) containers:
Limitations of the built-in containers:
- Only supports a subset of languages
- Only supports specific CI/CD options (FTP, Local Git, GitHub, Bitbucket)
However, regardless of the limitations, the fact that the service allows any container ready/compatible application to run with little to no effort on a managed container, it’s a great feature.
Bring your own container
This feature is what makes the service stand out. In most cases, developers will already have a solution that is designed to run in a container. Containers are an integral part of that architecture, especially now that more and more companies move into microservices solutions. Developers, code, test and run their apps in a container. Visual Studio makes this incredibly easy for an ASP.NET Core application. Adding container support to an ASP.NET Core application is only 2 steps away. Alternatively, the Docker CLI tools and Yeoman can provide the same functionality outside the Visual Studio ecosystem.
Containers that are ready for deployment tend to live in a repository. Azure offers its own container repository. Alternatively, some companies may opt-in for a public or private repository on DockerHub to host their containers. To accommodate both scenarios, the Web Apps for Linux service provides full support and integration for the following repositories:
- Azure Container Repository
- Private Repository
This integration goes a step further by also supporting continuous deployment of containers via webhooks. Consequently, once a container has been tested and uploaded to a supported repository through the build server, the container can automatically be deployed to the WebApps for Linux instance that is associated with that repository. This is an extremely powerful feature that was missing early on during the preview.
Regions – Unlike the normal Web Apps, the Linux flavour is not supported in all regions. The list of regions that currently support Web Apps for Linux is provided below:
Scalability – Not all tiers are supported either. Web App on Linux is only supported with Basic, Standard, and Premium app service plans and does not have a Free or Shared tier. In addition, non-Linux and Linux-based Web apps can’t coexist on the same App Service Plan (the infrastructure that runs your web apps). And finally, non-Linux and Linux-based Web apps can coexist within the same resource group as long as they are deployed on different regions.
Deployment and Administration
Depending on what you need to achieve, you can use any of the built-in and supported tools for deploying your App Service Plan. This includes PowerShell, ARM templates, the Azure CLI and finally, the Azure Portal. The Azure CLI is probably going to be the tool of choice for anyone outside the Windows ecosystem, even though PowerShell is now also cross-platform and supports the same operations on any environment. To deploy code, Visual Studio Team Services is ideally placed to work with Azure and can support both normal Web Apps and Web Apps on Linux. Your ARM templates can be designed to use WebDeploy for your code or you can go hard-core and use the Kudu API. If you wish to keep things simple, you can use the built-in Source Control integration for continuous deployment, but this comes with more overhead. However, its value is undeniable for simple application such as a personal blog site or anything that doesn’t have an inherent risk due to code being involved – static sites are a good example of this.
Finally, since this is all about Linux, SSH is fully supported both on built-in and custom containers. The built-in containers require that administrators are logged in to Azure with either their personal or Service Principal account. For SSH support in custom containers, you need to follow the steps outlined in this Azure documentation . Note that even with this configuration external connections to the container are not allowed. Instead, SSH can only be accessed via the Kudu / SCM Site, which is authenticated using the publishing credentials.
It’s interesting to note that, by default, when a container is deployed, the service will mount an SMB share to the /home/ directory that will override all existing contents. Subsequently, if you need to use the /home/ directory and persist data, then you need to set the WEBSITES_ENABLE_APP_SERVICE_STORAGE app setting to false. This will prevent container restarts when the platform storage goes through a change. In addition, it will result in the /home/ directory to be no longer shared across scale instances, and files written there will not be persisted across restarts.
There’s a hard timeout setting for container restarts set to 230 seconds. If a custom container takes a long time to start then there’s a good chance that the platform will attempt to restart the container before it finishes starting up. To avoid this, you can extend the timeout by setting the WEBSITES_CONTAINER_START_TIME_LIMIT app setting to the desired value in seconds. The maximum allowed value for this setting is 600 seconds.
The ‘Web Apps on Linux’ service is probably one of the most exciting of the service propositions on Azure. It combines the best of both worlds in that you gain the ability to run Linux and microservices in a fully-managed platform that allows developers to quickly get off the ground in a scalable and reliable manner. The service in in General Availability (GA), so it comes with full enterprise support, scalability and the expected SLAs that all other Azure services offer. As a developer or an architect, you can be confident that this is a mature and battle-tested platform and its features and availability will expand because of the continuous interest and popularity of containers and microservices-based architecture.