RailCar: Rust implementation of oci-runtime | Hacker News Reader

RailCar: Rust implementation of oci-runtime

github.com

99 pointsalexellisuk23 comments

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.

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.

I'd be curious if you could share some thoughts on lxd/lxc - Canonical's foray into containers?

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.

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-...

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

There was a blog post from Oracle describing this project last week: https://blogs.oracle.com/developers/building-a-container-run... , and a corresponding reddit thread with the author's participation: https://www.reddit.com/r/rust/comments/6kaexs/building_a_con...

You linked the same article twice, btw.

I think this was the reddit thread, https://www.reddit.com/r/rust/comments/6kaexs/building_a_con...

Ah, thanks. :)

For context, some people at Oracle want to use containers but they don't want to use layers, overlayfs, or "docker pull": https://blogs.oracle.com/developers/the-microcontainer-manif...

I guess this project is perfect for them but it's probably a bit impoverished for other people.

I would think Oracle could afford a copy editor for their world-facing communications. That post could use a once-over by a competent editor.

That said, the complaints they have about Docker are extremely valid. I've been grumbling about them for years. Though some of their solutions seem clunky. The /read, /write and /run directories seem...weird, at best.

Containers are in significant use across Oracle, and there has been a strong focus from the Oracle Linux team to provide full support of Docker, including on Oracle Linux 6, for those that aren't in a position to upgrade to OL/RedHat/CentOS 7.

OCI = Open Container Initiative

(I think. I wish the README would have made that more clear.)

Yes, that's correct.

Thanks. I'd assumed it was Oracle Call Interface (OCI), the C API for Oracle DB...

i will update the readme to clarify that, thanks

It's always good to see more development in this area. Here's hope the runtimes become as rock solid as they should have been in the first place (given their central role in the container story).

I can't help but notice the UPL license is an odd choice. The whole thing about contributors granting patent licenses.. isn't that a legal minefield?

Both Apache-2.0 and [L]GPLv3 have patent licensing clauses as well. Patents are a more general problem that you cannot solve with just a license, but patent license clauses avoid patent treachery[1] by construction -- as long as you can trace back your copy of the software to a patent holder then the patent cannot be used against you. This is obviously not ideal, the ideal solution would be to eradicate the concept of software patents entirely, but as far as legal hacks go this is as good as you can get.

Patents are a legal minefield (for users) whether or not your licenses talk about them (though licenses that remain silent about patents open you up to patent treachery) because of the laws that surround them (independent discovery is not protected). As for patent holders, they simply are not allowed to both distribute software under those licenses and harass users of said software using patents contained in the software. I think that's more than a fair trade (in fact, the scales are tipped in their favour because they can still sue you if someone else independently discovers something they patented).

[1]: https://www.gnu.org/licenses/license-recommendations.html#sm... -- In particular `[...] it does prevent patent holders from setting up a “bait and switch” where they release the software under free terms then require recipients to agree to nonfree terms in a patent license.`

Thank you, that was very informative.

Author here. I missed that this hit hacker news. Happy to answer any questions if people are still lurking.

An a-class company (size/influence wise not niceness) like Oracle adopting Rust is quite big news!

It is. The same author is writing quite a bit of Go in Oracle Github organization. I think Java/JVM is going to be less relevant in containerized applications and systems.

Reply on news.ycombinator.com