4 ms·

Operating systems abstract resources.* Unixes got the abstraction boundary not-quite-right, by excluding networking and filesystems from the concept of process

Operating systems abstract resources.* Unixes got the abstraction boundary not-quite-right, by excluding networking and filesystems from the concept of process. Containers are a correction to this. i.e. not quite as catchy, but: "Containers: the present is what the past should have been." * Windows abstract screens, Files abstract storage Sockets abstract connections, Threads abstract CPUs, etc.

downerending 7y ago
Maybe so, but somehow containers aren't really there yet. As a trivial example, when I 'lsof' a container process (as root), it often cannot "see" all of the information about the process' open files, apparently because they're mapped into a different chroot, or because of other cgroups/namespace issues. This is one of a number of issues that make containers hard to deal with. (We also see an issue where containers interact badly with the OOM killer, leading the entire system to hang because /proc/*/cmdline cannot be read at all.)
- geggam 7y ago
  They work for google, however there just arent many companies with the resources of google. If you had a small army of SRE and seriously senior devs / devops you could easily manage containers. If you are just stuck on running containers and k8s I suggest you leverage their resources and get to GKE But then releasing k8s might just have been the plan to get people into GKE instead of AWS Who am I to speculate on googles marketing acumen ?
- atombender 7y ago
  The failure of userland tools (such as lsof) to correctly show work with containers is unfortunate, but this is partly an artifact of the Linux kernel's somewhat ramshackle approach to containerization. The kernel doesn't have a concept of containers, but rather of kernel namespaces. For example, it's possible for a process to create a new namespace that is the same as that of a default process, except with a new file system namespace — i.e., a chroot. Hopefully we'll see these tools updated to better understand kernel namespaces. In the meantime, if you need to interact with containers, use the nsenter [1] tool. For example, it allows you to enter the same PID namespace as the container, but still use the host file system. For example, run to lsof against a container's PID 1 (corresponding to the host PID 1234): $ nsenter -p 1234 lsof -p 1 [1] http://man7.org/linux/man-pages/man1/nsenter.1.html http://man7.org/linux/man-pages/man1/nsenter.1.html
mixmastamyk 7y ago
Which OS did? From memory this sounds like Plan9.

downerending 7y ago

Maybe so, but somehow containers aren't really there yet. As a trivial example, when I 'lsof' a container process (as root), it often cannot "see" all of the information about the process' open files, apparently because they're mapped into a different chroot, or because of other cgroups/namespace issues. This is one of a number of issues that make containers hard to deal with. (We also see an issue where containers interact badly with the OOM killer, leading the entire system to hang because /proc/*/cmdline cannot be read at all.)

geggam 7y ago
They work for google, however there just arent many companies with the resources of google. If you had a small army of SRE and seriously senior devs / devops you could easily manage containers. If you are just stuck on running containers and k8s I suggest you leverage their resources and get to GKE But then releasing k8s might just have been the plan to get people into GKE instead of AWS Who am I to speculate on googles marketing acumen ?
atombender 7y ago
The failure of userland tools (such as lsof) to correctly show work with containers is unfortunate, but this is partly an artifact of the Linux kernel's somewhat ramshackle approach to containerization. The kernel doesn't have a concept of containers, but rather of kernel namespaces. For example, it's possible for a process to create a new namespace that is the same as that of a default process, except with a new file system namespace — i.e., a chroot. Hopefully we'll see these tools updated to better understand kernel namespaces. In the meantime, if you need to interact with containers, use the nsenter [1] tool. For example, it allows you to enter the same PID namespace as the container, but still use the host file system. For example, run to lsof against a container's PID 1 (corresponding to the host PID 1234): $ nsenter -p 1234 lsof -p 1 [1] http://man7.org/linux/man-pages/man1/nsenter.1.html http://man7.org/linux/man-pages/man1/nsenter.1.html

mixmastamyk 7y ago

Which OS did? From memory this sounds like Plan9.