3 ms·

Perhaps a more productive comment (and I honestly am curious), would be -- what does systemd do right?

by sargun 4y ago

XorNot 4y ago
Systemd is containers, is the thing. Its entirely built around using cgroups to manage process resources, it just starts from the normal "I'm running root processes" level because it was intended to init a whole system. The one missing component was the concept of union mounting layered file systems from a repository.
- jsmith45 4y ago
  The systemd-nspawn system (which is how running more more typical containers is normally implemented) is a little unusual because it it geared towards running os containers, including running their whole init system (via --boot or the template unit file). There is a reason why machinectl calls the input machine images, and both accept raw disk images. This is also reflected in the systemd-nspawn requirement of having an os-release file in the container. Of course, it is entirely capable of running application containers (hence features like --as-pid2), but some of the defaults like registering with systemd-machined don't make as much sense in those scenarios. Docker is nominally geared towards application containers, although it mostly works with OS containers. Indeed it seems like container images that contain a full OS (minus kernel) are probably more common than not.
xorcist 4y ago
It is much more straightforward to use and with less surprises. The limits actually do what they say the do. It also takes care of process lifecycle. And logs by default. It's preferable in every way. What it doesn't do is manipulate and transfer file system images, that's outside the scope. Which is probably the right design. The whole thing of having Docker manipulate images for you was a strange decision and makes CI/CD unnecessarily complicated.
- magicalhippo 4y ago
  Any examples of this? I got an application, I want to specify where the internal /etc/foo and /data lives outside the "systemd-container" and I want to map some ports to the internal IP. How do I set this up with systemd?
  - xorcist 4y ago
    There is plenty of examples in the documentation. The man page (man systemd-nspawn) is short and to the point. As for your example,for regular daemons you probably want to use plain old unit files. You map ports with "Port=" and bind filesystems with "Bind=" ("/outside/data:/data" in your example). Again, plenty of examples in the documentation and in the Gentoo/Arch wikis which are excellent. It also includes examples working with (not against) SELinux. Lots of other parts of the systemd family is nasty and full of surprises but this one pretty straightforward. systemd was built on cgroups from the ground up and it makes administering them fairly trivial.
    - magicalhippo 4y ago
      Thanks, hadn't heard about systemd-nspawn. Arch wiki to the rescue again, as you say.
  - exabrial 4y ago
    I post a gist for you. This is filtered through our maven build where variables are substituted, so you'll see a bunch of placeholders that get replaced during compilation: https://gist.github.com/exabrial/fbda5ebceb94ae2397aac16f586e70fd https://gist.github.com/exabrial/fbda5ebceb94ae2397aac16f586... This particular template we're not really worried about mem/cpu limits so that isn't in there. Authbind is in there to allow it to grab lower ports, but this particular app does not. I would recommend reading these as well: * https://gist.github.com/ageis/f5595e59b1cddb1513d1b425a323db04 https://gist.github.com/ageis/f5595e59b1cddb1513d1b425a323db... * https://www.opensourcerers.org/2022/04/25/optimizing-a-systemd-service-for-security/ https://www.opensourcerers.org/2022/04/25/optimizing-a-syste...
exabrial 4y ago
Systemd is a bit of a joke in some areas: binary logs for instance. So praising systemd at all often invokes scorn. That being said, ‘containing stuff’ is one area it actually does really well. Two other excellent comments have covered the meat and potatoes of it, so I will just add a few things because they are spot on. What does right is it allows you to very specifically set ports allowed, cpu/mem limits, filesystem access limits, read-only paths, read/write Paths, chroot, private devices, private network, and many more for any single generic program: you can contain anything. We add authbind to the mix to allow for binding to lower ports. All of the spawned processes are visible from the host system using regular normal unix tools. What does even better than Docker is _not_ downloading third party code/programs from a repository. This is a much smaller footprint and allows for much easier inspection. You _can_ if you want, use systemd-nspawn which will give you a completely private deb-bootstrap, sorta mirroring what Docker does, but in my opinion that’s not necessary and increases the amount of things you need to update.

