5 ms·

RailCar: Rust implementation of oci-runtime

99 points by alexellisuk 9y ago

wmf 9y ago
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-manifesto 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.
- SwellJoe 9y ago
  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.
- Twirrim 9y ago
  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.
kibwen 9y ago
There was a blog post from Oracle describing this project last week: https://blogs.oracle.com/developers/building-a-container-runtime-in-rust 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_container_runtime_in_rust/ https://www.reddit.com/r/rust/comments/6kaexs/building_a_con...
- sinistersnare 9y ago
  You linked the same article twice, btw.
- simcop2387 9y ago
  I think this was the reddit thread, https://www.reddit.com/r/rust/comments/6kaexs/building_a_container_runtime_in_rust/ https://www.reddit.com/r/rust/comments/6kaexs/building_a_con...
  - kibwen 9y ago
    Ah, thanks. :)
jimktrains2 9y ago
OCI = Open Container Initiative (I think. I wish the README would have made that more clear.)
- cyphar 9y ago
  Yes, that's correct.
- mkj 9y ago
  Thanks. I'd assumed it was Oracle Call Interface (OCI), the C API for Oracle DB...
- vishvananda 9y ago
  i will update the readme to clarify that, thanks
ejholmes 9y ago
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.
coldtea 9y ago
An a-class company (size/influence wise not niceness) like Oracle adopting Rust is quite big news!
- geodel 9y ago
  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.
gtirloni 9y ago
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?
- cyphar 9y ago
  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#small 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.`
  - gtirloni 9y ago
    Thank you, that was very informative.
vishvananda 9y ago
Author here. I missed that this hit hacker news. Happy to answer any questions if people are still lurking.

99 points by alexellisuk 9y ago

wmf 9y ago

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

SwellJoe 9y ago
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.
Twirrim 9y ago
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.

kibwen 9y ago

There was a blog post from Oracle describing this project last week: https://blogs.oracle.com/developers/building-a-container-runtime-in-rust 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_container_runtime_in_rust/ https://www.reddit.com/r/rust/comments/6kaexs/building_a_con...

sinistersnare 9y ago
You linked the same article twice, btw.
simcop2387 9y ago
I think this was the reddit thread, https://www.reddit.com/r/rust/comments/6kaexs/building_a_container_runtime_in_rust/ https://www.reddit.com/r/rust/comments/6kaexs/building_a_con...
- kibwen 9y ago
  Ah, thanks. :)

jimktrains2 9y ago

OCI = Open Container Initiative (I think. I wish the README would have made that more clear.)

cyphar 9y ago
Yes, that's correct.
mkj 9y ago
Thanks. I'd assumed it was Oracle Call Interface (OCI), the C API for Oracle DB...
vishvananda 9y ago
i will update the readme to clarify that, thanks

ejholmes 9y ago

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.

coldtea 9y ago

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

geodel 9y ago
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.

gtirloni 9y ago

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?

cyphar 9y ago
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#small 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.`
- gtirloni 9y ago
  Thank you, that was very informative.

vishvananda 9y ago

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