Windows Docker第一时间揭秘

这是盆盆谈微软两会的系列之一，所谓微软两会，是指微软Build大会和微软Ignite大会。

在咱们微信群里听一位兄弟提到，Docker能将DevOps(意即"开发"和"运维")整合在一起，暗合王阳明先生的“知行合一”之教，这真是一种有趣的说法。

话说从头，盆盆在 《Windows Docker深入原理分析》 里曾经提到微软Build大会后，会第一时间给大家介绍Windows Docker技术。本文最初发表在盆盆自己的微信 华来四公众号 上。

还没看过Build在线视频的朋友，您可以泡杯咖啡，带上耳机，静静地欣赏以下由Taylor Brown主讲的Windows Docker讲座，我们的文章就以此为蓝本。

http://channel9.msdn.com/Events/Build/2015/2-704

这里需要注意的是：以下的论述，大多是盆盆根据Taylor的demo效果所做的推论，并不是Taylor本人的陈述，所以并不一定正确。由于能力所限，必然谬误不少，还望大家能及时指出哈。

容器即隔离

拿大家熟悉的Linux Docker来看，其涉及到Linux内核所提供的Namespace隔离技术和资源控制的CGroup技术。

这里推荐大家阅读浙大SEL研究生孙建波老师的文章 《Docker背后的内核知识——Namespace资源隔离》 。

孙建波先生提到了一张表格，其中列出了Linux内核所支持的6种隔离：主机名、IPC、进程ID、网络、文件系统、账号。

尽管Windows内核实现和Linux不同，但是两者还是有不少可比拟处。所以盆盆根据Build大会上Mark Russinovich这位大神以及Taylor Brown的讲座，来条分缕析。试图按照这几个Namespace隔离的框架来进行阐述。

文件系统隔离

先来看看浙大SEL的另一位大牛孙宏亮老师的文章 《Docker源码分析（九）：Docker镜像 》 。这篇文章清晰地描述了Linux Docker的文件系统隔离，多层的可叠加文件系统。

孙宏亮老师指出，假设我们下拉了Ubuntu:14.04映像，并通过命令docker run –it ubuntu:14.04 /bin/bash将其启动运行。则Docker为其创建的rootfs以及容器可读写的文件系统参见下图。从容器的视角来看，虽然只有一个逻辑的完整文件系统，但该文件系统由“2层”组成，分别为读写文件系统和只读文件系统(按只读层还可以再逻辑分层，所以极大地节省磁盘空间)。

Windows Docker同样如此，顶层的沙盒层(sandbox layer)是可读写的，只允许该容器自己占用，而其他层则是只读的，可供不同容器共享。在下图中，底层的基础OS层和中间的应用程序框架层都是只读的，而顶层的沙盒层则可读写，在容器的视角看来，它独占了完整的OS。这有点类似于Hyper-V的差异磁盘链(顶部的子盘才能读写，其上方的所有父盘和Base盘都是只读的)。

为了说明文件系统隔离的魔力，Taylor演示了在Windows容器里用 del 命令删除C盘根目录下所有文件，然后再用 reg 命令删除HKLM/Software下的所有注册表键值，尽管这个容器被毁了，但是并不会影响其他容器，更不会影响主机。

盆盆猜测，在Windows容器的视角里，如果只是读取一个文件，在最顶端的沙盒层里只有该文件的重解析点(reparse point)；只有在修改该文件时，才会用copy-on-writer的方法从下方的只读层中把文件内容复制到可读写的沙盒层。

创建Windows Container

视频里演示了一个demo。用一段简单的代码，在Docker Client的console里显示“This is a pretty cool app”。

这是用来构建Windows Docker映像的Dockerfile。这个文件由以下4行命令组成，基本上每一行命令等于叠加1个Layer：

• 第1行：表明该映像基于windowsservercore这个Base映像，可以将其理解为rootfs
• 第2行：表示工作目录是C盘根目录
• 第3行：将应用目录复制到容器映像里
• 第4行：启动该应用程序
  
  

用 docker build 命令将其构建为容器映像，Tag是1。从命令结果中可以看到Dockerfile里的每个命令都被执行，并叠加新的Image Layer。

Docker映像构建完成后，可以运行 docker image 命令查看新建的映像，运行 docker run 命令即可快速启动该映像，并成功显示"This is a pretty cool app..."。

通过使用 docker history 命令，我们可以查看容器映像的构建历史，这甚至可以用来逆向生成Dockerfile。例如视频里演示了sysinternals这个映像的构建历史。从中我们可以看到：首先记录维护人员是谁；然后指定工作目录是C盘根目录；再者是将sysinternals suite这个工具软件目录拷贝到容器映像里；然后设定容器的运行账户(文章后面讲到)；最后设置启动ipconfig以便显示容器的IP地址。

IPC隔离

和Linux Docker容器一样，Windows容器也采用IPC隔离机制。Windows容器使用Windows自己的session隔离机制。

会话(session)隔离机制，最初是用在Windows终端服务和快速用户切换中，以便这些不同用户的进程不会互相干扰，确保安全。从Windows Vista开始，也采用这种技术对系统会话进行隔离，Windows系统自己的服务和进程会占用原来的控制台会话(会话0)，而后续的用户会依次使用会话1、会话2等等，这就是我们不能再使用 mstsc /console 进行控制台登录的原因。

从《Windows Internals》里我们可以学习到：不同会话里的应用，不能够发送窗口消息(Window Message)，以防止粉碎攻击。每个会话拥有自己专用的对象命名空间。同样每个Windows容器，也会有自己的独立会话，有自己专用的BaseNamedObjects等对象命名空间，以便隔离事件、互斥信号和内存段等对象。这样不同容器在同一个Windows主机上访问同一个命名对象，就不会导致冲突。以下的WinObj对话框是在盆盆自己的Windows 10上截图的，虽然不是取自Windows Docker系统，但是道理是一样的，可以看到不同的会话，拥有自己专用的对象命名空间。

有兴趣的朋友可以参考盆盆在9年前发表在ITECN博客上的文章，介绍会话隔离技术：

http://blogs.itecn.net/blogs/w ... .aspx

视频里演示了Docker容器的会话隔离能力。Taylor启动了两个容器，都是从同一个windowsservercore映像里派生出来的。其中一个容器，可以运行 Tasklist 命令，看到该容器运行在会话14中。而且还能看到两个系统进程，一个是System进程，代表操作系统本身，另一个是空闲进程，这两个进程都运行在会话0里。

在同一个映像所创建的另一个容器里，我们可以看到该容器运行在会话15中，同样可以看到System进程和空闲进程。

Taylor的解释是由于容器是共享Windows Kernel的，所以容易可以看到System进程的PID是一样的，都是4。其实System进程并不是用户模式进程，而是用来代表所有操作系统和驱动程序的内核模式线程，在所有的Windows主机上，System进程的PID都是4，空闲进程也是同样的道理。

网络隔离+图形化访问

和Linux容器一样，Windows容器也可以有自己的独立网络配置。

此外，由于最新的Windows Server 2016具备SDN功能，不但包含先前Windows 2012对于NVGRE的支持，同时也支持Vxlan。期待这些Window内置的网络支持能力能够和Windows Docker有机的整合。

由于传统的Windows应用大多是有GUI的，所以这些应用可能需要通过图形化方式进行远程操控。

视频里Taylor举了一个sysinternals容器的例子。有趣的是，这个demo本来是Mark Russsinovich的保留曲目，可惜Build大会Keynote的时间十分宝贵，Mark没有足够的时间去演示，而由Taylor代劳。

Taylor演示直接在 docker client 上下文里启动Sysinternals Suite里的经典工具Process Explorer，由于该工具带GUI，所以虽然进程已经在容器里启动，但是在Docker Client里无法直接远程显示。

如何才能正常显示呢？Taylor用了一个CC命令，直接连接到该容器的IP地址(192.168.0.23)。从demo里我们可以看出，实际上这个CC命令连接到容器的RDP服务上，这样就相当于直接通过终端服务连接到容器里的会话里，哈哈，有点类似RemoteApp(或者Citrix XenApp)的效果！

