The document discusses Windows Server Containers and Docker for Windows, highlighting system architecture, namespaces, and the differences from traditional virtualization. It details the technical foundations, including the hybrid model for file systems, the use of Hyper-V, and contributions to the Docker project. The future direction includes support for multi-architecture images and hybrid swarm clusters for deployment.

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

2. Docker for Windows
System architecture
Porting Docker
Demos!
Agenda

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 (currently TP3)

6. System architecture
Windows Server Containers internals

7. System architecture
7
Basics
Abstraction layer between Docker and kernel
execdriver -> hcsshim -> vmcompute -> ???
Internals generally not exposed
Shared kernel
Resource controls
Namespaces

8. System architecture
8
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

9. System architecture
9
Object namespace
System-level namespace, hidden from users
C:Windows maps to Global??C:Windows
Contains all device entry points
Global??C:
Registry
DeviceTcp
Added “chroot”, one namespace per container
ContainersfooGlobal??C:
ContainersbarGlobal??C:

10. System architecture
10
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

11. System architecture
11
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

12. System architecture
12
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

13. Porting Docker
Two worlds collide

14. Porting Docker
14
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

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

16. Porting Docker
16
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

17. Demo 1
Yay!

18. Demo 2
A hybrid Swarm cluster

19. Demo
19
A hybrid Swarm cluster

20. Demo
20
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

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