非商业转载请注明作译者、出处，并保留本文的原始链接：http://www.ituring.com.cn/article/201256
曾金龙就职于迅雷网络，是国内覆盖面最广的“迅雷P2P引擎”核心研发成员。他毕业于中山大学，具有计算机科学硕士学位，他的研究方向是P2P网络、音视频传输和CEP系统。曾金龙对Docker技术有着深入的理解，是国内较早将Docker引入到实际软件开发、测试和部署中的人。他在2015年出版了《Docker开发实践》一书。
问：作为迅雷P2P引擎的核心开发成员，能否谈一下当时开发的经历以及克服了哪些困难？
我一开始工作的时候就进入到了一家在P2P领域NO.1的公司，而且还是核心团队，所以压力非常大。我发现，现实的P2P依然处在第一代P2P的水平，和研究上的P2P有很大差异。我们在高校里面研究的是各种结构化的P2P，叫做第二代P2P。这就意味着即便我是以P2P为研究方向来到了迅雷，但一切都是归零的。这是理想与现实之间的差异，对我个人而言是个困难。
开发上的困难有两个方面，一是新做的项目往往配置基础环境会耗费大量的时间，而且开发不会碰到的问题在测试和运营那里会“莫名其妙”地出现，所以容器是解决程序员痛点的好技术。另外就是迅雷云是全国最大的P2P数据平台，所以里面有非常多分工不同的服务器，有打洞的Punch服务、有索引的Hub服务、跟踪的Tracker服务以及CDN管理服务等，而且处理的数据量非常大。让公司各个事业群的项目组合理管理和使用这些集群确实不容易，而大多数问题都来自不正确的使用，所以我们必须为各个事业群提供更为易用的服务和更加统一的接口。所以我们后面在迅雷云引入了Docker。
问：能否谈一下迅雷云使用Docker的过程？
其实最初的时候，迅雷团队对Docker是怀有谨慎的态度的。不能因为别人说好我们就用，需要先试，真的好我们才敢用，尝到甜头我们才愿意用。一开始我们用Docker来加快团队之间的协作效率，因为通过它部署的环境可以一次构建到处使用，所以开发、测试和部署都能够在一个非常一致的环境中进行，这是很初级的用法。随着对这个模式的认可，迅雷内部越来越多的团队接纳了我们的建议，于是迅雷、迅雷看看、迅雷游戏都采用了Docker，引入到了开发、测试和部署中。
后面我们的服务器项目基本就迁移到了Docker之上。当然，一开始大家对Docker的安全性都会有所顾虑，但其实大多数顾虑都是因为对Docker不够理解而产生的。有了内部产品线的支持，我们后面把迅雷云部分服务器资源用Docker重新部署。迅雷云本身就是一个非常高效的集群系统，现在引入Docker是为了让资源使用更加便捷。因为研发人员的流动性比较高，不是所有的开发者对迅雷云内部资源的使用都熟悉，所以我们现在就是借助Docker去为各个业务的开发提供一套更普适的接口。
问：迅雷云在容器方面做了哪些优化和调整？
一是整合现有的集群，将部分集群更改为Docker集群，特别是新增部分。二、由于迅雷云是一个重数据、轻业务的云，所以在数据管理方面，像Docker的Data volumes和Data volume containers这种简单的方式还是不能够满足，所以我们主要还是以迅雷云自己的管理系统为主。为了能够让Docker之上的业务更好地使用我们的集群，我们添加了适配层。三、调度算法是迅雷云定制优化的。最后，我们有自建的私有仓库，提供常用镜像，让我们的开发更加快速。
问：Adrian Cockcroft是云技术社区中的思想家之一，他将微服务与Docker的结合视为一种颠覆，认为这种开发方式会极大提高开发团队敏捷性和适应性。请问迅雷云团队是否有这方面的实践？对于这方面的技术融合你有什么样的建议？
微服务是把一个原本很复杂的服务解耦拆解为一些相对功能单一的服务，这在迅雷云内部是一直都非常提倡的。我们认为一个服务专心做好一件事是最好的，这对解耦、易用、升级都非常有好处。迅雷内部把Hub服务和Tracker服务都进行了分解和抽象，提供给各个项目组。Hub本身是很复杂的，但我们的服务接口却是个位数，包括对CDN资源服务的使用方面我们也是重构了一套更加简单易用的服务。
有一点很遗憾的是我觉得迅雷云里面做得最好的微服务并没有使用到Docker，也就是我们的“水晶计划”。这主要是因为我们的节点是各种客户端设备，但我们的设计宗旨依然是遵循微服务的。水晶计划的节点是各种各样的设备，差异性非常大。但没有关系，在用户那里，它就是可靠的CDN。我个人觉得微服务加上Docker是非常合适的，因为微服务很重要的一点就是解耦，而采用容器技术来解耦隔离是非常恰当的。再进一步考虑到服务的扩容和迁移的话，微服务设计加上Docker作为载体也是非常合适的。我的建议就是，一个服务一个容器，或者说一种服务，一类容器，这样一一对应地去部署。
问：Docker的image和安全问题一直都受到关注，特别在去年的出现的ShellShock和Heartbleed问题之后，请问在Docker的安全方面你是否有哪些经验可以分享？
其实，越多人使用的技术越安全，但一旦不安全造成的损失也非常大。迅雷在使用Docker这方面一直没有把数据层面交给迅雷云之外的系统。即便是Docker使用迅雷云的数据，也是通过我们的适配层，而通过适配层接进来的操作是要经过授权的，对使用能力也要进行限制，同时操作都是可跟踪和统计的。另外就是对用户的授权管理，严格规范的管理在安全方面很有必要。还有就是做好隔离工作，不仅仅是通过内核的Namespace/cgroup，同时也可以在不同层面隔离，比如VM和容器的隔离等。
问：在ClusterHQ最近的一项调查中显示，只有38%的IT专业人士在生产环境中使用容器，人们对于容器技术使用的顾虑包括安全、数据管理、IT人员技能、永久存储与可靠性等问题。你认为以Docker为代表的容器技术面临的最大阻碍是什么？是否在不远的未来有望跨越技术应用的鸿沟？
我觉得当前容器技术面临的最大阻力是安全问题和管理工具。安全性一直是企业使用容器所担心的问题，而另一个问题就是管理工具，特别是对集群的管理。现有的集群管理工具，比如Kubernetes，并不是很好上手，对于很多运维人员而言，特别是对一些小企业来说，运维人员可能并没有深入地去学习这些工具怎么使用。所以如果这些工具的部署配置和使用能够非常简单，那么容器在实际生产中可能会越来越广泛。
这种情况有些类似于ISO/OSI的参考模型和TCP/IP协议模型，前者从设计上而言是很优秀的，但后者却成了事实标准，为什么？因为简单。所以一门好技术，不但要技术本身好，而且要做到让别人更好地接纳也很重要。Docker相对于以前的诸如lxc的系统是一个进步，我希望Docker能继续做好整个工具链，让Docker集群更加平易近人。
问：Docker, CoreOS, 以及其他业界成员一起创立了“开放容器计划（OCP)”，你认为OCP的成立对于软件开发行业会造成什么影响？
Docker和CoreOS这对竞争对手握手言和，一起成立OCP，对于整个容器生态圈而言是一个非常重大的利好。因为OCP可以让容器技术更加统一化，如果所有的容器都遵循一套标准，那么使用容器的开发者就省了很多麻烦。而且有了统一的标准，就意味着在不同平台上的容器也可以相互迁移，Docker的镜像可以迁移到CoreOS上，反之亦然。破除各自为阵，容器技术会变得更加易用，同时也会加快其在产业上的应用。
问：Docker和CoreOS各自都具有哪些优势？它们的结合会带来哪些好处？
Docker更想去做一个以容器为中心的服务平台，所以它给用户提供了很多便利的操作，还包括一些集群管理工具链。CoreOS则更加侧重容器本身的标准化，CoreOS的开放标准更能够促进容器的开放，这也是OCP的宗旨，此外，CoreOS在安全性和可组合性上也做得更好。它们的结合可以取二者优势，弥补各自不足。
问：Docker最新发布的“Docker试验性发布”是一次有趣的尝试，请问你是否使用过上面的实验性功能？你觉得这个系统的发布对于Docker来说有哪些好处？
如果你指的是out-of-process volume plugins，我有了解但没有使用过。在对数据方面采用插件的形式，让用户自己去适配不同的存储系统是非常有必要的，所以我觉得这个功能非常有用。我在上面也提到了，我们迅雷云就写了一套适配层去操作我们自己的数据系统。所以后面我们团队会去深入地理解这个功能，然后跟进。
问：学习Docker的进阶过程有哪几个阶段？你希望程序员们以怎样的方式使用《Docker开发实践》这本书？
我觉得学习Docker有三个阶段。第一个阶段是对Docker本身功能的使用，也就是入门层，你要理解什么是镜像、容器、Registry、Dockerfile等，了解这些对象的基本操作，能够构建出自己的应用环境来。第二个阶段是能够驾驭Docker集群。这个阶段你需要学习和使用Docker相关的工具，比如Kubernetes、Shipyard、Machine+Swarm+Compose等，根据不同的需求，需要使用不同的工具。第三个阶段就是发现和解决这些工具里面的问题，为自己的场景深度定制。
我觉得程序员可以从两个方面来使用好《Docker开发实践》这本书，一方面可以把它当做开发手册，因为这本书的内容几乎涵盖了Docker所有的知识点，我们对其内容进行了很系统地梳理。所以当你对Docker有什么疑问的时候，把《Docker开发实践》放在电脑前面，随手翻一翻基本就可以解决。另一方面，可以作为案例引导。这本书后面两篇甄选了当前经典的应用场景，一步步带领读者把服务搭建起来，并且把可能遇到的问题都标出来，教读者如何解决。所以，读者也可以参照本书的案例去更好更快地在实际生产中使用Docker，提升效率、少走弯路。
问：《Docker开发实践》的高级篇对Docker生态圈做了非常翔实的介绍和实践，为什么要对Docker生态圈着墨如此之多？对于这部分内容的遴选你有什么样的标准和原则？
Docker本身的操作其实很简单，如果复杂的话，Docker就不会像今天这样成功。然而我所知道的市面上之前所有关于Docker的书籍，都是把基础操作写了一大篇，然后堆砌一些案例，就成了一本书，我认为这是在浪费读者的钱和时间。基础的东西写成几章是合理的，写成一本书就是打肿脸充胖子了。我们在《Docker开发实践》中把这些内容进行了压缩，不想去滥竽充数，也不会去浪费笔墨。
上面我提到的Docker面临的阻碍很大一点就是它的工具链不完善和不易用。你会发现在网络上程序员求助最多的也是Docker生态圈的实践，因为Docker做得还不够好，稍微不小心就犯错。所以，既然基础篇不该讲那么多，而且生态圈又是使用Docker的开发者心中的痛点，那么我就着重笔墨去写这部分，让大家少走弯路。这部分内容看上去有些散，每一章都是讲一个工具或者是一组工具，但是书中选的Kubernetes、Shipyard等都是我们最需要的和最热点的工具，而且它们的构建又相对复杂。所以，我遴选的原则就是，重要又是难点的，我就选。所以这就成了《Docker开发实践》中的高级篇。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。