This repository has been archived by the owner on Jun 20, 2024. It is now read-only.
Add weave launch-proxy #652
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…s work Previously, the result output would include: Docker on: <command> result output text etc... But this would cause: assert "docker_on ..." to fail
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.
Add a /weave endpoint to it, and use curl to wait for it to boot.
This will make adding the CreateContainer hook cleaner.
Otherwise they get smashed together on the command line, and the call fails.
If no entrypoint is specified on the container, it should use the entrypoint of the image. Code for this is based on powerstrip-weave.
I'm not sure if it will cause issues, but seems like a sane thing to do.
The reason being, that because WEAVE_CIDR is inherited from images (along with env vars), setting it to blank is equivalent to unsetting it.
|
docs need updating |
Off the top of my head:
I think it'd be worth having a brief description of how weave run goes through the proxy, and how one can use docker directly to do the same thing. |
|
As per f2f discussion with @rade, let's not change bash script commands to use proxy, or autolaunch. Just provide launch-proxy as a "beta feature" and document how to use it with the docker cli tool. |
|
Closed in favour of #655 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a docker remote API proxy to the weaveexec image. The proxy is
auto-launched when running a container with weave cli.
The proxy currently has hooks for:
Other changes include: