转载

如何理解LXC与Docker之间的主要区别

【编者的话】这篇翻译文章从两个部分来探讨LXC，LXC和Docker的容器托管，以及轻便的容器技术将取代虚拟技术的可能性。LXC有可能会改变我们如何运行和缩放应用程序。Dr.Rami Rosen 做过一个很棒的演示文稿，是关于LXC的前世今生，其中还不乏有趣的观点和内容。

两者的概述

容器技术独立运行并且从主机系统上封装应用程序工作量。把容器想象成可以安装和运行应用程序的主机操作系统里面的操作系统，从实用目的来讲，它就像一个虚拟机。

LXC项目给不同配置和用户空间应用提供最小的容器操作样本来管理容器生命周期， LXC项目的这个特性和Linux内核使模仿机制能够正常启用。

便携性

容器技术将应用从主机操作系统上解耦下来，摘录该程序并且使之在任意支持LXC的系统上都实现轻便化。低调的说法就是：非常好用。用户在这样一个原始和最小库的Linux操作系统上可以在容器里运行任何程序（就像是在容器里运行LAMP堆栈）。

因为应用程序和工作量是相对独立的，所以用户可以运行多版本的语言，比如PHP，Python，Ruby，Apache，这些语言都可以共存，隐藏在容器里。实现云计算，就好比是这些例子和工作量都可以灵活的被移动到别的系统，复制，以及快速配置。

难道虚拟技术就做不到吗？

不不不，虚拟技术也可以做到，但是会有一定程度的性能损失，灵活度也会下降。容器技术不是模仿硬件层次，而是在Linux内核里使用cgroup和namespaces来打造轻便的、将近裸机速度的虚拟技术操作系统环境。因为不是虚拟化存储，所以容器技术不会管底层存储或者文件系统，而是你放哪里，它操作哪里。

这从根本上改变了我们如何虚拟化工作负载和应用程序，因为容器速度比硬件虚拟化技术更快，更加便捷，弹性扩容的更加高效，只是它的工作负载要求操作系统，而不是Linux或特定的Linux内核版本。

那VMWare就这样玩完了？

没那么快！虚拟技术相对成熟，又有广泛的工具，还有生态系统来支持它在不同环境下的配置。至于工作负载，它要求非Linux操作系统，或者只能使用特定的核心虚拟化技术。

LXC

LXC起源于cgroup和namespaces在Linux内核方面的发展，它支持轻便的虚拟技术操作系统环境（容器技术），Daniel Lezcano和Serge Hallyn做了一些它的早期工作，这个可以追溯到2009年在IBM的时候。

LXC系统提供工具来管理容器，先进的网络和存储支持，还有最小容器操作系统模板的广泛选择。它目前由一个两人的团队领导：来自Ubuntu的Stephane Graber和Serge Hallyn。LXC是由Ubuntu支持的。

如何区分他们

生产Docker的目的是为了尽可能减少容器中运营的程序，减少到只运营单个程序，并且通过Docker来管理这个程序。

有了Docker，可以从底层应用程序通过Docker来配置，网络，存储和编排。

LXC用正常操作系统环境回避那个问题，并且因此可以快速兼容所有应用程序和工具，以及任意管理和编制层次，来替代虚拟机。

除此之外，Docker使用层次，禁用存储持久性。LXC支持AUFS层次和覆盖，对COW克隆和用brtfs、ZFS、LVM Thin快照广泛支持，并且将选择留给用户。LXC容器技术里的分散存储是绑定安装的，来为用户达到主机或者另一个容器。

Docker和LXC都设置了一个默认的NAT网络。另外，Docker设置一个端口转发到主机上，就会有一个－p标记，比如“－p80:80”就是80从主机转发到容器。有NAT，本地主机就可以直接通过IP访问容器，外部服务需要的时候可以通过IPtable规则来简单完成，当外部服务被消耗的时候，只需要端口转发就可以。至于为什么需要这么做，原因目前还不是很明确。

要把事项复合起来，Docker只给了很少的IP和主机文件控制权，所以不能给容器设置静态IP，这对于IP的分配任务来说有点让人疑惑。我们需要使用“－－Links”标记来连接容器，这个容器中要在被连接的容器中加一个入口在／etc／主机上。

有了LXC，分配静态IP，动态IP，使用多网络设备就简单多了，可以使用／etc／hosts文件，基本上使用Linux网络全栈是没有限制的。您希望在主机上连接容器吗？用户使用GRE，L2TPV3或者VXLAN来快速设置层次，或者是任意的在使用的网络技术。

