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>
... | ... |
@@ -1,118 +1,68 @@ |
1 |
-Docker Engine Roadmap |
|
2 |
-===================== |
|
1 |
+Moby Project Roadmap |
|
2 |
+==================== |
|
3 | 3 |
|
4 | 4 |
### How should I use this document? |
5 | 5 |
|
6 | 6 |
This document provides description of items that the project decided to prioritize. This should |
7 |
-serve as a reference point for Docker contributors to understand where the project is going, and |
|
8 |
-help determine if a contribution could be conflicting with some longer terms plans. |
|
7 |
+serve as a reference point for Moby contributors to understand where the project is going, and |
|
8 |
+help determine if a contribution could be conflicting with some longer term plans. |
|
9 | 9 |
|
10 | 10 |
The fact that a feature isn't listed here doesn't mean that a patch for it will automatically be |
11 |
-refused (except for those mentioned as "frozen features" below)! We are always happy to receive |
|
12 |
-patches for new cool features we haven't thought about, or didn't judge priority. Please however |
|
13 |
-understand that such patches might take longer for us to review. |
|
11 |
+refused! We are always happy to receive patches for new cool features we haven't thought about, |
|
12 |
+or didn't judge to be a priority. Please however understand that such patches might take longer |
|
13 |
+for us to review. |
|
14 | 14 |
|
15 | 15 |
### How can I help? |
16 | 16 |
|
17 |
-Short term objectives are listed in the [wiki](https://github.com/docker/docker/wiki) and described |
|
18 |
-in [Issues](https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3Aroadmap). Our |
|
17 |
+Short term objectives are listed in |
|
18 |
+[Issues](https://github.com/moby/moby/issues?q=is%3Aopen+is%3Aissue+label%3Aroadmap). Our |
|
19 | 19 |
goal is to split down the workload in such way that anybody can jump in and help. Please comment on |
20 |
-issues if you want to take it to avoid duplicating effort! Similarly, if a maintainer is already |
|
21 |
-assigned on an issue you'd like to participate in, pinging him on IRC or GitHub to offer your help is |
|
20 |
+issues if you want to work on it to avoid duplicating effort! Similarly, if a maintainer is already |
|
21 |
+assigned on an issue you'd like to participate in, pinging him on GitHub to offer your help is |
|
22 | 22 |
the best way to go. |
23 | 23 |
|
24 | 24 |
### How can I add something to the roadmap? |
25 | 25 |
|
26 |
-The roadmap process is new to the Docker Engine: we are only beginning to structure and document the |
|
26 |
+The roadmap process is new to the Moby Project: we are only beginning to structure and document the |
|
27 | 27 |
project objectives. Our immediate goal is to be more transparent, and work with our community to |
28 | 28 |
focus our efforts on fewer prioritized topics. |
29 | 29 |
|
30 | 30 |
We hope to offer in the near future a process allowing anyone to propose a topic to the roadmap, but |
31 |
-we are not quite there yet. For the time being, the BDFL remains the keeper of the roadmap, and we |
|
32 |
-won't be accepting pull requests adding or removing items from this file. |
|
31 |
+we are not quite there yet. For the time being, it is best to discuss with the maintainers on an |
|
32 |
+issue, in the Slack channel, or in person at the Moby Summits that happen every few months. |
|
33 | 33 |
|
34 | 34 |
# 1. Features and refactoring |
35 | 35 |
|
36 | 36 |
## 1.1 Runtime improvements |
37 | 37 |
|
38 |
-We recently introduced [`runC`](https://runc.io) as a standalone low-level tool for container |
|
39 |
-execution. The initial goal was to integrate runC as a replacement in the Engine for the traditional |
|
40 |
-default libcontainer `execdriver`, but the Engine internals were not ready for this. |
|
38 |
+We introduced [`runC`](https://runc.io) as a standalone low-level tool for container |
|
39 |
+execution in 2015, the first stage in spinning out parts of the Engine into standalone tools. |
|
41 | 40 |
|
42 | 41 |
As runC continued evolving, and the OCI specification along with it, we created |
43 |
-[`containerd`](https://containerd.tools/), a daemon to control and monitor multiple `runC`. This is |
|
44 |
-the new target for Engine integration, as it can entirely replace the whole `execdriver` |
|
45 |
-architecture, and container monitoring along with it. |
|
42 |
+[`containerd`](https://github.com/containerd/containerd), a daemon to control and monitor `runC`. |
|
43 |
+In late 2016 this was relaunched as the `containerd` 1.0 track, aiming to provide a common runtime |
|
44 |
+for the whole spectrum of container systems, including Kubernetes, with wide community support. |
|
45 |
+This change meant that there was an increased scope for `containerd`, including image management |
|
46 |
+and storage drivers. |
|
46 | 47 |
|
47 |
-Docker Engine will rely on a long-running `containerd` companion daemon for all container execution |
|
48 |
+Moby will rely on a long-running `containerd` companion daemon for all container execution |
|
48 | 49 |
related operations. This could open the door in the future for Engine restarts without interrupting |
49 |
-running containers. |
|
50 |
+running containers. The switch over to containerd 1.0 is an important goal for the project, and |
|
51 |
+will result in a significant simplification of the functions implemented in this repository. |
|
50 | 52 |
|
51 |
-## 1.2 Plugins improvements |
|
53 |
+## 1.2 Internal decoupling |
|
52 | 54 |
|
53 |
-Docker Engine 1.7.0 introduced plugin support, initially for the use cases of volumes and networks |
|
54 |
-extensions. The plugin infrastructure was kept minimal as we were collecting use cases and real |
|
55 |
-world feedback before optimizing for any particular workflow. |
|
55 |
+A lot of work has been done in trying to decouple Moby internals. This process of creating |
|
56 |
+standalone projects with a well defined function that attract a dedicated community should continue. |
|
57 |
+As well as integrating `containerd` we would like to integrate [BuildKit](https://github.com/moby/buildkit) |
|
58 |
+as the next standalone component. |
|
56 | 59 |
|
57 |
-In the future, we'd like plugins to become first class citizens, and encourage an ecosystem of |
|
58 |
-plugins. This implies in particular making it trivially easy to distribute plugins as containers |
|
59 |
-through any Registry instance, as well as solving the commonly heard pain points of plugins needing |
|
60 |
-to be treated as somewhat special (being active at all time, started before any other user |
|
61 |
-containers, and not as easily dismissed). |
|
60 |
+We see gRPC as the natural communication layer between decoupled components. |
|
62 | 61 |
|
63 |
-## 1.3 Internal decoupling |
|
62 |
+## 1.3 Custom assembly tooling |
|
64 | 63 |
|
65 |
-A lot of work has been done in trying to decouple the Docker Engine's internals. In particular, the |
|
66 |
-API implementation has been refactored, and the Builder side of the daemon is now |
|
67 |
-[fully independent](https://github.com/docker/docker/tree/master/builder) while still residing in |
|
68 |
-the same repository. |
|
69 |
- |
|
70 |
-We are exploring ways to go further with that decoupling, capitalizing on the work introduced by the |
|
71 |
-runtime renovation and plugins improvement efforts. Indeed, the combination of `containerd` support |
|
72 |
-with the concept of "special" containers opens the door for bootstrapping more Engine internals |
|
73 |
-using the same facilities. |
|
74 |
- |
|
75 |
-## 1.4 Cluster capable Engine |
|
76 |
- |
|
77 |
-The community has been pushing for a more cluster capable Docker Engine, and a huge effort was spent |
|
78 |
-adding features such as multihost networking, and node discovery down at the Engine level. Yet, the |
|
79 |
-Engine is currently incapable of taking scheduling decisions alone, and continues relying on Swarm |
|
80 |
-for that. |
|
81 |
- |
|
82 |
-We plan to complete this effort and make Engine fully cluster capable. Multiple instances of the |
|
83 |
-Docker Engine being already capable of discovering each other and establish overlay networking for |
|
84 |
-their container to communicate, the next step is for a given Engine to gain ability to dispatch work |
|
85 |
-to another node in the cluster. This will be introduced in a backward compatible way, such that a |
|
86 |
-`docker run` invocation on a particular node remains fully deterministic. |
|
87 |
- |
|
88 |
-# 2. Frozen features |
|
89 |
- |
|
90 |
-## 2.1 Docker exec |
|
91 |
- |
|
92 |
-We won't accept patches expanding the surface of `docker exec`, which we intend to keep as a |
|
93 |
-*debugging* feature, as well as being strongly dependent on the Runtime ingredient effort. |
|
94 |
- |
|
95 |
-## 2.2 Remote Registry Operations |
|
96 |
- |
|
97 |
-A large amount of work is ongoing in the area of image distribution and provenance. This includes |
|
98 |
-moving to the V2 Registry API and heavily refactoring the code that powers these features. The |
|
99 |
-desired result is more secure, reliable and easier to use image distribution. |
|
100 |
- |
|
101 |
-Part of the problem with this part of the code base is the lack of a stable and flexible interface. |
|
102 |
-If new features are added that access the registry without solidifying these interfaces, achieving |
|
103 |
-feature parity will continue to be elusive. While we get a handle on this situation, we are imposing |
|
104 |
-a moratorium on new code that accesses the Registry API in commands that don't already make remote |
|
105 |
-calls. |
|
106 |
- |
|
107 |
-Currently, only the following commands cause interaction with a remote registry: |
|
108 |
- |
|
109 |
- - push |
|
110 |
- - pull |
|
111 |
- - run |
|
112 |
- - build |
|
113 |
- - search |
|
114 |
- - login |
|
115 |
- |
|
116 |
-In the interest of stabilizing the registry access model during this ongoing work, we are not |
|
117 |
-accepting additions to other commands that will cause remote interaction with the Registry API. This |
|
118 |
-moratorium will lift when the goals of the distribution project have been met. |
|
64 |
+We have been prototyping the Moby [assembly tool](https://github.com/moby/tool) which was originally |
|
65 |
+developed for LinuxKit and intend to turn it into a more generic packaging and assembly mechanism |
|
66 |
+that can build not only the default version of Moby, as distribution packages or other useful forms, |
|
67 |
+but can also build very different container systems, themselves built of cooperating daemons built in |
|
68 |
+and running in containers. We intend to merge this functionality into this repo. |