DockOne技术分享（十一）：DockerCon 见闻

本次主要分享DockerCon上的见闻，分享所有内容大致可以分为三个部分：1. Docker 1.7.0深度解析；2.DockerCon Hackathon见闻；3. DockerCon盛典。

第一环节：Docker 1.7.0深度解析

从Docker的版本变更日志来看，Docker 1.7.0在四个方面会有或多或少的变动，分别是：Docker运行时（Runtime），Docker的代码变化，Docker的builder模块，以及Docker的bug修复。

此次分享主要涉及Docker 1.7.0的runtime。

1.1.增添了一个仍然处于试验阶段的特性：支持out of process的数据卷插件

何为试验性质的特性，换言之Docker的这部分特性还不支持在生产环境中采用，这些特性更多的希望用户仅仅在测试环境，以及沙箱环境中采用。试验性特性完全是Docker 1.7.0的一大亮点。

在以上的基础上理解out-of-process，就容易很多，插件本身与Docker Daemon无耦合，即插即用，在Docker Daemon范畴之外发挥作用。

目前Docker的试验性特性可以从两个方面来描述，首先Docker目前已经支持用户自定义第三方插件的使用；另外在这基础上，Docker自身支持了容器数据卷volume插件。此外，Docker还定义了一整套与插件相关的API，方便用户使用。当然，相信后续在该领域，不论是Docker官方，还是整个社区，都会不断有新的插件诞生。值得一提的，在数据卷volume插件方面，出现了Flocker的身影，这也意味着容器的数据存储问题，真正被提上台面，并有相应合理的解决方案。

1.2.从docker daemon的角度，添加了userland-proxy的起停开关

首先介绍userland-proxy一直以来的作用。众所周知，在Docker的桥接bridge网络模式下，Docker容器时是通过宿主机上的NAT模式，建立与宿主机之外世界的通信。然而在宿主机上，一般情况下，进程可以通过三种方式访问容器，分别为：<eth0IP>:<hostPort>, <containerIP>:<containerPort>,以及<0.0.0.0>:<hostPort>。实际上，最后一种方式的成功访问完全得益于userland-proxy，即Docker Daemon在启动一个Docker容器时，每为容器在宿主机上映射一个端口，都会启动一个docker-proxy进程，实现宿主机上0.0.0.0地址上对容器的访问代理。

当时引入userland-proxy时，也许是因为设计者意识到了0.0.0.0地址以及localhost对容器访问上的功能缺陷。然而，在docker-proxy加入Docker之后相当长的一段时间内。Docker爱好者普遍感受到，很多场景下，docker-proxy并非必需，甚至会带来一些其他的弊端。

影响较大的场景主要有两种。

第一，单个容器需要和宿主机有多个端口的映射。此场景下，若容器需要映射1000个端口甚至更多，那么宿主机上就会创建1000个甚至更多的docker-proxy进程。据不完全测试，每一个docker-proxy占用的内存是4-10MB不等。如此一来，直接消耗至少4-10GB内存，以及至少1000个进程，无论是从系统内存，还是从系统CPU资源来分析，这都会是很大的负担。

第二，众多容器同时存在于宿主机的情况，单个容器映射端口极少。这种场景下，关于宿主机资源的消耗并没有如第一种场景下那样暴力，而且一种较为慢性的方式侵噬资源。

如今，Docker Daemon引入- -userland-proxy这个flag，将以上场景的控制权完全交给了用户，由用户决定是否开启，也为用户的场景的proxy代理提供了灵活性。

1.3. docker exec命令增加- -user参数，用户控制docker exec在容器中执行命令时所处的用户

自从docker 1.3.0引入docker exec之后，用户对容器的操纵能力被大大释放，容器对用户而言不再是一个运行的黑盒。然而，docker exec带来巨大好处的同时，我们也能看到这其中的一些瑕疵，当然Docker社区也在不断地完善docker exec。

首先，docker exec在容器中运行的进程会以root权限运行，在权限方面缺乏灵活性的同时，容器的安全很有可能失控。参数- -user恰好弥补了这方面的不足。其次，docker exec的存在打破了容器内进程呈现树状关系的现状，而设计初期Docker容器的很多概念均以树的思想从init process入手，因此目前docker exec的进程并不能和原生态容器进程完全一样地被Docker Daemon管理。

1.4. 增强Docker容器网关地址的配置广度

