前言
这几年，准确说应该是前几年，容器的浪潮席卷了整个互联网，Docker作为容器的领导者可谓风光无限。一时间几乎所有的互联网IT公司都要上Docker，招聘职位也多了各种“容器工程师”，各种公众号纷纷发表文章“微服务为什么一定要上Docker”云云。整个互联网行业对Docker的追捧有如大跃进一般的热情。当然，这其中也有个别不一样的声音，不过这声音太过微弱，完全淹没在这浪潮之中。
这一两年随着K8S的崛起，Docker的影响慢慢弱化，K8S渐渐主宰了容器帝国。现在看来，Docker只不过是那卒子，K8S才是那将军。
虽然这几年耳濡目染了Docker的各种传教，但作为一个运维人员，大部分时候对Docker实在是喜爱不起来，总结一句话：Docker在标准交付、环境一致性和资源隔离等方面所带来的优势，完全被它所带来的复杂性等问题所抵消了。
一些前提声明
1、环境
在开始讨论之前，我觉得要先明确一下环境的具体含义。在一个软件从开发到上线的过程中主要包括三个环境：
- 编译环境：将代码编译成可运行的应用程序的环境，不在我们的讨论范围之内。
- 运行环境：让应用程序运行起来的环境。对于java应用来说，包括jdk版本、各种jar包等等；对于python应用来说，包括python版本、各种模块等等。
- 业务环境：让业务逻辑正常提供服务的环境，这通常是别的应用来提供的，比如依赖的数据库、缓存、rpc服务等等。
在网上所有关于Docker的讨论中，所涉及的环境都是运行环境。而在后面的篇幅里会看到，业务环境的问题才是应用部署和运维要解决的主要问题。
2、Docker的比较对象
还有一个需要澄清的地方，目前看到的几乎所有文章都将Docker与虚拟机作比较，因此得出了Docker要更轻量、更快速的结论。但是，站在运维的角度来看，无论原来的应用是部署在虚拟机还是物理机上，使用Docker以后，都是在原有的基础上在操作系统与应用程序之间加了一层Docker的封装。由此可以得出：从系统复杂性的角度来说，Docker（以及里面跑的应用程序）对应的是原来的应用程序（进程）,它无疑增加了系统的复杂性。
运维与Docker的目标
运维简单说就是管理应用的交付和运行维护。运维会有各种规范来尽量保证环境和配置的一致性。这些规范规定了服务器如何选型、安装什么操作系统、如何命名、如何安装应用、安装什么版本的数据库、要监控哪些东西、如何监控、如何告警等。保证环境一致性是运维人员的一项非常重要的工作内容。
Docker的设计目的是为了让应用程序能一次构建到处运行，实现原理简单说就是提供了一个类似于虚拟机的封装，但要轻量很多，应用运行在这个“虚拟机”里。在这一点上Docker与Java虚拟机类似。
不难发现，Docker的设计出发点是默认运行环境是不一致或者难以做到一致的，而且为了达到适配不同环境的通用性，必定会在某些方面有所牺牲。因此，在这个前提下设计出来的产品对于特定的场景肯定不会是最佳选择。
对于专业运维人员来说，在大多数场景中，完全能通过其他更简单更有效的方法来解决运行环境的一致性问题。
docker的优点
先来简单看一下目前业界普遍所认为的docker的优点：
1、环境一致性
准确来说，这里的环境指的是运行环境，即应用所依赖的运行环境全部打包在Docker镜像里了，无论拷贝到哪里都能马上运行起来。
2、标准交付
如果想要测试开源软件或者搭建开发环境，传统做法是下载源码、编译、配置、启动，对于比较安装部署比较复杂的软件，该过程可能会非常痛苦。而Docker能将整套系统打包到一个镜像里，我们只需下载镜像并运行即可。
3、资源隔离
Docker能限制每个容器的资源使用，确保容器不会抢占主机的资源。同样该特点有点像JAVA虚拟机，但Docker能够限制除内存外的CPU、磁盘IO等资源。
Docker的优点真的有优势吗？
可以看出来，这些优点都是确实存在的。但是，这些优点所适用的场景范围非常有限，来具体分析一下：
1、Docker真的能解决环境的问题吗？
Docker鼓励“一个容器一个进程(one process per container)”，这也是业界的普遍做法。这种情况下Docker解决的只是应用（进程）的运行环境问题。而现在的系统，特别是微服务架构，都是由多个应用相互调用来提供服务，作为业务环境的服务依赖问题才是环境的核心问题。有过一线运维经验的运维人员都知道，90%以上的各种环境问题都是业务环境的问题，而这个是Docker解决不了的。
2、生产环境交付无优势
同样是基于“一个容器一个进程”的原则，交付到生产环境时，传统方式完全可以做到标准交付，容器镜像的交付方式并无优势。而由于镜像文件比原来的应用要大很多，甚至会增加交付时间。
3、资源隔离优势不明显
一是Docker的隔离性不好，二是资源过度使用的问题有其他的方式来监控和预防。
docker带来的问题
1、复杂性
为了隔离现有业务网络，Docker虚拟出一个新的网络，增加了网络复杂性。表现在：
- 增加了一个新的网段
- 启用了原本不需要的iptables服务用于转发流量，该特性同时会降低网络性能
复杂性增加了，安全性势必会降低。
2. 性能损耗
前面提到过，从运维角度来看，Docker对应的是传统方式的应用程序（进程），因此，它必然会在CPU、网络IO及磁盘IO方面带来性能损耗。
3、成本增加
同样将Docker与传统方式应用进程对比来看，网上所说的Docker能节省成本简直是无稽之谈。Docker只会增加内存和磁盘空间使用的成本而不会减少。
Docker受追捧的原因
那么，为何Docker如此受互联网IT行业从业人员的追捧呢？我觉得有以下原因：
- 降低了开发人员搭建开发测试环境和试用新软件的难度，提高了开发效率，因此开发人员在行业内对其广泛传播。
- 云计算厂商和培训机构等对Docker等新技术（背后的商机）的推波助澜。
- K8S的支持。有作为互联网巨头的谷歌公司的K8S支持，众信徒唯恐跟不上脚步。
- 国内IT行业技术跟风严重，想做一件事的理由仅仅是因为别人做了。而在这个过程中，一些公司的老板起到了不可忽视的作用。
- 没有反对意见或者反对意见很少，运维人员相对于开发人员来说数量上相差太多，人微言轻，意见得不到重视。
总结
最后，总结一下，对于开发人员来说，搭建开发环境或试验新软件，Docker能够发挥明显的优势，提高开发效率；但是对于运维人员来说，Docker所带来的复杂性超过了其优势，在大多数场景下，完全有更好的方案来解决Docker所要解决的问题。所以，Docker并不是运维的瑞士军刀，充其量只是一把指甲刀。
