Unit multi-language simple docker container

[javorszky]

Hello!

We've been trying to put together a docker image that supports multiple images in a way that's also easy to understand and easy to replicate. Here's where the current state of this is:

Existing images

We provide a few docker images for single language supports or no language support in our repository in the pkg/docker directory.

Each of the language specific image is based on a docker image for that specific language. In PHP 8.3's case, it starts with this:

FROM php:8.3-cli-bullseye

The only outlier is the -minimal unit image which starts with debian:bullseye-slim.

Aim

We're looking to create an image that supports PHP, Python, and WebAssembly out of the box in a single image.

That single image should be easy to develop and understand its inner workings.

Ideally it should either be based on an image where unit is already installed, or unit should be installed easily with something like apt install unit or apk add unit.

The point is that instead of having incredibly long sections where we configure and build and configure and build unit and related modules from source, we have individual lines of adding the required software from a package manager of the underlying system and we should be ready to go.

Non-goals

Final docker image size is not something I want to care about at the moment.

Issues we've faced so far

Based on debian:bookworm-slim

unit is not available to install as a package. This means we'd have to copy in the entire source code and build it from scratch, which is not something we want to do.

Based on unit:minimal

It's based on bullseye-slim (debian 11), where the latest PHP version is 7.4. The slim image out of the box doesn't work when following this guide: https://php.watch/articles/php-8.3-install-upgrade-on-debian-ubuntu#detailed

The lsb_release command is not available in the slim image, which results in a malformed entry in the sources file. Fixing that with apt install lsb-release enables installation of php8.3.

Python's version 3.9 is installed, however to install 3.11 or 3.12 we'd need to install python from source, which is not ideal.

Based on the alpine image

Wasmtime would need to be built from source, but the C compiler version is the other one that is in wasmtime's toolchain.

Otherwise PHP and Python are both available, as well as unit and the language specific extensions on it.

Recap

What do we need to do on our end to make sure we can build a multi-language docker image easily such that a user who knows some docker, some linux package management, but very little about compiling software from source can replicate and customize what we're doing in the image. A pseudo-dockerfile is below:

FROM debian

RUN apt update -y && apt upgrade -y

RUN apt install -y php8.3 python3 wasmtime

RUN apt install unit unit-php unit-python unit-wasm

CMD ['unitd', '--no-daemon', '--control', 'unix:/var/run/control.unit.sock']

[callahad]

I'd maybe question this aim:

Ideally it should either be based on an image where unit is already installed, or unit should be installed easily with something like apt install unit or apk add unit.

We're going to need an easy path to build images with development sources of Unit. Is there a way we can use this effort to also achieve that?

[javorszky]

Or a multi-stage build that does a COPY --from, even.

Yes, though I haven't figured out how to do a multi-stage build where a FROM ... AS step 4 is a dockerfile rather than a pre-built image someplace 🤔

[lcrilly]

I believe multi-stage builds are not permitted for Docker Official Images. @thresheek is the expert on this topic.

[javorszky]

I believe multi-stage builds are not permitted for Docker Official Images

That's another question we talked about during our standup on 14th may: do we really need this image to be on the official images repo, or are we okay with this being under nginx/unit? The benefits on the surface outweigh the nicety of having to use nginx/ in the image name.

[lcrilly]

Let's understand the constraints first. To enjoy the benefits of the new image, you first need to discover and acquire the image. Nothing beats a Docker Official Image for discoverability and confidence.

[callahad]

@lcrilly We know we need a Ridiculously Easy omnibus image as a first port of call. If we can achieve that as an Official Image, great! If not, we still need the omnibus image. So we'll start by building that, and then figure out if we can back it into the Official Image programme.

[callahad]

I'm a little leery of elevating downstream distro packages of Unit (or even of Python / PHP / Wasmtime) into being the foundation of our upstream Docker images.

What do we do when Python n+1 releases, but isn't available in Debian / Alpine?

[javorszky]

That's the exact issue we have with php8.3 and debian. It's a value judgement and decision we as the unit team need to make:

• do we make our jobs easier and say "here's a bunch of example docker images, essentially you need to learn how to build unit and python from source and look up the articles that actually work in adding python version n+1 to debian/alpine, good luck!"
• or do we do this work to make our users' lives easier? Even if it's not a docker image, but maybe some documentation that we keep reviewing to make sure that what we've written there still works

[callahad]

Do we know how we want to approach to runtime versions for the omnibus image? Latest stable for everything? Multiple language versions all in the same image? Combinatoric explosion of images?

E.g., I don't think it'd be unreasonable to want (Py311, Py312) × (PHP82, PHP83), etc.

[javorszky]

I think one image of the latest stable versions of the languages is a good opinionated approach. Normally if someone can install php8.3, then php8.2 is also available. Same with python3.12, if that's available, so is 3.11, and usually in that case it's a case of swapping version numbers during installation of those languages.

[callahad]

Aside: If Python + PHP proves painful, a good escape hatch would be two images: Python or PHP. Both with Wasmtime. I think the key direction we need to move in is making Wasm support an integral feature of all Unit releases.

[avahahn]

could we could just statically link the wasm components at build time?
Then that specific goal would only a matter of extending the build processes of the existing unit docker images.

[ac000]

If you go with Debian and install the unit-wasm package then it comes with a wasmtime DSO.

# dpkg -L unit-wasm
/.
/usr
/usr/lib
/usr/lib/libwasmtime.so
/usr/lib/unit
/usr/lib/unit/debug-modules
/usr/lib/unit/debug-modules/wasm.unit.so
/usr/lib/unit/debug-modules/wasm_wasi_component.unit.so
/usr/lib/unit/modules
/usr/lib/unit/modules/wasm.unit.so
/usr/lib/unit/modules/wasm_wasi_component.unit.so
/usr/share
/usr/share/doc
/usr/share/doc/unit-wasm
/usr/share/doc/unit-wasm/changelog.Debian.gz
/usr/share/doc/unit-wasm/changelog.gz
/usr/share/doc/unit-wasm/copyright

But if you only need wasm_wasi_component.unit.so, that is the component supporting rust based language module. Then you don't even need the wasmtime DSO.

[ac000]

Based on debian:bookworm-slim

unit is not available to install as a package. This means we'd have to copy in the entire source code and build it from scratch, which is not something we want to do.

Hmm, unless I'm missing something, we provide Debian Bookworm packages, take a browse through here

[javorszky]

Based on that, my expectation is that when I'm inside this image:

FROM debian:bookworm-slim

RUN apt update && apt upgrade

I could run apt install unit, and I would have unit installed. This happens however:

# apt install unit
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package unit
#

What's the correct package name to install via apt inside a debian container?

[callahad]

From @ac000:

We provide the packages, as we do for many distributions. In this case you need to install the apt source, see https://unit.nginx.org/installation/#debian

(Reposting here because emailed replies don't thread properly in GitHub Discussions)