- Nameserver holds a sorted list of (hostname, peer, container id, ip) tuples.
- Entries are gossiped using topology gossip / broadcast - only new/updated entries
are propogated as expected.
- Entries for a given peer are removed when the connection to the peer is lost.
- Entries are tombstoned when containers die. Tombstones are kept for 10mins,
as they do not need to survive partition, only gossip propagation delay.
Provides to new two new flags: `--hostname-match <regexp>`
and `--hostname-replacement <replacement>`. When launching a container, its name
matched against regular expression `<regexp>`. Then, based on that match,
`<replacement>` will be used to generate a hostname, which will ultimately be
handed over to weaveDNS for registration.
The substitution is implemented with
https://golang.org/pkg/regexp/#Regexp.ReplaceAllString . Thus, references to
regexp substitution groups should be prepended with a dollar sign.
For instance, if we provide `--hostname-match '^aws-[0-9]+-(.*)$'` and
`--hostname-replacement 'my-app-$1'`, running a container named
`aws-12798186823-foo` through WeaveProxy will lead to WeaveDNS registering
`my-app-foo`.
Closes#1018
Adds a --no-rewrite-hosts flag to the proxy, and be default, removes the
docker IP from hosts. We only discard the docker host when it exists, so
--net=none works.
The go docker client's ErrNoSuchImage does not include the image
name. However, it is imperative that this name appears in error
messages sent to clients, since the docker client, as of version
1.7.0, only automatically pulls images when their name is present in
the error.
Fixes#967.
Tells the proxy not to do anything with this container. We set it when
running weaveexec/weave/etc containers, so that the weave script works
through the proxy.
It's ugly, but beats arg-parsing, inspecting the container and piecing
the address together from exposed ports.
We could just use the host from DOCKER_HOST, but that will fail in the
case of a host with multiple IPs, where the proxy only listens on one.
There are two problems with obtaining the proxy status via the normal
proxy endpoint...
1. when TLS is enabled, this requires using TLS at the client end
2. the status URL is mixed in with the docker remote API, which is
rather unclean
There is limited value to having some status output from the proxy,
since all the output is constant.
So instead we log the version and command line args, and in `weave
status` only report whether the proxy is running.
We still want a way to wait for the proxy to start up, and log a nice
error if it dies. We do this by polling the docker logs for a startup
message.
Fixes#877. Fixes#876.
Undoes most of #756, #800, #854.
Paul Bellamy