Michael Bridgen
8d12810446
This rearrangement means that the `weave` command can be used remotely; and, as a side-effect, the script that does all the work is using executables in its own filesystem, rather than invoking them via docker. The remote weavetools is given a terminal so it can be interrupted. With the flag `--local`, the script will assume all its dependencies are available and run then and there. Without the flag, it will run via the weavetools image (adding the flag to the invocation). A choice here is whether to base the tools image on scratch and add all the deps, or base it on something else. I've used alpine linux, which itself is based on busybox. This gives us the usual tools (sed etc.) while keeping the image size small. Adding the docker binary adds substantially to the image size, but it cannot always be e.g., bind-mounted. To mitigate this image bloat, we might build or otherwise get a client-only docker executable, or write a special-purpose client, or indeed rewrite the driver script and use a client library. This also makes the dockerhub user part of the image names parameterised, to make it easier to test the release process in full.
7 lines
238 B
Docker
7 lines
238 B
Docker
FROM gliderlabs/alpine
|
|
MAINTAINER Weaveworks Inc <help@weave.works>
|
|
WORKDIR /home/weave
|
|
RUN ["apk-install", "ethtool", "conntrack-tools", "curl", "iptables", "iproute2", "docker"]
|
|
ADD ./weave /home/weave/
|
|
ENTRYPOINT ["/home/weave/weave"]
|