This post was authored by Boris Scholl, a Program Manager on the Azure Compute team.
At a high level, containers can be seen as encapsulated, individually deployable components running as isolated instances on the same kernel, leveraging operating system level virtualization. This means that each application, its runtime, dependencies, and system libraries run inside a container with full, private access to their own isolated view of operating system constructs. Along with portability, this degree of security and resource isolation is the main benefit for using containers with Service Fabric, which otherwise runs services in traditional processes. On Linux, this isolation has traditionally been provided by cgroups and namespaces, and Windows Server Containers (coming in Windows Server 2016) will behave similarly. In addition, Windows Server 2016 will offer Hyper-V Containers, an even higher level of security isolation for hostile multi-tenant scenarios. Figure 1 shows the different isolation levels.
Figure 1: Isolation level spectrum
Service Fabric will support the different types of containers discussed above in an upcoming release. In this post, I’ll provide an early look at Service Fabric container integration, its scenarios and implementation.
For more information on Docker and Windows Containers in general, see Mark Russinovich’s blog post about containers, docker, windows and trends .
Service Fabric container integration
Service Fabric leverages Docker for container management on both Linux and Windows containers. Under the covers, we use Docker to create, manage, and delete containers and container images. From a user perspective, Service Fabric will support two container scenarios:
In this case, you can take advantage of Service Fabric’s cluster management and orchestration capabilities in the same way you would with guest executables. You reference a container image in Docker Hub, a Docker Trusted registry, or a private registry, in your service manifest, along with additional parameters, such as environment variables. Service Fabric will pull down the image (if it’s not already in the local registry) and launch a container based on the arguments you provide. Below is an example of a service manifest that defines the container image contoso/frontend.
<ServiceManifest Name=“ContosoServiceTypePkg" Version="1.0"> <ServiceTypes> <StatelessServiceType ServiceTypeName=“ContosoServiceType" ... > </StatelessServiceType> </ServiceTypes> <CodePackage Name="CodePkg" Version="1.0"> <EntryPoint> <ContainerHost> <ImageName>contoso/frontend</ImageName> <Commands></Commands> </ContainerHost> </EntryPoint> </CodePackage> . . . </ServiceManifest>
Service Fabric Services inside a container
In this scenario, you build Service Fabric stateless and stateful services normally and then package them inside a container. This approach gives you all the benefits of native Service Fabric services, such as networking naming service support, self-reporting of load metrics and integration with code, config, & data upgrades, in addition to higher isolation levels provided by containers. At a high level, the container integrates with the Service Fabric runtime on the host system by using Docker data volumes. Figure 2 shows a Service Fabric cluster with running containers that communicate with Service Fabric on the host machine.
Figure 2: Service Fabric Cluster running containers
This post was a quick overview of how Service Fabric will manage containers. We will have much more detail to share when Windows containers launch in Windows Server 2016 and Service Fabric on Linux enters public preview, so stay tuned!