Porting Docker for Windows is no small feat. The technology behind Docker today takes advantage of Linux capabilities like namespaces and cgroups. For native containers to exist on Windows and to have a Docker Engine for Windows, first similar primitives needed to be developed into the Windows operating system. In this session we will explain these Windows primitives in relation to similar primitives in Linux and other architectural changes on the OS and Engine side to make containerization possible. The process of porting includes not only the technology but also open source community interactions and cultural changes to enable this development. And of course there will be a cool demo…

1. Windows Server Containers
John Starks
Principal Software Engineering Lead, Microsoft
Arnaud Porterie
Senior Engineering Manager, Docker

2. Agenda
Porting Docker
By the numbers
Technical details
Multi-arch images
Demo!
Title
Title
Title
Docker for Windows
What it is
What it’s not
Title
System architecture
Title
Title
Title

3. Docker for Windows
Understanding the basics

4. Docker for Windows
4
What it is
It’s Docker as you know it
Same user experience
It’s Windows as you know it
Complete environment inside the container
It’s native containers
Contained processes run on the host system
It’s available for testing

5. Docker for Windows
5
What it’s not
It’s not virtualization
Docker for Windows will not run Linux images
It’s not a different project / code base
The existing Docker tree was ported
It’s not quite finished
Required Windows Server 2016 (current TP4)

6. System architecture
Windows Server Containers internals

7. System architecture
7
Namespaces
Silo: extension of Windows Job object
Set of processes
Resource constraints
New: set of namespaces
New namespace virtualization
Registry
Process IDs, sessions
Object namespace
File system

8. System architecture
8
Object namespace
System-level namespace, hidden from users
C:Windows maps to DosDevicesC:Windows
Contains all device entry points
DosDevicesC:
Registry
DeviceTcp
Added “chroot”, one namespace per container
ContainersfooDosDevicesC:
ContainersbarDosDevicesC:

9. System architecture
9
Filesystem
Windows applications expect NTFS semantics
Transactions, file IDs, USN journal
Building a full union FS with NTFS semantics is hard
Hybrid model
Virtual block device + NTFS partition per container
Symlinks to layers on host FS to keep block devices small

10. System architecture
10
Base image
Public Windows API delivered via DLLs, not syscalls
Highly dependent on RPC to system services
FROM scratch
Windows images must derive from Windows base image
windowsservercore – large, nearly full Win32 compatibility
nanoserver – small, fast to boot, software may need porting
Base images are delivered separately from Docker

11. System architecture
11
Hyper-V containers
New in Windows Server 2016 TP4
Docker runs on host
Launches silo in a stateless, lightweight Hyper-V VM
VM invisible to user
Appears like a process-based container
docker run --isolation=hyperv
Use SMB over VMBus to provide layers, volumes

12. Porting Docker
Two worlds collide

13. Porting Docker
13
Microsoft contributions in numbers
319 pull requests
(+) 182,315 (-) 12,113
#4 contributor in terms of pull requests
#5 contributor in terms of lines of code

14. Porting Docker
14
Technical details
Go build tags
In source: // +build windows
In the filename: daemon/containers_windows.go
Go interfaces
Graph driver (~ image storage)
Execution driver

15. Porting Docker
15
Future: multi-architecture images
Example: docker pull redis
What’s my executing OS?
Not just Windows, but also ARM, …
Proposal docker/distribution#1068
A new image manifest format to support multi-arch

16. Demo
Yay!

17. Demo
17
A hybrid Swarm cluster

18. Demo
18
A hybrid Swarm cluster
All components speak the Docker API
Docker daemon on Linux host
Docker daemon on Windows host
Swarm master (hosted on the same Linux host)
Deploying to either is just a scheduling decision
Using Swarm constraints mechanism

19. Thank you!
John Starks
john.starks@microsoft.com
Arnaud Porterie
@icecrime
arnaud@docker.com