3 ms·
How is this true? A container _is_ an ordinary process. https://iximiuz.com/en/posts/not-every-container-has-an-operating-system-inside/#container-is-just-a-p
by pests 5y ago
How is this true?
A container _is_ an ordinary process.
https://iximiuz.com/en/posts/not-every-container-has-an-operating-system-inside/#container-is-just-a-processes https://iximiuz.com/en/posts/not-every-container-has-an-oper...
(we just discussed another article by the same author a few days ago on slimmer containers)
"The container process is isolated (namespaces) from the rest of the system and restricted from both the resource consumption (cgroups) and security (capabilities, AppArmor, Seccomp) standpoints. But in the end, this is still a regular process, same as any other process on the host system."
- jandrewrogers 5y agoIn a normal process (or VM in many cases) you can take direct control of the physical hardware via standard syscalls and mechanisms, which is idiomatic for a lot of high-performance infrastructure software. These appear to stop working or have unexpected (and suboptimal) behavior if the same code is executed in a container. Note that configurations modifying syscall behavior is not unique to containers. There are other ways, only rarely encountered in the wild, to configure your Linux system to inadvertently break the same required syscall behavior. Linux makes no guarantees about the behaviors of syscalls. Nonetheless, high-performance software is necessarily designed under the assumption of specific behaviors that are almost always true on bare metal and modern virtual machines when configured sensibly. AFAIK there is no way to configure a container to ensure the same behavior, which is the problem. VMs in the early days had many of the same issues. It may be sorted eventually (like with VMs) but for now it causes severe regressions in many codes.