Docker 1.7.0发布之前，在bridge桥接模式下，Docker容器的网关地址是默认生成的，一般为Docker环境中的docker0网桥地址。从容器通信的角度而言，默认的方式已经可以满足需要。但是，我们依然可以发现，这种模式存在一些弊端，比如网络配置的灵活性以及网络安全性。

Docker容器的网络一直广受关注，缺乏可配置的特性，在如今的软件发展中，几乎就意味着封闭。 –default-gateway 以及–default-gateway-v6 这两个参数，很大程度上提高了用户自定义容器网络的灵活性，用户更多场景的覆盖，似乎从Docker的发展中若影若现。结合最近几次新版本，功能的增强与丰富，不难猜测，Docker的企业化以及生产化，已经更上一层楼。

默认网关的设置，为什么说会和容器的网络安全相关呢？过去很长一段时间内，docker0作为容器的网关地址，这种方式将容器与宿主机的耦合关系体现的很彻底。docker0作为宿主机上的网络接口，充当容器与宿主机的桥梁。然而，也正是桥梁的存在，使得容器内部进程很容易穿过网关，到达宿主机，此过程并非对用户透明。

1.5. 容器CFS quota的支持

完善Docker对内核cgoups的支持，指的是对于一个组内的进程组在一个周期内被内核CFS调度算法调度的时间限额，单位为微秒。该配置项在cgroups中相应的文件为/sys/fs/cgroup/cpu/cpu.cfs_quota_us。

1.6. 容器磁盘IO限制的支持

众所周知，容器将会为用户提供一个隔离的运行环境，容器内部的进程或者进程组使用资源时将受到限制，这样的资源，包括：内存资源（物理内存以及swap），CPU资源（CPU时间片以及CPU核等），磁盘空间资源等，以上这部分内容或多或少，Docker的新版本之前或多或少都可以实现，然而隔离维度依旧不够完美，这次Docker添加了—blkio-weight参数，实现对容器磁盘IO限制的支持。隔离更加完备，用户也不再需要担心容器间磁盘IO资源的竞争。

1.7. ZFS支持

Docker 1.7.0 正式宣布支持ZFS文件系统。此举也意味着Docker容器文件系统的支持从原先的5种增加到6种。此前，Docker支持aufs，devmapper，btrfs，ovelayfs，vfs（用于支持volume），如今添加对ZFS的支持。ZFS的支持，不禁让人联想到与Docker的数据卷volume插件的Flocker。错进错出，似乎关系较为微妙。

值得一提的是，除了支持ZFS之外，笔者发现在负责容器文件系统的graph模块中，添加了driver_windows.go,虽然内容极其简易，并非完全实现对windows的全盘支持，但是至少让大家看到Docker支持windows的步伐在不断迈进。

1.8. docker logs的功能扩展

查看容器日志，相信很多Docker爱好者都体验过，这也是用户查看容器运行状态的重要依据。

可以简单了解Docker容器日志的原理：对于每一个创建的Docker容器，Docker Daemon均会在内部创建一个goroutine来监听容器内部进程的标准输出stdout以及标准错误stderr，并将内容传递至日志文件中。每当用户发通过Docker Client发起查看容器日志的请求docker logs之后，Docker Daemon会将日志文件的内容传递至Docker Client显示。

docker logs的发展，几乎可以分为4个阶段：Docker诞生初期的原生态日志打印；允许用户follow容器的日志；开启容器日志的tail功能，以及容器日志的since功能，打印从某一个时间戳开始之后的容器日志。

虽然容器日志的功能在逐渐增强，但是不可否认的是，容器日志是容器本身与Docker Daemon耦合最大的模块之一，而这涉及Docker设计之初的计划，绝非完美，但的确是短时间内最易用的方案。

1.9. 容器与宿主机共享UTS命名空间的支持

不同的场景下，容器与宿主机可以完全隔离，容器也可能与宿主机存在共享信息的情况，Docker网络的host模式就是一个很好的例子，该模式下的容器共享宿主机的网络命名空间。

共享UTS命名空间的支持，意味着容器与宿主机的关系越来越微妙。也许目前很多Docker爱好者已经习惯容器与宿主机完全隔离的运行，当然也会有一些用户曾经抱怨完全隔离的运行环境并不能平滑的将传统遗留业务容器化。那么，目前Docker在兼顾两者的情况下，更多地在满足后者的需求，不久的将来，Docker容器的运用场景必将更加丰富，这也是Docker走向企业化以及生产化必须要趟的路。

