This blog post originally appeared in the OpenShift development mailing list
A few months ago, Docker (then dotCloud) and Red Hat announced 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.
- Integrate existing organizational build processes into OpenShift without pain
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
- That is managed in bulk by existing administrative tools
- That is secured and supported by the Red Hat kernel teams
- That is deeply integrated into existing Linux toolchains
I invite everyone who is a user, developer, cartridge author, or administrator of OpenShift (whether you have experience with Docker or not) to help map out how cartridges can get even better. An early draft of the Docker Cartridges PEP is available for public discussion and we would like to explore different ways of using Docker to build cartridges – I’ve started some very simple examples (ruby, buildpack, and a simple db) and I’m hoping as a community we can draft many more.
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.