CSDN首页>

【OSTC2015现场】马全一:使用Docker构建持续集成服务

发表于2015-04-01 10:34| 次阅读| 来源CSDN| 0 条评论| 作者CSDN CODE

摘要:Docker中文社区创始人马全一在会上介绍了如何使用Docker构建持续集成服务。并介绍了目前几款开源工具 Jenkins、Drone 和 Go 等的对比。

2015年3月28日,由全球最大的中文IT社区 CSDN 主办的“开源技术大会·2015” (Open Source Technology Conference 2015,简称OSTC 2015)在北京丽亭华苑酒店召开。本次大会以“社区胜于代码”(Community Over Code)为主题,邀请到了来自全国各地30多位开源业界资深人士发表主题演讲,数十个开源社区现场互动,到场的开源软件开发者、贡献者和开源爱好者总计近1000人。

Docker中文社区创始人马全一在会上介绍了如何使用Docker构建持续集成服务。以下是演讲速记:


马全一:其实去年我也讲过一次。去年主要介绍Docker,去年3月份的时候,Docker不被很多人接受或者知道,去年6月份才真正比较火,国内的开发者社区才开始做,今年就不会特别讲Docker是什么,我就讲一些很核心的东西,包括我今年的方向。大家看过哈利波特,这家公司把Docker的商标在美国注册,所以你真的讲Docker的时候,你就要了解这样的公司。如果在这样的会议里面,你要讲Docker,用了它的Logo,它可以说你侵权,也可以不管你,但是他要怎么做,完全看他的心情。

这个事情从今年1月份开始包括国内的社区,Docker关于它的商标,包括名称的使用,都在为名称纠结。官方说,你不要在域名里面使用任何含有Docker的单词,你可以讲你是Docker,但是你又不能提它的名字,所以我就放了这么一页。其实国内有很多状况,包括CSDN今年都在做Container的会。你不能讲你是Docker,包括域名,域名又是很特别的地方。我们以前有一个Docker域名,这个是07年注册的,我是2013年买过来的。你任何域名里面如果含有Docker的单词,都认为是侵权的。在这点上,我也不是特别的理解,我咨询了国内很多法务、知识产权、律师,Docker在中国没有办法说,有权利这样说,只是说在美国是这样的。总的来说,这个事情是很诡异的。你讲项目,但是又不能讲它的名字,你又要讲它,这是很难的。所以我今年讲基本上都是打XX讲这个事。

今年我想做ContainerOps,今年我开始写程序的时候,都是瀑布式开发,什么时候交工。后来出现敏捷,然后出现持续集成、持续测试、持续部署。所有的这些工作,到现在为止拉近了研发和运维之间的距离。有一些观点认为技术会让研发人员产生很明星或者高水平的开发者。我以前工作的时候,两三个人,从开发之后到上线,最后到给客户服务的时候,都是我们自己做。我要知道前端怎么写,后端怎么写,怎么装服务器,所有的事情都要自己做。出了这种事情我不用很关心,因为有很完整工作链就可以做这个事。上服务器,可以把依赖的环境做好。这时候你再做程序的时候,你很难接触到这些方面了。作为研发人员就不知道怎么编了,你需要调整的时候,你根本不用关心这个问题,因为有人帮你干了。很多做运维的可能也是这样的,如果你没有那么高的需求的时候,就不需要调整,很多工作链已经帮你做了。

越来越自动化了,在这个自动化过程中,DevOps还会往前演进。原来的DevOps是以各种方式的脚本在你所有的流程中帮你串起来。比如说你PUSH一个代码,告诉你的服务器,你说你要做这个项目,这时候你可能要做一些工作,你要写一个脚本,所有的工作要写很多脚本。这个方式,我觉得是比较重的。很多大型团队里,其实都有一个职位,开发配置管理,专门管理这个事情。我觉得这个工作,这个流程是比较麻烦的,因为你用脚本处理的时候,你可能有环境依赖。这个问题用Docker就很容易解决了。Container最容易的就是帮你把研发的环境的依赖解决掉,但是它不是说用了Container再做ContainerOps的时候,就把原来的DevOps抛弃掉,不是这样的。ContainerOps是DevOps的升级版。没有把原来的DevOps的流程改掉,没有把原来的,你在TEMES,大家遵循 DevOps的要求逆转。现在你关心就有一些改变了。原来DevOps的时候,你关心的是SOS怎么在Ops怎么保持它的唯一性和版本的关联。做ContainerOps的时候,你关心的是Container的建造,你关心的是Container版本的变化。我觉得这是Docker产品所带来的核心的理念。

