s6-overlay v3

[eitsupi]

Related to #332 (cc @kforner)

s6-overlay Version 3 seems to be close to being released (binaries have not been uploaded, but tags have been created).
https://github.com/just-containers/s6-overlay/releases/tag/v3.0.0.0

Since most of the source code seems to have been rewritten, I think it is necessary to do sufficient testing before upgrading.

@cboettig How can I help with testing?

[mcanouil]

The following resource might help to upgrade to v3: https://github.com/just-containers/s6-overlay/blob/master/MOVING-TO-V3.md

Version 3 is still compatible with the use of /etc/services.d, although for the future, services definition should be rewritten using s6-rc format (https://skarnet.org/software/s6-rc/).

Most of the changes rely on the install process which requires two tarball.

S6_VERSION=${S6_VERSION:-v3.1.0.1}
S6_BEHAVIOUR_IF_STAGE2_FAILS=2

ARCH=$(uname -m)

apt-get update && apt-get -y install wget xz-utils

DOWNLOAD_FILE=s6-overlay-noarch.tar.xz
wget -P /tmp/ https://github.com/just-containers/s6-overlay/releases/download/${S6_VERSION}/$DOWNLOAD_FILE
tar -C / -Jxpf /tmp/$DOWNLOAD_FILE

DOWNLOAD_FILE=s6-overlay-${ARCH}.tar.xz
wget -P /tmp/ https://github.com/just-containers/s6-overlay/releases/download/${S6_VERSION}/$DOWNLOAD_FILE
tar -C / -Jxpf /tmp/$DOWNLOAD_FILE

Note: I am currently testing it in a similar framework as rocker.

[salim-b]

Just a note: s6-overlay v3.x (in contrast to v2.x) seems to require being PID 1, i.e. refuses to start if it's not. This (without additional workarounds) makes s6-overlay incompatible with hosting environments like Fly.io where container images are transformed into Firecracker VMs.

I haven't tested this myself but the information linked above seems consistent to me. I currently use the rocker/r-ver container image as a basis for a custom RStudio Server setup hosted on Fly.io that automatically scales to zero after the last user quits their session.

[benz0li]

@salim-b FYI

[...] s6-overlay was always meant to run as pid 1. In v2, it appeared to run as another pid, but it was just more subtly broken; any case where it worked was purely accidental. In v3, we purposefully prevent the boot if /init isn't running as pid 1, in order to avoid silent breakage.

Container managers that force you to run a pid 1 of their choice are going out of their lane and breaking the convention for containers. They do not qualify as container managers; they may be useful for other purposes, but you cannot expect projects meant to run with containers to properly interact with them.

– just-containers/s6-overlay#358 (comment)

[salim-b]

@benz0li Thanks for the highlight.

Fly.io is in fact not a "container manager" but runs Docker images without Docker. The containers are converted to KVM-based Firecracker VMs which have stronger isolation guarantees than containers. That's why they can claim "User code is fraught with peril. Fly Machines run it safely - even the most awful, buggy, and downright hostile user code."

Furthermore, Fly machines start up in about 300ms (any supported region). And they offer a generous free tier (not enough for a usable RStudio Server, though).

Anyways, I don't wana promote them. I just think there is value in keeping the Rocker container images compatible with such non-PID1 setups (aka "microVMs").