This document is a high-level overview of where we want to take Docker next. It is a curated selection of planned improvements which are either important, difficult, or both.
For a more complete view of planned and requested improvements, see the Github issues.
Tu suggest changes to the roadmap, including additions, please write the change as if it were already in effect, and make a pull request.
Our goal is to make Docker run everywhere, but currently Docker requires Linux version 3.8 or higher with lxc and aufs support. If you‘re deploying new machines for the purpose of running Docker, this is a fairly easy requirement to meet. However, if you’re adding Docker to an existing deployment, you may not have the flexibility to update and patch the kernel.
Expanding Docker's kernel support is a priority. This includes running on older kernel versions, but also on kernels with no AUFS support, or with incomplete lxc capabilities.
Our goal is to make Docker run everywhere. However currently Docker only runs on x86_64 systems. We plan on expanding architecture support, so that Docker containers can be created and used on more architectures.
We want Docker to be the secret ingredient that makes your existing tools more awesome. Thanks to this philosophy, Docker has already been integrated with Puppet, Chef, Openstack Nova, Jenkins, DotCloud sandbox, Pallet, Strider CI and even Heroku buildpacks.
Expect Docker to integrate with even more of your favorite tools going forward, including:
We want Docker to run everywhere, and to integrate with every devops tool. Those are ambitious goals, and the only way to reach them is with the Docker community. For the community to participate fully, we need an API which allows Docker to be deeply and easily customized.
We are working on a plugin API which will make Docker very, very customization-friendly. We believe it will facilitate the integrations listed above - and many more we didn't even think about.
Let us know if you want to start playing with the API before it's generally available.
In 0.3 we introduced data volumes, a great mechanism for manipulating persistent data such as database files, log files, etc.
Data volumes can be shared between containers, a powerful capability which allows many advanced use cases. In the future it will also be possible to share volumes between a container and the underlying host. This will make certain scenarios much easier, such as using a high-performance storage backend for your production database, making live development changes available to a container, etc.
We believe that great documentation is worth 10 features. We are often told that “Docker's documentation is great for a 2-month old project”. Our goal is to make it great, period.
If you have feedback on how to improve our documentation, please get in touch by replying to this email, or by filing an issue. We always appreciate it!
Docker is still alpha software, and not suited for production. We are working hard to get there, and we are confident that it will be possible within a few months.
Docker currently supports 2 flavors of port redirection: STATIC->STATIC (eg. “redirect public port 80 to private port 80”) and RANDOM->STATIC (eg. “redirect any public port to private port 80”).
With these 2 flavors, docker can support the majority of backend programs out there. But some applications have more exotic requirements, generally to implement custom clustering techniques. These applications include Hadoop, MongoDB, Riak, RabbitMQ, Disco, and all programs relying on Erlang's OTP.
To support these applications, Docker needs to support more advanced redirection flavors, including:
These flavors should be implemented without breaking existing semantics, if at all possible.