Re: Init systems and docker
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
Reply to: