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

  • 刘羽飞

2015 年 12 月 21 日

话题:数据库云计算DevOps语言 & 开发架构AI其他容器

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

数据库云计算DevOps语言 & 开发架构AI其他容器