As a quick recap, Docker containers are:
- Encapsulated, deployable components that can run as isolated instances
- Small in size with a fast boot-up time
- Include tools that enable containerized application images to be easily moved across the public cloud and on-premises
- Capable of applying limits on physical resources consumed by any given application
Given the popularity of Docker containers, it should come as no surprise that the Azure platform already provides first-class support for a container hosting solution, in the form of Azure Container Service (ACS). ACS makes it simple to create a cluster of Virtual Machines that can run containerized applications. ACS relies on popular open-source tools – with Docker as the container format, and a choice of Marathon, DC/OS, Docker Swarm and Kubernetes for orchestration and scheduling, etc. All this makes it possible to easily run containerized workloads on Azure in a portable manner.
But the Docker containerization story on Azure does not stop here.
It is also being weaved more and more into existing PaaS offerings, including Azure Batch, Azure App Service and Azure Service Fabric. Let’s briefly review the latest developments to see how Docker integrates with Azure PaaS:
Azure Batch makes it easy to run large-scale jobs in parallel without worrying about all the scheduling and clustering details. You essentially tell Azure Batch what type of VMs you need and how you need them configured. From this point, you simply submit jobs and tasks and the service takes care of the rest.
Azure Batch service started out supporting Windows VMs but added support for Linux VMs back in March. As you can imagine, with the support for Linux VM, you can run Linux container workloads on Azure Batch. (You can do the same with ACS of course; however Azure Batch-hosted containers are optimal for scheduling repetitive compute jobs.)
These two samples on GitHub are designed to show you how to integrate Docker with Azure Batch. In a nutshell, you create a VM pool that installs a Docker container using a startup task. Once the Docker container is in place, you create a job with a preparation task that pulls down a Docker image from Docker hub. Subsequent tasks simply build on the preparation task. When the container exists, the task is marked as complete.
Azure App Service
Like Azure Batch support for Linux, the current preview of App Service for Linux allows for running web apps natively on a Linux platform. This allows for better compatibility for applications that need it. App Service also provides pre-defined application stacks such PHP 7.0 and Node.js 4.5, as Docker images that can be hosted inside App Service. In addition to the predefined Docker images, you can also bring custom Docker images. Custom images can be hosted in either public or private repositories.
Azure Service Fabric
You are probably thinking at this point that the Docker integration with Azure Batch and App Service seems fairly intuitive – use containers as deployment and execution mechanisms for an Azure Batch job or App Service application. And I agree…however, as it turns out, Azure Service Fabric integration with Docker is much more nuanced. Here’s why:
- Azure Service Fabric already has a well-defined packaging and deployment story in the form of an application manifest. The application manifest defines the composition of (micro)-services that make the up the application. The application manifest also defines partitioning scheme, instance count, etc.
- Service Fabric also already provides a number of platform capabilities like orchestration, resource governance, and service discovery. This is in addition to the core clustering capability that allows multiple Service Fabric nodes to appear as one.
As you can see, there is some overlap between Service Fabric and the Docker packaging and clustering story. However, as we will discuss in a moment, overlap represents choice! But before we get to that, it would be remiss not discuss capabilities of Service Fabric that go beyond containerization and clustering. Service Fabric offers a rich programming model that eases building stateful and stateless microservices, including full application lifecycle support for deployment, versioning, plus upgrade and self-healing.
So how do containers and Service Fabric come together?
- A Service Fabric application can now be a mix of microservices that are hosted in a process or hosted within containers. You can use a yeoman template to package multiple containers inside a Service Fabric application. You can also take advantage of ancillary services such as container image deployment and activation, image repository authentication, container-to-container discovery, and communication.
- Microservices hosted within containers can leverage the stateless and stateful programming model (with some limitations that will hopefully go away in the future, i.e. Reliable Services are not supported on Linux). The containers hosting the Service Fabric-based microservices can, in turn, integrate with the Service Fabric runtime running on the host node. Refer to the diagram below (originally from Boris Scholl’s blog) that illustrates Service Fabric cluster running containers.
As you can gather from the aforementioned integration scenarios, Service Fabric integration with Docker can bring you the native benefits of Service Fabric (such as networking, naming, load metrics, upgrades, combined with isolation and other benefits provided by containers). But what about Docker Swarm, Kubernetes, Marathon, etc? How do they relate to Service Fabric?
Well, that’s where the choice of openness offered by the Azure platform comes in. You can go down the path of ACS and leverage any of these open-source tools for clustering and orchestration. Or you can select Service Fabric as the orchestrator of your microservices, while at the same time leverage the benefits of Docker containers.
No doubt about it: Azure PaaS services are increasingly taking advantage of the fast-evolving Docker container story.
Further Reading on the AIS Blog: