如何理解 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 和提交将容器和覆盖文件系统包装到一个友好的开发者模型中。只有当你在一台单独的笔记本上操作的时候，像托管，监视，存储和网络这样的弹性扩容问题才会让这个模型复杂脆弱。

另一方面，操作系统容器在操作系统性能上跟虚拟机的相似，这使得运用目前的工具，来集成到正常和分布式系统更加简单，不需要开发任何单独的工具。

Docker 公司受到风投支持，积极投入市场。众多用户在 Docker 的内容中听说到容器技术，但是并不清楚操作系统容器技术以及自己所熟悉使用的。可以看到，用户单纯希望运行容器，就好像运行一个轻量级的虚拟机一样，他们拼命的想做到运用单个应用程序的容器技术，分层结构和持久存储。

如果将工作量从虚拟机转移需要额外的工程工作量，那么很多大规模用户和企业根本不会考虑，而且转移之后，将跟他们其他基础设施的网络，存储和托管都不兼容。

LXC 就是这样获得承认的，不是固执己见，它有容器技术所有平行计算的优点——从虚拟机无缝过渡到 LXC ，而不需要架构师重新架构，这真是一个不可思议的价值主张。

（尊重知识产权，人人有责，小伙伴们转载请与我们联系：）