fermyon/spin

Spin Docker image

vdice opened this issue · 5 comments

vdice commented

Do we want to also publish a Docker image wrapping the spin binary on each release? (eg ghcr.io/fermyon/spin:v2.6.0)

One recent use case is in the SpinKube project: having the ability to run a workload (Spin app) via such an image for certain scenarios (when, say, the standard containerd shim isn't used).

However, perhaps there are other scenarios where users would like to run Spin in container form?

If Yes, we'd like to publish, we have a few options to consider:

  1. A lightweight (as much as possible) image (eg distroless) containing a statically-linked Spin binary (would need to be linux amd64 or arm64 currently). No default plugins/templates/etc included. Image size around 150MB-ish (static binary itself looks to be 110MB)
  2. A heavierweight image containing distro, glibc, etc, containing a dynamically-linked Spin binary. This could be installed via Spin's standard install script and include default plugins/templates/etc. More in the 500-700MB range (haven't looked super in-depth at min size)
  3. Other (somewhere in between?)
itowlson commented

I like this. A lightweight image would presumably also be able to work as a base for users to create customised images with the plugins etc. required for their use case, is that right? I guess that would require a distroful image though?

Your mention of templates makes me wonder about targets for this work though. Do you envisage this as primarily about running Spin workloads, or do you want it to enable the Spin developer loop? I'm not sufficiently au fait with Docker to know how friendly the "new > build > up > commit" loop would be in the latter case.

calebschoepp commented

@vdice chime in if you disagree: I envisage this image being purely focused on running Spin workloads not being used for the developer loop. Templates is really a bit of a red herring, the more important thing gained from the install script is plugins which would allow you to run custom triggers (although I suppose there aren't any custom triggers in the default plugins anyways).

Yep using the lightweight image as a base makes sense to me. The tricky part is making sure that dynamic linking works for the plugins since the lightweight base image uses a static binary.

Overall I'm a +1 for putting the image here instead of SpinKube.

One other thing worth noting is that I'd love for this to generate images for all versions of Spin (greater than some reasonable cutoff point like 2.5 🤷 ).

  • 👍1
vdice commented

I envisage this image being purely focused on running Spin workloads not being used for the developer loop.

Same ^^. Attempting to support the full developer loop (especially spin build with its language ecosystem requirements) would be a much larger/different endeavor. Thank you for clarifying @itowlson. I wonder if there's a need here to make this clear to users of this Docker image?

Re: lightweight image. I guess I should have split it into:

  • featherweight: 165 MB. Distroless image containing the static spin binary which would only really be useful for running workloads that don't require plugins. As of today, we don't yet offer static builds for plugins under the fermyon org (though we could of course add in the future), so attempting to run any of them in this container would fail.
  • lightweight-ish: TBD/200ish MB; Don't have a solution right now. I just spent an hour trying various alpine-with-glibc approaches but still couldn't get the regular (dynamically-linked) spin binary to run.
  • midweight: 459 MB. debian:bookworm-slim base image, regular (dynamically-linked) spin binary (installed directly, not via install script). Would support users installing plugins.

In my mind, if we're forced to choose one, I'm tempted to go midweight to ensure plugin installation is supported. Alternatively, we could publish both: midweight as eg ghcr.io/fermyon/spin:v2.6.0 and featherweight as eg ghcr.io/fermyon/spin:v2.6.0-distroless. (Or, of course, we could switch defaults there if others preferred, i.e. distroless is the default tag and the 'full' image is tagged appropriately.) Thoughts?

  • 👍1
calebschoepp commented

Your proposal makes sense to me. I'm fine with the naming scheme you proposed.

Would the midweight image still expose an entrypoint of Spin?

vdice commented

Would the midweight image still expose an entrypoint of Spin?

Yes, both images would have eg ENTRYPOINT [ "/usr/local/bin/spin" ]

Here's what I had been experimenting with:

Dockerfile (distroless/featherweight)

FROM debian:bookworm-slim AS install
ARG spin_version=v2.6.0
WORKDIR /opt/install

# Install deps
RUN apt-get update && apt-get install -y --no-install-recommends \
  ca-certificates \
  curl \
  git

# Install Static Spin binary
RUN ARCH=$(uname -m | sed s/x86_64/amd64/) && \
  curl -fsSL -o spin-${spin_version}-static-linux-${ARCH}.tar.gz https://github.com/fermyon/spin/releases/download/${spin_version}/spin-${spin_version}-static-linux-${ARCH}.tar.gz && \
  tar xvf spin-${spin_version}-static-linux-${ARCH}.tar.gz

FROM gcr.io/distroless/static-debian12
COPY --from=install /opt/install/spin /usr/local/bin/spin

ENTRYPOINT [ "/usr/local/bin/spin" ]

Dockerfile (midweight)

FROM debian:bookworm-slim
ARG spin_version=v2.6.0

# Install deps
RUN apt-get update && apt-get install -y --no-install-recommends \
  ca-certificates \
  curl \
  git

# Install Spin
RUN ARCH=$(uname -m | sed s/x86_64/amd64/) && \
  curl -fsSL -o spin-${spin_version}-linux-${ARCH}.tar.gz https://github.com/fermyon/spin/releases/download/${spin_version}/spin-${spin_version}-linux-${ARCH}.tar.gz && \
  tar xvf spin-${spin_version}-linux-${ARCH}.tar.gz && \
  rm spin-${spin_version}-linux-${ARCH}.tar.gz && \
  mv spin /usr/local/bin/spin

ENTRYPOINT [ "/usr/local/bin/spin" ]
  • 👍1