总体而言，Docker 1.7.0给笔者的感受是：功能上逐渐向企业需求靠拢，在production-ready的路上不断优化，另外在安全方面在不涉及内核基础上也不断完善。

就在发布1.7.0之后没几天的DockerCon上，Docker宣布production-ready并严肃看待安全，其实从1.7.0的变更来看，完全可以感受到这一点。

另外，需要提及的是：以上的3、5、6三点均是国内公司华为的大力推动下完成的，作为一个Docker开发者，由衷的感谢华为以及众多的docker committer的贡献。

第二环节：DockerCon Hackathon

6月7号8号，咱们中国的开发者在北京举办了一次Golang&Docker Hackathon，DockerCon前夕旧金山也举办了一次Docker Hackathon。

这次黑客马拉松诞生了很多新颖的想法，鲸鱼粉的Geek精神发挥得淋漓尽致。由于内容过于丰富，我仅仅给大家介绍两个我印象非常深刻的项目。

2.1.参赛项目：Swarm-SEC

这是一个Swarm集群安全评估工具

通过Swarm、预先定义的安全规范来扫描整个集群。评估的安全维度有主要有三点：Swarm中docker daemon的安全配置，Swarm集群中Docker Node的具体安全策略使用情况，Swarm集群的运行时安全情况。

这是swarm-sec的启动方式：

docker run -it --net host --pid host --cap-add audit_control \
-v /var/lib:/var/lib \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /usr/lib/systemd:/usr/lib/systemd \
-v /etc:/etc --label swarm-sec \
swarm-sec <token-id>

网络命名空间，Pid命名空间，几乎将所有的Docker信息都挂载到容器内部了，另外还添加了一个Capability能力audit_control，用以获取audit守护进程的信息。

我主要介绍一下Swarm-sec关注了Swarm Daemon以及Docker Node上Docker Daemon的哪些安全问题。

Swarm Daemon

1.查看Swarm是否运行在容器之中，

2.查看Swarm是否是一个最新的稳定版本

3.查看Swarm的日志级别，不建议使用debug模式

4.验证是否占用Docker的默认端口

5.验证Swarm Daemon是否启用了TLS安全传输协议

6.验证容器调度驱动是否是mesos，目前mesos驱动仍处于试验阶段

7.查看类似于SELinux和AppArmor是否启用

……

Docker Daemon

验证Docker Node的label设置是否规范，验证docker daemon的配置手否符合安全，比如不建议使用AUFS等。

项目源码：https://github.com/snrism/swarm-sec

2.2.参赛项目：Sherdock RancherOS的作品

主要的特征有：

基于正则表达式，对Docker镜像进行自动回收。

镜像GC的的原因主要还是因为在build失败的时候会产生一系列的none镜像，这些镜像未必有用。此时就可以基于给定的正则表达式，将这样的镜像清理掉。

基于docker 1.7.0做孤儿数据卷的清理工作。（孤儿数据卷：有data volume的容器在删除时没有指定－v参数）

提供UI界面。

Hackathon的报道分享得太多容易占篇幅，如果大家感兴趣，可以查阅：DockerCon之黑客马拉松见闻

第三环节：DockerCon盛典

分享DockerCon见闻，DockerCon两天发生的内容自然是重头戏。这部分的分享，我主要分为两部分：第一，keynotes的内容，并通过几个关键字进行介绍；第二，介绍我参加的几个分会场的topic内容。

3.1 keynotes关键字

3.1.1 OCP

Docker联合众多IT巨头，共建完全开放的容器标准，名为OCP，意为“开放式容器项目”，我国的公司华为也赫然在列。OCP是全球首个容器技术界开放并统一的标准。

OCP的诞生意味着Docker与CoreOS之间曾有的容器标准之争，暂告一段落。OCP的开放性使得容器的标准能够得到更好的完善。

OCP使得容器的发展能够被广泛认同并支持，个人或团队伸直企业对容器技术的共享能够更多的被思考，能够更多的被实践，其发展对容器的影响绝对不可小估。

3.1.2 新项目

Experimental binary

Docker的experimental binary是那种功能非常强大、但不可能被加入Docker官方版本的功能组件。这种实验性质的构建允许用户自行体现Docker的新功能，并且给Docker的维护者提供反馈。通过这种方式，Docker官方希望可以将一些新功能预先暴露给全球的开发者，从而让大家在实践以及反馈中重塑这些重要功能。

目前，Docker的网络插件以及数据卷volume插件是最先问世与大家见面的试验性功能插件。

Docker plugins

