Comment by k_bx
6 months ago
I develop my apps in the most possible native way I can: deb packages, apt repo, systemd, journald etc. however I would like to also be able to run it in docker/vm. Is there a good systemd-in-docker solution for this to basically not run anything differently and not have to maintain two sets of systems?
Have you looked at systemd-nspawn[0]? Its not docker so it wouldn't be useful for writing Dockerfiles but it is light containers that work beautifully with systemd.
[0] https://wiki.archlinux.org/title/Systemd-nspawn
Thanks, this looks awesome! Will play around on my CI/CD first to see if it's any good for the build-server to add trixie builds. Might use in prod deploys later.
Update: I looked at it. Overall it looks very promising on paper.
However, the bootstrapping process is so much work that I've ended up ditching it for now. I don't want to "automate the automation" yet.
Trying out podman now.
3 replies →
Containers with systemd as an init process are considered first-class citizen by the Podman ecosystem (the base images are named accordingly: e.g, ubi10-init vs ubi10)
My current production systems are running Ubuntu 22.04, and there is no official images with systemd for them in Podman. So it does feel like second class citizen.
On another hand, if ubi’s work fine — that means there should be no technical limitation to keep Ubuntu working.
I’ll keep playing with Podman for now, but will switch to Incus if that will fail
You might be better served by Incus/LXD which run "Linux containers" (ie: a full distro including systemd, SSH etc) as opposed to OCI containers.
https://github.com/Azure/dalec
Build system packages and containers from those packages for a given target distro.
Behind the scenes it uses buildkit, so it's no extra stuff you need, just docker (or any buildkit daemon).
You could use Nix to build the package and provide a nixos module and a docker image from the same derivation. Now you only have to manage three systems instead of two. /s