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.
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.
Caveats:
* TLS files must be present on the target server (and readable)
* TLS file paths cannot contain spaces
* TLS file paths must be absolute (i.e. cannot be relative)
* Bash argument parsing is terrible
The code is quite messy, but particularly the argument parsing and
volume-mounting. Also, it doesn't support args with spaces, or
non-absolute file-paths.
Bug came up in a test where we are restarting and doing an exec checking
a network interface right away. weavewait is only added if the container
has a WEAVE_CIDR var set, the same as at container creation.
In the proxy, I swapped the 'flag' library for
'code.google.com/p/getopt', which uses double-dash flags.
proxy lets 'weave attach' do dns registration on container start
proxy needs to set DNSSearch if not specified
This adds a docker remote API proxy to the weaveexec image. The proxy
has hooks for (post-) container start and (pre-) container create; the
former attaches a weave interface to a container given a WEAVE_CIDR
environment entry, and the latter adjusts the entrypoint of a container
to wait for the ethwe interface.
Notes:
None of the hooks need to inspect/change large bodies. In order to avoid
a crash when handling images larger than memory we need to ensure that
the entire request body is never loaded into memory (i.e. No
ioutils.ReadAll).
When proxying a raw-stream response, we can't use http.WriteHeader. It
sets the Transfer-Encoding to chunked, which will throw off the clients.
Instead we have to hijack the socket, and write out http status code
manually.
For chunked transfer-encodings, clients (docker-py) depend on each http
chunk containing exactly one JSON object. Therefore, we cannot re-chunk
the body, and have to pass it across verbatim.
Proxy needs to pass multi-cidrs separately when calling weave. Otherwise
they get smashed together on the command line, and the call fails.
When creating the image, if no entrypoint is specified on the container,
it should use the entrypoint of the image. Code for this is based on
powerstrip-weave.
We handle WEAVE_CIDR='' by acting like it is not set. The reason being,
that because WEAVE_CIDR is inherited from images (along with env vars),
setting it to blank is equivalent to unsetting it.
Paul Bellamy