Forgot to add that docker has a recommended way of running multiple processes per container and it actually avoids init systems launching its own micro init: https://docs.docker.com/config/containers/multi-service_container/
On 10/11/19 19:25, Jose-Luis Rivas wrote > Here's a little bit of history on trying to make systemd work into > containers and the reason why it was tried (IMO, a silly one): > https://lwn.net/Articles/676831/ > > In short: they should not be using systemd inside the container and if > they want to the issue is not on how Debian ships systemd but that they > are not using the --privilege parameter for launching their container. > > The extended version: > > There's not much sense in using systemd inside a docker container, to be > honest. Generally you want to launch your service as custom as possible > and the ENTRYPOINT allows you to do just that. Docker already sends the > SIGKILL to the PID 1, which should be the service you're shipping in > that container. > > Ideally (and this is one the best practices I've seen people using) > containers should be built following something like the UNIX paradigm, > so: they ship one service and only one which then communicates with > others via some network protocol. People trying to use systemd inside a > container is probably trying to ship several services in just one image > which is essentially an anti-pattern on containerization. > > On the other hand, not all people is using a container to launch a > service installed via the package manager, so very few would benefit > from having systemd doing the init of the service they installed. > > In my opinion, there's no requirement at all to maintain sysv scripts, > at least not under the assumption that they are required by docker > containers because they are not. Actually, no init script at all is > required by docker containers. > -- \\\\__. https://wiki.debian.org/JoseLuisRivas ___\\\\'/___ rsa4096/D278F9C15E5461AA3C1E2FCD13EC43EEB9AC8C43
