4 ms·

>Note that Alpine Linux doesn’t use systemd, it uses OpenRC. This didn’t factor into my decision at all. systemd has worked well for me on my Arch Linux systems

by adtac 8y ago

>Note that Alpine Linux doesn’t use systemd, it uses OpenRC. This didn’t factor into my decision at all. systemd has worked well for me on my Arch Linux systems. [...] How does systemd, or any init for that matter, come into the picture if you're running everything inside docker? Containers don't use any init, right? They just execute the binary in the host environment (but containerised). Or am I missing something? Edit: nevermind, OP is using Alpine as the host OS as well.

unk 8y ago
The host environment you're running Docker in still needs a services to be executed at boot.
- adtac 8y ago
  I just ran `docker run -it alpine /bin/sh` and when inside, I ran top. It looks like `/bin/sh` ran as PID 1. No init, just sh (busybox in this case). Edit: Ah you meant the host OS. I can't reply to wezm down below for whatever reason (there's no "reply" button), so I'll just edit this to say I didn't realise that he was using alpine as your host OS as well. I haven't seen many people running it outside Docker, so it's quite interesting.
  - Scarbutt 8y ago
    He means the host OS.
    - adtac 8y ago
      Host operating systems need a init, of course. I was just startled by the irrelevant discussion on alpine's init system when it isn't involved anywhere.
      - wezm 8y ago
        Yeah my host is running Alpine as well the containers so it's init needs to start docker, cron, etc.
  - krferriter 8y ago
    There's no init and only one process by default in alpine's docker image but you can add them and run more processes if you want.
jackalo 8y ago
To the best of my knowledge, they share a kernel, not an init.
dmix 8y ago
In my experience I had to update a bunch of scripts and configs which used systemd commands as well as using GNU versions of other commands (with some basic programs like `find` or `grep` this turned out to break a lot of stuff). That was my only big annoyance. Plus the package manager and system structure was a bit of a learning curve. But otherwise I was very happy with it. The lack of portability with my Linux ArchLinux/Debian desktop/servers can be overcome with time and experience like anything. I used some basic Docker images as well but they always needed some config work, as they mostly installed the base software but didn’t get your apps running. Other people may be using more sophisticated images though.
freedomben 8y ago
Correct. Docker containers typically only contain one process, and that process runs as PID 1. If you need an init system, tini is very popular, and is now built in to docker itself[1]. Systemd is way heavy and overkill inside docker. [1] https://github.com/krallin/tini https://github.com/krallin/tini
- krferriter 8y ago
  They don't always have one process though. And this is actually a significant good case for OpenRC, as it is far more lightweight than systemd. I haven't used tini.
- Gigablah 8y ago
  s6-overlay [1] is also a popular choice for Alpine-based containers. [1] https://github.com/just-containers/s6-overlay https://github.com/just-containers/s6-overlay
- inetknght 8y ago
  Specifically why is it way heavy though? What does systemd provide which isn't needed?
  - JoshuaRLi 8y ago
    Primarily, you would run an init system in a docker container in order to correctly proxy signals to the one process in question, which would otherwise run as PID 1 - for example, sending SIGTERM to docker run running a PID 1 with no registered handler will result in nothing, because Linux won't use the default handler (killing it). Secondarily, if you want to be neat and save some pids and kernel memory, you need an init system to wait(3) on orphaned zombie processes. These are the only two use cases AFAIK, which a small init system such as tini satisfies, without the complexity and size of systemd.
    - inetknght 8y ago
      That doesn't answer the question: what does systemd provide which isn't needed? I have multiple network devices. I want some to be controlled by processes running in a container; effectively I want some processes to run under a user account but still provide root (root-like?) access to the specified network device(s). I want to be able to give a specific (containerized) user full control over one or more specific network devices. My (naive?) understanding is that the init daemon takes care of bringing the network online and then subsequent management of it. For systemd, that would be Network Manager? Or do I misunderstand?