Perhaps a more productive comment (and I honestly am curious), would be -- what does systemd do right?

by sargun 4y ago

Perhaps a more productive comment (and I honestly am curious), would be -- what does systemd do right?

Systemd is containers, is the thing. Its entirely built around using cgroups to manage process resources, it just starts from the normal "I'm running root processes" level because it was intended to init a whole system. The one missing component was the concept of union mounting layered file systems from a repository.

jsmith45 4y ago
The systemd-nspawn system (which is how running more more typical containers is normally implemented) is a little unusual because it it geared towards running os containers, including running their whole init system (via --boot or the template unit file). There is a reason why machinectl calls the input machine images, and both accept raw disk images. This is also reflected in the systemd-nspawn requirement of having an os-release file in the container. Of course, it is entirely capable of running application containers (hence features like --as-pid2), but some of the defaults like registering with systemd-machined don't make as much sense in those scenarios. Docker is nominally geared towards application containers, although it mostly works with OS containers. Indeed it seems like container images that contain a full OS (minus kernel) are probably more common than not.

xorcist 4y ago

It is much more straightforward to use and with less surprises. The limits actually do what they say the do. It also takes care of process lifecycle. And logs by default. It's preferable in every way. What it doesn't do is manipulate and transfer file system images, that's outside the scope. Which is probably the right design. The whole thing of having Docker manipulate images for you was a strange decision and makes CI/CD unnecessarily complicated.

magicalhippo 4y ago
Any examples of this? I got an application, I want to specify where the internal /etc/foo and /data lives outside the "systemd-container" and I want to map some ports to the internal IP. How do I set this up with systemd?
- xorcist 4y ago
  There is plenty of examples in the documentation. The man page (man systemd-nspawn) is short and to the point. As for your example,for regular daemons you probably want to use plain old unit files. You map ports with "Port=" and bind filesystems with "Bind=" ("/outside/data:/data" in your example). Again, plenty of examples in the documentation and in the Gentoo/Arch wikis which are excellent. It also includes examples working with (not against) SELinux. Lots of other parts of the systemd family is nasty and full of surprises but this one pretty straightforward. systemd was built on cgroups from the ground up and it makes administering them fairly trivial.
  - magicalhippo 4y ago
    Thanks, hadn't heard about systemd-nspawn. Arch wiki to the rescue again, as you say.
- exabrial 4y ago
  I post a gist for you. This is filtered through our maven build where variables are substituted, so you'll see a bunch of placeholders that get replaced during compilation: https://gist.github.com/exabrial/fbda5ebceb94ae2397aac16f586e70fd https://gist.github.com/exabrial/fbda5ebceb94ae2397aac16f586... This particular template we're not really worried about mem/cpu limits so that isn't in there. Authbind is in there to allow it to grab lower ports, but this particular app does not. I would recommend reading these as well: * https://gist.github.com/ageis/f5595e59b1cddb1513d1b425a323db04 https://gist.github.com/ageis/f5595e59b1cddb1513d1b425a323db... * https://www.opensourcerers.org/2022/04/25/optimizing-a-systemd-service-for-security/ https://www.opensourcerers.org/2022/04/25/optimizing-a-syste...

exabrial 4y ago

Systemd is a bit of a joke in some areas: binary logs for instance. So praising systemd at all often invokes scorn. That being said, ‘containing stuff’ is one area it actually does really well. Two other excellent comments have covered the meat and potatoes of it, so I will just add a few things because they are spot on. What does right is it allows you to very specifically set ports allowed, cpu/mem limits, filesystem access limits, read-only paths, read/write Paths, chroot, private devices, private network, and many more for any single generic program: you can contain anything. We add authbind to the mix to allow for binding to lower ports. All of the spawned processes are visible from the host system using regular normal unix tools. What does even better than Docker is _not_ downloading third party code/programs from a repository. This is a much smaller footprint and allows for much easier inspection. You _can_ if you want, use systemd-nspawn which will give you a completely private deb-bootstrap, sorta mirroring what Docker does, but in my opinion that’s not necessary and increases the amount of things you need to update.