5 ms·

This is great. I really wish the container boom started with a more Unix philosophy around containers; package "images" as a tarball, run the container with a w

This is great. I really wish the container boom started with a more Unix philosophy around containers; package "images" as a tarball, run the container with a wrapper like runc. The container inherits Stdout, Stderr, Stdin, etc. You can pipe the output to log aggregation, etc. Small, sharp, reusable tools. Containers should just be the new static binary. Instead, we have Docker "Daemon"'s that can crash.

cyphar 9y ago
I'm one of the runc maintainers, and have been thinking a lot about how to create a new runtime from scratch. Despite a lot of flaws, runc's daemonless design is something that we did that was the right decision. However, I've also been thinking about ways to defend against hostile containers. And it turns out that a lot of the tricks you need to do are very hard if you don't use a daemon and are impossible if you don't want to pollute the host namespaces. I've spoken to Vish (the author) and we'll see if we can include some of my architecture reworks into railcar or if I'll go off and do my own thing. Oh, and by the way, if you like runc's design you should probably go look at rkt. I'm planning on putting in the work to make rkt work without systemd, but the really nice thing about rkt is that it's architecture is also completely daemonless.
- e12e 9y ago
  I'd be curious if you could share some thoughts on lxd/lxc - Canonical's foray into containers?
  - cyphar 9y ago
    I'm actually good friends with a couple of the maintainers of lxc/lxd :P. It's not really fair to call it "Canonical's" -- it existed before the lead developers started working for Canonical and it still gets plenty of contributions from outside of Canonical. lxc and lxd have quite a large amount of very interesting technology and features. lxd has live migration and a whole host of other cool features, and lxc is quite well designed from my experience. Also the developers are quite clever folks IMO. I've been bouncing some of my ideas for a new container runtime off them, since they also have seen the issues I've seen with the current state of things. The big difference is that lxc/lxd is designed to "boot" an operating system as a container, not just to run a single application. While there is actually no significant technical difference between the two usecases, the features that have grown out of each runtime are tailored for those usecases. lxc lets you log into a console (in the same way you would on a physical box) and do a full getty login. runc has tools for managing containers in a far more "micro-service" sense. I really wish that the lxc folks had helped us with the OCI, but I have a feeling their usecases are so different to us that it's unlikely we could reach agreement in the spec. Overall though, lxc definitely has a place and it's a shame more people don't try it out.
mkj 9y ago
Maybe you could even make them run out-of-the-box like a static binary, using binfmt-misc https://www.kernel.org/doc/Documentation/admin-guide/binfmt-misc.rst https://www.kernel.org/doc/Documentation/admin-guide/binfmt-...
- cyphar 9y ago
  You don't even need binfmt_misc. Jessie Frazelle wrote a PoC that did this by embedding the image and runtime into one static binary. https://github.com/jessfraz/binctr https://github.com/jessfraz/binctr

cyphar 9y ago

I'm one of the runc maintainers, and have been thinking a lot about how to create a new runtime from scratch. Despite a lot of flaws, runc's daemonless design is something that we did that was the right decision. However, I've also been thinking about ways to defend against hostile containers. And it turns out that a lot of the tricks you need to do are very hard if you don't use a daemon and are impossible if you don't want to pollute the host namespaces. I've spoken to Vish (the author) and we'll see if we can include some of my architecture reworks into railcar or if I'll go off and do my own thing. Oh, and by the way, if you like runc's design you should probably go look at rkt. I'm planning on putting in the work to make rkt work without systemd, but the really nice thing about rkt is that it's architecture is also completely daemonless.

e12e 9y ago
I'd be curious if you could share some thoughts on lxd/lxc - Canonical's foray into containers?
- cyphar 9y ago
  I'm actually good friends with a couple of the maintainers of lxc/lxd :P. It's not really fair to call it "Canonical's" -- it existed before the lead developers started working for Canonical and it still gets plenty of contributions from outside of Canonical. lxc and lxd have quite a large amount of very interesting technology and features. lxd has live migration and a whole host of other cool features, and lxc is quite well designed from my experience. Also the developers are quite clever folks IMO. I've been bouncing some of my ideas for a new container runtime off them, since they also have seen the issues I've seen with the current state of things. The big difference is that lxc/lxd is designed to "boot" an operating system as a container, not just to run a single application. While there is actually no significant technical difference between the two usecases, the features that have grown out of each runtime are tailored for those usecases. lxc lets you log into a console (in the same way you would on a physical box) and do a full getty login. runc has tools for managing containers in a far more "micro-service" sense. I really wish that the lxc folks had helped us with the OCI, but I have a feeling their usecases are so different to us that it's unlikely we could reach agreement in the spec. Overall though, lxc definitely has a place and it's a shame more people don't try it out.

mkj 9y ago

Maybe you could even make them run out-of-the-box like a static binary, using binfmt-misc https://www.kernel.org/doc/Documentation/admin-guide/binfmt-misc.rst https://www.kernel.org/doc/Documentation/admin-guide/binfmt-...

cyphar 9y ago
You don't even need binfmt_misc. Jessie Frazelle wrote a PoC that did this by embedding the image and runtime into one static binary. https://github.com/jessfraz/binctr https://github.com/jessfraz/binctr