weaveworks-experiments / docker-plugin

Deprecated, part of Weave Net now
https://github.com/weaveworks/weave
Apache License 2.0
33 stars 9 forks source link

work with 'local' scope #43

Closed rade closed 8 years ago

rade commented 8 years ago

...so users don't need to set up a kv store

strawman, inspired by @bboreham...

weave launch
weave launch-plugin --local [<network-name>] // defaults to 'weave'
docker run --net=weave ...

Note that you can only have one weave network when operating in this way, because of limitations in the Docker Network Plugin API.

rade commented 8 years ago

NB: requires us to implement the Docker IPAM plugin API.

awh commented 8 years ago

NB: requires us to implement the Docker IPAM plugin API.

It may also be possible to implement a 'null' IPAM plugin purely to wean Docker off the KV store, and then let weave use its own IPAM behind the scenes of the network plugin. It's possible that things like docker inspect won't return the correct values for addresses if we do that though...

squaremo commented 8 years ago

Note that you can only have one weave network

I think you mean "all networks using weave as the driver will be treated as the same network".

rade commented 8 years ago

Revised strawman:

weave launch
weave run --net=weave ... // run a container in the universal weave network
docker network create --driver=weave weave1
docker run --net=weave1 ... // run a container in your own custom weave network

So weave launch here is launching two instances of the plug-in (or one instance listening on two different domain sockets), which operate in local and global scope respectively.

The local-scope driver is is usable w/o having set up any kv store or creating any network (launch did the latter for you). But there is just one of them, or, rather, as @squaremo said, if you created more than one (with docker network create --driver=weave-universe weave2) then they'd all be treated as one.

The global scope driver requires setting up a k/v store for docker, and the networks need to be created by the user. But you can have as many as you like. Micro-segmentation FTW.

Naturally there'd also be a weave launch-plugin - similar to the arrangement we have with the proxy - if you want to pass any exotic arguments to the plugin, e.g. specify a different network name for the universal weave network.

(Note that weave launch can launch the plug-in even on older Dockers, since all plug-in interaction is initiated by Docker. It will just be inactive.)

squaremo commented 8 years ago

That's not bad.

In the local case, weave launch can start the driver then create the network, so no more needs to be done by the user to use docker run --net=weave .... Cute.

To use the global variety of driver, the user has to have set up the kv-store and told docker about it, and that's probably something that can be detected (but it might be better to let it fail).

With respect to IPAM: libnetwork first procures an IP address, then tells the driver about it; you can't reply back with a different IP address, or if you can, it's a bug. So I think it'll be necessary to implement an IPAM plugin.