3 ms·

I don't see why systemd is at the core of all those graphs. Why do we need that particular program to run containers? Or does systemd mean, in this context, "an

by duck2 10y ago

I don't see why systemd is at the core of all those graphs. Why do we need that particular program to run containers? Or does systemd mean, in this context, "any daemon-controlling process"?

darfs 10y ago
Think it's a "process Graph"... and Process ID 1 is systemd on the[/her] machine. Edit: turns Out, she explains: [...]systemd: rkt will run a program called systemd-nspawn as the init (PID 1) process inside your container. This is because it can be bad to run an arbitrary process as PID 1[0] -- your process isn't expecting it and will might react badly. It also run some systemd-journal process? I don't know what that's for yet.[...]" [0] https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-f...
- tadfisher 10y ago
  The systemd-nspawn manual might be more useful here: https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html https://www.freedesktop.org/software/systemd/man/systemd-nsp... Personal opinion: If you're already using systemd on the host, nspawn containers are trivially easy to create, boot, and maintain. Running systemd as the guest init allows you to use `systemctl -M <machine>` and `journalctl -M <machine>` the same way you would for the host, and the guest process tree is exposed in the host's `systemctl status`.
  - darfs 10y ago
    I grepped the Link above from the article. But yea, first look, it seems usefull :-)
  - Klasiaster 10y ago
    It's still ok to also use rkt because it is compatible with machinectl+nspawn from systemd, in both directions.
    - tadfisher 10y ago
      In this case, rkt (or CoreOS?) eschews the more advanced features that rely on btrfs in favor of an overlayfs solution, so it's not a complete abstraction.
CSDude 10y ago
Because, systemd is like a mafia in modern(!) linux distros, you have to pay tribute to it by integrating with it, because it is an all controlling daemon. Not trying to flamewar here, but as you do, I really dont understand why we need to have systemd integration for just doing anything.
- tadfisher 10y ago
  Some advantages: - I can use the same tools to administer both host and guests (systemctl and journalctl). - cgroups and namespaces are managed the same way on both host and guests. - I can integrate containers (via .nspawn and .service units) with my host init/supervision daemon, like any other systemd service, without translating from one configuration format to another. - Because of the above, resource/quota constraints for a single container or groups of containers can be described via a common configuration.
  - sjellis 10y ago
    Yeah, there's an underlying point here that containers are just processes, so there should be little difference between containerized services and services running directly on the host. There's an idea that the desired end-state should be that all services are containerized, which means that either Docker manages services (as in RancherOS), or systemd does.

by duck2 10y ago

I don't see why systemd is at the core of all those graphs. Why do we need that particular program to run containers? Or does systemd mean, in this context, "any daemon-controlling process"?

darfs 10y ago

Think it's a "process Graph"... and Process ID 1 is systemd on the[/her] machine. Edit: turns Out, she explains: [...]systemd: rkt will run a program called systemd-nspawn as the init (PID 1) process inside your container. This is because it can be bad to run an arbitrary process as PID 1[0] -- your process isn't expecting it and will might react badly. It also run some systemd-journal process? I don't know what that's for yet.[...]" [0] https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-f...

tadfisher 10y ago
The systemd-nspawn manual might be more useful here: https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html https://www.freedesktop.org/software/systemd/man/systemd-nsp... Personal opinion: If you're already using systemd on the host, nspawn containers are trivially easy to create, boot, and maintain. Running systemd as the guest init allows you to use `systemctl -M <machine>` and `journalctl -M <machine>` the same way you would for the host, and the guest process tree is exposed in the host's `systemctl status`.
- darfs 10y ago
  I grepped the Link above from the article. But yea, first look, it seems usefull :-)
- Klasiaster 10y ago
  It's still ok to also use rkt because it is compatible with machinectl+nspawn from systemd, in both directions.
  - tadfisher 10y ago
    In this case, rkt (or CoreOS?) eschews the more advanced features that rely on btrfs in favor of an overlayfs solution, so it's not a complete abstraction.

CSDude 10y ago

Because, systemd is like a mafia in modern(!) linux distros, you have to pay tribute to it by integrating with it, because it is an all controlling daemon. Not trying to flamewar here, but as you do, I really dont understand why we need to have systemd integration for just doing anything.

tadfisher 10y ago
Some advantages: - I can use the same tools to administer both host and guests (systemctl and journalctl). - cgroups and namespaces are managed the same way on both host and guests. - I can integrate containers (via .nspawn and .service units) with my host init/supervision daemon, like any other systemd service, without translating from one configuration format to another. - Because of the above, resource/quota constraints for a single container or groups of containers can be described via a common configuration.
- sjellis 10y ago
  Yeah, there's an underlying point here that containers are just processes, so there should be little difference between containerized services and services running directly on the host. There's an idea that the desired end-state should be that all services are containerized, which means that either Docker manages services (as in RancherOS), or systemd does.