Ship a "containerd managed /opt" Docker image as part of release

[TBBle]

As a QoL feature request, it'd be nice if the release process for containerd-shim-runhcs-v1.exe including pushing a Docker image to a known/published location, suitable for containerd Managed /opt use.

Since the container is not run, merely extracted from, I imagine the DockerFile would look something like:

FROM scratch
ADD containerd-shim-runhcs-v1.exe /bin/containerd-shim-runhcs-v1.exe

I haven't tested this though, and Windows support for this feature was not in the containerd 1.3.x series, but should be in 1.4.x, so the current audience is slightly limited. It'd be nice to be ahead of the game though.

It'd be doubly nice if auto-builds also pushed an image somewhere. This is less marginal value, since one can always grab the binaries for master HEAD from Travis; unless no one commits for six months and they expire.

[jterry75]

This is an interesting idea. Let us think more about it on our end and how that plans into the containerd tool

[TBBle]

I just discovered that Docker considers scratch to be a Linux image, and won't let you base a Windows Container image on it.

So this isn't as trivial as it should be... I'm not sure if there's an equivalent for scratch... Nanoserver is still a few hundred megabytes which is a lot for a binary or two, and that has licensing complications.

Since I wrote this suggestion I noticed that the containerd shim may call out to runhcs in lcow code paths, so the second line is also not as trivial as it could be.

[slonopotamus]

Why do you want this to be an image instead of, I dunno... Just a file attached to GitHub release?

[TBBle]

Now that #1637 has been merged, we have a wclayer makebaselayer and the wclayer export command-line tools workable, and so I guess with a small amount of effort and scripting (for the manifest) a full image (in OCI tarball format) could be generated by the CI pipeline and pushed using Docker or skopeo or something.

That would avoid the bootstrap problem of needing working containerd to run BuildKit to generate the image, although the Dockerfile I initially described would not require containerd to have access to the containerd-shim-runhcs-v1 executable, so it's not really a bootstrap problem.

Why do you want this to be an image instead of, I dunno... Just a file attached to GitHub release?

Because containerd already has built-in support for pulling such an image and extracting it, and using the binary as a shim.

This saves the user from having to actually go looking on GitHub at all, they only need containerd/ctr and the appropriate image reference; it would possibly also make sense for a default known-good version to be defaulted in containerd, so the user only needs to mess about if they want an alternative version.

And of course, running the same command with a different tag is a very convenient way of switching shim versions if a problem is encountered.

I haven't tested this, but I perhaps it could be an OCI image tarball attached to the GitHub release, rather than needing to be pushed to a registry, if the image-reference syntax in containerd supports it.

[slonopotamus]

Because containerd already has built-in support for pulling such an image and extracting it, and using the binary as a shim.

Oh, OK, I just skimmed through that page and din't get into details.

they only need containerd/ctr

And here is the question: if you managed to apt-get install -y containerd (or whatever way was used to obtain containerd), why can't shim be obtained using the same mechanism? Sysadmins already have tools to audit packages, there are update notifications, config merging, etc... IMHO, this "managed /opt" feature is evil.

[TBBle]

That becomes yet another way to package the shim. In fact, multiple ways, given all the different package managers. In effect, this "managed /opt" system is a containerd-specific package manager for containerd-specific tools that works irrespective of the actual package manager you used to install containerd.

I don't expect it's widely used, since if you are packaging containerd, you would probably bundle the shims etc you need with it or rely on existing packages in your package manager if they exist. It's mildly useful if you're not using a package manager, but I'm honestly not sure if any real, maintained examples of this system exist. Both the examples in the doc are not upstream-official AFAIK.

This does however provide a use-case for the base-layer manipulation work that doesn't then rely on an entire stack of other changes; getting FROM scratch working in BuildKit is the very far end of the tail. That's gotten a lot closer over the three years since I opened this though.

It would also simplify the containerd CI pipeline for running tests quite a bit. In fact, it might even speed it up, I'm not sure if the current CI pipeline is still building the shim from source on each run, but a 20MB download of an (ideally cached) image is probably going to be faster than that.