Embed the cnab base invocation image into docker-app binary

[silvin-lubecki]

In an airgap environment, the user has to pull locally, his own way, the docker/cnab-app-base image in order to execute any basic action (bundle, install, upgrade, uninstall, inspect...).

Embedding the base image inside the docker-app binary can resolve this issue.
docker-app would then first detect if the image is present in the image store, if not it will then load it and apply the action.

One drawback is adding more MB to the docker-app binary, which weigh already almost 40 MB. The invocation image itself weigh 40 MB too, but once compressed it falls down to 14 MB.

[simonferquel]

I am a bit worried about the size of the binary as well. Let us see if we can dig a little into what we can do to improve that (I don't know if the go linker can actually do some tree shaking at a lower granularity level than the package). Maybe @ijc knows.

[ijc]

I'm afraid I have no special knowledge on that one or magic ways to shrink things.

[silvin-lubecki]

Just tried using upx to shrink the cnab-run binary. The binary itself weighs 11 MB instead of 39 MB.
But if I compare the standard base image, docker saved and then gziped, to a new image with the upxed cnab-run binary, docker saved and gziped too, we only gain 1 MB in favor of the upx binary
(14 MB vs 13 MB).
Just to say that gziping the image is simple enough to get a small image.

[ulyssessouza]

What about a 2 binaries solution, with an online and an offline binary?
Using something like https://github.com/go-bindata/go-bindata and conditional compiling would let the decision to the user.

[silvin-lubecki]

I've already made a PoC with go-binddata which works fine. But there's a not-that-small overhead (25+MB) in the binary.
I'm not fan of releasing another "offline" version of docker app plugin, its behavior (and bugs) may differ from the other one.

[agners]

How will this work in the context of cross-platform support (e.g. aarch64)?