Hey, have you heard? Pivotal Cloud Foundry now supports running applications in Windows Server Containers.
The platform has supported .NET apps on Windows Server 2012 R2 for two years. This move is a significant step for .NET developers, continuing to improve on the .NET developer experience.
That effort got a huge boost with Windows Server 2016 and its native support for Windows Server Containers. “Native” is the key term; it enables a far more robust .NET developer experience in Pivotal Cloud Foundry. Specifically, with native Windows Server Containers developers can:
We launched this effort months ago, and planned to support Windows Containers from Windows Server 1709. And that’s just what we’ve done!
Previously, for applications running on the windows2012R2 stack, the garden-windows team implemented a Windows backend to the garden API and maintained garden-windows-bosh-release. This allowed the team to have flexibility and ownership of their own code base. But, we felt some pains when integrating with new platform features.
We wanted to improve our development process when building our Garden implementation for Windows Server 2016. So, we prioritized more cross-team collaboration with the core Garden team. We also wanted to adopt the OCI standards for container lifecycle and container image management. (We build to this standard for Linux on Cloud Foundry, so it makes sense to do this for Windows too).
The pluggable nature of Guardian means we can focus on solely implementing the Runtime, Network, and Image plugins for Windows Server 2016:
Here’s a quick diagram, showing how these components interact.
You’ll notice that the Garden components on a Windows Server 2016 Diego cell are the same as those on a Linux Diego cell…except for the new plugins mentioned above.
Windows Server 2016 comes with Windows Server Containers. The primitives here are similar to those Linux kernel. We use the official hcsshim Go library for instrumenting the Windows Server Containers in Cloud Foundry. The underlying container operations are performed by the Windows Host Compute Service (HCS). Windows Server Containers provide application isolation through process and namespace isolation technology. A Windows Server container shares a kernel with the container host and all containers running on the host.
What about security? Here’s how Garden-Windows secures applications:
C:\drive). Any modifications made to the container filesystem or registry are captured in a sandbox that’s managed by the host. As a result, we are now able to create and maintain a root filesystem (rootfs) that allows applications to receive security upgrades when running on the platform.
windows2016stack. Previously, this quota applied to all files owned by a given user. But, now with Windows Server Containers the quota is applied to the sandbox image. (We used disk quotas because HCS currently doesn’t have support for enforcing disk limits.)
There’s a .NET Renaissance underway, and we’re excited to be a part of it. That’s why we’re continuing to contribute to the cloud-native .NET movement, including .NET Core and Steeltoe.
The best part? Native Windows Server Containers feature makes it easier for us to add new capabilities. In the coming months, we plan to add support for Container-to-Container networking and Volume Services for Windows Server Containers
We hope this post serves as a good introduction to containers as we’ve implemented on Windows Server 2016. What are your plans for .NET and Cloud Foundry? We want to hear from you! Visit us on Slack and tell us about your scenarios.