WeaveDockerProxy

A proxy to docker

The basic idea is that weave intermediates between the docker client and the docker daemon. This has been discussed a few times for different reasons:

1. It might allow people to use a docker client to run containers, rather than having to use the weave script

2. It could let weave run things "in the foreground"

3. It could let weave delay execution of container processes until the weave interface is available

Using the docker client

This is useful for a couple of reasons: firstly, in some scenarios it is easier to launch a long-running process (or a container), and then use the docker CLI rather than the weave script. Secondly, there are tools that use the docker CLI or API directly and it would be good to be able to integrate with those.

Any extra information that weave needs may be set in environment entries for the container. This does not quite match up with weave's current command set, since it expects to be able to give containers IP addresses while they are running.

Running things in the foreground

A weakness with weave presently is that it has to run containers with the -d switch, because it needs to run the container to get its ID and network namespace.

The docker client does this in three steps: firstly it creates the container, then it attaches to it, then it runs it. A weave proxy could effect the same thing.

Waiting for the interface

The weave script has a chicken-and-egg problem with supplying ethwe -- it wants the container to run only once it's available, but it has to wait for the container to be run before it can supply it.

One way around this is to rewrite the entry-point "on the way past" to something that will wait for the interface to be present, then exec the original entry point.

The docker runtime already does something like this, in that it inits the container with a process that waits until the namespace etc is ready, then execs the entry-point.

Operation

There's a few ways the proxy could be run. Some of these overlap, in the sense that the same executable could run in more than one way without too many differences in the code.

As a daemon

Most simply, conceptually, is to run as a daemon on the docker host. You then talk to it instead of the docker daemon.

As a daemon container

This is similar to the above, but it's run in a container, and ports are forwarded to it for operation from outside (or it shares the host network).

As a regular process

A weave executable could act itself as a proxy, invoking the docker CLI but pointing the client at itself in order to rewrite arguments.

Running as an extension point to docker

There is significant overlap with a proposal for docker extensions, which is to compose extensions as proxies to docker.