Amazing work 👍 and I have tested this, it's really awesome.

This make daemon hot upgrade possible and make engine with high availability. I think this also need the libnetwork to restore the old running container network settings. I create an issue #moby/libnetwork#975. I make some progress to support this https://github.com/coolljt0725/docker/tree/containerd-integration-network, it can work.

Ping @chanwit: I know you've been experimenting with containerd and we'd love to have your feedback!

This is wonderful.

Read the code and not sure I'm understanding it correctly.

This PR is replacing the execdriver with containerd, but I am expecting containerd to be working in parallel with the current implementation.

WDYT?

@chanwit There is a --containerd= option in the daemon if you want to use external containerd. If not then docker will start one for you(and shut down if needed).
edit: you probably meant "parallel with current execdriver implementation". Execdrivers are supposed to be replaced by different oci compliant binaries.

@tonistiigi Maybe I couldn't explain it clearly. What I meant is that execdriver and containerd are at the different abstraction.

execdriver is the umbrella for both libcontainer (native) and containerd for example.
To make it has both direct libcontainer implementation along with containerd, maybe it's better to have this containerd patch being under the execdriver rather than replacing it.

W00000000t! Great work all!

Congratulations! 🎆

🎉

Congrats!

🎉

😺

congrats! ㊗️

gg, hope migration/update will be smooth

Does this require runc and containerd pre-installed on the host now, before the daemon is usable?
Or do you bundle them together in some way?
Thinking about ARM support and kubernetes-on-arm

@luxas Yes it does.

However, the docker packages will bundle all necessary binaries. So if you're using our packages they'll be automatically installed.

If you build directly from master, you can copy the generated binaries from the image generated by make build or build your own using the same commands that can be found in the Dockerfile.

I'm currently working on a follow up PR that will be adding the binaries to the packages.

I'll also be working on adding all of the binaries to the tar files that we provide so that you will be able to download a tar bundle with all required binaries.

congrats! amazing work!

hi @tonistiigi or other docker maintainers, since related docker contribution docs not updated. I tried

root@bf86488287ac:/go/src/github.com/docker/docker# cp bundles/1.11.0-dev/binary/docker /usr/bin/
root@bf86488287ac:/go/src/github.com/docker/docker# docker daemon -D
DEBU[0000] docker group found. gid: 999
DEBU[0000] Listener created for HTTP on unix (/var/run/docker.sock)
FATA[0000] Failed to connect to containerd. Please make sure containerd is installed in your PATH or you have specificed the correct address. Got error: exec: "containerd": executable file not found in $PATH

Do I need to download containerd and install on my test container env ?

@HackToday I think so, they are separate binary, you need install containerd containerd-shim runc, the Dockerfile has show how to install them(see https://github.com/docker/docker/blob/master/Dockerfile#L252 and https://github.com/docker/docker/blob/master/Dockerfile#L262)

@tonistiigi

Do you mind if I ask why the other execdriver was purged in a single minor version release of Docker? LXC died after at least 2 years of support, and now we've nixed libcontainer in a single patchset? I don't understand the reasoning behind such a sudden switch, it's bordering on harmful (containerd is listed as "alpha quality software" -- so now distributions have to package self-proclaimed alpha quality software in order to keep up with upstream!). I mean, the 1.10 image manifest migration wasn't great either, but come on, we're better than this.

hi @coolljt0725 and @tonistiigi I am not sure if it is good practice for that, I assume if we introduce such change, it would be better to add developer support, like
https://docs.docker.com/opensource/project/set-up-dev-env/
should keep updates in master branch, we means, developers can know what special build to do and what special binary need to install with.

To me, it seems not friendly to developers. Unless I miss something in master branch doc.

@HackToday

I think they are working on docs, it should come soon I guess.

#20662 (comment)

Documentation will come in a followup PR as agreed with @thaJeztah.

I have removed old built image dry-run-test. and run docker build -t dry-run-test . again, and find that image can work now, start docker, and docker would start containerd by itself. Maybe it was old image issue, but anyway, it would be better to have a doc related about containerd, how docker call it etc, which could help more devlopers to understood and debug. Thanks

@cyphar We're not removing libcontainer, we're adding a new process boundary in between. Containerd is obviously not alpha anymore, but you're right we should update the README accordingly.

@icecrime Correction, 3 process boundaries (containerd, containerd-shim and runc). The point is that the native execdriver has been removed in a single minor version release -- that's not how stable software operates. You don't just rip out a subsystem in a single release.

@cyphar Can you please explain what is the user-facing breaking change?

For package maintainers, we now have to maintain 2 more packages (containerd and runc) which have non-trivial interactions between each other. Sure, users won't notice anything happen unless the new and shiny (three) levels of indirection break (which will happen). The issue is that if someone wants to use 1.11, but containerd breaks, there's no recourse to use the old native execdriver. I'm also not convinced of the perceived benefits, but that's a separate issue.

Also, "what is the user-facing breaking change" is not the only relevant question. There are also questions about maintainability that need to be considered before core components are removed.

I was hoping that we could retain the execdriver abstraction too at least for 1 release so we can roll this out and test it slowly on a few applications instead of having to test it on a few nodes.

User will not see any changes, but operators of large cluster probably will :p