Hey, have you heard? Since last fall, Pivotal Cloud Foundry supports running applications on Windows. As part of the process for supporting this, we implemented Diego’s Garden API on Windows, and cross-compiled Diego and Loggregator components for Windows. Implementing garden-windows required us to come up with a way to “containerize” applications on Windows. Here’s how we did it.
On Linux, applications deployed to Cloud Foundry are run inside containers. Both DEA and Diego-based CF deployments use low-level Linux APIs to create a “container” environment that isolates the contents of each container from one another, and from the host. This is the same technology used by Docker and other high-level container technologies.
In Diego, this component is called Garden and is currently being rewritten to use the same API as Docker, RunC.
Containers are popular because they provide strong isolation between applications, without the overhead of virtualization technology. Two applications deployed on the same machine have an isolated filesystem and process list, preventing cross-application interference. On Linux, containers even have their own isolated network stack. An application running inside one container can bind to the same ports used by another container on the same machine.
For the most part, users can treat a container on Linux just like you would treat a VM – though containers are lighter-weight and have less overhead.
Specifically, containerization on Linux provides isolation in the following ways:
In designing Windows support for Cloud Foundry, we decided to take a containerized approach to application deployment. We chose containers over virtual machines due to the lightweight nature of containers when compared to their VM counterparts. This also brings the experience in line with that of Linux.
Windows Server 2012 provides process isolation primitives, similar to those found in the Linux kernel. We’ve contributed to an open source project called IronFrame to abstract these kernel primitives into an API which Garden utilizes. The low-level APIs available on Windows differ from those on Linux. As a result, the functionality of our Garden implementation on Windows is slightly different.
Here are some of the details on how Garden-Windows secures applications:
Job objects’ memory limits are enforced by the Windows kernel. Additionally, enforcement of memory limits is assisted by the Guard. The Guard polls for application memory usage and ensures that no application has mapped more memory than allowed. If an application exceeds its memory limit, the Guard will kill the offending job.
Additionally, if a process attempts to escape a Job Object, The Guard will stop this rogue behavior and kill the process if needed. This ensures that memory limits and job teardown can be enforced.
We at Pivotal believe that .NET is an important enterprise platform and are committed to the success of the project. We’re also excited about future opportunities for .NET on Cloud Foundry, including .NET Core and our Steel Toe initiative. Though the details of containerization on Linux and Windows are currently different, the user experience is getting closer and closer every day.
We hope that this serves as a good introduction to containers as they have been implemented on Windows 2012. Our team is always available on Slack to answer any questions you may have.