盆盆在 《Windows Dcoker深入原理分析》 里曾经提到，Windows Docker的前身DrawBridge在其沙盒里实现了RDP服务，Windows Docker的原理应该类似。

Linux Docker也能访问图形化界面，在这篇文章 《在 Docker 中运行 OpenOffice》 里介绍，只需在Dockerfiles里添加安装X Server的命令，就能借助VNC客户端连接到OpenOffice图形化界面。

PID隔离

在Linux容器里，容器里的PID有自己的独立命名空间。从演示的情况来看，Windows容器的PID隔离方法看上去略有不同。

在前面IPC隔离一节，我们可以通过tasklist命令确认不同的容器，其CSRSS、Lsass、SVCHOST等重要进程的PID有所不同，用户进程的PID也不一样，可见彼此之间是完全隔离的。

那么从宿主机的角度来看呢？

我们可以用Process Explorer的例子来确认，这需要观看 Ignite大会上由Taylor所主讲的视频 ，由于Process Explorer是在终端会话里打开的，所以我们可以在容器的任务管理器里看到有两个会话：

- 会话14是Docker客户端访问生成

- 会话15则是通过RDP访问生成

可以看到Process Explorer的进程有两个版本。显然，会话14是Taylor在Docker客户端里运行的结果(但是我们无法看到图形化界面)，而会话15则是RDP访问的结果。

两者的运行账户不一样，RDP登录的运行身份为Administrator(应该和Docker History一致)，而会话14则是System账户。

以下是从容器视角所看到的任务管理器。这个任务管理器是从容器的角度来看的，我们可以记下其中的若干SVCHOST进程的PID。

接下来我们打开宿主机的任务管理器，从全局的角度来查看。可以发现，从宿主机的角度来看，能看到每个容器里的进程，其PID和容器里面的版本是一样的。

用户账户隔离

Linux内核拥有账户隔离能力，可以让容器里的进程以root身份运行，而在宿主机上，该账户实际上是普通用户权限，这样可以极大地改进安全性。

在Taylor的这个演示中，我们也能“察觉”到一些蛛丝马迹。在 PID隔离 一节的两个任务管理器截图里，从容器的视角来看，可以看到Process Explorer的运行账户为Administrator，但是从宿主机上查看，对应进程的运行账户为空。所以Windows容器可能也实现了类似的账户隔离技术(抱歉这只是推测，我们现在还拿不到Windows Docker的测试版本)。

计算机名和域名隔离

Windows容器拥有自己的计算机名和域名隔离能力，这样在网络上，Windows容器看上去类似于一台独立的虚拟机。

不过由于共享内核，所以Windows容器目前应该不支持活动目录，毕竟同一台宿主机上所有容器应该都具有同一个SID，这样就无法加域(无法验证计算机账户)。

盆盆推测，到了Windows容器时代，类似于活动目录这类比较笨重的验证协议可能会逐渐退出历史舞台。毕竟活动目录需要开放那么多端口，需要借助ADFS等手段才能穿透Internet。

不过Windows容器的验证并不会存在问题，Azure AD和证书等都是很合适的办法。

容器的优势

容器非常适合开发的快速迭代、快速回滚。Taylor做了一个简单的演示，对前面所述的代码进行修改，调用私有的msvcr120.dll文件里的_snwprintf函数，以显示"Now it's really cool"。

但是在docker build的时候，Taylor没有修改Dockerfile，没有像Mark之前的demo那样把私有的msvcr120.dll拷贝到容器映像中，以便生成新的Layer。

结果由于容器的目标宿主机上没有安装Visual Studio，所以新Build的容器运行失败，提醒缺少msvcr120.dll文件，而无法显示"Now it's really cool"。

解决这个问题很简单，可以根据先前的映像快速生成新的容器，这大概只需要几秒钟时间，这样就可以有充足的时间去调试了。

在Build大会的Keynote上，Mark Russinovich演示了用Visual Studio把同一个电商网站的代码签入到Windows容器和Linux容器里，并且可以用Visual Studio来调试Linux容器里的代码。