4 ms·

I am starting to wonder, why not just execute processes directly with cgroups commands? $ cgcreate -g memory,cpu:groupname/foo $ cgexec -g memory,cpu:gr

by frik 9y ago

I am starting to wonder, why not just execute processes directly with cgroups commands? $ cgcreate -g memory,cpu:groupname/foo $ cgexec -g memory,cpu:groupname/foo bash https://wiki.archlinux.org/index.php/cgroups https://wiki.archlinux.org/index.php/cgroups It's the bare basic that libvirt and Docker et al are based anyway. So if you want to run just one process per "container" it seems rather logical to keep it simple and use cgroups commands directly. (Similar on Windows, using just sandboxie is so simple. Or do it like Android, execute every app/process with a different user.) https://en.wikipedia.org/wiki/Cgroups https://en.wikipedia.org/wiki/Cgroups

joshwget 9y ago
Managing cgroups directly would be redoing a lot of work already done by libcontainer/runc (which we leverage through Docker now, probably containerd in the future). Using these projects in RancherOS allows us to focus on other things and not reinvent the wheel.
wmf 9y ago
systemd already puts each service in a separate cgroup AFAIK, so commands like cgexec aren't even needed. I suspect people are more interested in namespace separation, but recent versions of systemd can also do that [1]. I don't think systemd has image management so that's still a reason to use Docker. [1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html https://www.freedesktop.org/software/systemd/man/systemd.exe...
- gtrevorjay 9y ago
  In the case of system services, it is probably acceptable (perhaps even ideal) to leave the image management up to deb, RPM, or ostree. systemd shouldn't do everything :) .
- technofiend 9y ago
  Systemd creates three "slices": system, user and machine. Daemons started by systemd go in system, user processes in user and virtual machines go in machine. Each process is placed in a hierarchy so you end up with system-httpd which makes it easy to assign or limit resources based on the slice. Redhat covers it extensively in their performance and tuning class.
- jvoorhis 9y ago
  Systemd technically does include rudimentary image management through systemd-importd and machinectl.
dboreham 9y ago
Because you can't make billions of $ doing that?
zenlikethat 9y ago
A lot of different concepts got conflated into "containers", but a big value add of systems like Docker over this is the use of immutable FS images with built-in distribution mechanisms. Just like it's nice to have git remotes and porcelain around them vs. the limited utility of git if you couldn't push and pull.
JdeBP 9y ago
Linux's control groups are a resource management system, an attempt to do resource management better than the POSIX rlimit mechanism. They are not job objects, and do not do all of the things that jobs do (on operating systems that have them). However, a job object is the kind of mechanism that people want for this sort of thing. * http://jdebp.eu./FGA/linux-control-groups-are-not-jobs.html http://jdebp.eu./FGA/linux-control-groups-are-not-jobs.html

by frik 9y ago

joshwget 9y ago

Managing cgroups directly would be redoing a lot of work already done by libcontainer/runc (which we leverage through Docker now, probably containerd in the future). Using these projects in RancherOS allows us to focus on other things and not reinvent the wheel.

wmf 9y ago

systemd already puts each service in a separate cgroup AFAIK, so commands like cgexec aren't even needed. I suspect people are more interested in namespace separation, but recent versions of systemd can also do that [1]. I don't think systemd has image management so that's still a reason to use Docker. [1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html https://www.freedesktop.org/software/systemd/man/systemd.exe...

gtrevorjay 9y ago
In the case of system services, it is probably acceptable (perhaps even ideal) to leave the image management up to deb, RPM, or ostree. systemd shouldn't do everything :) .
technofiend 9y ago
Systemd creates three "slices": system, user and machine. Daemons started by systemd go in system, user processes in user and virtual machines go in machine. Each process is placed in a hierarchy so you end up with system-httpd which makes it easy to assign or limit resources based on the slice. Redhat covers it extensively in their performance and tuning class.
jvoorhis 9y ago
Systemd technically does include rudimentary image management through systemd-importd and machinectl.

dboreham 9y ago

Because you can't make billions of $ doing that?

zenlikethat 9y ago

A lot of different concepts got conflated into "containers", but a big value add of systems like Docker over this is the use of immutable FS images with built-in distribution mechanisms. Just like it's nice to have git remotes and porcelain around them vs. the limited utility of git if you couldn't push and pull.

JdeBP 9y ago

Linux's control groups are a resource management system, an attempt to do resource management better than the POSIX rlimit mechanism. They are not job objects, and do not do all of the things that jobs do (on operating systems that have them). However, a job object is the kind of mechanism that people want for this sort of thing. * http://jdebp.eu./FGA/linux-control-groups-are-not-jobs.html http://jdebp.eu./FGA/linux-control-groups-are-not-jobs.html