到底什么是Docker?Docker是它的公司也好,是它的技术也好,是它的平台也好,这个很难讲。Docker到底做什么?在它自己的概念有两部分,一部分是它有一个Engine,之前叫DevOpsEngine,后来叫ContainerEngine。比较早的实现使用内核特性做Container技术。它的接口可能不太友好。在这些Library(音译)里面很难用。Docker做了很多改进,然后重写,让你用Container技术的时候,门槛变得非常低,这是它最终的初衷。后来觉得只做Business太小,不符合融资的概念,所以后来搞大概念,就是Container的Engine。 Docker会兼容LXC,同时Docker实现了自己的Container的解决方案。再往后觉得这个概念还是太小了,再做大一点叫 DockerEngine,它要成为Container的代名词,希望成为Container的实施标准。

后来知道的人,一提到Docker就是Container,一提到Container就会想到Docker,最后Engine的核心部分是ContainerEngine,ContainerEngine除了实现了LXC,现在兼容比较好的就是微软的Container,将来微软会有一套Container的技术解决方案。你可以使用Docker命令,在Windows或者在云内部启用Container,或者用Docker的命令启用Windows的Engine。任何软件修改的时候你关掉了,就没有了。这是DockerEngine到状况。Docker发布的时候遵循很多发行的管理。后来有组织,有团队,有管理权限。这是Docker目前的状况。

在Docker整个的环境里面有一场『战争』,国外媒体认为2015年是Container的大战,Rocket有一个比较激烈的竞争,我觉得这个应该是在2016年出现,因为Rocket项目还在初期阶段,所以它要实现跟Docker竞争还需要很长的时间,因为这两者的路线不太一样。Docker对于Container的定义相对来说是比较封闭的,完全在Docker自己的公司控制之下。现在希望大家遵循这样的要求去做,希望有一个公开的标准,希望Rocket是它的一种实现,Docker也是它的一种实现。现在我看Rocket项目介绍里面有4个这样的实现。这个实现,其实都是希望有一个共同的标准。其实大家做这个事的时候,有一个共同的标准制定,所有的人都按这个标准实现。

虽然Docker有一个管理咨询委员会可以和社区沟通这些标准,但是其实在整个制定的过程中,其实社区的发言权还是小于厂商对于Docker的影响。今年比较激烈的竞争是使用Container技术的OS,现在有一个说法是网络操纵系统,包括Ubuntu(音译)。所有的操作系统是今年在技术领域竞争比较激烈的,而且这样的操作系统的技术门槛比较低,我知道国内还有一家公司前段时间也跟我聊,他们也在做类似的公司。从我2013年看到Docker这个项目,它最大的核心价值就是Union File。比如说你在Base这个目录里面,原来有一个Base目录,你跑一个Container的时候,你把所有的这些都放在同一个位置,如果在同一个目录里面,这两层目录里面有相同文件的时候,Docker会遵循覆盖的原则,从上往下你看到最上面的文件,你要修改这个文件,会把它复制到可以写的这个目录里面再去修改。从上往下看,就怕前面的覆盖掉了。我觉得这是在运行期会产生版本管理的概念。以前我们管理的时候,叫运行的管理,你改了一次配置文件,会产生一个新的行为,这个时候你是记录这个Page文件的改变,这时候你要关联的时候,就需要一些脚本。

你每次做一个修改的时候,你都是新产生一层,把原来的一层覆盖掉了。我需要找原来的一层的时候,我找原来一层,以这一层为最后的一层跑起来的时候,我就知道原来的版本。我觉得Union File其实带来了很关键的一个技术点,可以让你生产上的recation(音译)会有一个管理概念。我觉得实际生产落地的时候,可能会有一个Application Version challenge。如果你采用这种方式的时候,其实你会有一个新概念在里面,我觉得这是比较重要的地方。

现在Docker Union File,最早用AUFS。如果这个跟我前面讲的Rocket其实不一样,Rocket没有AUFS层级观念,它就是一个文件。所以有一个项目帮你实现从 Docker整个这一层转为Rocket单一的文件。我跟他们交流过,他们认为这种方式应该成为Rocket或者Application的方式。我觉得这个是到目前为止Docker最核心的。其实这块的技术相对来说是比较复杂的。在下个月的CSDN的会上,我请了京东的天奇(音译)他在实现这种逻辑架构上内核设计上是非常清楚的。如果大家对这方面感兴趣的话,可以再关注他。

我们讲一下如果以Container的方式去做的话,做ContainerOps之前,你可以去看一下,不要把DevOps拓展。这是IBM的云计算设计里面,所有的任何一部分,都是一个服务器,我认为在任何一个服务器上都是以Container方式实现的。比如说我们在研发,我个人觉得没有必要以 WebIDE的方式写代码的话,如果你用这样的方式写代码放到ContainerOps的时候,这样的话就把Dev变成服务器,让所有的研发人员去做。去年我交流的时候,知道成都一家游戏公司,他们的配置管理人员怎么做呢?用Docker专门装gsomon环境里面,他们的研发人员写游戏的时候,需要 4.4安卓SDK就会给Docker的境像,用这个环境去写。WEBIDE或者linux的方式去写也可以。

