1. docker
  2. Commit aa5fb884b44af40220f47d12a779223653f5a625
Browse code

Add ROADMAP.md

Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>

Arnaud Porterie authored on 2015/06/16 03:30:08
Showing 1 changed files
ROADMAP.md
History View file @ aa5fb88
1 1 
new file mode 100644
... ... 
@@ -0,0 +1,154 @@
0 
+Docker Engine Roadmap
1 
+=====================
2 
+
3 
+### How should I use this document?
4 
+
5 
+This document provides description of items that the project decided to prioritize. This should
6 
+serve as a reference point for Docker contributors to understand where the project is going, and
7 
+help determine if a contribution could be conflicting with some longer terms plans.
8 
+
9 
+The fact that a feature isn't listed here doesn't mean that a patch for it will automatically be
10 
+refused (except for those mentioned as "frozen features" below)! We are always happy to receive
11 
+patches for new cool features we haven't thought about, or didn't judge priority. Please however
12 
+understand that such patches might take longer for us to review.
13 
+
14 
+### How can I help?
15 
+
16 
+Short term objectives are listed in the [wiki](https://github.com/docker/docker/wiki) and described
17 
+in [Issues](https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3Aroadmap). Our
18 
+goal is to split down the workload in such way that anybody can jump in and help. Please comment on
19 
+issues if you want to take it to avoid duplicating effort! Similarly, if a maintainer is already
20 
+assigned on an issue you'd like to participate in, pinging him on IRC or GitHub to offer your help is
21 
+the best way to go.
22 
+
23 
+### How can I add something to the roadmap?
24 
+
25 
+The roadmap process is new to the Docker Engine: we are only beginning to structure and document the
26 
+project objectives. Our immediate goal is to be more transparent, and work with our community to
27 
+focus our efforts on fewer prioritized topics.
28 
+
29 
+We hope to offer in the near future a process allowing anyone to propose a topic to the roadmap, but
30 
+we are not quite there yet. For the time being, the BDFL remains the keeper of the roadmap, and we
31 
+won't be accepting pull requests adding or removing items from this file.
32 
+
33 
+# 1. Features and refactoring
34 
+
35 
+## 1.1 Security
36 
+
37 
+Security is a top objective for the Docker Engine. The most notable items we intend to provide in
38 
+the near future are:
39 
+
40 
+- Trusted distribution of images: the effort is driven by the [distribution](https://github.com/docker/distribution)
41 
+group but will have significant impact on the Engine
42 
+- [User namespaces](https://github.com/docker/docker/pull/12648)
43 
+- [Seccomp support](https://github.com/docker/libcontainer/pull/613)
44 
+
45 
+## 1.2 Plumbing project
46 
+
47 
+We define a plumbing tool as a standalone piece of software usable and meaningful on its own. In
48 
+the current state of the Docker Engine, most subsystems provide independent functionalities (such
49 
+the builder, pushing and pulling images, running applications in a containerized environment, etc)
50 
+but all are coupled in a single binary.  We want to offer the users to flexibility to use only the
51 
+pieces they need, and we will also gain in maintainability by splitting the project among multiple
52 
+repositories.
53 
+
54 
+As it currently stands, the rough design outlines is to have:
55 
+- Low level plumbing tools, each dealing with one responsibility (e.g., [runC](https://runc.io))
56 
+- Docker subsystems services, each exposing an elementary concept over an API, and relying on one or
57 
+multiple lower level plumbing tools for their implementation (e.g., network management)
58 
+- Docker Engine to expose higher level actions (e.g., create a container with volume `V` and network
59 
+`N`), while still providing pass-through access to the individual subsystems.
60 
+
61 
+The architectural details are still being worked on, but one thing we know for sure is that we need
62 
+to technically decouple the pieces.
63 
+
64 
+### 1.2.1 Runtime
65 
+
66 
+A Runtime tool already exists today in the form of [runC](https://github.com/opencontainers/runc).
67 
+We intend to modify the Engine to directly call out to a binary implementing the Open Containers
68 
+Specification such as runC rather than relying on libcontainer to set the container runtime up.
69 
+
70 
+This plan will deprecate the existing [`execdriver`](https://github.com/docker/docker/tree/master/daemon/execdriver)
71 
+as different runtime backends will be implemented as separated binaries instead of being compiled
72 
+into the Engine.
73 
+
74 
+### 1.2.2 Builder
75 
+
76 
+The Builder (i.e., the ability to build an image from a Dockerfile) is already nicely decoupled,
77 
+but would benefit from being entirely separated from the Engine, and rely on the standard Engine
78 
+API for its operations.
79 
+
80 
+### 1.2.3 Distribution
81 
+
82 
+Distribution already has a [dedicated repository](https://github.com/docker/distribution) which
83 
+holds the implementation for Registry v2 and client libraries. We could imagine going further by
84 
+having the Engine call out to a binary providing image distribution related functionalities.
85 
+
86 
+There are two short term goals related to image distribution. The first is stabilize and simplify
87 
+the push/pull code. Following that is the conversion to the more secure Registry V2 protocol.
88 
+
89 
+### 1.2.4 Networking
90 
+
91 
+Most of networking related code was already decoupled today in [libnetwork](https://github.com/docker/libnetwork).
92 
+As with other ingredients, we might want to take it a step further and make it a meaningful utility
93 
+that the Engine would call out to instead of a library.
94 
+
95 
+## 1.3 Plugins
96 
+
97 
+An initiative around plugins started with Docker 1.7.0, with the goal of allowing for out of
98 
+process extensibility of some Docker functionalities, starting with volumes and networking. The
99 
+approach is to provide specific extension points rather than generic hooking facilities. We also
100 
+deliberately keep the extensions API the simplest possible, expanding as we discover valid use
101 
+cases that cannot be implemented.
102 
+
103 
+At the time of writing:
104 
+
105 
+- Plugin support is merged as an experimental feature: real world use cases and user feedback will
106 
+help us refine the UX to make the feature more user friendly.
107 
+- There are no immediate plans to expand on the number of pluggable subsystems.
108 
+- Golang 1.5 might add language support for [plugins](https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ)
109 
+which we consider supporting as an alternative to JSON/HTTP.
110 
+
111 
+## 1.4 Volume management
112 
+
113 
+Volumes are not a first class citizen in the Engine today: we would like better volume management,
114 
+similar to the way network are managed in the new [CNM](https://github.com/docker/docker/issues/9983).
115 
+
116 
+## 1.5 Better API implementation
117 
+
118 
+The current Engine API is insufficiently typed, versioned, and ultimately hard to maintain. We
119 
+also suffer from the lack of a common implementation with [Swarm](https://github.com/docker/swarm).
120 
+
121 
+## 1.6 Checkpoint/restore
122 
+
123 
+Support for checkpoint/restore was [merged](https://github.com/docker/libcontainer/pull/479) in
124 
+[libcontainer](https://github.com/docker/libcontainer) and made available through [runC](https://runc.io):
125 
+we intend to take advantage of it in the Engine.
126 
+
127 
+# 2 Frozen features
128 
+
129 
+## 2.1 Docker exec
130 
+
131 
+We won't accept patches expanding the surface of `docker exec`, which we intend to keep as a
132 
+*debugging* feature, as well as being strongly dependent on the the Runtime ingredient effort.
133 
+
134 
+## 2.2 Dockerfile syntax
135 
+
136 
+The Dockerfile syntax as we know it is simple, and has proven succesful in supporting all our
137 
+[official images](https://github.com/docker-library/official-images). Although this is *not* a
138 
+definitive move, we temporarily won't accept more patches to the Dockerfile syntax for several
139 
+reasons:
140 
+
141 
+- Long term impact of syntax changes is a sensitive matter that require an amount of attention
142 
+the volume of Engine codebase and activity today doesn't allow us to provide
143 
+- Allowing the Builder to be implemented as a separate utility consuming the Engine's API will
144 
+open the door for many possibilities, such as offering alternate syntaxes or DSL for existing
145 
+languages without cluttering the Engine's codebase
146 
+- A standalone Builder will also offer the opportunity for a better dedicated group of maintainers
147 
+to own the Dockerfile syntax and decide collectively on the direction to give it
148 
+- Our experience with official images tend to show that no new instruction or syntax expansion is
149 
+*strictly* necessary for the majority of use cases, and although we are aware many things are still
150 
+lacking for many, we cannot make it a priority yet for the above reasons.
151 
+
152 
+Again, this is not about saying that the Dockerfile syntax is done, it's about making choices about
153 
+what we want to do first!