虚拟机已死 容器才是未来？

我也曾经是容器技术尤其是Docker粉丝，但用了一年后觉得事情也没那么美好，而颇有一些同学以及一些公司依然认为容器就是银弹，虚拟机已经是昨儿黄花必须打倒，大家赶紧一切皆容器。这里我对这种观点吐吐槽。仅代表作者个人看法

首先要明确的是，软件开发和运维活动中，可维护性、正确性、性能的优先级是依次降低的，不要跟我抬杠少数极端情况。关于可维护性和正确性的先后，著 名的 "worse is better" 文章就是很好的无奈的解释，如果你犹豫这两者，这还情有可原，毕竟真善美和糙快猛的斗争从未停歇，而你如果第一反应觉得性能是最重要的，那就不要继续往下 看了，洗洗去睡吧——适合的才是最好的。

那么对于虚拟机vs 容器，自然我们也需要从这三方面考察。

回合一：可维护性之争

虚拟机—维护性

从 hypervisor 讲，Xen/KVM/vSphere/HyperV 都很成熟了，久经考验，BSD 也在凑热闹搞 bhyve(FreeBSD) 和 vmm(OpenBSD)，最近 unikernel 也在试图跑在 hypervisor 上，而 AWS/GCE/Azure 等等云计算巨头以及 Intel/AMD 等在CPU、磁盘和网络IO虚拟化技术上的投资显然不会立马推翻，Linux 上虚拟机的开源管理方案也已成熟定型：libvirt， OpenStack， 没人吃饱了撑的去弄个 “新的开源” 项目替换它们，虽然我很不喜欢 OpenStack 的乱糟和复杂。VM 的动态迁移也是成熟技术，出来好多年了，实现原理非常简单，反正整个 OS 内存一锅端弄过去，不操心少个依赖进程的内存没过去。想用不同版本内核? 想要自定义内核模块?想调整内核参数?期望更安全的隔离?期望如同物理机版几乎一致的使用体验?VM 就是虚拟机的缩写嘛，这些都是拿手戏。

容器— 维护性

Linux 容器，Linux 一贯的作风，慢慢演化，不求仔细设计，然后就是 cgroup， pid/uts/ipc/net/uid namespace 一个个实现出来，凑出一个容器技术，貌似 uid namespace 还是最近刚刚出来的特性。用户空间则更是群雄并起，LXC，Docker，rkt，LXD，各有拥蹇，鹿死谁手，还真不好说，在这个局还没明朗的时 候，Mesos、Swarm、Kubernetes、Nomad 又出来一堆搅局的，眼下看来最吸引眼球的 Kubernetes 俨然有 OpenStack 继任者的感觉，但依然很嫩，没几个人敢在生产环境大规模使用。

Linux容器里进程的跨机器动态迁移我还没听说，不要说是个服务就得有集群有 HA 嘛，可还真有不少用户一个服务就单机顶着呢，就算有热备或者冷备，在线那台机器内存里的东西可宝贵了，轻易不能丢。用Linux容器就不能挑内核，不能加 载内核模块，不能挂载文件系统，不能调整内核参数，不能改网络配置，等等，不要告诉我你能——你是不是开了 docker run --privileged 了? 你是不是没 drop capability?你是不是没有 remap uid?话说某大公司的容器还真就用 --privileged 选项跑的呢。 而 Linux 的隔离不彻底恐怕大部分人都没意识到，/sys， /dev， /selinux 还有 /proc 下的某些关键文件比如 /proc/kcore 没隔离呢。

Redhat 做的 project Atomic 意识到这些问题，正在积极的给 Docker 加 SELinux 支持，指定 SELinux policy，但 Docker 官方爱搭不理，而且 SELinux 这种高端技术是凡人玩的么? 结局大概依然是 "FAQ 1： 关掉 SELinux"。Linux 容器本来并不局限在一个容器里跑几个进程，但 Docker 官方为了加强“轻量级”这词的洗脑效果，搞出个无比脑残的 single process 理念，被无数人捧臭脚，所幸有些人慢慢意识到问题，Yelp 搞了个 dumb-init 擦了一半屁股，还有无数 docker image 用 runit、supervisor 之类的做 /sbin/init 替换，但问题在于这要自定义启动脚本，需要加 ssh/cron/syslog/logrotate 等等边角料——这已然是解决了无数遍的问题，还要解决一遍，不觉得麻烦吗?难道没有人认为这些包的作者或者打包者更善于处理服务启动脚本么?像 systemd 那种搞法还算正道，特意考虑容器环境，跳过一些步骤，但貌似还没做完善，需要手动删除一些 .service 文件。