4 ms·

The model sounds like it might be inspired by git. If it truly is, that would be wonderful. (Example git extension: http://blogs.atlassian.com/2013/04/extending

by TheDong 12y ago

The model sounds like it might be inspired by git. If it truly is, that would be wonderful. (Example git extension: http://blogs.atlassian.com/2013/04/extending-git/ http://blogs.atlassian.com/2013/04/extending-git/ ) The idea of supplying a convenient set of low-level primitives and then letting you compose them, in any language, and become a first-class citizen (at least in cli exposure) is wonderful. I could see a world where docker plugins simply work by "docker XYZ" doing a "docker run XYZ" and bind-mounting the docker.sock in as well as providing a few additional convenience sockets / functions / potentially container links. Making docker plugins also docker containers sounds really appealing to me and if anyone has more information on the actual details being considered I'd love to hear.

lewq 12y ago
The current thinking from the meeting (correct me if I'm wrong) is that Docker extensions are late-bound named Docker containers; each extension defines a set of "drivers", which have privileged communication to the Docker daemon, and which speak libchan (which is msgpack over HTTP 2) to interface with well-defined "internal" (but public) APIs in the Docker daemon. Each driver can bind to sets of internal APIs, which allow it to insert blocking hooks in e.g. a networking API, for "network create" or for volumes, before "volumes create". In terms of extending the CLI, there was some mention of standardizing on JSON Schema for specifying the APIs, such that CLI user interfaces could be auto-generated. A lot of detail here remains to be thrashed out, but yes, the git model is definitely one to look at. We also talked about modelling this on other successful plugin models, such as the one that ships with Eclipse.
zenlikethat 12y ago
Disclaimer: I work for Docker. Having plugins defined in containers is definitely the eventual goal and it's something that I'm very excited about. With bindings for the right things you open up the door to write a Docker plugin in any language and, since the "virtualization" component to manage it all is built right it, there's no painful install process to get everything working exactly how you like. I'm very optimistic about the future of Docker plugins.

by TheDong 12y ago

lewq 12y ago

The current thinking from the meeting (correct me if I'm wrong) is that Docker extensions are late-bound named Docker containers; each extension defines a set of "drivers", which have privileged communication to the Docker daemon, and which speak libchan (which is msgpack over HTTP 2) to interface with well-defined "internal" (but public) APIs in the Docker daemon. Each driver can bind to sets of internal APIs, which allow it to insert blocking hooks in e.g. a networking API, for "network create" or for volumes, before "volumes create". In terms of extending the CLI, there was some mention of standardizing on JSON Schema for specifying the APIs, such that CLI user interfaces could be auto-generated. A lot of detail here remains to be thrashed out, but yes, the git model is definitely one to look at. We also talked about modelling this on other successful plugin models, such as the one that ships with Eclipse.

zenlikethat 12y ago

Disclaimer: I work for Docker. Having plugins defined in containers is definitely the eventual goal and it's something that I'm very excited about. With bindings for the right things you open up the door to write a Docker plugin in any language and, since the "virtualization" component to manage it all is built right it, there's no painful install process to get everything working exactly how you like. I'm very optimistic about the future of Docker plugins.