Docker 和一个正常的虚拟机有何区别？

问：

我多次重读Docker.io文档，希望搞明白Docker.io和一个完全的虚拟机的区别。Docker是如何做到提供一个完整的文件系统，独立的网络环境等等这些功能，同时还没有如此庞大？

为什么部署软件在一个docker镜像（image）比部署在一致的生产环境上要容易？

答：

当前，Docker内部使用的是Linux容器技术（LXC），这是运行在与它的宿主机器同样的操作系统上。这准许它可以和宿主机器共享许多系统资源。它也会使用AuFS作为文件系统，也为你管理网络。

AuFS是一个层状的文件系统，因此你可以有一个只读部分和一个只写部分，然后将二者组合起来。你可以使系统的共同的部分用作只读，那块是被所有容器共享，并且给每个容器自己的可写区域

好吧，让我们假设你有一个容器镜像（image）容量是1GB，如果你想用一个完整的虚拟机来装载，你得需要容量的大小是1GB乘上你需要虚拟机的数量。但使用Linux容器虚拟化技术（LXC）和AuFS，你可以共享1GB容量，如果你需要1000个容器，假设他们都运行在同样的系统影像上，你仍然可以用稍微比1GB多一点的空间来给容器系统，

一个完整的虚拟化系统得到了分给它的自有全部资源，只有最小的共享。你获得了更多的隔离，但是这是很庞大的（需要更多的资源）

使用Linux容器虚拟化技术（LXC），隔离性方面有所缺失，但是他们更加轻量，而且需要更少资源。所以你可以轻松运行1000个容器在一个宿主机器上，甚至眼都不眨。试着用Xen来实现那个，我想除非你有一个超级强大的主机，不然我看是不可能的了

一个完整的虚拟系统通常得用几分钟去启动，linux容器虚拟技术（LXC）只要数秒，甚至有时时间更短。

对于每种虚拟系统都有反对者和支持者。如果你希望一个完全隔离的和资源有保障的环境，那么完全的虚拟机是你的选择。如果你只希望进程之间相互隔离，并且希望大量运行他们在一个合理大小的宿主机器上。那么linux容器虚拟技术（LXC）是你的选择。

更多有关信息，可以参考这些博客，这非常详细介绍了LXC的工作 http://blog.dotcloud.com/under-the-hood-linux-kernels-on-dotcloud-part

"为嘛在docker镜像上部署软件比在一致生产环境上容易?"我觉得问这个问题是非常愚蠢的

部署一个一致的生产环境说起来容易做起来难。即使你使用了chef 和puppet之类的工具，像操作系统升级，还有一些其它的事情而造成的主机及环境之间的改变，往往是常有的事。

docker所做的事情就是赋予你一种能力，使你可以将OS快照存入一个通用的镜像，并使得在往其它的docker主机上部署时变得容易。对于本地，开发、质量管理、产品等等，都是用的同一个镜像。当然你也可以用其它的工具来做到这一点，但是可能没有这么容易或者这么快。

这对于单元测试是非常棒的。让我们来看看你有1000个测试，而且都需要连接数据库。为了不破坏任何事情，你需要一个接着一个的运行，以便这些测试不会相互影响（每个测试都在事务中，然后回滚回去）。使用Docker，那么你可以创建一个数据库的镜像（image），既然你知道这些测试会运行在相同的的数据库快照下，那么就可以并行地运行所有测试。既然这些测试都是并行运行在linux容器中，那么他们可以同时运行在同样的环境中。这样你的测试会完成的非常快。试着用完整的虚拟机来做这件事。

编辑：来着评论…

　　有趣！我觉得我仍然对于“系统快照”的概念有些模糊，如何没有使用这些系统 镜像（image）会怎么样啊？

好的，试着看我能不能解释。你开始有个基础 镜像（image），然后进行改变数据，并且使用docker提交这些改变,这个会建立一个镜像（image），这个 镜像（image）只包含数据改变的部分。当你想运行你的这个 镜像（image）你仍然需要这基础 镜像（image），然后使用层式的文件系统，将你的映像置于基础映像之上，这个例子中用AUFS，AUFS将不同层融合起来，然后你就会得到你想要的，你只要简单运行就可以了。你可以增加许多的 镜像（image），这些 镜像（image）只会记录改变的地方。

译文链接：http://www.oschina.net/translate/how-is-docker-io-different-from-a-normal-virtual-machine

原文链接：http://stackoverflow.com/questions/16047306/how-is-docker-io-different-from-a-normal-virtual-machine

这是我翻译的国外博客，如需转载请注明出处和原文链接，还要感谢 super0555的帮助

原文链接：http://blog.golang.org/playground