Docker和LXC有什么不同?

原文：http://dockone.io/article/368

【编者的话】Docker和LXC有什么不同? 这大概是很多初学者的困惑所在，为什么说Docker不是LXC的一个替代方案呢? Docker基于LXC的基础上做了哪些有想象力的工作呢? 本文作者就此分享了自己的一些独特见解。

自Docker诞生以来，顶级的云服务提供商们陆续发行了他们的企业级容器服务。

AWS弹性容器服务

微软为下一代云服务推出了新的集装箱技术

Mesosphere加入了对Docker的支持

但是，他们之中的一小部分仍然挂出一些基础问题的QA，像“什么是Docker，Docker和LXC的异同，Docker和VM的比较”。

而在这篇文章里，我们将深入研究Docker和LXC的真正不同之处。

Docker不是LXC的一个替代方案。『LXC』是指Linux内核（尤指命名空间以及Cgroup）的一个特性，它允许其他一些沙盒进程运行在一块相对独立的空间，并且能够方便的控制他们的资源调度。

而基于底层的内核特性的基础上，Docker在上层构建了一个更高层次的具备多个强大功能的工具集：
可移植的跨机器部署。
Docker定义了一个将应用打包的规范，而它的所有依赖都被封装到了一个简单对象里，它可以被传输到任意一台能运行Docker的机器，并且在这里启动Docker的实例之后，它能够确保承载应用的执行环境将会与之前所定义的完全一致。Lxc实现了进程级的沙盒封装，它是可移植部署的一个重要前提，但是要想实现可移植部署，仅仅是这样可还不够。如果你发送给我一份安装到一个自定义LXC配置下的应用副本，那么几乎可以肯定的是，它在我的机器上运行的结果不会跟你的完全一样，因为它绑定了你机器的一些特殊配置：网络、存储、日志、Linux发行版本等等。Docker为这些机器的特定配置定义了一个抽象层，所以它使得这些相同的Docker容器能够一成不变的运行在多个不同的主机上，甚至带上各种不同的配置。
以应用为中心。
相对于机器而言，Docker被用于优化应用的部署过程。这可以从它的API、UI、设计理念还有文档里得到体现。反之，lxc的辅助脚本专注在把容器作为一个轻量级的机器使用 —— 基本上就是一堆启动更快并且内存需求更小的服务器。我们认为容器技术的内容远远不止这些。
自动构建。
Docker为开发人员引入了一个可以用来把他们的源代码自动打包到容器里的工具，并且他们能够对于应用的依赖，构建工具，打包服务等有着完全的自主掌控能力。他们能够自由的使用make、Maven、Chef、Puppet、salt、debian包、RPM包，源码包，或者任意以上的结合，而无需关心机器本身的配置。
版本化。Docker引入了一个类似git的特性来完成一个容器的连续版本追踪，版本之间的差异diff，新的版本的提交，回滚等。历史记录信息里也包含了容器的用户信息以及他是如何构建它的，因此生产环境的服务器你都有充足的手段去一步步的定位到最上游的开发人员。Docker也实现了一个增量上传和下载功能，类似于git pull，所以更换到新版本的容器只需要传输增量部分就行。
组件的重用。
任意容器都能用作“基础镜像”来创建更特定的组件。这可以手工完成也可以做成自动构建的一部分。例如，你可以准备一个理想的Python环境，并且把它用作10个不同的应用的基础镜像。你所定义的标准PostgreSQL设置可以被将来你手上的所有项目重用。诸如此类。
共享。
Docker 有权访问一个公共的注册中心而这里有数以千计的业界人士上传各种各样有价值的容器：任一从Redis、Couchdb、Postgres到irc bouncers再到Rails应用服务器，Hadoop甚至是多个发行版本的基础镜像。该注册中心也包含了一个官方的“标准库”，这里提供了一些由Docker官方团队维护的实用容器。注册中心本身也是开源的，所以任何人都能部署他们自己的私有注册中心来存储和下发私有容器，例如用于内网服务器的部署。
工具生态圈。Docker定义了一个API来自动化和个性化的创建和部署容器。也因此催生了众多的工具集成到Docker，为之提供一些扩展特性。类PaaS的部署（Dokku、Deis、Flynn），多节点编排（Maestro、Salt、Mesos、OpenStack Nova），管理看板（Docker-UI、OpenStack Horizon、Shipyard），配置管理（Chef、Puppet)，持续集成（Jenkins、Strider、Travis）等等。Docker正在迅速的建立以它本身为标准的基于容器的工具生态圈。

原文链接：What is the difference between docker and Lxc? （翻译：吴佳兴）