BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

王振威:Docker的坑与编排系统
录制于:

| 受访者 王振威 关注 2 他的粉丝 作者 InfoQ 关注 13 他的粉丝 发布于 2016年3月15日 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。
32:24

个人简介 王振威,Coding 系统架构师,自封一个很二又很认真的程序员,多年系统软件开发经验,擅长 Linux,Golang,Java,Ruby,Docker等技术领域,进两年来一直在Coding从事系统架构和运维工作,领导公司技术团队进行技术革新,并推进Docker在公司内部私有云平台中的实践。

全球架构师峰会(International Architect Summit,下简称ArchSummit)是由InfoQ中文站主办的一次全球性架构师峰会。ArchSummit专门针对架构师人群,讲述与架构和架构师相关的各方面趋势、技术和案例。这也是继QCon之后,InfoQ中文站主办的又一次高端技术盛会。

   

1. 各位InfoQ的网友大家好,现在我们是在ArchSummit的北京现场,作客我们专访间的是Coding的软件架构师王振威,第一个问题先请您做一下自我介绍,跟介绍一下您在Coding从事的工作。

王振威:大家好,我是来自Coding的王振威,我现在在Coding主要做基础软件架构的改进以及运维方面的工作。我是在Coding创始的时候就加入这个团队,一直做到现在,之前主要做的是代码托管相关的工作,现在主要做运维和架构的改进。

   

2. 刚才您谈到您是从一开始就加入Coding,能否谈一下您之前的从业经历以及为什么加入Coding呢?

王振威:我之前在开源中国工作过一段时间,后来机缘巧合就加入了Coding。Coding是初创,我有幸作为创始团队成员之一,我们几个创始人做了一些比较基础的研发工作,今年就转职做运维和基础架构改进开发。从去年年底到现在我一直在做我们的运维平台的容器技术,也就是Docker的架构引进,以及做一些开发工具相关的工作。

   

3. 我看Coding这边,Docker用的比较多,您能谈一下您个人对于Docker技术的理解,以及为什么Coding选择Docker这种方案吗?

王振威:我们之所以选择Docker作为我们下一步的架构的计划,主要是因为我们之前遇到了一些问题,我们系统比较复杂,牵扯到各种各样的编程语言和框架,这些框架和编程语言做出来的软件、服务程序,交给运维去处理的时候非常痛苦,因为运维不清楚软件具体需要什么样的环境。有了Docker以后,它把整个软件、环境都打包成一个整体。作为运维来讲,对于任何一个程序我们都认为它是一个基础的容器,我们只需要给它分配相应的资源它就可以运行。首先容器在概念上跟我们遇到的问题是比较吻合的,所以我们选择了这样一个解决方案。Docker也是容器里面目前最成功的,所以我们选择了Docker。Docker本身有一个口号,叫做build,ship and run,我们也是基于这个出发点将我们的架构一步一步演化的。

   

4. 你对Docker的理解其实还是基于它的Slogan?

王振威:对,我认为docker的核心就是build,ship and run,它的其他高级的功能我们之前也尝试了,最后都放弃了,应用的最终结果就认为,它最核心也最属于中间力量的功能就是这个build,ship and run

   

5. 您能谈一下现在Coding是如何用Docker技术的?您之前做开发现在做运维,这个过程中肯定踩过好多坑,你挑两个比较典型的给我们解释一下是怎么解决的吧?

王振威:OK,我们现在用Docker是采用了自己写了一套简易的编排软件,比较像Docker官方的compose工具。用的Docker也就是一些比较基础的功能,比如打包,用它的网络也是用host模式,我们没有用它提供的日志功能用的自己文件系统mount进去,也就是说我们并没有使用Docker比较高级的功能,只使用它比较基础、比较可靠的功能作为我们的服务支撑。我们在Coding的架构演化主要遵循的理念就是平滑演进,能从传统架构慢慢变到最终的Docker环境里面。我们用Docker的过程中也会遇到一些问题,两个问题,一个是在Docker的可能是1.9版本以前,具体我不太记得,有这样一个Bug,它的容器的标准输出在输出大量数据的时候,容器会挂掉,甚至Docker daemon会挂掉,内存会出现爆炸式的上涨,直到docker daemon被操作系统oom。我们找到重现方案,并给官方提供了重现方式,他们在1.9.1,也可能这个修复还没有上到最新的release里面,但是这个Bug已经被他们修复了,这是其中一个。另外我们之前有一个应用场景,用户每进来一个请求我们都要启一个新的容器的场景,我们每天都有几十万的请求的量,后台只有三、四台服务器处理这样的请求,最后导致Docker daemon内存会缓慢增长。另外它的文件系统出问题了,container在停掉的时候,会残留很多小文件,最终导致文件系统的inode结点被占满,从而导致Docker daemon无法正常工作。这是另外一个问题,后来我们还是采用了使用单个进程处理的方式解决。Docker可能在某种条件下不适合用每一个请求都起一个container这种完全理想的状态下去处理我们的业务逻辑。

   

