4.1.3. 新组件
Docker Engine也有了一些新的变化,而部分功能实际上早在Docker 0.9就开始提供了。如果你还在运行Docker 0.8及其以前的版本的话,那么还是及早升级的比较好。
libswarm
libswarm是一个"toolkit for composing network services”。它定义了标准接口用于管理和编配一个分布式系统,并提供了一致的API。libswarm打算支持各种编配系统,虽然它看上去更像个高层接口封装的API而已。
libcaontainer
libcontainer是一个容器的参考实现,它通过Go语言实现来使用Linux的命名空间等技术,而不需要额外的外部依赖。
实际上在Docker 0.9的时候这个模块就已经分离出来了,到了1.0的时候,此模块成为了独立项目并且可以单独使用。并且从0.9版本的时候开始Docker就已经开始就采用libcontainer来代替LXC作为默认的容器实现方式了,LXC变成了可选项之一。
libchan
libchan现在是Docker的标准通信层,被称为网络上的go channel,普通的Go channel只能运行在单机上,而libchan可以跨Unix socket或纯TCP/TLS/HTTP2/SPDY/Websocket等运行。使用libchan,可以非常方便的进行任意结构的消息传递、实时双工异步通信、并发编程及同步等。
最后我们再从下面的这张图,更形象的认识一下这三个工具的作用及关系。
4.2. 大公司的热情
如果看一下演讲嘉宾列表注 13,你一定会感叹这阵容太豪华了。不错,很多演讲嘉宾都来自大型互联网公司,比如Facebook、Twitter、Google、Heroku、Yelp以及Group等,很多还都是VP、CTO等高级别的管理人员,可见这次大会规格之高,分量之重。并且他们中的很多人还都进入到了Docker治理委员会。
注 13 http://www.dockercon.com/speakers.html
4.2.1. Google
前面我们已经介绍了Google公司内部的服务都是跑在容器之中的,Google对Docker也表现出了相当浓厚的兴趣。除了他们负责基础设施的VP Eric Brewer进行了主题为《Robust Containers》的演讲之外,他们还介绍了自己开源容器管理软件Kubernetes和对容器资源进行监控的cAdvisor。
4.2.2. Red Hat
Red Hat Enterprise Linux 7版将内置Docker,虽然版本还是0.11,不过很快就会升级的。另外Atomic项目也是Red Hat主导开发的。
4.3. 其它感受
其他一些笔者认为比较有意思的就是使用基于Mesos工具群来对容器进行集群管理了。比如Twitter和Groupon都做了使用Mesos + Aurora/Marathon + ZooKeeper在数据中心进行资源分配和管理的分享;甚至在Twitter看来,数据中心也可以看做是一台计算机,Mesos就是这台计算机的OS。
另外就像我们前面在Docker使用场景中介绍过的那样,很多公司都在使用Docker进行持续集成。
5. Docker现状及展望
在本节我们将会站在一个开放的角度和更高的层次来审视一下Docker的现状,包括其问题点,以及对Docker将来的可能性做一些肤浅的推测。
5.1. 生态系统
Docker的发展离不开其生态系统注 14,我们学习Docker也同样需对其生态系统有所了解。我们可以从下面三点来审视一下Docker当前的发展状况。
注 14 关于Docker的生态环境,大家也可以参考网上有人制作的一份思维导图。http://www.mindmeister.com/389671722/docker-ecosystem
5.1.1. 厂商支持
前面我们已经说过了,包括RedHat等在内的Linux发行商以及Google、AWS、Rackspace等云服务提供商都表示对Docker非常浓厚的兴趣,甚至已经进行了非常深入的实践。从这一点上来说,Docker有非常好的政治背景。
5.1.2. 开源项目
围绕Docker的开源项目就更多了,主要有以下几类,我们将挑选出一些比较有意思且开发较活跃的项目进行简单介绍。
PaaS平台
PaaS平台大多基于容器技术,Docker天生就适合做PaaS。
- Flynn
Flynn是一个高度模块化的下一代开源PaaS实现。Flynn分为两层,Layer 0是底层,也叫资源层,基于Google的Omega论文注 15开发,这一层也包括服务发现。Layer 1则用来进行部署、管理应用程序。Flynn目前开发比较活跃,是一个值得关注的开源项目,而且今年夏天很可能就会发布1.0的版本了。
注 15 http://eurosys2013.tudos.org/wp-content/uploads/2013/paper/Schwarzkopf.pdf
- Deis
Deis是一个支持共有和私有PaaS的开源实现。它支持运行使用Ruby, Python, Node.js, Java, PHP和Go等语言进行应用开发,并能部署到AWS, Rackspace和DigitalOcean等云上。
CI/CD(持续集成/持续部署)
由于Docker的沙箱性、创建速度快等特性,它与生俱来也适合进行CI/CD。很多基于Docker的CI/CD开源方案和服务如雨后春笋般的涌现出来。
- Drone
开源的支持各种语言的CI工具,并且提供了CI/CD服务Drone.io
- Strider CD
开源的CI/CD方案,集成GitHub。
私有仓库托管(Registry)/容器托管
这类服务主要进行私有仓库的托管,根据用户的托管仓库数量收费。Doccker Hub也提供私有仓库的收费套餐。
- Quay
Quay除了能托管私有镜像之外,还能和GitHub集成,使用Dockerfile进行镜像构建。
- Shippable
Shippable支持Github和Bitbucket,并且提供100%免费的服务,包括私有仓库。
- Orchard
Orchard也是一个和StackDock类似的Docker托管服务,它提供了便捷的命令行工具来运行各种Docker命令。同时它也提供免费的私有Registry服务,前面介绍的Fig工具就是此公司开发的。
笔者认为传统的云计算服务提供商除了在云主机上提供对容器的支持之外,说不定将来还会提供专门托管容器的服务。
开发管理工具
软件工程师天生就是闲不住和想尽一切办法要提高自己效率的一群人。这里我们简单介绍两个方便进行Docker开发的工具。
- Shipyard
Shipyard是一个Docker镜像和容器管理工具,除了基本的镜像构建,容器启动等功能之外,它还具有在浏览器中attach到容器的功能,并通过hipache16来进行容器之间的连接。同时它也支持跨节点的Docker管理和容器Metrics采集。
注 16 Hipache: a distributed HTTP and websocket proxy https://github.com/dotcloud/hipache
https://github.com/shipyard/shipyard
- Fig
Fig是一个为了提高基于Docker开发的效率而创建的工具,它通过一个配置文件来管理多个Docker容器,非常适合组合使用多个容器进行开发的场景。
http://orchardup.github.io/fig/index.html
5.1.3. 社区
Docker开发社区非常活跃,除了35名全职员工(外加一只乌龟)之外,还有450名左右的外部代码贡献者。到目前Docker Hub已经拥有超过16000多个应用,在GitHub上也有超过7000个Docker相关的项目,其中不乏很多受关注度非常高的项目。
在Twitter上,科技媒体上以及个人Blog上,每天都能看到很多关于Docker的内容。
线下社区活动也在蓬勃展开中。在世界范围内除了南极洲,Docker Meetup已经遍布35个国家100多个城市,北京在今年3月8日举行了国内第一次的Docker Meetup,当时有超过40人报名参加。而且第二次北京Docker Meetup将在七月中举行,目前正在紧锣密鼓的筹备之中。
5.2. 运用中的问题点
虽然Docker很火,有时候我们也需要反过来看看它还有哪些不令我们满意的地方,或者说在使用上还存有疑虑。当然这里的问题都是笔者个人主观看法,只是非常片面的一部分,各位读者一定要带着批判性的思维去理解它。
5.2.1. Debug、调优
查看日志可能是最简单直接的方式了。当然也有很多人都会在Docker容器中运行一个SSHD服务,然后通过SSH登录到容器中去,不过不建议使用这种方法。
官方推荐使用nsenter注 17工具来完成类似的工作,通过它可以进入到指定的namespace中并控制一个容器。
注 17 https://github.com/jpetazzo/nsenter
5.2.2. 数据管理
这里所说的数据包括数据库文件,Log,用户上传的文件等。
在容器中要想处理数据文件,可能最简单的方式就是通过共享卷标来实现,即docker run -v。但是随之带来的问题是既然是文件,都存在备份问题,如何备份?用ftp或者在容器和宿主机之间共享文件夹的方式?而且随着容器数量的增多,对共享卷标的管理也势必会更复杂。
笔者认为理想的解决方法就是使用云服务,比如数据库使用RDS,文件使用S3。如果不想使用云服务,则可以考虑自己通过FastDFS等实现自己的“云存储”。Log则通过fluentd/logstash进行集计再用Graphite/Kibana等进行可视化。
5.2.3. 如何和配置管理工具配合使用
到底在容器时代,还需不需要传统的Puppet或Chef这样的配置管理工具?当然,从配置管理工具的角度来说,他们都不会放弃对Docker的支持,比如Puppet就已经增加了对Docker(安装、管理镜像和容器)的支持。
但随着不可变基础设施的普及注 18,幂等性将不再重要,因为我们的容器只需要配置一次。要对容器做出修改,可能只需要修改Dockerfile/manifest/recipe文件重新Provisioning即可。而且也不需要在容器内部安装任何agent,这样的话类似Ansible这样纯SSH的配置管理工具比较适合对Docker进行配置。甚至还可能出现专门为Docker的更简单的配置管理工具。
5.2.4. 安全性
是软件就会存在bug,包括安全漏洞,Docker也不例外。就