As noted in #388 comment 76958961, we need the docker client to be as
old as possible while supporting what weave needs to do. At the minute
that means version 1.3.1.
The `apk` package index does not have old versions of docker, so the
most direct way of getting a docker executable is to download the
specific version from https://get.docker.com.
This is to make a visible break with previous releases, such that a
newly downloaded weave script will definitely work.
Without this change in name, an existing weavetools image that doesn't
include the script might be invoked, resulting in a confusing message
for the user.
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.
So as not to pollute command-line flags with test.* options.
It appears that importing "testing" (from stdlib) will add flags. To
avoid this, we need code to not depend on testing. But, since
testing_utils was previously in the same package as the rest of the
code, it dragged testing in.
Renaming testing_util.go to e.g., util_for_test.go might be enough to
avoid it being compiled with the regular code. We may want it to be
available to tests for other packages -- after all it is utilities for
testing -- so it goes in its own package.
We use a plain ubuntu container as a build environment for ethtool &
conntrack, so a) we don't require onerous tooling on the build host,
and b) don't pollute the build host with build artefacts. The latter
arise because I can only get conntrack to build by installing its
dependencies 'globally'.
Th dir containing the build script is volume-mounted into the
container, and that is where we also expect to see the result, namely
a 'bin' sub-dir containing two executables.
The weavetools image is then constructed from the 'scratch' image and
contains just that dir.
Matthias Radestock