LXC容器技术可以无缝运行虚拟机运行的一切。

Docker

Docker是dotcloud也就是现在的Docker公司在2013年3月发布的，一开始是基于LXC项目来创建单个应用程序容器。Docker现在已经开发了他们自己的直接使用核心namespaces和cgroup的工具：libcontainer。

分层容器

Docker最开始是基于LXC对Aufs的支持来建立分层容器，因为Aufs可能无法被合并到核心中，所以现在对Brtfs、设备映射和覆盖也添加支持，

Docker容器技术是由基底镜像构成，当提交变成Docker镜像的时候会再加上一个分层面板。当运行一个镜像的时候，它的复本就作为容器被启动了，在提交之前，它的任何数据都只是暂时的。每一个提交都是一个独立的镜像，所以可以从镜像开始。

我们在《如何用LXC覆盖》里有一个指导说明，它给用户描述了分层结构是如何工作的。有了像Aufs或者覆盖（他们在实施上、性能上有区别，而且支持一定数量的低一点的层次）这样的文件系统的联合，较低一点的层次是只读的，而较高一点的层次是在运行的时候是可读可写的。在容器内容中通常是基底操作系统，但是也不是很必要，而上层的图层面板则是由你来修改。

虽然图层面板的想法听起来很不错，但是分层文件系统在技术上仍然是不成熟的，在使用图层面板的时候，还有有一个固有的复杂性和性能的损失。《陷入图层面板》是一个真实的冒险实例，大家不妨看看。

单个应用程序容器

Docker将容器技术限制到只能运行单个进程。Docker的底层镜像操作系统模版不是为运行多个应用程序，进程设计，也不是为像init，cron，syslog，ssh等服务而设计。

我们来看早期的东西，它介绍了日复一日的用户场景有一定的复杂性。因为目前的架构，应用程序和服务是为正常的多程序操作系统环境设计的，所以需要去寻找一种以Docker的方式来工作或使用工具来支持Docker。

拿一个简单的应用程序举个例子，比如WordPress。你可能需要建立3个容器来互相消耗服务。PHP容器，Nginx容器和MySQL容器加上2个分别用来放MysqlDB和WordPress文件持久性数据的容器。然后通过适当的权限将WordPress文件安装成PHP－FPM和Nginx两种语言都可用，然后为了把东西弄得更加让人兴奋，找出一种能够让容器在本地网络上可以互相交流的方法，不需要对网络不定时的控制，也不需要Docker后台程序设置IP！但是我们还没有计算WordPress账户管理的cron和Email。哎！

为了在Docker里运行多个程序，你需要shell 脚本，或者是一个分开的程序管理，比如runit或者管理器。但是Docker生态系统会将之视为“反模式“，而且Docker的整个架构是建立在运行单个程序的容器上的。

代码库

Docker为用户提供公共或者个人push和pull镜像的数据库。这个跟Flockport app Store为用户使用容器做好准备有点相似。这样做，对用户来说，分享和分布应用程序就很简单了。

Dockerfile

Dockerfile是一个告诉Docker如何从镜像用特定的应用程序来创建容器的脚本。跟使用特定的安装好的应用程序通过bash脚本来创建一个LXC容器相似。

跟LXC拉开距离

LXC的特点需要通过Docker团队来重载实现，使之在Docker中可用，比如LXC现在支持让非根用户创建和配置容器的未经授权容器，LXC现在还致力于实时迁移和多主机管理。这些对容器来说都是很大的进步，也为更好的安全性，多租户工作量以及虚拟平价铺平了道路。

Docker还不支持这些。随着最近的libcontainer声明，推测两者间的差距还将增大。

运行容器的方法没有对错之分，容器怎么用主要取决于用户，docker方法是独特的，而且还将在每个阶段自定义途径成为必须途径，并以此来找到Docker的方法从安装和运行应用程序来完成任务，完成弹性扩容。

前景

虚拟技术通过操作系统和应用程序被冻结在一个状态，使云计算成为可能，并将之转化为可以从硬件和操作系统上轻易转移。操作系统添加了很多：速度，灵活性以及可移动性，扩大了潜在价值。

Docker擅长用dockerfile和提交将容器和覆盖文件系统包装到一个友好的开发者模型中。只有当你在一台单独的笔记本上操作的时候，像托管，监视，存储和网络这样的弹性扩容问题才会让这个模型复杂脆弱。