全角度回顾DockerCon 2015
这是DockerCon2015第一天的实况记录,可以看出Docker的战略意图与未来Docker技术方面的走向。
这是在旧金山万豪酒店举办的DockerCon2015第一天的会议实况,这个会议会持续两天;这是我(作者)第一次参加DockerCon,我希望能满载而归。
会议开始播放了一个视频,一个动画视频,是一个工作视频,关于Solomon Hykes如何产生容器想法以及Docker如何诞生的;这个视频非常的幽默诙谐。当视频结束,Docker的CEO Ben Golub走上了舞台。
Golub首先讲了下自己的创业经历,以及他著名的“two fold test”(that it has global significance and that it is easy to explain when you go home for Thanksgiving);也许感恩节测试(Thanksgiving test)不是很有用,但是Golub觉得Docker应该会是个具有世界影响力的产品。Golub说,Docker已经是很多公司构建,发布与运行分布式应用程序的基础构架;而且Docker是容器化进程对工业界与开发方式进行影响与变革的主力军。然后,Golub还谦虚的赞誉了那些创造了 namespace、LXC工具、Cgroups以及所有Docker依赖的低层技术开发商,称Docker正是站在了这些技术与公司的“巨人肩膀”之上才有如今的成功。Golub接着对所有为Docker贡献代码的contributor,以及Docker社区与Docker项目的贡献者提出表扬并表示感谢,当然还包括Docker公司的正式雇员;最后,当然也是最重要的,答谢了所有Docker的用户。
接下来,Golub描述了过去一年Docker开发项目取得的成绩:
- 贡献者增长了183%;
- GitHub上关于Docker的项目增长了515%;
- Docker提供的工作机会增长了1720%;
- 使用Docker构建的应用程序增长了934%(Boot2Docker下载量增加了1456%);
- 容器的下载量增加了18082%(这个是根据DockerHub上镜像下载量来统计的)。
这个话题引出了Golub的关于Docker核心特新的话题——是什么使Docker从一个有意思的项目,变成一种解决方案,然后变成一个平台,最后发展成一种“运动”;Golub总结了Docker未来的5步发展计划:
- 构建一个轻量级的容器;
- 制定容器之间的通信标准,同时降低容器使用的门槛;
- 为容器创建生态圈;
- 使多容器共同运行;
- 创建管理工具,管理容器运行。
这是Golub在2014年DockerCon上提出的Docker发展的5个步骤,然后总结了这些步骤的履行情况。他指出,第3个及其以上的都完成了,现在开始着手处理第4,5。另外,Golub指出关于第3点还能做更多,同时暗示,Solomon Hykes (Docker的CTO)会在大会中讲第4、5的细节。
最后,Dolub声称,虽然这次DockerCon主题是Docker在生产环境的特性;但是,Docker必须能够大范围普及,所有人都要能用,能在任何地方运行,同时要能支持扩展与插拔,同时还需要为企业将Docker部署在生产环境提供真实的解决方案与指引(roadmap)。
Dolub在结束演讲前称Docker可以“撬动地球”,然后将舞台交给了Solomon Hykes——Docker的创始人与CTO。
Hykes在演讲的开始感谢了Docker的贡献者与社区,然后他为与会者描述了Docker要实现的“蓝图”,以及为什么要这么做。他指出,Docker的目标是为万众创新提供低层工具。(The mission of Docker is to build tools of mass innovation)Hykes相信,Docker可以为全世界上所有有新的创新想法但是没有足够的工具去实现这些想法的人搭建一个桥梁——一个连接新技术与全世界热爱创新的人们之间的桥梁。Hykes相信,编程(软件编程)是世界万众创新的最大摇篮,同时他进一步阐述了他要使互联网变得“可编程” (programmable)的论断,同时也是他的最终理想。但是,挡住其去路的是软件之间形形色色的“隔阂”(walled gardens);当然,构建Docker就是为了消除这些隔阂使的。最后,他说,Docker会花5年的时间来实现互联网的可编程性,这也是未来 Docker的使命。
Hykes提出了未来Docker在技术上的4个目标:
- 重新发明程序员的编程工具集;
- 打造更好的软件构件(plumbing);
- 提出制定开放的标准;
- 为企业提供统一的、一致的解决现实问题的解决方案。
Hykes觉得实现第一个目标很重要,因为现在开发分布式应用程序太困难了。为什么呢?因为,变成工具的匮乏。而造成分布式应用程序开发工具匮乏的原因是大部分开发工具都是分布式应用程序出现或者流行之前发明的;因此提升开发人员的体验十分重要,他认为重新开发一套分布式应用开发工具的原则是“增量迭代”(incremental revolution),这个原则有三个要素:
- 发现问题的根源;
- 用最简单的方法解决它;
- 然后重复这个过程。
”增量迭代“的方法论会演变成一个大的改变,但是你必须要留意你的每一次小的改变。在过去两年中,Docker的开发过程就是”增量迭代“的真实写照。比如说容器引擎的开发就是个例子。镜像,Docker Compose,Docker Machine与Docker Swarm都是从解决一个小问题入手的,然后迭代成一个大的项目,大的解决方案。
好吧——什么是下一个要解决的问题呢?
接下来Hykes宣布了Docker还处于实验阶段的release,以及开发者与公司用户如何去测试这个最新版本的方法。
什么是Hykes提出的”下一个问题“呢?是网络。他认为,基础构架(机器)与网络都是应用程序的一部分,必须符合应用程序的需求来构建。 Docker与Socketplane共同努力的结果是还处于实验阶段的新功能——Docker Network——使Docker支持原生的multi-host networking。micro-segmentation被集成到Docker Network中,它可以使用户可以将虚拟网络也纳入到网络的拓扑结构中。这些技术是符合工业标准的。Docker Network使用DNS来做服务发现。为了演示Docker Network的扩展性与可插拔性,Hykes,提供了11个社区的网络与发现服务插件(Hykes points out the 11 community-contributed networking and service discovery plugins)。
Hykes将舞台交给了Ben Firshman来演示Docker Network的Demo版。Ben Firshman将Docker Machine部署在VMware Fusion上,这样他就能在他的笔记本电脑上使用Docker Compose来测试\运行他之前做好的容器与应用程序了。本地测试运行完他的例子程序,Ben Firshman接着使用Docker Swarm与Docker Network将它们部署到生产环境中。他使用Docker Machine创建Swarm集群,同时演示了Docker Compose中”应用程序定义“(application definition)长什么样。接着,Firshman运行”docker-compose scale“来增加web服务器的数量来达到扩容的目的(从现场的demo来看,效果并没有那么好)。Alvin Richards一个Docker软件工程师,接替Firshman来运行这个Demo程序,但是不幸的是,现场演示出现了两个错误,demo演示失败了,甚至Richard备用的视频演示也没有能够演示成功;所以,最后他只能将demo正常运行时的结果阐述给观众听了。
接下来,Hykes重返舞台,重新阐述了Docker Network项目的进展。接着,开始另一个话题——重新打造诚程序员的工具集的下一个问题是解决工具集的可扩展新,即,如何让程序员将自己的工具加入到工具集中?
这引出了下一个要发布的产品——Docker Plugins(同样也是出于实验阶段的产品)。通过这个工具,用户可以将“插件”(plugin)插入到Docker中固有的”扩展点 “(extension points)上,来改变容器运行时的行为;扩展点广泛的存在于Docker的“网络”、“数据卷”、“调度器”与“发现服务”等构件中。Hykes也表示会为Docker设置更多的“扩展点”。使用“插件”并不需要为Docker打补丁,Docker也不需要重新启动以加载所有“插件”。“插件”的使用也很灵活,你可以一次性加载多个,也可以为不同应用加载不同的插件。
接下来,Hykes花了很少的时间对Docker生态圈表示了感谢。接着将舞台交给了Deepak Singh——来自AWS与Amazon ECS。Singh讲述了Amazon支持Docker的历史,比如加入支持Docker的AMI与Beanstalk。所有这些都最终形成了EC2容器服务(ECS)。最后,Singh宣布年底Amazon ECS会支持原生运行Docker Swarm与Docker Compose。
Singh的演讲最终回到了重新发明更好的编程工具集问题上来,并以此结束。Hykes重新上台,将话题过度到他之前提出的第二个目标——“打造更好的软件构件”(building better plumbing)。他重申了打造更好基础构件的重要性,同时提出软件构件的开发原则:
- 尽量重用已经存在的软件构件(plumbing);
- 新的软件构件必须易于使用与改进;
- 遵守UNIX原则(工具必须小而简单);
- 定义标准的接口,使得小的构件可以组装成大的系统。
Hykes强调了那些在Docker中重用的软件构件(Linux, namespaces, cgroups, SELinux, AppArmor, layered file systems, tar, SSH, OpenSSL等等)。Hykes再次感谢了这些工具的开发者,以及它们对Docker的重要性。Hykes进一步指出,Docker50%的代码是基于构件原理开发的(也就是可以被别的项目重用)。Hykes进一步引出,Docker中的软件构件会逐步从项目中分离出去,回到开源社区,供开源社区使用并改进它们。同时,他宣布“Docker构件项目”(Docker Plumbing Project)已经有了成果。
Hykes宣布了Notary项目——一个可信的发布系统,通过它用户可以发布任何内容。Notary是“Docker构件项目”下的产物,“Docker构件项目”的宗旨是将所有Docker的软件构件都用于开源项目中。Notary是一个平台无关的,可以基于任意协议的传输信息的,使用业内领先加密技术的内容发布平台。Hykes将舞台交给Diogo Monica 来演示Notary。
不像之前的演示,Notary的演示非常顺利,完事后,Diogo将舞台交给Hykes。Hykes发布了另一个“Docker构件项目”下产生的项目,关于OS容器的项目——runC。runC是个通用的OS容器运行时(http://runc.io)。 runC支持所有的Linux安全策略(SELinux, AppArmor, cgroups, namespaces, seccomp, cap-drop等);支持用户级namespace与live migration(通过CRIU)。微软正在开发以支持runC。ARM对runC的支持也在进行中。Intel正在开发DPDK与Secure Enclave来支持runC。runC定义了一个标准的,可以移植的,可运行的程序格式;可以通过命令行或者变成的方式启动。而Hykes对runC的标语是“只是个运行时,别的啥也不是。”
接着,Hykes转向了他提出的第三个目标(提出制定开放的标准)。Hykes指出,Docker最具价值的不是它的技术,而是使人们对事物达成了一致的看法——这里说的是容器运行时(container runtime)。Hykes开始阐述Docker对容器标准化所负有的责任,以及Docker如何践行的。那么这个标准是什么呢?它可能包括:
- 容器格式标准;(A formal specification)
- 独立的容器治理方式(Independent governance);
- 中立的引用实现(A neutral reference implementation);
- 广泛的支持(Support from a broad coalition);
- 开放的文化(An open door to fresh ideas)。
Hykes接着发布了OCF(Open Container Format?)一个普适的容器运行格式,与ELF兼容,但是只是针对容器提出。runC会一直支持OCF格式。为了保证“独立的容器治理”,docker与Linux Foundation合作研发Open Container Project,提供对OCF的支持。为了保证“中立的引用实现”,Docker使runC能够支持所有容器技术。为了保证Docker“广泛的支持”,Hykes宣读了一份支持Docker的厂商列表:AWS, Apcera, Cisco, CoreOS, EMC, Fujitsu, Goldman Sachs, Google, HP, Huawei, IBM, Intel, Joyent, Linux Foundation, Microsoft, Pivotal, Rancher, Red Hat, and VMware。为了让Docker有“开放的文化”,所有appc的维护者都能加入“Open Container Project ”,以委员的形式。Hykes接着隔空呼喊了CoreOS,以及感谢它对容器社区做出的贡献。
Hykes重新回顾了下他的4个伟大目标,同时讲述了他的第4个目标(为企业解决实际问题)的大概内容,并介绍了明天的议程,同时表示第4个问题在明天的议程中会详细阐述;并重申:Docker所有的努力都是为人们实现理想与万众创新而服务的。
接着,Hykes宣布今天的议程结束。
原文链接:Liveblog: DockerCon 2015 Day 1 General Session(翻译:肖劲)
来自:http://dockone.io/article/460