Docker的可扩展性再次被Solomom及其团队提上议程并实践。目前，Docker的network模块，数据库volume模块，swarm中的调度模块以及服务发现模块，均已经逐渐被插件化，体现Docker生态中软件强大的扩展性能力之外，更体现了Docker生态的开放性。当然除了以上这些已经支持的插件之外，未来的插件必定会更多。

此外，插件的使用，对于Docker Daemon以及其他的软件模块没有其他的patch引入，然而目前仍然需要重启Docker Daemon或者其他软件。另外，插件的支持，对于Docker应用而言是全盘透明的，插件的引入不会改变原有Docker应用的使用方式。

Docker Notary for security

Notary由server端和client端组成，Server端主要运行并维护一个容器的受信集合，Client端用以与Server交互最终实现安全任务的分发。

总体而言，Notary希望提供一种简单的方式，便于用户更安全的发布以及验证网络数据。原则上，我们可以通过TLS安全传输层协议保障通信双方的安全性，然而这本质上存在缺陷，原因很简单，Server端的任何疏忽，都将导致恶意内容替换合法内容，从而前者危及网络通信。

在Notary的帮助下，网络内容的发布者可以通过强安全的key对用户内容进行签名加密。一旦完成并准备发布，则内容首先被推送至Notary受信的集合中。访问者只有通过安全隧道获取了发布者的公钥之后，才能和Notary中的任意server建议通信，并访问到合适准确的资源。

runC.io

