Discussion: consolidate Alpine and Ubuntu images?

[slauger]

Currently the project maintains two separate Containerfiles — one for Ubuntu (Containerfile) and one for Alpine (Containerfile.alpine). They differ significantly in their approach:

• Ubuntu: installs openvox-server and openvoxdb-termini via .deb packages from the APT repository, uses System Ruby, and relies on the packaged file layout.
• Alpine: installs from upstream tarballs, builds the directory structure manually, installs gems (including openvox/puppet) at the system level, and runs rootless with USER puppet:0.

This dual-image approach creates maintenance overhead — every fix or improvement needs to be applied twice, and the two images can drift apart in behavior. For example, rootless container support (see #121, #123) is straightforward on Alpine but much harder on Ubuntu due to the deb package layout and assumptions.

Some questions worth discussing:

1. Is there a reason to keep both images long-term, or could the project consolidate on one?
2. If both are kept, should they converge on the same installation method (e.g., both using tarballs)?
3. Are there users who specifically depend on the Ubuntu-based image?

cc @rwaffen @sebastianrakel

[sebastianrakel]

imho drop ubuntu images

[rwaffen]

"maintain" is a bit much said. the alpine are only in beta mode, and i never moved on with making them stable and replace the ubuntu one. in my opion we need only one image, best be if it is the alpine one.

you also see this in the names of the tags: 8-alpine-beta

[bootc]

My fear is that the musl libc in Alpine is very different from glibc on Ubuntu, and unless we test Puppet specifically on Alpine/musl we can run into issues. musl is also known to have reduced performance compared to glibc, particularly in the allocator, though I don't know how that interacts with the Java runtime and JRuby for example.

[sebastianrakel]

is running with gcompat and glibc libs in alpine an option?

[slauger]

I can also provide a patch for a rootless Ubuntu image. But I'd recommend going the same tarball route as the Alpine image instead of using APT packages - the .deb packages pull in a lot of unnecessary dependencies (systemd, init scripts, etc.) that are useless in a container context.

With a tarball-based approach we could probably also switch to Ubuntu minimal as the base image to further reduce the image footprint.

[rwaffen]

That’s a solid approach. First, let’s standardize how the Containerfiles work, and then evaluate whether Alpine is sufficient to serve as our primary—or even sole—base image. 🤔

[slauger]

While working on the tarball-based Ubuntu rebuild, I noticed that r10k, rugged, git and their dependencies (openssh-client, libssh2) are not used anywhere in the entrypoint scripts. From my point of view these don't belong in a server image.

Is there a valid use case for having r10k in the server container, or would a dedicated r10k image make more sense?