【ArchSummit北京2015】容器化与Docker实践过程中的利与弊

年度IT行业技术领域收官大会ArchSummit北京2015已于12月19日顺利闭幕。在19日进行的“UCloud技术专场:企业容器化应用实践”活动中,来自Coding、UCloud、大众点评的3位技术专家分享了各自在容器化以及Docker应用过程中所得到的经验与教训,其中内容涉及开发与运维、云数据、私有云平台与Docker的结合等多个方面,为其他容器技术以及Docker的实践者们提供了大量的技术参考与实践经验。

Coding从今年7月份开始就开始逐渐将所有的服务都放在了Docker Container上运行,因此在Docker的使用也有很多心得可以分享。据Coding首席技术官孙宇聪介绍,Coding已经做了Docker的库,维护自己的私有Registry基础镜像,以供开发和生产使用。Coding还参与了Docker开发,比如Upstream,提交过多份Issue / Patch。另外Coding也自研了一套生产环境容器编排系统。

孙宇聪认为Docker技术真正重要的是四个部分——Packaging、Distribution、Runtime、Orchastration。使用Docker,需要先明确自己能用哪个部分,因为这四个部分是结合比较紧密的,但不一定都是合适的。

Coding在使用Docker的过程当中就出现了一些问题,比如发现Docker image是比较无用的。首先Dockerfile在FROM、RUN、CMD / ENTRYPOINT方面都有不同的问题,基础镜像可能基于各种不同的系统,配置文件也不再一起,运行方式更是奇怪,最后可能还是要自己写。Dockerfile打包后生成的镜像会变得非常大,冗余的垃圾信息过多,需要很长的时间进行编译。

针对Docker使用过程当中出现的问题,孙宇聪表示通过大量的实践,发现一开始认为Docker解决了很多问题,后来发现原来是自己对这个问题的理解还不够。Docker在Build和Packaging上带来的启发,是接口统一的重要性。不应该关心一个程序到底是怎么编译出来的,从运维层面来讲,只要接口统一就可以了,然后如何编译都是无所谓的,只要能实现出Build这个结果就可以了。

在Coding的实践中另外还发现,其实Docker Registry同样也不重要。这实际上只是一个FTP,可能还不如自己做的FTP好用,本来列一个目录就足够了,现在还需要导一个API,之前是用的Registry V1,现在用的是Registry V2,Registry V1的客户端还不能访问V2的。

Docker Runtime同样也有很多问题。Docker container在stdout下的子进程Docker Daemon想要做的事情太多,导致Docker Daemon挂掉。Docker container在 stdout/stderr有大量数据传输会导致内存泄露,直至Docker Daemon OOM。另外Docker Daemon在频繁创建container后,会在文件系统中遗留很多垃圾文件不清理,导致磁盘inode被耗尽。Docker里面没有init,Daemon也没有reap子进程fork的很多进程,会在系统中出现很多僵尸进程,最终导致Docker Daemon出现问题。

对于Coding自研生产环境容器编排系统的需求,孙宇聪表示主要出于三方面的考虑,首先Swarm、kubernetes、Mesos都处于早期,跨步不能太大;其次,动态伸缩的需求并没有那么大,需要静态、手动的进行资源分配,而且IaaS也降低了这个需求;第三,对Docker容器的直接接管能力不足,真正需要的功能都没有。

Coding在容器实践方面的关注点,总结起来主要有三点:第一是软件架构的升级——其实做容器化,最终就是软件升级,做微服务、无状态、数据执行分离,这些跟容器没有关系,容器化只是一种手段;第二是研发体系、环境管理理念的升级——容器化做成代码化、自动化比较容易一些,但它不是必要条件,同样可以用别的方式来做;第三是资源管理概念的升级——多留富余量,迁移能力比压榨能力更重要。

你可能感兴趣的:(【ArchSummit北京2015】容器化与Docker实践过程中的利与弊)