github.com/damirazo/docker@v1.9.0/ROADMAP.md (about)

     1  Docker Engine Roadmap
     2  =====================
     3  
     4  ### How should I use this document?
     5  
     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.
     9  
    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.
    14  
    15  ### How can I help?
    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
    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
    22  the best way to go.
    23  
    24  ### How can I add something to the roadmap?
    25  
    26  The roadmap process is new to the Docker Engine: we are only beginning to structure and document the
    27  project objectives. Our immediate goal is to be more transparent, and work with our community to
    28  focus our efforts on fewer prioritized topics.
    29  
    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.
    33  
    34  # 1. Features and refactoring
    35  
    36  ## 1.1 Security
    37  
    38  Security is a top objective for the Docker Engine. The most notable items we intend to provide in
    39  the near future are:
    40  
    41  - Trusted distribution of images: the effort is driven by the [distribution](https://github.com/docker/distribution)
    42  group but will have significant impact on the Engine
    43  - [User namespaces](https://github.com/docker/docker/pull/12648)
    44  - [Seccomp support](https://github.com/docker/libcontainer/pull/613)
    45  
    46  ## 1.2 Plumbing project
    47  
    48  We define a plumbing tool as a standalone piece of software usable and meaningful on its own. In
    49  the current state of the Docker Engine, most subsystems provide independent functionalities (such
    50  the builder, pushing and pulling images, running applications in a containerized environment, etc)
    51  but all are coupled in a single binary.  We want to offer the users to flexibility to use only the
    52  pieces they need, and we will also gain in maintainability by splitting the project among multiple
    53  repositories.
    54  
    55  As it currently stands, the rough design outlines is to have:
    56  - Low level plumbing tools, each dealing with one responsibility (e.g., [runC](https://runc.io))
    57  - Docker subsystems services, each exposing an elementary concept over an API, and relying on one or
    58  multiple lower level plumbing tools for their implementation (e.g., network management)
    59  - Docker Engine to expose higher level actions (e.g., create a container with volume `V` and network
    60  `N`), while still providing pass-through access to the individual subsystems.
    61  
    62  The architectural details are still being worked on, but one thing we know for sure is that we need
    63  to technically decouple the pieces.
    64  
    65  ### 1.2.1 Runtime
    66  
    67  A Runtime tool already exists today in the form of [runC](https://github.com/opencontainers/runc).
    68  We intend to modify the Engine to directly call out to a binary implementing the Open Containers
    69  Specification such as runC rather than relying on libcontainer to set the container runtime up.
    70  
    71  This plan will deprecate the existing [`execdriver`](https://github.com/docker/docker/tree/master/daemon/execdriver)
    72  as different runtime backends will be implemented as separated binaries instead of being compiled
    73  into the Engine.
    74  
    75  ### 1.2.2 Builder
    76  
    77  The Builder (i.e., the ability to build an image from a Dockerfile) is already nicely decoupled,
    78  but would benefit from being entirely separated from the Engine, and rely on the standard Engine
    79  API for its operations.
    80  
    81  ### 1.2.3 Distribution
    82  
    83  Distribution already has a [dedicated repository](https://github.com/docker/distribution) which
    84  holds the implementation for Registry v2 and client libraries. We could imagine going further by
    85  having the Engine call out to a binary providing image distribution related functionalities.
    86  
    87  There are two short term goals related to image distribution. The first is stabilize and simplify
    88  the push/pull code. Following that is the conversion to the more secure Registry V2 protocol.
    89  
    90  ### 1.2.4 Networking
    91  
    92  Most of networking related code was already decoupled today in [libnetwork](https://github.com/docker/libnetwork).
    93  As with other ingredients, we might want to take it a step further and make it a meaningful utility
    94  that the Engine would call out to instead of a library.
    95  
    96  ## 1.3 Plugins
    97  
    98  An initiative around plugins started with Docker 1.7.0, with the goal of allowing for out of
    99  process extensibility of some Docker functionalities, starting with volumes and networking. The
   100  approach is to provide specific extension points rather than generic hooking facilities. We also
   101  deliberately keep the extensions API the simplest possible, expanding as we discover valid use
   102  cases that cannot be implemented.
   103  
   104  At the time of writing:
   105  
   106  - Plugin support is merged as an experimental feature: real world use cases and user feedback will
   107  help us refine the UX to make the feature more user friendly.
   108  - There are no immediate plans to expand on the number of pluggable subsystems.
   109  - Golang 1.5 might add language support for [plugins](https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ)
   110  which we consider supporting as an alternative to JSON/HTTP.
   111  
   112  ## 1.4 Volume management
   113  
   114  Volumes are not a first class citizen in the Engine today: we would like better volume management,
   115  similar to the way network are managed in the new [CNM](https://github.com/docker/docker/issues/9983).
   116  
   117  ## 1.5 Better API implementation
   118  
   119  The current Engine API is insufficiently typed, versioned, and ultimately hard to maintain. We
   120  also suffer from the lack of a common implementation with [Swarm](https://github.com/docker/swarm).
   121  
   122  ## 1.6 Checkpoint/restore
   123  
   124  Support for checkpoint/restore was [merged](https://github.com/docker/libcontainer/pull/479) in
   125  [libcontainer](https://github.com/docker/libcontainer) and made available through [runC](https://runc.io):
   126  we intend to take advantage of it in the Engine.
   127  
   128  # 2 Frozen features
   129  
   130  ## 2.1 Docker exec
   131  
   132  We won't accept patches expanding the surface of `docker exec`, which we intend to keep as a
   133  *debugging* feature, as well as being strongly dependent on the Runtime ingredient effort.
   134  
   135  ## 2.2 Dockerfile syntax
   136  
   137  The Dockerfile syntax as we know it is simple, and has proven successful in supporting all our
   138  [official images](https://github.com/docker-library/official-images). Although this is *not* a
   139  definitive move, we temporarily won't accept more patches to the Dockerfile syntax for several
   140  reasons:
   141  
   142  - Long term impact of syntax changes is a sensitive matter that require an amount of attention
   143  the volume of Engine codebase and activity today doesn't allow us to provide.
   144  - Allowing the Builder to be implemented as a separate utility consuming the Engine's API will
   145  open the door for many possibilities, such as offering alternate syntaxes or DSL for existing
   146  languages without cluttering the Engine's codebase.
   147  - A standalone Builder will also offer the opportunity for a better dedicated group of maintainers
   148  to own the Dockerfile syntax and decide collectively on the direction to give it.
   149  - Our experience with official images tend to show that no new instruction or syntax expansion is
   150  *strictly* necessary for the majority of use cases, and although we are aware many things are still
   151  lacking for many, we cannot make it a priority yet for the above reasons.
   152  
   153  Again, this is not about saying that the Dockerfile syntax is done, it's about making choices about
   154  what we want to do first!
   155  
   156  ## 2.3 Remote Registry Operations
   157  
   158  A large amount of work is ongoing in the area of image distribution and
   159  provenance. This includes moving to the V2 Registry API and heavily
   160  refactoring the code that powers these features. The desired result is more
   161  secure, reliable and easier to use image distribution.
   162  
   163  Part of the problem with this part of the code base is the lack of a stable
   164  and flexible interface. If new features are added that access the registry
   165  without solidifying these interfaces, achieving feature parity will continue
   166  to be elusive. While we get a handle on this situation, we are imposing a
   167  moratorium on new code that accesses the Registry API in commands that don't
   168  already make remote calls.
   169  
   170  Currently, only the following commands cause interaction with a remote
   171  registry:
   172  
   173  - push
   174  - pull
   175  - run
   176  - build
   177  - search
   178  - login
   179  
   180  In the interest of stabilizing the registry access model during this ongoing
   181  work, we are not accepting additions to other commands that will cause remote
   182  interaction with the Registry API. This moratorium will lift when the goals of
   183  the distribution project have been met.