4 ms·

Let's say you are installing this from a normal package manager and want to limit it: To install: apt install mypackage To edit the systemd unit (automat

Let's say you are installing this from a normal package manager and want to limit it: To install: apt install mypackage To edit the systemd unit (automatically creating the file in the right place): systemctl edit mypackage Then add these lines to limit to 2 cpus and 500mb memory: [Service] CPUAccounting=true CPUQuota=200% MemoryAccounting=true MemoryHigh=500M And then to start it now and on boot: systemctl enable --now mypackage This is now integrated with package updates, starts on boot, logs to the same place that most other system utilities do and so on.

hardwaresofton 6y ago
I'm not about to argue against systemd, it's great software, and it's in every distro right now for a reason. Understanding apt (+/- how to package for it), systemctl, and the options you've laid out in your unit file are not trivial, and I would argue that they are less trivial (or harder) than understanding what's happening with containers, especially if you're running rootless containers, and/or using a container tool like podman which does without the daemon. --cpus 2 --memory 500M is easier, and gets you the same results though they may not be as permanent or as well managed -- the management and external stuff is an orthogonal concern, and that's not the situation I was addressing. The original point was insinuating that throwing up a binary and getting it to run. your filesystem is also not available to the container by default, and in this way docker sort of fails closed. If you're running a rootless container, the story is even better. One thing you have not covered is filesystem isolation, which docker also does very easily. There is a lot to configure on the systemd side[0] and the parts that are overlapping are just easier to configure and run with docker. Systemd is the better tool to build repeatable installs for pet processes, but again, there is a lot of knowledge underneath that is related. People to this day still complain that systemd does too much (I personally like it a lot, and it's great to have everything in one place). [EDIT] Just to make myself clear, systemd is an amazing tool -- I like it, I run it, I'm not smart enough to administer a more complicated setup -- but docker is easier, for a large part of the small subset of systemd's capabilities that docker covers. [0]: https://www.redhat.com/sysadmin/mastering-systemd https://www.redhat.com/sysadmin/mastering-systemd
aequitas 6y ago
But there is a lot of work to be done before you can do the simple apt install. I (gladly) don't know how it is nowadays but before Dockerfiles/Docker creating your own packages according to the various standards was a pita. Most companies needed a 'packaging specialist/release engineer' role as most developers where not up to the task. Solutions like FPM[0] did help somewhat, but it was still hard when dealing with non-homogeneous environments. Containers solved that problem universally for all distributions. [0] https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm

hardwaresofton 6y ago

I'm not about to argue against systemd, it's great software, and it's in every distro right now for a reason. Understanding apt (+/- how to package for it), systemctl, and the options you've laid out in your unit file are not trivial, and I would argue that they are less trivial (or harder) than understanding what's happening with containers, especially if you're running rootless containers, and/or using a container tool like podman which does without the daemon. --cpus 2 --memory 500M is easier, and gets you the same results though they may not be as permanent or as well managed -- the management and external stuff is an orthogonal concern, and that's not the situation I was addressing. The original point was insinuating that throwing up a binary and getting it to run. your filesystem is also not available to the container by default, and in this way docker sort of fails closed. If you're running a rootless container, the story is even better. One thing you have not covered is filesystem isolation, which docker also does very easily. There is a lot to configure on the systemd side[0] and the parts that are overlapping are just easier to configure and run with docker. Systemd is the better tool to build repeatable installs for pet processes, but again, there is a lot of knowledge underneath that is related. People to this day still complain that systemd does too much (I personally like it a lot, and it's great to have everything in one place). [EDIT] Just to make myself clear, systemd is an amazing tool -- I like it, I run it, I'm not smart enough to administer a more complicated setup -- but docker is easier, for a large part of the small subset of systemd's capabilities that docker covers. [0]: https://www.redhat.com/sysadmin/mastering-systemd https://www.redhat.com/sysadmin/mastering-systemd

aequitas 6y ago

But there is a lot of work to be done before you can do the simple apt install. I (gladly) don't know how it is nowadays but before Dockerfiles/Docker creating your own packages according to the various standards was a pita. Most companies needed a 'packaging specialist/release engineer' role as most developers where not up to the task. Solutions like FPM[0] did help somewhat, but it was still hard when dealing with non-homogeneous environments. Containers solved that problem universally for all distributions. [0] https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm