Decker = Docker + Cloud Foundry

Software is eating the world. From the web as we know it, to the Internet of Things, to Microservices, software is taking over. The ability of businesses to deploy, manage, and iterate on their software is becoming the key determinant in their success. Cloud Foundry enables businesses to empower developers to deliver great software by removing barriers such as infrastructure configuration, inconsistent deployments, and service wiring chaos.

Forward-thinking organisations such as Comic Relief and Baidu are already realising the benefits.


Just as the PaaS revolution is sweeping through software development so the container revolution is taking the infrastructure world by storm. I’ve spoken many times about how the vast majority of applications can and should be deployed using Cloud Foundry buildpacks; deploying a custom infrastructure is an impediment to delivery and an ongoing maintenance headache. I am sometimes asked ‘What about legacy applications?’, ‘What about this custom setup I need to run for compliance?’, ‘What about this obscure binary I need?’ – this is where we can drop down a level from PaaS to deploy custom containers.


Docker is gaining a huge amount of traction in the container space. I’ve enjoyed deploying custom services with Docker – the filesystem layer caching and registry aspects are fantastic. The ability to construct containers via a Dockerfile is also very powerful, although fraught with dangers from non-deterministic operating-system commands. The difficulties experienced when attempting to scale beyond a single host can sometimes be frustrating.


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. Thus the idea for Decker was born.

Cloud Foundry already uses the same Linux containerisation technology as Docker: cgroups. The differences lie in the orchestration of cgroups; Docker initially chose LXC, while the Cloud Foundry team found the LXC implementation troublesome to work with and instead created their own orchestration layer – Warden.


Application execution happens on the DEA component in Cloud Foundry. There have been some issues running LXC and Warden against the same kernel so I decided early on in Decker’s development to deploy a separate pool of DEAs to run Docker containers. A DEA with Docker creates Decker. Decker virtual machines run alongside Cloud Foundry virtual machines.


The driving force behind the implementation was my desire to provide a user experience based around cf push in a directory with a Dockerfile. I have provided a demonstration of this functionality here. Deploying containers in this way brings the enabling power of Cloud Foundry to an entire new audience. Container developers can scale (cf instances +200), bind services (cf bind-service cassandra), and map routes (cf map) – they too can focus on delivering value rather than configuring and managing distributed infrastructure.


Deployment of Decker is achieved via BOSH. The Decker job requires a custom stemcell. Deploying alongside Cloud Foundry is a composite deployment of Cloud Foundry and Decker. I will be publishing a tutorial soon outlining the complete deployment steps. Alternatively, if you like the idea of push-button deployments as illustrated in the Decker demo, please contact us to gain access to the CloudCredo Platform.


We’re actively working on Decker and using the feedback from our clients to drive future iterations. If you’d like us to deploy and manage it for you, or for any other Cloud Foundry requirements, please get in touch. We’re looking forward to hearing from you.

Colin Humphreys

  • drnic

    Great job guys, keep going!

  • Andy Piper

    Nice work!

  • Kapil Thangavelu

    nice work. one minor correction “instead created their own orchestration layer – Warden.” .. umm.. i think you mean container layer nor orchestration.