general/other daemonless - Native FreeBSD OCI Containers

[AlfredoLlaquet]

I've seen this mentioned in the forums a couple of times and now it's also on Vermaden's Valuable News. I think it's good to have a thread about it because it seems something many people can be interested in nowadays.

daemonless

Run Docker-like containers natively on FreeBSD using Podman and ocijail. Pre-built images for Radarr, Sonarr, Plex, Immich and more. No Linux VM required.

daemonless.io

 

[OpenFreeNet]

Reading the daemonless documentation, I stumbled into s6 process supervision mechanism/paradigm. Every process is not started directly, but it is started from a parent supervisor process, that can manage the service errors according user defined policies. The paradigm is similar to Erlang Actor model.

There is also s6-rc that is one of the various service managers based on s6.

Probably a s6-rc like solution for FreeBSD can be the best answer to SystemD "innovations": powerful like SystemD; a lot simpler; robust.

 

[daemonless]

By using s6, we get that granular supervision without the 'daemon' bloat, keeping the containers lightweight and self-healing. We also focused on making it easy for the user to directly control UID/PID mapping.

 

[fahrenheit]

By using s6, we get that granular supervision without the 'daemon' bloat, keeping the containers lightweight and self-healing. We also focused on making it easy for the user to directly control UID/PID mapping.

As someone who used alpine linux and s6 I can confirm that s6 does what it says on the tin, you just need the relevant start, stop scripts and you are good to go.
What I have doubts is why one would use s6 with containers. Sure you can use it, but you are probably duplicating or imparing the container manager own container control plane and/or preventing the consumer to define the required flow.
As an example, the container for service A in isolation should automatically restore it's state on failures and that is what the s6 supervisor on the container will do, but if I'm using service A with another service and in that case I don't want the automatic restart.

I've tried to figure out from daemonless documentation if there's any type of container control outside of what the container provides but couldn't find any information (may have not looked at the right place).

In any case I do like what it's aiming to do. Though an option that isn't podman (due the rootfull only mode atm) would be nice.

 

[OpenFreeNet]

What I have doubts is why one would use s6 with containers.

I never used s6 and daemonless, but probably the answer is in s6-overlay, the s6 based service manager for Docker containers. They say

One of the oft-repeated Docker mantras is "one process per container", but we disagree. There's nothing inherently bad about running multiple processes in a container. The more abstract "one thing per container" is our policy - a container should do one thing, such as "run a chat service" or "run gitlab." This may involve multiple processes, which is fine.

...

Our policy is that if "the thing" fails, then the container should fail, too. We do this by determining which processes can restart, and which should bring down the container. For example, if cron or syslog fails, your container can most likely restart it without any ill effects, but if ejabberd fails, the container should exit so the system administrator can take action.

 

[daemonless]

s6-overlay is definitely on my radar for daemonless, but the porting effort required for FreeBSD puts it in the 'long-term' category for now. I’d certainly prioritize it sooner if someone wants to port it!

 

[daemonless]

I've tried to figure out from daemonless documentation if there's any type of container control outside of what the container provides but couldn't find any information (may have not looked at the right place).

We use vanilla s6, same idea as s6-overlay which LinuxServer.io uses, just more minimal.

Your point about crash propagation is valid and we should document it better. If, for example, postgres crashes inside its container, s6 restarts it before compose ever sees it, so if you wanted the whole stack to come down, you can't rely on compose for that. `podman stop` works fine externally, it's specifically the internal crash-restart path that s6 owns.

The reason we're here is init sequencing -- ordered startup scripts for PUID/PGID, permissions, and config generation before the main process starts. Hard to do cleanly without it, and the auto-restart behavior is what most users want for single-service deployments.