WIP: Download arm64 docker binary from Ubuntu repo

[bboreham]

Not finished yet - at the very least I need two more sha checksums.

A bit of refactoring was required so I could extract the binary in two different ways depending on whether we have a .deb package or the Docker tarfile download.

Whilst working on that I noticed the sub-publish rule to make images was only working by accident, so fixed that.

Fixes #2832

[luxas]

Perfect -- thanks @bboreham, me and @vielmetti were just talking about this.
We're gonna start running e2e tests w/ Weave on arm64 servers and kubeadm soon I think, and it will appear here-ish: https://k8s-testgrid.appspot.com/misc#kubeadm-gce

[bboreham]

I got a bit further: seems that binary needs a few libraries:

root@host1:~# docker run -ti --entrypoint=/bin/sh bboreham/weaveexec:git-816cbc44d914
/home/weave # ldd /usr/bin/docker
	/lib/ld-linux-aarch64.so.1 (0xaaaab5797000)
Error loading shared library libapparmor.so.1: No such file or directory (needed by /usr/bin/docker)
	libpthread.so.0 => /lib/ld-linux-aarch64.so.1 (0xaaaab5797000)
Error loading shared library libdevmapper.so.1.02.1: No such file or directory (needed by /usr/bin/docker)
	libc.so.6 => /lib/ld-linux-aarch64.so.1 (0xaaaab5797000)
Error loading shared library ld-linux-aarch64.so.1: No such file or directory (needed by /usr/bin/docker)

[rade]

So this is a dynamically linked binary. Not good. To be fair, this follows established policy by distributions.

It is mighty odd for the docker client to require libdevmapper.

[luxas]

Yeah, this is one of the drawbacks with bundling the client and daemon in the same binary... but they fixed it later so not complaining ;)

[luxas]

ping @bboreham I'd love to get this through pretty soon, would make me be able to run Weave on Packet ;)

[bboreham]

I thought #2545 would help - the newer docker binary is client only - but it keeps failing tests. Trying to figure that out now.

[bboreham]

It occurred to me that weave-kube doesn't actually use the Docker binary at all.
With some re-ordering of container image layers we can dispense with this issue, at least for Kubernetes users.

[vielmetti]

Hi @bboreham - any progress on this? It looks like Docker is on track for a supported arm64 release some time soon, though I don't know an exact time scale.

[bboreham]

@vielmetti Do you need it for Kubernetes or non-kube? The re-ordering I described was done in #2954 so the :latest image should now work for weave-kube.

Otherwise, we can wait for a usable binary or someone can do #2957

[vielmetti]

Great, this would be for Kubernetes so I think we're good here. @luxas can you take a look, would be happy to see this go.

[bboreham]

This was made unnecessary by #3110