u801e 8y ago
> Containers don't use any init, right? They just execute the binary in the host environment (but containerised). It depends on the container runtime. LXC/LXD run an actual init system and can be treated like lightweight VMs running multiple processes.
kingosticks 8y ago
You can run systemd inside a systemd-nspawn container. I've found this quite useful for debugging/testing custom Raspberry Pi disk images. You can simply import the rootfs into the container and have something that behaves almost like the real system, including startup, but right there on your development machine. I don't think you can do anything like that in Docker. But I do appreciate most people probably don't want/need that systemd support.

by adtac 8y ago

unk 8y ago

The host environment you're running Docker in still needs a services to be executed at boot.

adtac 8y ago
I just ran `docker run -it alpine /bin/sh` and when inside, I ran top. It looks like `/bin/sh` ran as PID 1. No init, just sh (busybox in this case). Edit: Ah you meant the host OS. I can't reply to wezm down below for whatever reason (there's no "reply" button), so I'll just edit this to say I didn't realise that he was using alpine as your host OS as well. I haven't seen many people running it outside Docker, so it's quite interesting.
- Scarbutt 8y ago
  He means the host OS.
  - adtac 8y ago
    Host operating systems need a init, of course. I was just startled by the irrelevant discussion on alpine's init system when it isn't involved anywhere.
    - wezm 8y ago
      Yeah my host is running Alpine as well the containers so it's init needs to start docker, cron, etc.
- krferriter 8y ago
  There's no init and only one process by default in alpine's docker image but you can add them and run more processes if you want.

jackalo 8y ago

To the best of my knowledge, they share a kernel, not an init.

dmix 8y ago

In my experience I had to update a bunch of scripts and configs which used systemd commands as well as using GNU versions of other commands (with some basic programs like `find` or `grep` this turned out to break a lot of stuff). That was my only big annoyance. Plus the package manager and system structure was a bit of a learning curve. But otherwise I was very happy with it. The lack of portability with my Linux ArchLinux/Debian desktop/servers can be overcome with time and experience like anything. I used some basic Docker images as well but they always needed some config work, as they mostly installed the base software but didn’t get your apps running. Other people may be using more sophisticated images though.

freedomben 8y ago

Correct. Docker containers typically only contain one process, and that process runs as PID 1. If you need an init system, tini is very popular, and is now built in to docker itself[1]. Systemd is way heavy and overkill inside docker. [1] https://github.com/krallin/tini https://github.com/krallin/tini

krferriter 8y ago
They don't always have one process though. And this is actually a significant good case for OpenRC, as it is far more lightweight than systemd. I haven't used tini.
Gigablah 8y ago
s6-overlay [1] is also a popular choice for Alpine-based containers. [1] https://github.com/just-containers/s6-overlay https://github.com/just-containers/s6-overlay
inetknght 8y ago
Specifically why is it way heavy though? What does systemd provide which isn't needed?
- JoshuaRLi 8y ago
  Primarily, you would run an init system in a docker container in order to correctly proxy signals to the one process in question, which would otherwise run as PID 1 - for example, sending SIGTERM to docker run running a PID 1 with no registered handler will result in nothing, because Linux won't use the default handler (killing it). Secondarily, if you want to be neat and save some pids and kernel memory, you need an init system to wait(3) on orphaned zombie processes. These are the only two use cases AFAIK, which a small init system such as tini satisfies, without the complexity and size of systemd.
  - inetknght 8y ago
    That doesn't answer the question: what does systemd provide which isn't needed? I have multiple network devices. I want some to be controlled by processes running in a container; effectively I want some processes to run under a user account but still provide root (root-like?) access to the specified network device(s). I want to be able to give a specific (containerized) user full control over one or more specific network devices. My (naive?) understanding is that the init daemon takes care of bringing the network online and then subsequent management of it. For systemd, that would be Network Manager? Or do I misunderstand?

u801e 8y ago

> Containers don't use any init, right? They just execute the binary in the host environment (but containerised). It depends on the container runtime. LXC/LXD run an actual init system and can be treated like lightweight VMs running multiple processes.

kingosticks 8y ago

You can run systemd inside a systemd-nspawn container. I've found this quite useful for debugging/testing custom Raspberry Pi disk images. You can simply import the rootfs into the container and have something that behaves almost like the real system, including startup, but right there on your development machine. I don't think you can do anything like that in Docker. But I do appreciate most people probably don't want/need that systemd support.