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