Is it recommended to run systemd inside docker container?

Question

I am planning to use 'systemd' inside the container. Based on the articles I have read, it is preferable to limit only one process per container.

But if I configure 'systemd' inside the container, I will end up running many processes.

It would be great to understand the pros and cons of using systemd inside the container before I take any decision.

Lilongwe

Using systemd inside the container is matter of personal choice. You can implement in either ways. – Gaeta

what's your usecase that you need systemd? – Happy

Instead of systemd how about using docker restart always? – Coo

Did you able to solve your use case with the selected answer? could you provide more details please? – Salts

What about using systemd-nspawn? It's not a docker container and it runs off a rootfs directly, but it has the full set of systemd features like cron jobs and service autostart. It does run a few processes but it's very lightweight, rebooting takes two seconds. – Overwrite

Answer 1

I'd advise you to avoid systemd in a container if at all possible.

Systemd mounts filesystems, controls several kernel parameters, has its own internal system for capturing process output, configures system swap space, configures huge pages and POSIX message queues, starts an inter-process message bus, starts per-terminal login prompts, and manages a swath of system services. Many of these are things Docker does for you; others are system-level controls that Docker by default prevents (for good reason).

Usually you want a container to do one thing, which occasionally requires multiple coordinating processes, but you usually don't want it to do any of the things systemd does beyond provide the process manager. Since systemd changes so many host-level parameters you often need to run it as --privileged which breaks the Docker isolation, which is usually a bad idea.

As you say in the question, running one "piece" per container is usually considered best. If you can't do this then a light-weight process manager like supervisord that does the very minimum an init process is required to is a better match, both for the Docker and Unix philosophies.

Lessard

Answer 2

s6 became a somewhat popular init for containers when you need more than one process. And yes, it's not "one process per container", it's "one thing per container". Running a website e.g. is still one thing but it's usually more than one process.

Knotgrass

It's not "one thing" per container, it's actually one process per container! I don't know where you got that from, but it's wrong. That doesn't mean there aren't exceptions where you need to run several processes in the same container, but you'd better have a good reason not to observe the principle. – Antiphlogistic

"I don't know where you got that from" → It's from here github.com/just-containers/s6-overlay#the-docker-way – Immaculate

aha - one thing per container - and then we have docker in docker official deployments. And what to do, if your one thing spawns 20 another processes: how it would be different from the systemd or bash then? One process per container is just pathetic excuse to the road of k8s and pods with it's own deployment logic, or swarm - what docker pushed hard at the times. But if there's no plan to use swarm or k8s, container is just and environment in a isolated namespace where you can do everything you want. – Josefjosefa

Answer 3

You should think it more to be a question which init system you like to use.

One may use the old /sbin/init or the systemd-daemon running as PID-1 in a container. Any command like "docker stop" will talk to PID-1 only. If you do only have one java application in a container then it is recommended to run that process directly as PID-1 of the container.

Running systemd is mostly not required - if you have multiple services in a container or if some wrapper script uses 'systemctl' then you may still want to use activate it. But the latter use cases would also be covered by docker-systemctl-replacement.

Karelia