Replies: 1 comment 1 reply
-
I also ran into the dilemma regarding to musl vs glibc and landed on supporting Alpine and Debian. It feels sub-optimal but I don't know a better strategy. Anyway, I'm thrilled that this has been added to the official repo so I'll probably be marking my version as archived/deprecated in the near future. ETA: I'm also a big fan of avoiding Docker tooling whenever possible. 👍🏻 |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Based on a user request in #95, I decided to try building a multi architecture image for runitor and publish on Docker Hub, using only Podman. (For reasons irrelevant to discussion, I don't want to rely on any Docker tooling).
For now docker.io/runitor/runitor has a Alpine based images of v1.2.0 release (and symbolic
latest
) foramd64
,arm64/v8
,arm/v7
, andarm/v6
architectures. The images offer no entrypoint as they are intended to be the base layer for your workload images.As I mentioned in the issue thread, I was only able to test the ARM images under binfmt with QEMU emulation. So I have a favor to ask. If you run Linux containers on an ARM machine, please test and report.
I understand there can be demand for more traditional Linux distribution based images, rather than Alpine (which uses musl, BusyBox, OpenRC instead of glibc, core utils, systemd). So I intend to add at least Debian based image as well. Currently I don't plan to be as comprehensive as Go's images where they support multiple Debian and Alpine releases.
If you have opinions, this is the right thread to chime in.
I'm going to tag two of the runitor container image maintainers, @markcaudill and @SkYNewZ here to give them a chance to chime in as well if they are interested.
Beta Was this translation helpful? Give feedback.
All reactions