好吧，我承认我标题党了。但是这篇内容应该让你从一个新的角度理解Docker的本质是什么。

我们在学C的时候，就有静态链接，动态链接，本质上是程序代码库的复用而已。那个时候我们认为动态链接库是最优的。为什么呢？因为一开始磁盘很贵，内存很贵，网络也很贵！是的，我们节省了硬件相关的东西，但是我们也为处理系统的各种链接库版本而付出了惨重的代价，浪费了程序员多少光年。Hey,身为程序员的你，是不是多次为编译依赖的链接库而苦恼不已。而随着程序规模的不断庞大， 各种依赖冲突也是不断。

现在，是时候让静态链接发挥作用的时候了。你看Docker容器动则几百M。如果是以前，你分发一个程序要几百M,你自己都吐血了，但是现在，大家已经毫不犹豫的感觉什么都没有发生的一样，接受了动则几百M的镜像了。

假设你用Docker运行MySQL。当你使用ps命令，你只能看到MySQL进程，而看不到包裹他的壳(容器)的影子。是的这里的主体依然是MySQL,而不是壳，我们有时候会因为这个漂亮的壳而出现买椟还珠的有趣事情。

既然Docker只是无侵入性的让现存的进程变成具有资源限制的进程,那么进程原来是什么样，就应该是什么样：

• 对于网络，Host 模式足够啦，高效而不带性能损失。其他的模式让你无谓的各种复杂
  
• 对于硬盘，mout 本地磁盘足够了，为什么还有新的文件系统？
  
• 为什么有registry 这个东西？ Image 不就是个文件么，提供一个标准的文件下载服务器存放image不就行了？
  

程序和镜像本身也不是耦合的。只是程序运行的时候顺带加上容器这个壳，从而实现资源的隔离。这种模式该是怎么样的呢？

比如，我部署tomcat服务，以前是要现在服务器上部署调试好tomcat,然后分发war包运行。现在是我把war包放到一个目录，然后运行tomcat docker容器并且加载它就好(我们最漂亮-v参数)。对的，我们只是运行一个进程，并且指定了他的数据目录或者程序目录，就是这样。

MySQL也是，你为什么要纠结能不能把MySQL的存储也放到容器里呢？Docker容器+MySQL 就是MySQL啊，只是给MySQL包了个跨平台的壳，但它依然只是个普通的进程呀,所以数据还是应该在宿主机的磁盘上。

我们的思想会被羁绊，这也是Docker公司的误导导致的，他为什么要在进程里面虚拟出一个文件系统的，而且各种各种的实现，让有选择障碍性的人纠结的要死，因为他是一家商业公司，希望把大家绑定在自己的生态上。所以，把数据剥离出来，和以前一样的方式，Docker容器只是一个壳，我们真正的主题还是被包裹的应用。

推销下我开发的一套容器调度工具： mammuthus-yarn-docker-scheduler