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