ActiveState has pioneered the use of Docker as an alternative container technology underneath Cloud Foundry by integrating it into its Stackato product.
We posted recently about Docker, a technology that is very new (although related tech has existed for some time). Docker has caught the imaginations of many by breaking down the conceptual barrier between the host operating system and the container running within it, allowing the creation and configuration of containers in milliseconds through simple scripts in the host operating system. This simplicity and speed makes it easy to think of Docker as a form of do-it-yourself PaaS. If you are prepared to leave certain things outside the PaaS-like database, you can probably knock something together that will cover your basic deployment use cases simply by writing a few scripts.
ActiveState is coming at this from the other direction. It is asking what happens if we take a more mature PaaS (like Cloud Foundry), add to it a number of additional management tools and support for Heroku Bundles (turning it into ActiveState Stackato), and then stir Docker into the mix. ActiveState isn’t quite alone in this space; Decker, from CloudCredo, takes the same approach. CloudCredo has an interesting spin on the benefits of doing so. According to CEO Colin Humphreys, “Docker addresses the micro world of single hosts well, and Cloud Foundry’s Elastic Runtime addresses the macro world of distributed orchestration well—what we needed was the combination of the two.”
To be clear, ActiveState doesn’t currently allow the running of Docker containers inside Stackato, due to a security issue. (The container and the host OS share UIDs, so if you are root in the container you are root in the host OS.) It only uses Docker containers for its own internal services. However, the direction of travel is clear. Once the security issue is resolved, we anticipate that ActiveState will, like Decker, move towards positioning Cloud Foundry (or more specifically Stackato, its own value-added version of Cloud Foundry) as the way to orchestrate Docker containers. However, ActiveState isn’t doing this in the main open-source Cloud Foundry codebase. It forks its own version and resolves conflicts between its version and the open-source project every three months or so, and it pushes that out as a supported Stackato release.
In fact, it is only an accident of history that caused the divergence of Cloud Foundry and Docker in the first place. Docker builds on Linux Containers (LXC) in user space, which build on the underlying cgroups at the kernel level. Cloud Foundry continues to use cgroups, but it built its own Warden layer on top because of problems it had with LXC. So, there aren’t vast differences, but there is no direct compatibility—you can’t run a Docker container inside Cloud Foundry. What is also ironic is that Docker came from a company known as dotCloud, which had its own PaaS solution. Given the competition from Cloud Foundry and Red Hat OpenShift, dotCloud has now pivoted its business to focus primarily on Docker, which was developed as a constituent technology for PaaS in the first place.
This is a very dynamic space, one for which it is hard to predict what will happen next, and it’s quite important. Docker, as we mentioned in a previous post, is a bit like a Swiss Army Knife. It’s small, and developers, operations, and those Frankenstein DevOps people can put it in their pocket and pull it out to solve all sorts of little problems. That means it is turning up everywhere. I remember having the same kind of “hey, I can solve that problem” feeling when I first came across VMware. Cloud Foundry, on the other hand, is powerful but a little monolithic. It’s not something you install on a whim and keep in your pocket.
Now, Docker is not a PaaS, but it provides a way to create building blocks for a PaaS. People have started to think about ways to take Docker and turn it into a simple PaaS, with software like Flynn or Serf. These container orchestration technologies are essentially the sort of scripting you might do to set up your own proto-PaaS with Docker, but in its early days. There is also a new orchestration API for containers called libswarm—a bit like libvirt for containers. If the first generation of PaaS was single-language, proprietary, or both (e.g., Force or the original Ruby Heroku), and the second generation is polyglot (exemplified by Cloud Foundry), it may well be that we are starting to see a third generation of PaaS, based on Docker. This may well end up being the technology that finally takes PaaS to the mainstream.
From the Cloud Foundry vendor’s perspective, the smart thing to do is to try to glue Docker and Cloud Foundry together like ActiveState and CloudCredo. However, one could argue that the right thing to do is actually to throw Warden out of the main Cloud Foundry open-source stream and replace it with Docker. Of course, that depends on which company ends up acquiring Docker Inc. If it is Pivotal, then great. If it’s Red Hat, then perhaps it is not as good an idea. The question is, which has the deeper pockets?
It is actually the other way around, we *do* run *all* user apps inside Docker containers.
We don’t allow_sudo by default for the reasons stated (root in the container is the same as root on the host), although there is no actually known exploit so far that would allow you to escape the non-privileged container.
What we don’t allow is BYOC (bring-your-own-container) because then we cannot guarantee that you cannot elevate to root inside the container. Instead, we use a known base Docker container and use Heroku-style buildpacks to build up the stack.
As for services running in Docker containers – very few other Stackato core processes were dockerized in Stackato 3.2.
Hi Phil,
Thanks for the correction. This space is moving so fast its sometimes hard to follow.
Mike