Docker on Windows: State of Play

By | November 17, 2015

Just a few *very quick* and typo-riddled thoughts on what I understand to be the state of play with containers on Windows. I’m basing this on a session I attended at Dockercon that had a John Starks from Microsoft talk about Windows and Cotnainer internals and also perform some demos.

First up….. it’s quite clear that the guys at Microsoft have done a shed-load of works to get things to where they are now. But the question is….. where are they now?

Hiding the mess

In my personal opinion… all of which could be totally wrong… is that there is a lot of fudging going on to make containers work on Windows.

For example, there’s this shim layer in between the Docker execution and the API interfaces into the Windows kernel. My understanding is that this is because a ton of the internal Windows stuff is gonna change over time – so why bother exposing all of the internal if you know they’re gonna be majorly rewritten soon. And that says to me that they’re doing a bunch of tactical stuff today. Probably in order to ship soon (soon in MS timescales).

Heavy containers

Kind of related… a shiny new Windows container will have a bunch of processes running inside.

The demo at Dockercon showed a couple of Windows containers – each running 19 processes – and both were on a base Windows container without an app running. This is glaringly different from a Linux container that usually has a single process. And I believe I’m right in saying that some of those 19 processes are *spare processes* for the container to use when it needs to create new ones…. Coz apparently it’s not possible to create a new process from within a container running on Windows – something to do with having to make RPC calls back to the host in order to perform certain basic system services (kinda like syscalls).

How does Windows build a “Container”?

Internally Windows has the notion of a “job”…. a collection of processes and resources those processes are using. To create a container, Windows takes this “job”, injects it with steroids, and calls it a “silo”. Think of a “silo” as a container. These “silo’s” get a bunch of namespaces and restrictions etc that aren’t too dissimilar to Linux namespaces and cgroups. E.g. Object namespaces are used to give each container (silo) its own C: drive.

Union filesystems

Not surprisingly, the way the native Windows filesystem (NTFS) works doesn’t make it easy to implement a union filesystem.  That’s not surprising considering the age of NTFS.  Though let’s not forget that AUFS never made it into the mainline Linux kernel – too many patches and too much of a mess.  So no disrespect to MS there.

What I did find surprising though was that there’s apparently nothing in the Windows storage stack that resembles device-mapper snapshots. Or I’m assuming there isn’t, as this would surely have been an option as a graphdriver – lets not forget that back in the day Red Hat wrote the devicemapper storage driver (graph driver) for Docker on Linux coz they couldn’t go with AUFS.

Anyway… MS has a workaround. I understood this to be a virtual block device on top of NTFS with symlinks. My *guess* is that this is not too dissimilar to Docker Linux using OverlayFS – a single writeable container layer on top of an image layer that is a bunch of directories with hard links. Don’t get me wrong here…. even if I’m right with my assumption you shouldn’t take the comparison too far (I do know that OverlayFS doesn’t deal with blocks etc).

Windows base images

Also…. every Windows Docker image will have to be built off one of two official Windows base images – Windows Server Core, or Windows Nanoserver.  And check this out…. for legal reasons neither can be hosted on Docker Hub!

Oh dear…. talk about politics getting in the way of engineering and innovation. C’mon Microsoft you’re doing so well!

On a side note, it does seem that Nanoserver is seen by MS as the default server platform to build against in the future. Makes sense to me as it seems like it’s gonna be a real server OS and not a desktop OS dressed up to look like a server OS.

Hyper-V containers

OK so Hyper-V contaienrs work like this – On a Windows server you spin up a Hyper-V container.  Windows then spins up a lightweight Hyper-V VM (sorta like boot2docker) and runs the container inside the Hyper-V VM. It seems to be a 1 Hper-V VM <> 1 container model.

Hyper-V containers also seem to be the direction that MS are going for folks who wanna run Windows containers on their laptops – basically saying Windows 10 won’t be offering native container support. Suppose this isn’t too different to boot2docker.

Final thoughts

All in all…. I was kinda disappointed. I’d genuinely hoped the implementation would’ve been cleaner. Though I don’t want to take away from the great work being done at MS. And let’s not forget that namespaces and the likes didn’t land in the Linux kernel overnight (not by a long-shot).

DISCLAIMER: Like I said at the beginning….. I reserve the right to be wrong about every single thing I’ve said above. It was the last seesion of DockerCon and my brain was dumping unwanted memories as fast as it could in order to take in more of what was being said… sadly my grey matter didn’t keep up as well as I’d have liked 😀

