Windows 原生 Docker 正式商用

Windows 应用已经可以稳定地运行在原生容器管理平台之上

2016 年 9 月 26 日，微软 Ignite 技术大会在亚特兰大举行，微软官方正式发布了 Windows Server 2016。对于广大 Windows 开发人员和 IT 技术专家来说，Windows 最令人激动的新功能，非「容器」莫属。而运行在 Windows Server 2016 上的容器，正是由 Docker 公司所驱动。

本篇博客将详细剖析这些让 Docker 容器与 Windows 完美匹配的技术创新点，并尝试阐述这些成就的重要意义。我们也推荐你看看同期发布的几篇博客，其中一篇讲述了如何创建你的第一台 Windows 容器，还有一篇详细介绍了 Docker 公司和微软公司为了在 Windows 上支持 Docker 而开展的一系列商业合作。

2013 年，第一版 Docker 正式问世。从那以后的三年间，Docker 发展势如破竹，彻底改变了 Linux 开发者和运维人员 “构建、交付和运行（build，ship and run）” 应用的方式。如今，Docker Engine 和容器已经可以在 Windows 平台之上原生使用了，开发者和 IT 专家们也可以在 Windows 平台应用和基础架构上，体验一把 Linux 用户曾经经历过的大革新，享受 Linux 用户曾经享受过的福利：更好的安全性、更高的敏捷性、更优良的便捷性，以及随时可以把私有应用迁移到云端之上的灵活性。

而对于那些需要创建和维护 Linux 和 Windows 两大架构平台的开发人员和 IT 专家们来说，Docker 运行在 Windows 平台的重大意义更加不言而喻：现在，Docker 平台已经可以为 Linux 和 Windows 应用的管理提供一整套工具、API 和镜像格式了。随着 Linux 和 Windows 应用与服务器不断地 「Docker 化」，开发者和 IT 专家将能够通过使用 Docker 技术来管理和改进本地和云端的复杂微服务部署。

在 Windows Server 之上运行容器

Docker 和微软已经磨合了两年，期间开展了一系列的合作——Windows 内核中容器化基元（primitives）越来越多，为了充分利用这些新基元，双方协力把 Docker Engine 和 CLI 迁移到 Windows 平台上，Docker 还给 Docker Hub 增加了多架构镜像支持。今天 Windows 平台中正式引入 Docker，正是这两年合作的结晶。

结果就是，现在在 Windows 平台上已经可以完美使用强大无比的 docker run 来快速启动一个完全独立的新容器了。

内核容器化功能已经整合进所有版本的 Windows Server 2016，在 Win10 的周年更新系统中也有。Windows 原生的 Docker daemon 可以在 Windows Server 2016 和 Win10 系统上运行（虽然 Win10 上只能创建和运行基于 Windows Server 的容器）。

Windows 版的 docker run 和 Linux 版有着一样的意义：全进程隔离，自带层级变动支持的沙盒文件系统（还有 Windows 注册表！）。每个容器都只面向一个纯净的 Windows 系统，而且无法介入到系统上的其他进程（不管这个进程是否被容器化了）。

举个例子，两个用着不同网络信息服务（IIS）版本，用着不同 . NET 框架的 Docker 化应用，可以在同一个系统中友好共存，甚至可以在互不影响的情况下，给各自的文件系统和注册表读写数据。

容器化之后，Windows IT 专家们可以隔离全部进程，发布状态的工件将变得非常稳定，用起虚拟机来就更加得心应手了，不必担心在硬件虚拟化过程中产生的资源超支和灵敏度降低。

Linux 上的容器可以用不同的安全档案运行，Windows 上的容器也与此类似，可以运行以下两种隔离模式中的一种：

1、Windows Server 容器使用和 Linux 容器一样的共享内核进程隔离范式。由于容器作为标准（但是隔离）的进程来运行，所以启动很快，而资源超支可以降到最低。

2、有了 Hyper-V 隔离，容器一启动就会生成一个很小的管理程序，容器进程就在这个程序里运行。虽然启动速度会稍慢一点，资源占用也会略有增加，但整体的隔离环境却会好上不少。

可以通过 docker run 上一个简单的开关来设置隔离：

