Cloud Foundry Containers: Warden, Docker, and Garden

by Maksim ZhylinskiSeptember 16, 2015

This blog post compares Warden and Docker across implementation, differences/similarities, and their interaction with Garden.

logo_cloud_docker_400_200px

Warden is a container implementation currently used in Cloud Foundry. At the same time, Docker is another option to easily and efficiently manage containers. That’s why a lot has been made to enable Docker in the Diego runtime.

In addition to a brief comparison of Warden and Docker, we will also highlight how the solutions work together in Garden—the new container back end that will become available in Diego.

Table of Contents

What is similar?

Warden and Docker containers have a number of similarities in their internal implementation, for instance:

Both employ cgroups—to isolate usage of resources—and namespaces—to separate apps running inside containers from each other and from host processes. (These two features are provided by the Linux kernel.)
Both Warden and Docker use layers combined with a union file system, which organizes them into a single isolated root file system to be used inside a container.

What is different?

There are also some differences. Warden is part of Cloud Foundry, so it doesn’t need to support many file systems. At the moment, it works with AUFS and OverlayFS. Docker covers more union file systems, including these two, as well as Btrfs, ZFS, VFS, and the devmapper framework.

The main difference between Docker and Warden is in the way container images are organized. Warden is designed to run applications that get all their dependencies from pieces of software called buildpacks. Warden containers usually have only two layers: a read-only layer with an OS root file system (for example, Ubuntu 14.04) and a nonpersistent, read/write layer for the application itself, all its dependencies, and temporary data.

Unlike Warden, Docker is built to run images, which are distributed through Docker Hub. Before an app can work with Docker, you need to create an image for it. Users can download publicly available images and make their own based on them.

Docker images consist of multiple layers, one for each RUN command. Layers are combined into a single file system, the same way as in Warden (see the diagram below). When a user creates an image based on someone else’s image, Docker reuses the layers. For example, if they have a Jenkins image based on JRE and want to make their own, with a Java application that also needs JRE, Docker will reuse the JRE image and all of its parents.

There are also some other differences. This table sums up what resources can be isolated and what features are currently available in Warden and Docker containers.

Feature	Warden	Docker
1. Resource isolation and control	CPU shares memory + swap network bandwidth disk size quota	CPU shares CPU sets memory memory swap block device bandwidth
2. Dynamic resource management	Warden containers support this feature, but Cloud Foundry doesn’t use it.	Not supported.
3. Image management	Only whole images can be reused to create new containers.	Layered—allows for reusing separate layers.
4. Linking containers	no	yes
5. Exposing ports	Single port per container (Multiple ports will be available in Garden/Diego.)	Multiple ports per container

Garden (Diego)

Garden is the new Cloud Foundry container back end, which will be available in Diego—the brand new Cloud Foundry runtime. Garden is built around the same idea as Warden, but it has been refactored and re-implemented in Go. (Warden was written in Ruby.)

So, what’s the difference between Warden and Garden? First of all, Garden is modular. It supports multiple pluggable “back ends”—pieces of software responsible for creating containers. At the moment, three back ends are available: Linux, runC (a container specification from the Open Container Initiative), and Windows. Yes, you can run Windows (.NET) applications with Garden!

Another killer feature of the new Garden Linux back end is the possibility to run Docker images. Garden is able to fetch Docker images from Docker Hub, as well as from your own Docker repository. Generally, availability of Docker on Cloud Foundry is very good news for teams that already employ Docker images in their everyday activities and want to continue using them after they move to Cloud Foundry.

Although Diego is still in development, some Cloud Foundry distributions (e.g., Pivotal CF) are already using it as a default app runtime. According to the public tracker, Diego 1.0—which will finally replace DEA in open source Cloud Foundry—will be out very soon.

About the author

Maksim Zhylinski is a Cloud Foundry Engineer at Altoros. He is an expert in cloud computing, networking, and Cloud Foundry BOSH, having worked on multiple BOSH CPIs, releases, and service brokers. Maksim has 6+ years of experience in everything Ruby, JavaScript, and Go, as well as extensive skills in server and client-side web application development. He is an active member of Ruby and Go communities and a frequent contributor to various open-source projects.

Posted In