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?
Linux containers in 500 lines of code (2016)
11–20 of 31 posts
Re: Linux containers in 500 lines of code (2016)
#12[deleted]
Re: Linux containers in 500 lines of code (2016)
#13Liz Rice has done some awesome on-stage live coding, including a very small container runtime in go.
Re: Linux containers in 500 lines of code (2016)
#14I 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 webs…
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.
Re: Linux containers in 500 lines of code (2016)
#15Liz 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.
Re: Linux containers in 500 lines of code (2016)
#16I 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 webs…
Podman with the new crun[1] container runtime is pretty lightweight. Everything circles back to C.
Re: Linux containers in 500 lines of code (2016)
#17Earlier quoted context omitted.
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}' )"
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.
Re: Linux containers in 500 lines of code (2016)
#18Linux 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.
Re: Linux containers in 500 lines of code (2016)
#19I 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 webs…
Under the hood docker uses `runc` which is fairly small and easy to use, IMO.
Re: Linux containers in 500 lines of code (2016)
#20Earlier quoted context omitted.
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}' )"
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.