
RunC – A lightweight universal runtime container, by the Open Container Project - tlrobinson
http://runc.io/
======
waffle_ss
It's not mentioned on this page, but these runc containers will also run on
Windows[1], which is pretty amazing.

Not having to run the Docker daemon will also be pretty nice. Currently when I
upgrade Docker, all containers have to be restarted on the host due to the
daemon dependency. So to maintain uptime with Docker containers currently you
better be running your stuff clustered (e.g. via Mesos/Marathon).

Standalone containers was something I felt rkt (alternate container format
from CoreOS people) got right, so nice to see it carrying over here through
the collaboration.

[1]:
[https://twitter.com/docker/status/613039532422864896](https://twitter.com/docker/status/613039532422864896)

~~~
mmastrac
Is it spinning VirtualBox up in the background or virtualizing syscalls?
That's the interesting question.

~~~
nickstinemates
Neither, Microsoft is creating the equivalents (and more) in the Windows
Kernel in the next version of Windows Server and contributing the api
compatibility to runC

~~~
geertj
This would for running a Windows container, I assume?

Microsoft implementing the Linux system call ABI, now that would be truly
amazing. I guess it's possible (FreeBSD does some of this), but I guess this
is not that?

~~~
nickstinemates
Yes, this is for windows specific workloads. Not the ability to virtualize the
Linux ABI in Windows. That's what VMs are for.

------
advanderveer
This is by far the most important announcement of the Keynote, it really shows
that Alex (CoreOS) and Solomon (Docker) managed to come together and create
this as part of a new open standard.

If there is ever gonna be a page in some book that covers server software
development, I believe it will tell about this standard.

------
api
What we're seeing emerge here is a new universal binary format.

I've thought of Docker containers for a long time as gigantic statically
linked binaries. This isn't necessarily a bad thing (though it does present
issues). In some ways the process of installing the different moving pieces of
a service and configuring them is a bit like manually "linking" something --
sub-services like MySQL, Redis, etc. are analogous to libraries.

Now what we're seeing is a runtime for this binary being ported around to
different platforms. This could get interesting.

~~~
toomuchtodo
> Now what we're seeing is a runtime for this binary being ported around to
> different platforms. This could get interesting.

With x86 being the primary server/workstation workhorse (lets exclude mobile
platforms for the moment), is all of this abstraction necessary? Doing
Infrastructure and DevOps, I definitely see the benefit of containerization
for build reproducibility and decreasing the friction developers face for
running applications locally as they run in production.

Not everyone needs Borg/Mesos/Mesosphere. Not everyone needs containerization.
When you have a hammer though, everything starts looking like a nail.

~~~
alexchamberlain
I bet they all use HTTP to communicate too... Seriously though, I tend to
agree, could this be solved by using more static binaries?

~~~
XorNot
A return to statically linkable glibc would be a good start on that. It's
definitely the weakest link in the chain (as in, the only thing which a pulled
in cgo dependency tends to start complaining about).

------
JackdawX
Sometimes, posts like this appear on hacker news that are completely
impenetrable. I read the page for RunC and the only thing I could find out
about it from that page is that it is a "Container", and these are its specs.
A "Container" is something that is used by "Docker". "Docker" is a program
that "allows you to compose your application from microservices". A
"microservice" is "a software architecture style, in which complex
applications are composed of small, independent processes" (we're down to
wikipedia at this point). So a "microservice" is an abstraction of unix
design, and finally we're on solid ground. If you were interested you might be
able to work backwards through this list of projects, researching what each
one does, and then you could find out what RunC actually is.

~~~
parasubvert
The unstated assumption of this announcement is that if you haven't heard of
Docker, you may have been living under a rock. It arguably has more hype after
two years than Java did in 1996-97.

The other part of the problem is that this is a rapidly evolving space with a
ton of money and attention being pored into engineering and competitive
battles playing out, and not so much in the marketing and clear explanations.
runC is in part a symbolic "bury the hatchet" moment for a public feud over
standards with CoreOS and others that began in December 2014. If you haven't
been following the inside baseball, it it's all kind of confusing.

------
Animats
It's written in Go.

Another key bit of infrastructure moves to a safer language.

 _" This is not the end. It is not even the beginning of the end. But it is,
perhaps, the end of the beginning."_

~~~
AaronFriel
You might be overstating the "safer language" aspect. As another commenter
suggests, they are using Go as little more than glue to the C or C++ kernel
and libraries that run the important bits. And these searches should instill a
bit of fear in your heart when running Docker:

[https://github.com/docker/docker/search?utf8=%E2%9C%93&q=uns...](https://github.com/docker/docker/search?utf8=%E2%9C%93&q=unsafe)

[https://github.com/docker/docker/search?type=Code&utf8=%E2%9...](https://github.com/docker/docker/search?type=Code&utf8=%E2%9C%93&q=pointer)

Docker has such prodigious and repeated use of "unsafe" that it makes one
wonder what, if anything, using Go has bought them in terms of safety or
reliability? It seems like virtually every interface used in the Docker source
code relies on unsafe casts to pointers, and I hesitate to say I am not sure
how well the Go garbage collector meshes with casting pointers and providing
them to the kernel and other libraries.

Something like Rust's native ability to ensure a pointer provided to external
code lives long enough would be very useful.

------
praveenster
"[https://runc.azurewebsites.net"](https://runc.azurewebsites.net") "Copyright
(c) 2015, Linux Foundation"

Interesting times …

~~~
davexunit
Terrible. This website also promotes proprietary software right on the home
page. The Linux Foundation really doesn't seem to care about the "free" part
of FOSS anymore.

~~~
fleitz
Perhaps they are concerned with Linux and thus named themselves the LINUX
Foundation rather than the Free Software Foundation.

------
dubcanada
Speaking of containers I've always wondered if running a GUI app (something
like a kiosk) would work in these sorts of containers? I know you can do it
hackily in docker by playing with X and xfvb. But does any of them natively
(easily) support it?

~~~
tlrobinson
Yes, you basically just have to mount the X11 socket as a volume:
[https://blog.jessfraz.com/post/docker-containers-on-the-
desk...](https://blog.jessfraz.com/post/docker-containers-on-the-desktop/)

~~~
eropple
As discussed in the HN thread, this is dangerous and counterproductive to
security. It should not be encouraged.

[https://news.ycombinator.com/item?id=9086751](https://news.ycombinator.com/item?id=9086751)

~~~
zokier
Correct me if I'm wrong, but shouldn't Wayland fix these kinds of security
issues in X?

~~~
eropple
That's my understanding, but I think that's a ways off.

------
craneca0
What does this mean for rkt?

~~~
riquito
From their latest blog post

[https://coreos.com/blog/app-container-and-the-open-
container...](https://coreos.com/blog/app-container-and-the-open-container-
project/)

> CoreOS remains committed to the rkt project and will continue to invest in
> its development. Today rkt is a leading implementation of appc, and we plan
> on it becoming a leading implementation of OCP. Open standards only work if
> there are multiple implementations of the specification, and we will develop
> rkt into a leading container runtime around the new shared container format.
> Our goals for rkt are unchanged: a focus on security and composability for
> the most demanding production environments.

------
gtirloni
It's a little difficult to keep track of all the activity happening in the
container area. The runC repo's history begins in June 2014? I believe rkt was
announced in Dec 2014, right?

~~~
Alupis
> I believe rkt was announced in Dec 2014, right?

Yes but even ACI and Rkt were being worked on months before the announcement.

~~~
robszumski
It was just a week or two before the announcement. You can see the commit
activity here: [https://github.com/coreos/rkt/graphs/commit-
activity](https://github.com/coreos/rkt/graphs/commit-activity). The earlier
blips are standard license files and other boilerplate from a project template
used for new repos.

~~~
Alupis
You could be right, I seemed to recall it was started in July. They did move
repos around a few times and eventually split the ACI out of the Rkt repo, so
perhaps some history was dumped/re-written at some point.

------
wereHamster
What's the relation between RunC and the AppContainer spec?

~~~
advanderveer
Runc is the neutral implementation of the new open container standard that was
created with the Appc guys at the table. Although not stated explicitely, the
open standard will most probably supersede the appc spec

~~~
wereHamster
Was appc not open enough? Or unfixable? Why create yet another standard?

~~~
Alupis
> Was appc not open enough? Or unfixable? Why create yet another standard?

Based on history between Docker and ACI/Appc, I'd wager Docker didn't want to
fully submit to a standard they had zero input on (should note they elected to
have zero input, snubbed their nose at it, and declared their own "open"
standard).

It's likely this new standard was the CoreOS team compromising with Docker to
include them in the circle. Ultimately it will yield portable containers and a
better ecosystem. A big win for the community and users.

As has been said before, an Open Standard is far superior to an Open
Implementation.

~~~
chc
As far as I can tell, the Docker folks weren't consulted when CoreOS was
developing Rocket and App Container. They certainly seemed to be surprised
when it was announced.

~~~
Alupis
> They certainly seemed to be surprised when it was announced.

Yes they were, but they really should not have been. Docker had started with a
rough draft of an open specification, but then removed it. Every time the idea
was brought up, it was shot down. Docker viewed it as a strategic move to not
have an open spec that anyone could implement and use container images with.

However, with such a critical piece of technology, it was unreasonable to
expect no one else to want it to have a common standard format which could be
interchangeable with other container runtime implementations.

So I suspect the "surprise" was more "anger" than anything.

> As far as I can tell, the Docker folks weren't consulted when CoreOS was
> developing Rocket and App Container.

Right, they were not consulted prior to it's public release. However ACI was
an open standard and actively requested contributions to help shape it. ACI
was very early when it was released and needed implementations to help shake
out the bugs. At that point, Docker actively refused to participate, and
instead a week later cooked up their own "open" implementation which was
nothing more than rough documentation of how Docker behaves internally (not
something a person could write an implementation against).

Initially Docker staffers seemed excited to contribute, but it got shot down
quickly by shykes.

See these github issues:

[https://github.com/docker/docker/issues/9538](https://github.com/docker/docker/issues/9538)

[https://github.com/docker/docker/issues/10643](https://github.com/docker/docker/issues/10643)

And there was shykes' rampage when CoreOS made the initial announcement, which
began with this post:

[https://news.ycombinator.com/item?id=8683705](https://news.ycombinator.com/item?id=8683705)

So, it's not surprising that, fast forwarding to today, concessions had to be
made in order for Docker to save face and not appear to cave into public
demand for a standardized open format that no single for-profit organization
controlled entirely. Now both parties get good PR for working together and
settling their differences, and the community gets a truly open standard from
which, I expect, a great many implementations will arise.

------
bjt
The sample manifest at
[https://github.com/opencontainers/runc](https://github.com/opencontainers/runc)
makes it look like you just specify a big list of mounts, rather than it
supporting the higher level concept of overlayed layers that both Docker and
appc support.

Are layers not part of the opencontainers spec, or is the sample just missing
that bit?

~~~
shykes
That's correct, layers are not part of the spec. It's the caller's
responsibility to setup the container bundle (manifest + one or more rootfs
directories) so that runC can load it. _How_ that is done is not the concern
of runC.

This is by design: it turns out layers, as implemented by Docker, are not the
only way to download or assemble a container. The appc specification uses a
different, incompatible layer system. Many people like to "docker import"
tarballs which bypasses layers entirely. The next version of Docker is
gravitating towards pure content-addressable storage and transfer (a-la git),
possibly eschewing layers entirely.

runC is not concerned by _how_ you got a particular runnable object. It's only
concerned with its final, runnable form. The result is a nicely layered design
where different tools can worry about different levels of abstraction.

------
atonse
Great to see that AppC is joining too. That was going to be a weird splinter
otherwise.

------
haosdent
runC is libcontainer.....

~~~
andrewguenther
runC is a wrapper around libcontainer