这是大多公司做DevOps的要做的,然后去做bulild。你做的时候,bulild工具跑到Docker里面。整个的流程是这样的,你要完整的实现它还是很难的,大多数公司产品做的就是第一步,就是做一个bulild,至于是什么bulild那就很难讲了。其实我觉得以Container做Ops的时候,第一步也是bulild,你每次PUSH就做bulild的服务。大多数公司都是用Jenkins。因为Jenkins设计的时候,还没有 Container,所以它的理念不是这样的,所以我觉得应该还会有更新的产品,这是Docker自己讲的,在整个DevOps里面流程是怎么做的?你触发一个流程,bulild一个新的Container的境像,然后到一台服务器,依赖关系做好,访问一个邮件地址发给你的研发人员,测了以后没有问题,然后从一个分支到另外一个分支,最后交给测试组的人,没问题了,再给一个分支,最后进行人工测试,最后再部署到产品上。这是Jenkins讲的流程概念。 ContainerOps概念也是上一次CSDN举办的会上,Container讲的。但是真正以Container为核心的,构架这样的产品的东西,其实还没有。Docker到目前为止,在它的Container核心上做了很多,外围也做了很多工具。但是完全希望Docker为核心把这个工作完成,现在还没有这样的。

我们做了一个项目叫Wharf,当时发的时候,排了第四。我们做Wharf项目的愿景,我们要做一个Container Wharf的平台,这个平台会兼容Docker的规则,会兼容JRocket的规则。Docker的规则有两条,有V1和V2。现在只需要装一个系统就可以兼容V1和V2的协议。现在我们在做一个CI工具,完全以Container为核心的重写的CI。我们花了2个多月的时间研发代码,它的结构设计,其实它是能够让你实现很复杂的bulild的工具的东西,你有很多配置定义,有很多关系的时候,就不能满足。有一个Go的CI工具,有一个流的概念,你可以定义很多并行的bulild的工作,并行的测试,最后完成这件事。我们参照Go的设计和Drone的设计,重新写一个项目。

V1协议里服务器上存的时候,会先问服务器,服务器有这个ID,然后发上去,但是实际上,Docker设计的时候,参照的是DAT(音译)当同一个Docker在两台机器bulild的时候,会出现两个地址,但是这两个地址是重复的。

我今年主要讲的就是我们做Wharf的进展。以Container为核心的DevOps的工具和ContainerOps的工具是没有的,在工具链上是一个空白,这就是我们今年要做的事。

提问:您提到知识产权的问题,这个东西会不会导致限制Docker以后的发展。

马全一:这肯定有影响。看你要做什么,如果你出来讲就要注意一下,他将来是不是要讲你,如果你要做Docker的服务,你就要想,你在服务网站上能不能用 Docker这个单词。比如说在CSDN注册一个账号叫Docker,就认为你侵权了。第一你想怎么贡献。第二你做的事是不是要Open,你是不是要在公开的场合讲。去年我们做的时候,Docker的观点讲,类似做DockerHAB(音译)事,认为我们是做分裂社区。有一家QUIA.OA的也做 Docker的服务,最后也被收了。你要做这件事你绕不开,你在国内,我相信,因为我找过律师和事务所,他们认为Docker没有权利在国内禁止你使用 Docker这样的单词,你使用Docker这个单词是容易打,但是用了鲸鱼(音译)就没那么容易了。Docker用户把Docker的境像,每天拿一份新的给用户用,最后他们就说你这个是违反我们规定的,你不能这么做,反正有很多我也不能理解的事。如果你做一个产品叫Docker什么,你做的很小的时候,也不用介意它找你,但是产生一定经济价值的时候肯定会找你。

Docker这种东西叫Appcation Container,当你不需要的时候,你没有依赖的东西,这些文件都可以跑。比如LIC,看起来像一个操作系统,这两个是不同的应用领域,我认为应该是并存的。你现在想调动一个好的Docker的完整的环境,下面要有一套VM的调动机制。你的业务在openstac里面跑的时候,我需要跑到Docker 的时候,我可以自动分配VM,在Container里面跑起来的这是肯定的。Docker本身有一个很严重的安全问题,它是共享内核的,你跳到内核那一层,基本上就监管主机了。我觉得这是目前无法解决的问题。以Container为单元卖的话,后面要有很强的安全团队搞,还是有人照着他。现在你买一个漏洞几十万美金,你拿到以后把Docker打穿,可能要比打穿KUM更容易,我觉得这是制约它将来发展的一部分。它占的市场份额不应该超过30%。

以上为现场速记文稿,错误疏漏再所难免,欢迎批评指正更多精彩内容,请查看大会直播专题:http://special.csdncms.csdn.net/OSTC2015/
0
0