NOTE: I’ll add some pics later.

7 thoughts on “Docker on Windows: State of Play

  1. Edward Grigson

    Nice post. I was also at the session and noted the same issues – it’s clearly early days for Windows containers. I actually like the fact they’re sharing internals, even if they’re not perfect – it marches the ‘new’ Microsoft under Satya.

    It’ll be interesting to see licencing and pricing information (due this year apparently – not much time then) and whether that will pose another challenge as Nano needs to compete with ‘free’ Linux containers without sabotaging existing MS revenue.

  2. Nunix (hoxunn)

    indeed, thanks a lot for sharing a more detailed experience than in Twitter 😉
    Actually, while chatting yesterday it stroke me, and sorry I will go in a tangent: are containers the next big “piracy” thing also?
    Yes, big phrase here, but if you think about BitTorrent how it has been “distorded” from its original purpose, I would only guess that Pirate registries will grow like mushrooms no?
    With that in mind, current monolithic apps without “online licensing verification” are weaker than ever: I install the app on my container, save the image in my “private” registry and I just wait for the pulls.
    And above that, it comes to what you cited from Microsoft: “for legal reasons neither can be hosted on Docker Hub!”
    This means that in the future, I can have a nano server with a container Core? (guessing the later is more expensive)

    Hopefully, in the long run I’m totally out of my mind and Docker/Container won’t be seen as BitTorrent.
    Please “bash” me if you think I’m totally out, if so I will buy this great course we see in Pluralsight about Docker 😉

  3. Nigel Poulton Post author

    Yeah I see a lot of positives about Microsoft these days – the Satya affect is all positive so far IMO. Though the existence of the Windows cash-cow is gonna be hard to deal with. It’s certainly gonna be interesting to see how it pans out.

  4. Nigel Poulton Post author

    Hmmmm that’s an interesting point you make about pirate registries. I suppose all technology can be used for good stuff and bad stuff. I’m just not so sure I see the appeal *yet* for pirate container registries. I reckon – and could be totally wrong here – that pirating is more of an indivudal/consumer thing. I’m not sure it’s so rife in companies and enterprises. For starters most companies need to be able to trust any content they pull from the internet. Docker Content Trust and the likes are important to enterprises IMO and pirate Registries go totally against that grain. Sure you might get a free copy of XYZ expensive software, but is it work the risks of what else you’re getting with it? Not sure I know many companies that would take that risk.

    Though I suppose the temptation is there for the consumer market to hide pirated software inside a container/image. Hmmmmmm…. I guess time will tell. An interesting point that I’d never considered before. I guess you’re just more criminally minded than me 😉

  5. Nunix (hoxunn)

    weeell … sorry for the Criminal mind 😉
    Concerning “containers” (not only Docker, I really mean it), I see it not only as an Enterprise technology, but consumers will (have to) embrace it in the very near future.
    there’s a video with MS Jeff Snover trying to already discourage Admins (read Dev for the moment) to consider containers as applications packagers.
    While a valid point imo, why would someone go to lengths of knowing and adding yet another layer when the container is all they need (again, didn’t saw the course, so I’m lacking several knowledge on the current Containers).

    Last bit, I work in Pharma world, and I DO totally agree with you that Enterprises will/should never trust containers from fishy registries.
    Actually, I do have even a bigger problem today: in Pharma we need to “validate” the softwares we bring in. This comes in the form of lengthy installation procedures and functional testing.
    with Containers, the ball game changes totally and I’m looking to validate it as an Appliance rather than pure software.
    Anyway, back to work, thanks again for the great insights and looking forward to the Podcast 🙂

  6. Nigel Poulton Post author

    Do you know about project Nautilus at Docker? Not a silver bullet, and may be not what you need when you talk about validating software…. but it’s gonna be a technology that integrate with Docker Hub (and presumably Docker Trusted Registry in the future) that will inspect images for known vulnerabilities etc.

  7. Nunix (hoxunn)

    thanks, I will have a look on what Captain Nemo have in store 😉
    It might be helpful indeed to at least have the security part covered. There will still be a need for validating all the functional aspect of the app containerized.
    And again, great podcast -> I’ll try to take on the challenge of Office in Windows container (not docker sorry).

Leave a Reply

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


You can add images to your comment by clicking here.