Update the Roadmap
As part of the Moby transition (see #35115), update the Roadmap to reflect the new priorities. Also just update it as it was written a while back, and we made some progress in areas such as `containerd`. Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This commit is contained in:
Justin Cormack
parent
eee2df1083
commit
de86d33b4a
122
ROADMAP.md
122
ROADMAP.md
|
|
@ -1,118 +1,68 @@
|
||||||
Docker Engine Roadmap
|
Moby Project Roadmap
|
||||||
=====================
|
====================
|
||||||
|
|
||||||
### How should I use this document?
|
### How should I use this document?
|
||||||
|
|
||||||
This document provides description of items that the project decided to prioritize. This should
|
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
|
serve as a reference point for Moby contributors to understand where the project is going, and
|
||||||
help determine if a contribution could be conflicting with some longer terms plans.
|
help determine if a contribution could be conflicting with some longer term plans.
|
||||||
|
|
||||||
The fact that a feature isn't listed here doesn't mean that a patch for it will automatically be
|
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
|
refused! We are always happy to receive patches for new cool features we haven't thought about,
|
||||||
patches for new cool features we haven't thought about, or didn't judge priority. Please however
|
or didn't judge to be a priority. Please however understand that such patches might take longer
|
||||||
understand that such patches might take longer for us to review.
|
for us to review.
|
||||||
|
|
||||||
### How can I help?
|
### How can I help?
|
||||||
|
|
||||||
Short term objectives are listed in the [wiki](https://github.com/docker/docker/wiki) and described
|
Short term objectives are listed in
|
||||||
in [Issues](https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3Aroadmap). Our
|
[Issues](https://github.com/moby/moby/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
|
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
|
issues if you want to work on 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
|
assigned on an issue you'd like to participate in, pinging him on GitHub to offer your help is
|
||||||
the best way to go.
|
the best way to go.
|
||||||
|
|
||||||
### How can I add something to the roadmap?
|
### 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
|
The roadmap process is new to the Moby Project: 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
|
project objectives. Our immediate goal is to be more transparent, and work with our community to
|
||||||
focus our efforts on fewer prioritized topics.
|
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 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
|
we are not quite there yet. For the time being, it is best to discuss with the maintainers on an
|
||||||
won't be accepting pull requests adding or removing items from this file.
|
issue, in the Slack channel, or in person at the Moby Summits that happen every few months.
|
||||||
|
|
||||||
# 1. Features and refactoring
|
# 1. Features and refactoring
|
||||||
|
|
||||||
## 1.1 Runtime improvements
|
## 1.1 Runtime improvements
|
||||||
|
|
||||||
We recently introduced [`runC`](https://runc.io) as a standalone low-level tool for container
|
We 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
|
execution in 2015, the first stage in spinning out parts of the Engine into standalone tools.
|
||||||
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
|
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
|
[`containerd`](https://github.com/containerd/containerd), a daemon to control and monitor `runC`.
|
||||||
the new target for Engine integration, as it can entirely replace the whole `execdriver`
|
In late 2016 this was relaunched as the `containerd` 1.0 track, aiming to provide a common runtime
|
||||||
architecture, and container monitoring along with it.
|
for the whole spectrum of container systems, including Kubernetes, with wide community support.
|
||||||
|
This change meant that there was an increased scope for `containerd`, including image management
|
||||||
|
and storage drivers.
|
||||||
|
|
||||||
Docker Engine will rely on a long-running `containerd` companion daemon for all container execution
|
Moby 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
|
related operations. This could open the door in the future for Engine restarts without interrupting
|
||||||
running containers.
|
running containers. The switch over to containerd 1.0 is an important goal for the project, and
|
||||||
|
will result in a significant simplification of the functions implemented in this repository.
|
||||||
|
|
||||||
## 1.2 Plugins improvements
|
## 1.2 Internal decoupling
|
||||||
|
|
||||||
Docker Engine 1.7.0 introduced plugin support, initially for the use cases of volumes and networks
|
A lot of work has been done in trying to decouple Moby internals. This process of creating
|
||||||
extensions. The plugin infrastructure was kept minimal as we were collecting use cases and real
|
standalone projects with a well defined function that attract a dedicated community should continue.
|
||||||
world feedback before optimizing for any particular workflow.
|
As well as integrating `containerd` we would like to integrate [BuildKit](https://github.com/moby/buildkit)
|
||||||
|
as the next standalone component.
|
||||||
|
|
||||||
In the future, we'd like plugins to become first class citizens, and encourage an ecosystem of
|
We see gRPC as the natural communication layer between decoupled components.
|
||||||
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
|
## 1.3 Custom assembly tooling
|
||||||
|
|
||||||
A lot of work has been done in trying to decouple the Docker Engine's internals. In particular, the
|
We have been prototyping the Moby [assembly tool](https://github.com/moby/tool) which was originally
|
||||||
API implementation has been refactored, and the Builder side of the daemon is now
|
developed for LinuxKit and intend to turn it into a more generic packaging and assembly mechanism
|
||||||
[fully independent](https://github.com/docker/docker/tree/master/builder) while still residing in
|
that can build not only the default version of Moby, as distribution packages or other useful forms,
|
||||||
the same repository.
|
but can also build very different container systems, themselves built of cooperating daemons built in
|
||||||
|
and running in containers. We intend to merge this functionality into this repo.
|
||||||
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.
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue