
Containerd – An open and reliable container runtime, by Docker - e-sushi
https://github.com/docker/containerd/
======
thockingoog
To my eyes, this signals that Docker hears the complaints from systems like
Kubernetes that want to build on top of docker, but don't want all the Docker
platform stuff.

Layering matters, and Docker seems to be offering a solution that is Docker
compatible but more usable by layered systems.

Devil's in the details, of course, but this seems like what our customers want
- docker but not Docker.

Disclosure: Kubernetes dev

~~~
chrissnell
As a Kubernetes user who's been running 500+ containers in production for a
little over a year now, my chief complaint is not the Docker platform stuff,
it's the reliability of Docker itself. We've suffered through a number of bugs
that cause node instability and lock-ups and some of the underlying issues
have been open for close to a year.

I don't think that this is the exact bug for our issue but it's closely
related:

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

I really want to give rkt a shot but our tooling investment in Docker is huge.
I want to wait and see what the runtime ecosystem looks like in another 6
months before considering a switch.

~~~
cpuguy83
Recent versions (1.11+) have had various race conditions around stdio
handling. 1.12.4 (fingers-crossed) should resolves all the issues we've come
up to at this point (hopefully that's it).

The rest of the lockup issues have been related to kernel bugs which would
also be observed with other tools. One major issue we've had (which is really
multiple kernel issues with multiple causes) is netlink (a kernel interface)
not responding and the container's mutex is held forever while we wait on
netlink. The locking up part should be resolved in 1.12.4 for this as well,
where it uses a timeout on the netlink socket... still going to have errors
from this since if netlink isn't responding there's something else weird
happening, but at least the container mutex can be released you can interact
with the daemon.

In 1.14 we should have a lock-free container object so that any new issues
that come up in this regard are isolated to a particular thread. This makes
detecting that there is an issue harder, but something we could potentially
track and even report on.

 _note_ that the daemon isn't really locking up fully, just that any command
that tries to lock the container's mutex will get stuck, which includes
listing it in `docker ps`, start/stop/restart/etc on that particular
container.

~~~
chrissnell
The netlink not responding issue sounds like the one we've been battling. Now
we just have to wait for a CoreOS release with 1.12.4.

------
andrewguenther
Docker has been running on top of containerd since 1.11. This isn't really
news.

Previous discussions:

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

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

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

~~~
charlieegan3
I think this is the actual news: [https://www.docker.com/docker-news-and-
press/docker-extracts...](https://www.docker.com/docker-news-and-press/docker-
extracts-and-donates-containerd-its-core-container-runtime-accelerate)

> Docker today announced that it is spinning out containerd, a core component
> of Docker Engine, its industry-leading container platform, and donating it
> to a new community project.

Press release linked to from: [https://blog.docker.com/2016/12/containerd-
core-runtime-comp...](https://blog.docker.com/2016/12/containerd-core-runtime-
component/)

~~~
justincormack
Also containerd is going to have more stuff added - image management from the
OCI image spec for example. Not a lot of stuff, but all the key runtime parts,
see the Scope section for what is in and out.

~~~
thockingoog
yeah, this is key. It looks like JUST enough to be useful without the rest of
the Docker engine.

------
ainiriand
I love how amazingly this name ends in nerd. Ok, I'll show my way out...

~~~
Royalaid
This was all I could see too

------
binocarlos
I think this is a smart move by Docker. The experience of docker-compose for
local development is sublime. The option to deploy that local stack to any
number of schedulers but with the same core container runtime feels like the
right kind of prod-dev parity. Choice being the main point I'm making.

------
asb
Can anyone contrast this new (rebooted?) containerd to rkt?

------
jwildeboer
A "new" sytemd for containers? #sarcasm

Disclosure: Red Hat Evangelist.

~~~
mohanmcgeek
Tbh, _this_ is what would let you better use systemd to manage your
containers. It's a container runtime. Not an init system

------
nunez
If I'm reading this right, this seems like a really interesting and possibly
lighter-weight alternative to Packer + Kubernetes. I like this and will give
it a whirl.

~~~
charlieegan3
This is a different thing really. It's a container runtime used under the hood
by Docker; rather than a container orchestrator.

I know this is for rkt but it gives a good comparison of container runtimes.
[https://coreos.com/rkt/docs/latest/rkt-vs-other-
projects.htm...](https://coreos.com/rkt/docs/latest/rkt-vs-other-
projects.html#rkt-vs-containerd)

------
jwildeboer
Totally unrelated. Totally. Pure coincidence. Really. ;-)

[https://github.com/kubernetes-incubator/cri-o](https://github.com/kubernetes-
incubator/cri-o)

