This document provides description of items that the project decided to prioritize. This should serve as a reference point for Docker contributors to understand where the project is going, and help determine if a contribution could be conflicting with some longer terms plans.
The fact that a feature isn‘t listed here doesn’t mean that a patch for it will automatically be refused (except for those mentioned as “frozen features” below)! We are always happy to receive patches for new cool features we haven‘t thought about, or didn’t judge priority. Please however understand that such patches might take longer for us to review.
Short term objectives are listed in the wiki and described in Issues. Our goal is to split down the workload in such way that anybody can jump in and help. Please comment on issues if you want to take it to avoid duplicating effort! Similarly, if a maintainer is already assigned on an issue you'd like to participate in, pinging him on IRC or GitHub to offer your help is the best way to go.
The roadmap process is new to the Docker Engine: we are only beginning to structure and document the project objectives. Our immediate goal is to be more transparent, and work with our community to focus our efforts on fewer prioritized topics.
We hope to offer in the near future a process allowing anyone to propose a topic to the roadmap, but we are not quite there yet. For the time being, the BDFL remains the keeper of the roadmap, and we won't be accepting pull requests adding or removing items from this file.
Security is a top objective for the Docker Engine. The most notable items we intend to provide in the near future are:
We define a plumbing tool as a standalone piece of software usable and meaningful on its own. In the current state of the Docker Engine, most subsystems provide independent functionalities (such the builder, pushing and pulling images, running applications in a containerized environment, etc) but all are coupled in a single binary. We want to offer the users to flexibility to use only the pieces they need, and we will also gain in maintainability by splitting the project among multiple repositories.
As it currently stands, the rough design outlines is to have:
V and network N), while still providing pass-through access to the individual subsystems.The architectural details are still being worked on, but one thing we know for sure is that we need to technically decouple the pieces.
A Runtime tool already exists today in the form of runC. We intend to modify the Engine to directly call out to a binary implementing the Open Containers Specification such as runC rather than relying on libcontainer to set the container runtime up.
This plan will deprecate the existing execdriver as different runtime backends will be implemented as separated binaries instead of being compiled into the Engine.
The Builder (i.e., the ability to build an image from a Dockerfile) is already nicely decoupled, but would benefit from being entirely separated from the Engine, and rely on the standard Engine API for its operations.
Distribution already has a dedicated repository which holds the implementation for Registry v2 and client libraries. We could imagine going further by having the Engine call out to a binary providing image distribution related functionalities.
There are two short term goals related to image distribution. The first is stabilize and simplify the push/pull code. Following that is the conversion to the more secure Registry V2 protocol.
Most of networking related code was already decoupled today in libnetwork. As with other ingredients, we might want to take it a step further and make it a meaningful utility that the Engine would call out to instead of a library.
An initiative around plugins started with Docker 1.7.0, with the goal of allowing for out of process extensibility of some Docker functionalities, starting with volumes and networking. The approach is to provide specific extension points rather than generic hooking facilities. We also deliberately keep the extensions API the simplest possible, expanding as we discover valid use cases that cannot be implemented.
At the time of writing:
Volumes are not a first class citizen in the Engine today: we would like better volume management, similar to the way network are managed in the new CNM.
The current Engine API is insufficiently typed, versioned, and ultimately hard to maintain. We also suffer from the lack of a common implementation with Swarm.
Support for checkpoint/restore was merged in libcontainer and made available through runC: we intend to take advantage of it in the Engine.
We won't accept patches expanding the surface of docker exec, which we intend to keep as a debugging feature, as well as being strongly dependent on the the Runtime ingredient effort.
The Dockerfile syntax as we know it is simple, and has proven succesful in supporting all our official images. Although this is not a definitive move, we temporarily won't accept more patches to the Dockerfile syntax for several reasons:
Again, this is not about saying that the Dockerfile syntax is done, it's about making choices about what we want to do first!
A large amount of work is ongoing in the area of image distribution and provenance. This includes moving to the V2 Registry API and heavily refactoring the code that powers these features. The desired result is more secure, reliable and easier to use image distribution.
Part of the problem with this part of the code base is the lack of a stable and flexible interface. If new features are added that access the registry without solidifying these interfaces, achieving feature parity will continue to be elusive. While we get a handle on this situation, we are imposing a moratorium on new code that accesses the Registry API in commands that don't already make remote calls.
Currently, only the following commands cause interaction with a remote registry:
In the interest of stabilizing the registry access model during this ongoing work, we are not accepting additions to other commands that will cause remote interaction with the Registry API. This moratorium will lift when the goals of the distribution project have been met.