Use of containerd-shim in docker-architecture

[Sridarshan Shetty]

I'm still trying to warp my head around why containerd-shim is used in docker architecture. Can someone please help me with that?

I noticed that, for exec and start, containerd communicates through shim, but for other operations (list, ps), containerd directly invokes runtime. Why?

And, does the runtime need to be alive for the duration of container? (when the container was running, ps aux |grep runc, did not show anything)

[Michael Crosby]

The shim allows for daemonless containers.  It basically sits as the parent of the container's process to facilitate a few things.  

First it allows the runtimes, i.e. runc,to exit after it starts the container.  This way we don't have to have the long running runtime processes for containers.  When you start mysql you should only see the mysql process and the shim.  

Second it keeps the STDIO and other fds open for the container incase containerd and/or docker both die.  If the shim was not running then the parent side of the pipes or the TTY master would be closed and the container would exit.  

Finally it allows the container's exit status to be reported back to a higher level tool like docker without having the be the actual parent of the container's process and do a wait4.  

I did a talk on this last week at dockercon US.  You can see my slides here.  https://github.com/crosbymichael/dockercon-2016

Hopefully that will explain a little more about how containerd and the shim work. 

--
You received this message because you are subscribed to the Google Groups "docker-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to docker-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-----------------------------------------

Michael Crosby

@crosbymichael

[Sridarshan Shetty]

Thanks a lot Michael. For anyone looking at the slides, here is a link to the talk.