6. Docker跟存储和数据库怎么配合?之前Docker不能做存储,后来它好像又集成一些东西做存储,你们有没有遇到过跟存储相关的问题?

王振威:我们都是直接用文件系统mount到Docker容器里面,包括数据库也是这么干的,近期,我们上个月才完成了一次把我们主站的数据库迁移进Docker的工作,也是使用文件系统直接把数据库的文件目录mount进容器里面启动。

   

7. 挂载完之后如果要做数据迁移呢?你们可以直接做吗?

王振威:如果是做热迁移,我们就使用数据库的镜像机制,直接把数据同步到另外一个slave机,再通过业务层面迁过去。如果是冷迁移也好办,就是把容器停掉,把目录通过工具再传输到另外一个服务器上去。大致就是这样。

   

8. 最近我们看到Coding正在全面推进各个应用组件在Docker中构建项目,并且在Docker中运行,现在进行到什么程度?

王振威:我们现在的组件已经进行到大概90%都是在的Docker中运行。在Docker中构建分为两部分,一个是生产环境,一个是开发环境的构建。现在开发环境正在推进一种叫Coding local的机制,就是开发环境所有的测试、调试组件都运行在Docker里面,而且编译在Docker里面。为什么编译在Docker里面?存在一个问题,我们的生产部署环境都是 Linux,但是本地的开发环境可能有Windows、mac,我们担心因为编译工具链包括编译环境不同会导致一些问题,所以强制要求开发者都把程序原码放在Docker容器中构建。很简单,把Docker原码目录mount进Docker容器。比如说golang,你把golang的原码mount进去,然后使用golang1.5 Docker基础镜像,里面已经装好了Docker相关的工具链,编译好以后把二进制文件拷贝出来,这个二进制文件就是一个在Linux上ready to run的包,再把这个包打包进Docker image,我们的构建工作就完成了。生产环境和开发环境我们的目标期待是一样的,但是现在还存在一些便利性的问题,生产环境可能不需要考虑便利性,只是要最终的安全、稳定,但是本地很多时候要考虑一些便利性的问题,所以目前两者还没有完全融合到一起,但这是我们的一个目标。

   

9. 刚才您说开发环境,我又想到一个问题,如果编译器的版本有一些update,这时候容器需要再重新生成吗?

王振威:我们之前也遇到过关于编译器的版本,比如说Java JDK7和JDK8,它们编出来的class文件是不兼容的,我们系统中也有不同的应用会用到JDK7和JDK8,我们自己会维护一个基于官方的JDK7和jdk8衍生的基础镜像,在这个基础镜像里面我们会做其他的定制,比如说时区、local的设定,让它更适合于我们的条件,开发者把程序交付给运维的时候,必须告知我们这个程序要在什么环境下编译是用maven或者gradle。我们会选择合适的image把原码打包进去进行构建。要求的是生产环境和开发环境都是一致的。

   

10. Coding如何将原来本地运行的程序的构建过程转移到Docker当中去?

王振威:刚才我也大致提到这一点,问题在于很多时候我们本地的电脑上可能只允许你安装一套JDK,或者你也可以装多套开发环境,比如说ruby很多版本你可以装rvm解决,JDK很多版本可以通过其他方式解决,但是如果有了Docker这些问题就天然解决了。

   

11. 比如说环境变量?

王振威:这跟环境变量没有什么关系,比如说我们需要JDK7编译时候,就把Docker file中的JDK1.8改成1.7就可以了,需要1.8的时候,就把1.7改成1.8。编译出来的文件是相应环境下的二进制文件。

   

12. 这个Docker image是同一个吗?

王振威:不是同一个,不同的环境肯定要打包不同的。

   

13. 据我们了解Coding现在并没有使用现成的容器编排系统,是自己写了一套,为什么这么做?

