Further to the earlier technology preview, running MQ queue managers inside Docker containers is now supported for production use.  Check out this short demo video.

Why is this useful?

Docker allows you to "package an application with all of its dependencies into a standardized unit for software development" (see "What is Docker?"). This gives you a predictable environment for running your application, which in turn leads to reliable deployments.

There can be major benefits to your continuous delivery pipeline too.  Changes to your application can be deployed to test and staging systems quickly and easily.  You can even do more realistic tests on an engineer's laptop, due to the consistency of the environment provided by containers.  Using Docker, this process is typically much faster than using traditional virtual machines, as you can take advantage of Docker's filesystem layering to deploy just your changes, not a whole virtual machine image.

In addition, the Docker container runtime helps isolate your application from those running in other containers - all the processes associated with your application are run in their own process space, and can’t see any other processes running on your server.  You can also limit the amount of memory and CPU you allocate to your container, to prevent it from being affected by other software on the same server.

What's supported right now?

You will be supported running basic queue managers and any MQ client applications inside Docker containers, as long as you meet a few basic conditions.  Not all the MQ packages are currently supported, but we're working on adding more.

See the MQ Knowledge Center for details on how to get started, or check out the samples on GitHub.

What's next?

Docker Engine is just one part of an exciting new container-based cloud ecosystem, which offers many exciting possibilities. For example, consider running a cluster of MQ queue managers on a container orchestration system like Apache Mesos or Kubernetes. You could instruct the system to run a cluster of ten queue managers, and a scheduler would run those ten instances on any physical or virtual servers which match the constraints you give it - for example, at most one instance in each rack in your data center. The integrated monitoring (e.g. from Mesosphere Marathon or a Kubernetes replication controller) could detect a failing queue manager and run a replacement queue manager, potentially on a different server.  This is one way of getting some of the key advantages of cloud computing for your MQ-based solution.

The technology is moving fast in the container cloud space, and the possibilities here are virtually endless. So what should we do next?