Closed rade closed 8 years ago
NB: requires us to implement the Docker IPAM plugin API.
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...
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".
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.)
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.
...so users don't need to set up a kv store
strawman, inspired by @bboreham...
Note that you can only have one weave network when operating in this way, because of limitations in the Docker Network Plugin API.