Linux containers in 500 lines of code (2016) | Hacker News Reader

Linux containers in 500 lines of code (2016)

blog.lizzie.io

267 pointssturza28 comments

Docker in ~100 lines of bash: https://github.com/p8952/bocker

"100 lines of bash" is pretty generous. they might as well have just made it 1 line of bash with the way the code is written

Only the first few lines of the script look dense. Everything else looks normal to me.

Stuff like https://github.com/p8952/bocker/blob/master/bocker#L94 is super dense.

I might write that something like:

    cid="$(
      ps o ppid,pid |
        grep "^$(
          ps o pid,cmd |
            grep -E "^\ *[0-9]+ unshare.*$1" |
            awk '{print $1}'
        )" |
        awk '{print $2}'
    )"

or maybe even cid=$(pgrep -P $(pgrep -f "unshare.*$1")).

I agree with you that their code is fairly dense, yours is overly verbose.

Having said that, looking at their code, I don’t get the impression they’re optimizing for LOC. There is plenty of verbosity and opportunity to remove lines of code if they wanted.

Can confirm. The bocker code (incl. my modest contributions) was targeted towards showing that the Linux toolbox was available and scriptable.

Maybe I've spent too much time writing one-liners in bash but I really prefer the original to yours. I can read the original much faster because it matches the pattern for how I write bash on the command line. Yours looks totally foreign to how bash is normally written. Not saying one is better than the other, just my personal preference.

Dang, didn't expect the downvotes for sharing my bash coding style. :(

That's not fair considering the two longest lines are for logging into dockerhub and parsing input arguments.

Exactly... I mentioned this in an article 4 years ago.

https://www.theregister.co.uk/2016/07/05/containers_state_of...

Linux containers aren't rocket science, but the system call API is confusing and hard to get right (I find pid namespaces particularly annoying), the basic user commands (unshare, ip netns...) are kind of a pain to use, and orchestration using Docker/Kubernetes is overly complex and opaque. There is clearly room for improvement at all levels.

A thread from 2017: https://news.ycombinator.com/item?id=15608435

Liz Rice has done some awesome on-stage live coding, including a very small container runtime in go.

https://www.youtube.com/watch?v=8fi7uSYlOdc

She has an O'Reilly video course on building container runtime's in go that is really great as well.

I'm wondering if MacOS has the requisite system calls to have its own native containers, I imagine it does, Darwin being based on BSD. Are there any products that use that functionality?

Not sure how you get from Darwin being based on BSD to Darwin should be able to support something which heavily relies on Linux specific functionality to the point where even Freebsd having trouble https://wiki.freebsd.org/Docker

Sure with enough changes MacOS could support it, but then with enough changes to anything, so that is not really a sensible measure.

The question wasn't about running docker on *BSD or macOS, but rather running some form of native container. Native containers don't rely on linux, they rely on the kernel having some form of containerization primitive.

FreeBSD has jails, which are a native type of container on freebsd.

However, BSD operating systems are really different from each other. OpenBSD doesn't have jails or anything too like containers, and macOS does have sandboxes (which are kinda like a container in some way), but no proper containers.

Docker isn't really related to the question of whether a native container solution exists on non-linux platforms.

Darwin is the generic name for the open source posix OS that’s the basis for MacOS (and others).

It would be more appropriate to compare the XNU micro kernel used in Darwin to the Linux kernel used in GNU/Linux in your analogy.

It does,

https://developer.apple.com/documentation/hypervisor

https://developer.apple.com/app-sandboxing/

Kind of but with limitations. You have chroot, which may or may not be secure, app sandbox which is quite powerful (but best used without chroot). No process namespaces or jails, very limited network isolation. No bind mounts. Overall very limited, you could do something but it woild be quite different.

> pivot_root is a system call lets us swap the mount at / with another. Glibc doesn't provide a wrapper for it, but includes a prototype in the man page. I don't really understand, but OK, we'll include our own.

Probably because pivot_root is a speciality that is used in initramfs boostrapping and is exposed to that scriptology via the pivot_root program that comes from the util-linux project.

Simple unprivileged container runtimes: https://github.com/NVIDIA/enroot https://github.com/hpc/charliecloud

I like the use of noweb. Very slick.

I was actually wondering what the lowest-resource way of launching a bunch of mostly-idle single port applications in isolation currently is. Docker runtime is bloated, Kubernetes has recommended limits (and enforced on cloud providers), Runc feels like you have to implement Kubernetes/Docker on top yourself. Anyone seen anything else out there to run a few thousand single port binaries and multiplex them with a webserver?

I’ve had really good results with LXC/LXD. Depending on the privileges of the container the only area of overhead that sometimes concerns me is filesystem IO, but ive been able to work around it.

Podman with the new crun[1] container runtime is pretty lightweight. Everything circles back to C.

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

Under the hood docker uses `runc` which is fairly small and easy to use, IMO.

Reply on news.ycombinator.com