07250457df
As discussed on the maintainers mailinglist, and during a maintainers review session; We've recently made changes to the Dockerfile syntax (e.g., `HEALTHCHECK`, `SHELL`), so mentioning the Dockerfile syntax as a frozen feature is no longer accurate. Removing it from frozen features does NOT automatically state an intent to make big changes to the syntax; making changes to the syntax are important decisions and should never be taken lightly. This change is just to indicate that we can *accept* changes if they are meaningful, and we're confident they can be made. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
119 lines
6.2 KiB
Markdown
119 lines
6.2 KiB
Markdown
Docker Engine Roadmap
|
|
=====================
|
|
|
|
### How should I use this document?
|
|
|
|
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.
|
|
|
|
### How can I help?
|
|
|
|
Short term objectives are listed in the [wiki](https://github.com/docker/docker/wiki) and described
|
|
in [Issues](https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3Aroadmap). 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.
|
|
|
|
### How can I add something to the roadmap?
|
|
|
|
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.
|
|
|
|
# 1. Features and refactoring
|
|
|
|
## 1.1 Runtime improvements
|
|
|
|
We recently introduced [`runC`](https://runc.io) as a standalone low-level tool for container
|
|
execution. The initial goal was to integrate runC as a replacement in the Engine for the traditional
|
|
default libcontainer `execdriver`, but the Engine internals were not ready for this.
|
|
|
|
As runC continued evolving, and the OCI specification along with it, we created
|
|
[`containerd`](https://containerd.tools/), a daemon to control and monitor multiple `runC`. This is
|
|
the new target for Engine integration, as it can entirely replace the whole `execdriver`
|
|
architecture, and container monitoring along with it.
|
|
|
|
Docker Engine will rely on a long-running `containerd` companion daemon for all container execution
|
|
related operations. This could open the door in the future for Engine restarts without interrupting
|
|
running containers.
|
|
|
|
## 1.2 Plugins improvements
|
|
|
|
Docker Engine 1.7.0 introduced plugin support, initially for the use cases of volumes and networks
|
|
extensions. The plugin infrastructure was kept minimal as we were collecting use cases and real
|
|
world feedback before optimizing for any particular workflow.
|
|
|
|
In the future, we'd like plugins to become first class citizens, and encourage an ecosystem of
|
|
plugins. This implies in particular making it trivially easy to distribute plugins as containers
|
|
through any Registry instance, as well as solving the commonly heard pain points of plugins needing
|
|
to be treated as somewhat special (being active at all time, started before any other user
|
|
containers, and not as easily dismissed).
|
|
|
|
## 1.3 Internal decoupling
|
|
|
|
A lot of work has been done in trying to decouple the Docker Engine's internals. In particular, the
|
|
API implementation has been refactored and ongoing work is happening to move the code to a separate
|
|
repository ([`docker/engine-api`](https://github.com/docker/engine-api)), and the Builder side of
|
|
the daemon is now [fully independent](https://github.com/docker/docker/tree/master/builder) while
|
|
still residing in the same repository.
|
|
|
|
We are exploring ways to go further with that decoupling, capitalizing on the work introduced by the
|
|
runtime renovation and plugins improvement efforts. Indeed, the combination of `containerd` support
|
|
with the concept of "special" containers opens the door for bootstrapping more Engine internals
|
|
using the same facilities.
|
|
|
|
## 1.4 Cluster capable Engine
|
|
|
|
The community has been pushing for a more cluster capable Docker Engine, and a huge effort was spent
|
|
adding features such as multihost networking, and node discovery down at the Engine level. Yet, the
|
|
Engine is currently incapable of taking scheduling decisions alone, and continues relying on Swarm
|
|
for that.
|
|
|
|
We plan to complete this effort and make Engine fully cluster capable. Multiple instances of the
|
|
Docker Engine being already capable of discovering each other and establish overlay networking for
|
|
their container to communicate, the next step is for a given Engine to gain ability to dispatch work
|
|
to another node in the cluster. This will be introduced in a backward compatible way, such that a
|
|
`docker run` invocation on a particular node remains fully deterministic.
|
|
|
|
# 2 Frozen features
|
|
|
|
## 2.1 Docker exec
|
|
|
|
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 Runtime ingredient effort.
|
|
|
|
## 2.2 Remote Registry Operations
|
|
|
|
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:
|
|
|
|
- push
|
|
- pull
|
|
- run
|
|
- build
|
|
- search
|
|
- login
|
|
|
|
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.
|