只要底层主机能支持所需的隔离模式，任何 Windows 容器镜像都能当作一台 Hyper-V 或服务器容器来运行，而且一台容器主机可以一个接着一个地运行这两者。基于容器的隔离模式，它是不知道容器进程的，而 Docker 控制 API 对于两种模式而言都是一样的。

这样一来，开发者就无需经常为隔离模式操心了，他们只需要用默认的设置就行，或者自己做些方便上手的设定。当 IT 专家需要选择如何在产品中部署容器化的应用时，隔离模式实实在在地为他们提供了选择的余地。

当然了，有一点要注意：尽管 Hyper-V 是支持 Hyper-V隔离的运行时技术，但 Hyper-V 隔离了的容器并不是 Hyper-V 虚拟机，不能用标准的 Hyper-V 工具来管理。

构建 Windows 容器镜像

得益于 Windows 注册表和文件系统的层级改进，docker build 和 Dockerfiles 都能完全支持创建 Windows Docker 镜像。下面是一个 Windows Dockerfile 样例文件，它是由斯蒂凡·施尔提交给 Node.js 官方 Docker 库的镜像。它能用 docker build 在 Windows 上创建出来：

来看看 PowerShell 是如何用于安装和启动 zip 文件和应用程序的吧：Windows 容器运行遵循 Windows API 的可执行程序。要创建和运行 Windows 容器，你需要一个 Windows 系统。虽然 Windows 和 Linux 上的 Docker 工具、控制 API 和镜像格式都是一样的，Docker Windows 容器不能在 Linux 系统上运行，反之亦然。

还请注意，开始层是 microsoft/windowsservercore。在创建 Windows 容器镜像时，开启 FROMScratch 是没用的。镜像要么是基于 microsoft/windowsserverco，要么是基于 microsoft/nanoserver。

Windows Server Core 镜像还配有一个近乎完整的用户态，这个用户态有各种进程，还有建立在标准 Windows Server Core 安装上的 DLL。除了 GUI 应用，以及那些需要 Windows 远程桌面的应用，大部分运行在 Windows Server 上的应用都能被 Docker 化，以最少的误差，在一个基于 microsoft / windowsservercore 的镜像上运行。举几个例子：MicrosoftSQL Server, Apache, 网络信息服务（IIS），以及整个 .NET 框架。

这种灵活性，是以容量的暴增为代价的：microsoft/windowsservercore 镜像高达 10 个 G。不过幸好有了 Docker 高效率的镜像层级，在实际操作中容量过大并不是什么大麻烦。任何一台 Docker 主机只需要拖进底层一次便足矣，任何拖进系统或创建在系统上的镜像只不过是在重复利用底层。

另一个底层选项是 Nano Server，这是一款全新的小体积 Windows 版本，带有一个精简版的 Windows API。包括 IIS、新版 .NET Core framework，Node.js 和 GO 在内，已经有大量的软件运行在 Nano Server 上了。而且 Nano Server 基本镜像的体积远小于 Windows Server Core，这意味着它的必备组件更少，保持刷新所需的表面积也更小。Nano Server 是一个令人激动的成果，不仅因为，作为小型容器的底层，它的创建和 boot 非常快，还因为，它作为一种极小主义操作系统，是为了另一款同样优秀的，专门运行 Docker 镜像和容器的容器主机 OS 而生的——这就是它的伟大之处。

有了 Windows Server Core 和 Nano Server 可供选择，开发者和 IT 大牛们就可以自由玩转了，要么把异彩纷呈的 Windows 平台应用 “lift-and-shift” 到 Server Core 容器里，要么采用 Nano Server 搞绿地模式开发，要么把整个应用分解成数量更多的小部分，整合进微服务的组件里。

Docker 目前正与微软及其社区携手，在 WindowsServer Core 和 Nano Server 上创建容器镜像。Golang、Python 和 Mongo 语言作为正式 Docker 镜像，都可以用，更多的 Docker 镜像也正在开发之中，而且微软还维护了一系列非常普及的样本镜像。

总结

今天，Docker Engine 能在 Windows 系统上创建、运行和管理容器，是微软团队、Docker 团队，以及 Docker 社区成员经年累月劳动的成果。Docker 与微软通力合作，把容器化的福音带给了 Windows 开发者和 IT专家，我们为此感到无比自豪；让 Windows 和 Linux 技术能用同一套工具和 API 来创建、交付和运行应用，我们也为此感到无比激动。