The Future of OpenShift and Docker Containers

A few months ago, Docker (then dotCloud) and Red Hatannounced a partnership to collaborate around Docker, the excellent container management solution for Linux. At the time, the OpenShift team was heads down working on our 2.0 release, but we were already thinking about how we could use Docker to take application development and deployment on OpenShift to the next level.

For those who aren’t yet familiar with Docker, it takes the power of Linux containers (the ability to isolate software on a Linux system so that it can’t see other software), pairs them with an efficient file system abstraction for delivering the exact libraries you need to any server, and then makes it all ridiculously easy to use.

This gets to the heart of platform as a service – giving developers deep control over their stack (whether it’s JBoss, LAMP, Rails, or Python), and making it easy to control when and how changes are made. In addition, properly secured Docker containers can do things that were previously difficult to enable, like installing RPMs per container and changing system owned config files.

Some of the scenarios we think might matter to all of us are:

When building cartridges:

Make it easier to create cartridges

Make it possible to use RPMs and other packaging formats to do so

Make it easier to manage the processes in the cartridge

Make it easier to reuse cartridges others have written

Take an existing Docker image and easily turn it into a cartridge

Be able to take existing environments and make those into a cartridge

Be able to redistribute your cartridges to others easily

Inside an application:

Run arbitrary Docker images as new gears

Be able to roll back everything relevant to your application, including cartridge versions and security updates

Be able to use the same version of your entire “stack” (cartridge, libraries, and your source code) in a test environment and then move it to production

Run the same copy of your gear (your app, plus cartridges) in your local installation of OpenShift and in a cloud deployment of OpenShift

As an administrator:

Be able to manage when security updates are pushed out to user’s applications

Easily manage the set of cartridges that matter to my organization – whether they are coming from upstream, from the community, or from partners and vendors.

We think there is a great opportunity to take aspects of Docker that are appealing to deployers, and the lifecycle integration that OpenShift cartridges provide (source, build, event hooks, and port metadata), to improve both for everyone. What might a marriage of Docker images and cartridges look like? One possible model is as follows:

A cartridge is a Docker image with enough extra metadata for OpenShift to:

Provide a template/example repo for a Git repository if necessary

Build your source

Deploy your source

And connect a container (a gear) running that image with other containers in your app

A deployed cartridge is a Docker image with a built version of your source code.

To create it, OpenShift would:

Start a container running the cartridge image

Inject your source code

Invoke a script in the cartridge that will do any build and deployment steps necessary

And save the resulting Docker container as a new image

A gear is a Docker container based on your deployed cartridge image, running on an OpenShift node

This mailing list and the public IRC channel #openshift-dev on freenode are as always the best place to discuss, ask questions, and make suggestions. I’m excited to start exploring this as a community.