Microsoft has released the public preview of Windows container support in Azure App Service, which provides more control over what gets installed into the App Service environment. This announcement extends the capabilities of the web app for containers service not only to run Linux based, but now Windows-based containerized environments as well.
Azure App Service provides a locked down environment used to run application stacks on IIS, like ASP.NET or Node.js. As a result, Azure App Service gives no entry to administrative access points, no custom dependencies in the global assembly cache, and no option to install custom components. With Windows containers on App Service, these capabilities are available, as Windows containers contain all elements to run each application in an isolated environment.
To run these containers on the Azure App Service they must expose an endpoint through HTTP(S), for example, by running IIS. Consequently, making Windows container capabilities available in App Service allows for several new scenarios. Andrew Westgarth, program manager, Azure App Service, describes several of these scenarios in the announcement:
- Lift and Shift to PaaS – Ideal for customers interested in migrating .NET Framework and .NET Core applications to Azure, and going straight to a PaaS service to get the many productivity benefits from the App Service platform.
- Applications with dependencies – Deploying an app within a Windows Container allows customers to install custom dependencies. Examples include installation of custom fonts or component libraries which must be installed into the Global Assembly Cache (GAC).
- Relaxed security restrictions – When deploying a containerized application, the Windows Container is an isolation and security boundary. As a result, calls to libraries that would normally be blocked by Azure App Service will instead succeed when running inside of a Windows Container. For example, many PDF generation libraries make calls to graphics device interface (GDI) APIs. With Windows Containers, these calls will succeed.
- Thirdparty application migration – Customers often have business critical applications developed by third parties with which the company no longer has a relationship. Containerizing these types of applications unlocks the opportunity to migrate applications to Azure App Service.
In addition to the introduction of Windows container support, Microsoft also announced three new premium SKUs, explicitly for App Service plans hosting Windows containers. The SKUs are all based on the Dv3 capabilities and vary on CPU and memory capabilities.
- Small – 2 CPU virtual cores and 8GB of memory
- Medium – 4 CPU virtual cores and 16GB of memory
- Small – 8 CPU virtual cores and 32GB of memory
Windows containers derive from base images, which Azure App Service uses to create the hosted environments. The .NET Framework running in the containerized environment dictates the parent image. Specifically, applications running on .NET Framework use a parent image based the Windows Server Core 2016 LTSC release, while .NET Core applications need a parent image based on the Windows Server Nano 2016 LTSC release. Furthermore, App Service provides several cached parent images, which reduces the start time, as these are available during startup of the application instead of downloading them.
Getting started consists of creating a web app for containers, and choosing the container to deploy, described in detail on the blog Deploy Windows Containers. The author of the Deploy Windows Containers article mentions that these new capabilities allow for getting started with Windows Containers more quickly.
I have to say that I was excited to see this service going public, because up until now deploying Windows Containers was a process that involved many steps.
During the public preview of support for Windows containers on App Service, the following capabilities are available.
- Use Docker Hub, Azure Container Registry, or private registries to deploy containerized applications.
- Application logs and the use of the App Service log streaming feature incorporate logging of the applications.
- Deployment slots and slot swaps are available to deploy applications incrementally.
- Directly connecting to containers through PowerShell and WinRM.
- Autoscale provides capabilities for automatically scaling up and down.