81–89 of 89 posts
My 2018 joke has been implemented. > Or Gocker, an implementation of Docker in go... https://news.ycombinator.com/item?id=16119842
[0] https://github.com/moby/moby/commit/a27b4b8cb8e838d03a99b6d2...
My 2018 joke has been implemented. > Or Gocker, an implementation of Docker in go... https://news.ycombinator.com/item?id=16119842
My 2018 joke has been implemented. > Or Gocker, an implementation of Docker in go... https://news.ycombinator.com/item?id=16119842
As a kid I was a compulsive liar and would make up non-existent stories. With the advent of search engines I discovered that any story I can come up with actually happened somewhere in the world and has an article about it already.
Example: Fake barn county. You're driving in a county and see lots of barns. You point to one and say "that's a barn". Unbeknownst to you, almost all the barns are not barns but are facades. By accident you actually are pointing at one of the few real barns.
Can someone explain the value/purpose of docker to someone who (easily) deploys regular apps to a Digital Ocean droplet?
runc - which is the low-component that does the actual container launching in Docker and other runtimes - is mostly written in Go and quite approachable[1], if you're curious what a production-ready container runtime looks like.
Namespaces look simple on the surface, but there are plenty of subleties, particularly when using Go:
- `runtime.LockOSThread()` has to be called before entering a namespace to pin the goroutine to a specific OS thread. The unshare call affects only the current thread[2][3]. Even then, you have to be careful not to spawn any new goroutines[4]. For this reason, parts of runc are currently written in C (you could technically implement it in pure Go, but the maintainers believe it's easier to reason about the C implementation).
- The container runtime has to reexec itself from a copy of itself in a memfd to prevent the container from writing to /proc/self/exe[5][6].
- Various race conditions and symlink attacks during container setup[7][8].
- Some parts of the container initialization have to be done after switching to the new rootfs, which is attacker-controlled territory[9][10].
- ... and plenty of other gotchas, the runc code is full of comments that explain why things have to be done in particular ways.
Obviously, Gocker is an experiment and does none of these things, and you shouldn't run it on anything that you care about :) Sometimes things are complex for a reason.
[1]: https://github.com/opencontainers/runc
[2]: https://golang.org/doc/go1.10#runtime
[3]: https://github.com/golang/go/issues/20676
[4]: https://www.weave.works/blog/linux-namespaces-golang-followu...
[5]: https://github.com/opencontainers/runc/pull/1984
[6]: https://github.com/opencontainers/runc/commit/0a8e4117e7f715...
[7]: https://github.com/opencontainers/runc/issues?q=race+conditi...
[8]: https://github.com/cyphar/filepath-securejoin
Earlier quoted context omitted.
Lol. Should link the root though, plenty of suggestions for others: https://news.ycombinator.com/item?id=16117172
And no one thought of Focker written in F#?
Earlier quoted context omitted.
The joke that I think actually explains it pretty well is that it eliminates the "well it works on _my_ machine" problem, by not just shipping the code, but shipping the machine.
*shipping the userland It's not the equivalent of handing over a VM image. You're still open to unintended sensitivity to kernel versions, for instance.