Docker Engine on Windows

By | August 29, 2017

I’ve recently added a “Docker Engine” chapter to my Docker Deep Dive book. When I was writing it, I realised I didn’t know that much about how it implemented on Windows.

Anyway, here’s a bit of what I’ve learned…

At a pretty high level, the Docker Engine is a modular beast that’s currently made up of 4 components:
1. The client (arguably not part of the engine)
2. The daemon
3. containerd
4. OCI compliant runtime (E.g. runc)

Well, that’s how it is on Linux. It’s a bit different on Windows.

On a Windows system, the containerd and OCI parts are replaced by a Microsoft layer called the Compute Service layer.

To cut a long story short, Microsoft was working hard implementing containers in Windows at the same time that Docker was refactoring the engine and implementing OCI stuff. Had the timings been different, Windows would probably have implemented containerd and an OCI runtime (my own personal opinion – I do not speak for either Docker or Microsoft).

Q: Is the difference a big deal?

A: No.

Q: Why not?

A: Because the Compute Services layer does pretty much exactly what containerd and OCI layer do. As a user you’d never know the difference.

Container runtime

The job of the OCI layer (E.g. runc) is to interface with the kernel constructs that we use to build containers. These are things like namespaces and control groups. The OCI layer does this on Linux, the Compute Services layer does it on Windows. Simple.

There are a growing number of OCI runtimes available. runc is the reference implementation and also the default runtime that ships with Docker in Linux. However, other OCI runtimes do exist!

Container supervisor

containerd does all the container life-cycle and supervision stuff for Docker on Linux. The Compute Services layer does it on Windows. Simple.

I see no reason why containerd could not be implemented on Linux and Windows with feature parity. On each platform it would make calls to the OCI layer to actually interface with the kernel (Windows or Linux) and build containers. Once the containers are built containerd would then take-ver the job of running them.

A picture

The following picture might be useful:


The full Docker Deep Dive book is available on Amazon. It’s bang-up-to-date.

UPDATED 30th Aug 2017: To add clarity following Manuel’s comments. Previously the article made some references to runc when it should have more broadly referenced the OCI layer. Thanks to Manuel for pointing this out.

6 thoughts on “Docker Engine on Windows

  1. Manuel Patrone

    Hello Nigel,
    I have not looked at the code of either but… given that both runc and containerd interact with kernel primitives… how come would you expect those to be implemented in Windows? I guess we could have two building blocks with similar names but with rather different implementations. Am I totally off the mark here?

  2. Manuel Patrone

    Totally off the mark as far as containerd is concerned…. 🙂

  3. Nigel Poulton Post author

    Great, this is where we need to open the conversation….

    First up, looking back at my article (I’ll update it) I’d intended to say Windows could use containerd and an OCI runtime. I have the bad habit of referring to runc in the Docker stack when I really should be referring to the runc stuff as “the OCI layer“. So thanks for the clarification on that.

    Anyway….. back to the conversation. I believe I’m correct in saying that runc is the wrapper around libcontainerd that interfaces with the kernel primitives. Therefore, containerd calls out to runc to actually build the container. containerd then runs it (lifecycle and supervision stuff).

    I also believe I’m correct in saying that containerd aims to have full parity between Linux and Windows container support. And that it will be able to compile directly onto Windows. In this situation, containerd can replace part of the Compute Service layer on Windows and call out to an OCI runtime (See I’m getting better already :-D) to interface with the Windows kernel and build the container.

    So…. my opinion is that it should be entirely possible for the Compute Services layer to be replaced in Windows with containerd + OCI compliant runtime.

    Feel free to reply back, I’m all about having conversations in the open like this – even if I’m sometimes terrible at realising someone’s posted a reply.

  4. Nigel Poulton Post author

    @Manuel. I love this response about me being totally off the mark re containerd!!! 😀

    Please elaborate.

  5. Manuel Patrone

    No, no, no. I meant to say that I’m the one that was totally off the mark as fat as containerd is concerned. Totally agree with you… sorry for the misunderstanding. Cheers

Leave a Reply

Your email address will not be published. Required fields are marked *


You can add images to your comment by clicking here.