HN Explorer

8 comments

[ 3.2 ms ] story [ 21.3 ms ] thread
tyingq
Good read, but "The tool that really runs your containers" isn't quite right either.

Bocker (docker runtime in ~100 lines of bash) does a good job showing what's really happening. Basically namespaces and cgroups, both of which come with Linux. The source is probably the best "deep dive" on containers I've found.

https://github.com/p8952/bocker

Docker thrives because of the repository of images, a great name, and some marketing. Runc thrives because it provides a nice wrapper around namespaces, mounts, cgroups, virtual network interfaces, etc. Neither really provides the magic, though...it's already there.

monocasa
Namespaces and cgroups are orthogonal to OCI and runc.

gvisor is an example that runs containers via runc without all that, using the same scheme as User Mode Linux instead.

mav3rick
These are at different abstraction levels.
fodoj
I agree that the final “thing” that runs containers and provides isolation is Linux kernel, it’s also pointed out in the article :-) Thanks for the feedback! Bocker looks like a fun little project indeed
cyphar
A pretty good overview of the world of OCI containers, and I really appreciate the shout-out to umoci. I will admit that I did get a little fidgety when you started talking about --detach as well as the internals of /var/run/runc (to say that these things are "a little dodgy" would be an understatement -- the phrase "fundamentally misdesigned" comes to mind), but it is nice to show folks that containers really aren't that magical at the end of the day.
jka
Can anyone share their experiences using the 'crun' container runtime (alternative to 'runc') in their clusters?

(it's mentioned way down near the end of the article, and looks like it is less resource-intensive)

[1] - https://github.com/containers/crun

gscrivano
The OCI runtime cost is so small that I do not expect any measurable difference in a cluster.