don't wrap docker

[rade]

Weave currently 'wraps' docker, i.e. many weave commands end up invoking docker commands. This is especially problematic for starting application containers, i.e. weave run.

The principal issue is that weave application containers cannot be started via the docker API. A number of tools use that API, and composing weave with those tools at present is difficult/impossible.

[rade]

The main challenge here is that weave needs to perform a whole bunch of configuration work to hook containers into the weave network and weavedns. How can it do that when not invoked directly? Conceivably we could start a daemon that listens for docker events - in particular container start events - and then performs the necessary configuration. Similar to what the weavedns updater does. Ideally we'd want to run that daemon as a container, for ease of deployment and lifecycle management. This is tricky though, since we need to perform operations on the host and inside the container, but my experiments indicate that running a container with --net=host -v /proc:/hostproc would provide us with all the access we need.

That doesn't get us out of the woods though...

1. Ideally we want to configuring networking before the container's main process starts. This becomes impossible w/o changes to docker, e.g. a plug-in system with synchronous invocation at the point where docker has set up the container but not yet launched the main process.
2. It's impossible to configure the dns settings of a container post startup. We'd have to require users to supply the relevant settings when launching containers. Or require the docker daemon to be started with a specific --dns= setting, though that only gets us part of the way, since we also need to supply some --dns-search settings for each container.
3. All the extra information needed to hook containers into the weave network and weavedns, has to come from somewhere. Currently that's the CIDR. That may go away, but some indication of what application network a container should be part of has to come from somewhere. Perhaps just from the hostname though. Meanwhile, and in absence of some changes to docker, we could require the information to be supplied via --env et al.

[rade]

The docker proxy proposed in #47 (comment) can take care of 1+2.