runC是一个OS层面通用的运行时环境，而且仅仅是OS层面的运行时。项目地址：[https://runc.io]

Docker官方宣称runC以及通过全面测试，并且production-ready。

在功能方面，runC支持Linux所有的安全特性，比如：SELinux，apparmor，cgroups，seccomp等。

支持目前连docker都不支持的user namespace

支持容器的热迁移。

微软正在积极开展windows对runC的支持。

ARM体系的支持也正在积极进展中。

Intel也在对DPDK贡献

明确了标准化、可移植、可运行的格式

兼容于命令行形式以及编程方式

3.1.3 生产化

Docker Hub线上服务的增强和改进

升级到V2 open source registry

优化后端，实现了更快的下载速度，更少的客服端/服务器端的交互次数

提高稳定性、整体用户体验提升

新的UI界面

提升安全性方面Docker做了很多努力，包括

authentication micro services

content-addressable images

one time use build hosts

on-ging scanning and audits等等。

Ocra

Project Orca的愿景是提供一套自上而下的整合栈，能够抓取所有的工具和plumbing（Docker Engine、Docker Swarm、Networking、GUI、Docker Compose、安全、安装工具、部署、配置等）。Project Orca非常适合“build－ship－run”中“run”的部分。

代表着Docker开始真正的进军企业市场，私有化容器管理解决方法Docker推出解决方案。

3.2 分会场分享

3.2.1Docker的安全

Docker能提供的安全保障将涵盖以下7点：

namespace保障系统资源的隔离

cgroup完成进程组资源的限制

Linux的安全模块提供MAC（apparmor， SELinux）

capabilities将root的权限细分为多种类型

ulimit的功能更多维度的限制资源（docker 1.6之后支持）

user namespace保障容器内部的root在host上并非root（预计docker 1.8支持）

seccomp使得容器内进程受到系统调用权限的控制

Docker在安全方面还做了以下工作：

降低镜像带来的安全风向

设置更为精简的Linux发行版：

移除不需要的package、用户以及二进制工具文件

提出Tailored Profiles

容器可以创建least-privildge的文件

文件有能力随容器传递

通过独立的文件配置表明所有的权限

已经规划入runC

描述所有的隔离特性

值得提及的是：DockerCon安全话题的分享者，感谢了来自中国的华为公司。

3.2.2 Netflix的Docker企业级实践

为什么选择Docker？

1. 在netflix内部进程隔离的需求很大

2. Docker有能力将众多功能集一身，并打包成一个Docker二进制文件，用户完成无需关心与linux内核与其他特性之间的依赖关系，只需操纵Docker简易的API即可

3. Docker的周边工具链的发展以及集群间应用发布的可扩展性大大吸引了Netflix

DockOne技术分享（十二）：新浪是如何分析处理32亿条实时日志的？

我从2014年初入职新浪后就开始接触实时日志分析相关的技术，主要是ELK（Elasticsearch、Logstash、Kibana），当时是学习+ELK优化，接一些日志，小打小闹。从2015年起，我们正式得把实时日志分析作为服务提供给公司的其他部门。今天要给大家分享的是在服务化的道路上，我们的想法，方案和疑问。

服务介绍

随着实时分析技术的发展及成本的降低，用户已经不仅仅满足于离线分析。目前我们服务的用户包括微博、微盘、云存储、弹性计算平台等十多个部门的多个产品的日志搜索分析业务，每天处理约32亿条（2TB）日志。

技术架构

简单介绍一下服务的技术架构：

这是一个再常见不过的架构了：

（1）Kafka：接收用户日志的消息队列。

（2）Logstash：做日志解析，统一成JSON输出给Elasticsearch。

（3）Elasticsearch：实时日志分析服务的核心技术，一个schemaless，实时的数据存储服务，通过index组织数据，兼具强大的搜索和统计功能。

（4）Kibana：基于Elasticsearch的数据可视化组件，超强的数据可视化能力是众多公司选择ELK stack的重要原因。

努力提供更好的服务

我这次分享的重点不是这种架构的优劣或为什么选择这样的架构，而是在如此的架构上如何更好地传递实时日志分析的价值。为用户做好服务也不是修改几个配置文件，调优几个程序运行参数就能搞定的。为了提供更好的服务，我们在下面三个方向做了努力：

一、提升服务质量

我们首先做了Elasticsearch优化，Hardware Level由于我们当时拿到机器没有选择余地，只开启了超线程；System Level的优化如关闭swap，调整max open files等；App Level的优化如Java运行环境版本的选择，ES_HEAP_SIZE的设置，修改bulk index的queue size等，另外还设置了默认的index template，目的是更改默认的shard，replica数并将string改为not_analyzed，开启doc_values以应对elasticsearch进程OOM。详细的优化内容见Elasticsearch Optimization Checklist。

随着用户数据的不断增长，index管理也成了大问题，我们需要基于大量不同的用户配置定期的create、optimize、close、delete、snapshot不同的index，在某个服务器上手工配置crontab已是不可能，而且cron是单点。于是我们开发了一个独立的Elasticsearch Index管理系统，负责以上任务的调度及执行。这个管理系统背后使用的技术是Celery，一个用Python开发的任务队列及执行系统，提供了类似crontab的定时任务配置语法，并且实现了分布式，可用性更高的架构。

最近的服务升级，我们为Elasticsearch安装了HDFS Snapshot插件，可以定期将index备份到HDFS，这个功能目前主要用于备份Kibana的配置index，用以恢复用户查看或配置可视化界面时的错误操作。

监控报警方面，System Level的监控报警（如硬盘满、损坏、服务器宕机）直接使用了在新浪内部提供了多年服务的sinawatch；App Level（如Elasticsearch JVM Heap Usage过高，Kibana能否正常访问，Kafka topic的consumer offset lag），我们开发了对应的监控报警脚本。User Level（如日志解析失败数量），主要通过elasticsearch python client执行query去统计或搜索。常见的报警是Logstash-filter-grok，logstash-filter-json解析日志失败会输出的json中添加_grokparserfailure、_jsonparsefailure，我们执行query判断解析错误的量。

要说明的是，Marvel是Elasticsearch很好的监控工具和插件，但是它们是商业软件，我们没有采用。Marvel是基于Kibana做的，里面对一些重要指标（如index bulk reject number）的展示很有价值。

二、增强易用性

增强服务的易用性就是给用户更好的用户体验，减少用户的抱怨。ELK性能优化是一方面，但它是远远不够的，我们遇到的实际情况是，用户在其他方面抱怨更多，如下：

1，用户最先抱怨的是IP解析成地区、ISP信息一点都不准，完全没有参考意义。

如对于CDN这种服务，我们解析用户IP不准，定位问题边缘节点错误，问题没法查，这是帮倒忙。原因：Logstash默认自带的IP库是国外maxmind公司的免费版本，中国的信息尤其不准。解决方案：使用我浪较新较全的IP库生成能适配maxmind geoip2 api的二进制格式IP库（maxmindDB），再开发logstash-filter-geoip2来解析IP。实测不仅IP解析准确率与公司IP库相同了，解析速度也提高了。

2，然后我们与用户都发现日志接入流程复杂，沟通困难。

人做不到机器那样分毫不差，有啥说啥。接入用户日志的时候，例如常常因为用户对日志格式表达的不全面，模棱两可，导致日志解析失败，服务对接人多次重写配置。从用户提需求到用户可以看到数据可视化效果或搜到日志，需要几个小时到几天。一来二去，用户和我们都烦了，只能求变。为此，我们正在逐步实现用户数据接入的自动化，减少接入时间和沟通成本这个过程需要3个关键：A.用户配置日志格式的界面，尽可能简洁简单；B.根据用户配置自动生成logstash config、index管理需要的配置；C.自动部署配置（logstash config等），打通日志流。

后来我们做了一个简单的用来协商日志格式的界面：

目前我们已完成了A的一部分：用户日志格式配置界面；B的全部：开发了自动生成logstash conf的 python api；C即将开始，并且考虑使用Docker技术为我们提供一些便利。

3，部分数据可视化需求得不到满足，Kibana配置难度大。

我们起初采用官方Kibana v3，用户提出的类似SQL中的多个group by，画百分比，求指定区间占比等常见需求无法满足。之后通过三斗大神(微博@argv)定制版的Kibana 3满足了一些用户需求。Kibana 4诞生后，代码几乎是对Kibana3的重写，做了大幅改进，通过Elasticsearch Aggregation的强大数据统计功能及灵活的配置从Kibana 3解放出来。近期我们将迁移到Kibana 4。

三、提供新功能

我们为Elasticsearch安装了国内medcl大神开发的ik中文分词插件elasticsearch-analysis-ik。之前被分词为『中』和『国』的中国，现在终于可以被当做一个完整的词汇，否则搜索『中国』、『美国』也会出现。微盘的一些离线搜索需求使用了我们的服务，也用到了中文分词，Elasticsearch的搜索天赋满足了他们的需求，减少了他们的痛苦。

我们经历过的坑和坎儿：

1，elasticsearch 进程JVM Heap High Usage（ > 90% ）。

很长一段时间，我们都在应对JVM Heap High Usage，他带了的问题是Old GC次数多，时间长，es节点频繁退出集群，整个集群几乎停止响应。现在我们的主要策略是开启doc_values；限制query执行时占用的JVM Heap size；analyzed string只允许做query，不允许facets或者aggs；定期close 用户不需要的index。

2，Elasticsearch Query DSL、Facets、Aggs学习困惑。

有人为此开发了使用SQL执行ES Query的插件，一定程度上减轻了进入门槛。我们给出的学习他们的建议是观察Kibana的Request Body或试用Marvel的Senese插件，它有自动完成Query、Facets、Aggs的功能。另外最常用的query是query string query，最常用的aggs是Terms、Date Histogram，可以应付大部分需求。

3，logstash不工作。

非官方的问题插件，及使用logstash-filter-ruby时未考虑到的异常等，导致Logstash运行时工作线程（worker thread）异常退出，Logstash僵死。我们的建议是尽可能不要在config中使用logstash-filter-ruby，尽量使用官方插件。不过我们也遇到过复杂的日志，写过250行+的config，用尽了ruby filter。当前未发现Logstash有好的成熟的监控方案，Logstash的内部状态也获取不到。我们目前通过间接的监控Kafka topic consumer是否落后或elasticsearch indexing rate来检验logstash的工作情况。

4，Kibana没有用户的概念，不同用户的数据无法隔离。

多个用户共享的Kibana Dashboard，误操作或误删时常影响其他用户，保存的dashboard太多，找到特定的dashboard很困难。官方到目前为止，未在这方面做过改进。有很多非官方的改进，我们也曾经用过三斗大神定制的Kibana3，也对Kibana index做了snapshot储存到HDFS里面。

5，与用户沟通成本高。

与我们的用户协商日志格式，数据可视化配置时，由于人的不确定性容易造成多次来回确定和修改，效率低下。我们毕竟是提供日志分析服务的，不给用户做日志运维，所以近期也在探索通过日志接入自动化、推荐用户提供给我们json格式数据，定期组织用户的Kibana培训来减少沟通成本。

DockOne技术分享（十三）：十个问题带你了解Windows Docker

微软在5月份Build大会上的官方说法，说是这个夏天会放出Windows Server Container的测试版。也就是说，目前我们还无法看到Windows Docker的测试版本，无法直接上手测试。

微软在5月份Build大会上的官方说法，说是这个夏天会放出Windows Server Container的测试版。也就是说，目前我们还无法看到Windows Docker的测试版本，无法直接上手测试。接下来我就大家关心的十大问题进行介绍：

1. Windows Docker和Hyper-V有啥区别？

Hyper-V和VMware/Xen/KVM等类似，都是硬件虚拟化，安全但笨重。

Windows Docker是OS虚拟化技术，具备一定的隔离能力，性能更好、容易移植。

两者不是互相取代的关系。

注意：Windows Docker并不是我们在Docker 1.6时见到的Windows Docker Client，也不是Boot2docker这个Windows下的linux虚拟机，而是真正的Windows版本的Docker。其实其正式名称并不叫Docker，而是叫做Windows Server Container，还有Hyper-V Container，有2个产品，其中Windows Server Container类似于linux Docker，而Hyper-V Container有些类似于clear linux或者Hyper Docker。

这是因为Docker是商标名称，微软不能直接拿来使用。

2. Windows Docker和Softgrid(APP-V)/Thinstall等有啥区别？

Docker是OS虚拟化，主要场景是服务端应用，这些容器(应用)之间通过标准的网络接口进行通信，好像虚拟机一样。

Softgrid是应用程序虚拟化，主要用于客户端应用部署。例如Office，这些应用在同一个会话里运行，完全就是传统的应用，彼此之 间可以进行进程间通信，例如Word可以OLE调用Excel的表单等等。不同的进程，看到的文件系统不会隔离。适用于批量部署客户端应用。

3. 容器和沙盒是什么关系？

曾经看到一句很棒的评语，必须分享给诸位：

Sandboxing is focused on just security with code isolation. Containers have some security code isolation, but this is not the only or primary purpose. One way to think about containers is as a layered/quarantined filesystem which makes it quick/easy/lightweight to run an application and also makes the application (in the container) very portable.

从下图中我们可以看出，在Windows 10里，IE的继任者Edge浏览器就采用了沙盒技术。

同样在保护模式下运行的Office文档，也运行在 沙盒里。如下图所示。

而容器，则还必须要在移动能力上有所考量，确保让应用，也能变成按需递交的动态服务。以前的硬件虚拟化，能将OS、App等变成文档，从而把服务器资源变成按需递交的服务，现在Windows Docker和linux一样，也能变成image，变成文档，变成按需递交的动态服务。

4. Windows Docker和其他OS虚拟化工具之间是什么关系，例如很早就听闻的VPS等？

从技术角度看，底层原理大同小异。看图吧。

Docker和其他OS虚拟化技术一样，技术实现大致差不多。关键看谁能带动生态圈，能够赢得其他厂商的支持。同时Docker的分层文件 系统实现，也是其特别引人入胜的地方。这个截图的下载地址在这里。

5. Windows Docker分层文件系统？

先看看Linux的实现。DaoCloud的大牛孙宏亮老师指出：假设我们下拉了Ubuntu:14.04映像，并通过命令docker run –it ubuntu:14.04 /bin/bash将其启动运行。则Docker为其创建的rootfs以及容器可读写的文件系统。参考这张截图

从容器的视角来看，虽然只有一个逻辑的完整文件系统，但该文件系统由“2层”组成，分别为读写文件系统和只读文件系统。孙老师的雄文链接在此。

Windows Docker采用类似的分层文件系统。参考下图。

Windows Docker采用NTFS文件系统的重解析点技术（reparse point），顶层的沙盒层(sandbox layer)是可读写的，只允许该容器自己占用，而其他层 则是只读的。在这张图中，底层的基础OS层和中间的应用程序框架层都是只读的，而顶层的沙盒层则可读写，在 容器的视角看来，它独占了完整的文件系统。

这有点类似于Hyper-V的差异磁盘链（顶部的子盘才能读写，其上方的所有父盘和Base盘都是只读的）。

Windows Docker的分层文件系统，我是将其理解为类似符号链接(仅仅用来帮助理解，不要真的轻信)，当顶层的沙盒层打开文件时， 相当于打开一个符号链接，而尝试修改时，则COW（Copy on write）。到底采用什么底层文件系统技术，如何实现多个容器并发访问只 读Layer文件的性能，如何cache等，目前一概不知道。sorry！

6. Windows Docker的文件系统隔离

前段时间的热门话题，除了股票，就要算是某在线旅游商的悲剧了，坊间甚至传闻其为数据误删！！！

有客户曾经问到：Docker能否避免这种悲剧？其实Docker和虚拟机一样，都替代不了容灾和备份的机制。不过Docker确实有文件系统隔离 的能力。我在Build大会里看到，演示者在Windows Container里执行删除C盘根目录下所有文件和注册表键值，尽管这个容器被毁了 ，但是根本不会影响其他容器，更不会影响主机，这和linux Docker一样。看图片吧。

7. IPC隔离机制

在另一位孙老师，孙建波老师的文章里我们看到，linux Docker采用了IPC隔离机制。而Windows Docker也采用类似的隔离机制。这个机制就是所谓的会话隔离。

那么Windows里，哪些技术会用到会话隔离呢，盆盆简单总结一下：

首先是终端服务，会话就是为了这个技术而发明的。

快速用户切换，这和终端服务实际上是一样，只不过快速用户切换只会提供最新登录用户的桌面（shell）。

从Windows Vista开始，系统级进程和服务，运行在会话0里，这就是为什么我们无法再用"mstsc /console"命令来登录到服务器的控制台会话。

从Windows 8开始，Metro Application（平板专用的应用），也采用会话隔离技术。

也就是说，会话是为了终端服务这种多用户机制来准备的。

用Sysinternals Suite工具包里的Winobj这个小工具，可以看到会话隔离的效果。

在图中可以看到，不同会话里拥有不同的对象命名空间，例如不同容器，有自己独立的窗口站(终端服务，其他场合只有当前登录用 户才有Winsta窗口站)，BaseNamedObjects目录，包含事件、互斥信号和内存段等对象。不同会话里的应用，不能够发送窗口消息（Window Message，以防止粉碎攻击）。

Windows Docker沿用了会话隔离技术，不同容器在同一个Windows主机上访问同一个命名对象，就不会导致冲突。

在Build大会的演示里，启动了2个容器，都是从同一个Windows Server Core映像里创建出来。在其中一个容器里运行tasklist命令， 显示当前的进程信息，包括会话。

在这个截图中，我们可以看到该容器运行在会话14里。

在另外一个容器里同样运行tasklist。可以看到该容器运行在会话15里。

类似于两个容器，分别通过远程桌面访问一样，拿到不同的会话（session），从而获得namespace隔离能力。

从两个截图里能看到什么？其中System和空闲进程是共享的，这说明Docker是共享宿主机的内核。当然进程号都一样不代表什么，因 为所有Windows里，这两个进程的PID都一样！而每个容器都有自己的svchost进程、csrss进程和wininit进程等。这些进程都是 per-session的。

8. Windows Docker能显示图形化界面吗？

传统的Windows应用大多是有GUI的，所以这些应用可能需要通过图形化方式进行远程操控。Windows Docker会通过容器的RDP服务连 接上来。

图中显示通过RDP服务连接到Process Explorer这个带GUI的系统进程管理工具。由于RDP实际上就是终端服务，所以Process Explorer这个图形化进程相当于又运行在一个新的会话里了！这个说起来有点拗口。

从这张图里我们可以看出，由于Process Explorer是在终端会话里打开的，所以我们可以在容器的任务管理器里看到有两个会话：

1.会话14是Docker自己的会话，在这里尝试启动Process Exploer，但是啥都看不到，这个是正常的，因为图形化界面无法在Docker客户端 里显示，Linux也采用类似VNC/RDP等办法开专门的通道访问。

2.而会话15则是通过RDP访问的会话

9. 创建Windows Docker

和linux Docker，Windows Docker（记住有两个产品，Windows server container和hyper-v container）完全支持linux Docker的接口和工具集。就好比电视机和投影仪，其内部实现固然大相径庭，然其和电脑的之间的接口则几乎完全一致。

创建Windows 容器，和linux一样，有Docker file，直接Docker build，生成Image。

Docker File的简单范例：

From Windowsservercore
WORKDIR \
COPY bin\Debug\ \Deapp
CMD \DemoApp\Demoapp.exe

今后微软的Windows azure云，可以直接支持Docker，不管是Windows还是linux，都可以直接用最新的visual studio把代码签到azure的linux或者Windows容器里。当然也可以直接用azure的visual studio online服务。

10. Windows Docker不同版本，以及linux之间异同

首先分享灵雀云老大左玥老师的PPT。

可以看到session和JO，是Windows Docker的隔离技术，同时JO技术类似于linux里的CGroup。可以参考chrome的相关技术。chrome就是用到了不少Windows的隔离技术。

再看一张图片。

从这里可以看出Windows Docker不同版本和linux之间的异同点。其中Hyper-V Container的安全能力高于Windows Server Container。

Windows Server Container和Hyper-V Container之间的差异，可以参考这个图片。最大的差别在于，hyper-v container支持多租户安全能力，同时支持加域。而Windows server container则不能加域，这意味着如果这个应用需要加域的话，则无法用Windows Server Container。