王振威:我们做过一些考量,比如K8S我们有在内部尝试用它,但是发现它非常不接地气,具体来讲,第一它有很多高级复杂的功能我们目前是用不到的。第二我们需要的一些功能它是没有的。另外一个问题如果我们整站或者说整体一套系统迁移到K8S我们的成本跨度非常大,这是最重要的原因。我们没有办法一步一步把我们环境演进成K8S。所以我们做的是基于现有的架构慢慢把我们现有的进程、服务搬到Docker。现在主要做的这样一个工作。

   

14. 好像国内基本上用K8S的不是很多,那些大的电商都是自己写的一套系统,不大用K8S,就是因为它不接地气,是因为我们国内外开发的东西不一样还是因为业务上的不一样?

王振威:我觉得真正深入的去使用Docker这种团队,最终不一定会选K8S的原因在于我们都是基于现有的架构去演化,并不是全新的从零开始的一套东西,如果从零开始的话,整个程序最开始设计就可能会考虑使用K8S,或者应用设计会更倾向于向它靠拢,这样的话用起来就会非常方便,它也会成倍提升开发和运维的效率。但是如果是一个既有的系统一下子跨度到K8S,迁移成本太高,而且风险太大,一般公司无法承担。

   

16. 您认为目前Docker还存在什么问题吗?比如网络安全问题,还有没有其他问题?

王振威:Docker的问题在于现在扩的面有点太宽了,需要更注重作为容器的基础功能的研发。比如说它现在一些比较杂乱的没有什么意义的功能,不过也可能我是从使用者角度考虑,他们从Docker公司领导者的角度考虑,可能会有不同的意见。我认为他们做的一些,比如像Docker machine、swarm,包括Docker的多种网络模式,这些跟容器本身没有太大的关系,Docker本身需要更专注于搞容器技术,他的口号喊的比较好,快速交付。另外一个容器本身就是为了解决隔离性和安全性的问题,我觉得他们需要更多的着重这方面。

   

17. 刚才你说到安全性,因为Docker官方宣布他们有两个安全方面的强化措施,其中一个是用物理的Key对容器进行签名,你觉得这会不会在一定程度上改善容器的安全性?或者说这个东西,我还要整一个硬件过来,在国内这个是不是好推?

王振威:关于安全性问题,尤其对容器或者对镜像签名的工具我认为是有必要的,尤其在公有云上,比如我们下载一个软件,Docker image编译到最后它也是一个程序包,就是一个程序,这个程序不管传到哪,可能在某个过程中就被人篡改了,会出现一些问题,所以签名也是必要的,但是签名有没有必要用硬件确实是另外一个程度的考量,比如我们可以用PGP之类工具来做这个工作,因为它毕竟是一个文件,跟其他的文件没有什么区别。另外一个在私有云里面,可能需要更关注的是关于网络,包括资源的隔离性这方面的一些考量。

   

18. 安全方面还做了另外一个工作,就是对容器进行安全扫描,比如说突然爆发了某一个漏洞,我们随便举个例子,假如用的是Java的某一个环境,但是java现在出现了一个反序列化的突发漏洞,他会对这个漏洞扫描然后官方及时打补丁,这个措施会不会更好?你们是不是会做这方面的工作?

王振威:这个做得还是很好的,我们不管是用容器、操作系统还是各种的生产环境,毕竟最终Java的程序是要靠Java运行时驱动的,如果Java的运行时有BUG,不管什么样的环境都需要及时解决这个问题,所以我觉得Docker在这方面还是做得很好的。

   

19. 最后一个问题,你觉得未来容器技术的发展方向是什么?基于这个发展方向,Coding会怎么做?

王振威:现在容器也有好几家在做,包括一些业界的巨头,他们共同成立了一个组织叫open container,这可能是容器未来的发展方向,Docker也会渐渐向open container接口靠拢,以后容器可能就不再是Docker一家独大,像一些企业,比如说vmware、GOOGLE,他们内部的容器如果能接入open container的接口,那我们的选择就会更多。

   

20. 你是说大家都是一家?

王振威:大家都遵循这种公开的接口,我们不会受一家所累,因为大家的接口都统一的,比如虚拟机你用AWS的虚拟主机,某一天想迁移到ucloud或者阿里云,在底层来讲他们虚拟机的镜像都是可以共享的,所以是有这种迁移能力的,因为他们遵循了同样的接口。

InfoQ:好,谢谢你接受我们今天的采访!

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT