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

Posted 2023-03-25

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也实现了一个增量上传和下载功能，类似于gitpull，所以更换到新版本的容器只需要传输增量部分就行。组件的重用。任意容器都能用作“基础镜像”来创建更特定的组件。这可以手工完成也可以做成自动构建的一部分。例如，你可以准备一个理想的python环境，并且把它用作10个不同的应用的基础镜像。你所定义的标准postgresql设置可以被将来你手上的所有项目重用。诸如此类。共享。Docker有权访问一个公共的注册中心（/）而这里有数以千计的业界人士上传各种各样有价值的容器：任一从redis，couchdb，postgres到ircbouncers再到rails应用服务器，Hadoop甚至是多个发行版本的基础镜像。该注册中心也包含了一个官方的“标准库”，这里提供了一些由Docker官方团队维护的实用容器。注册中心本身也是开源的，所以任何人都能部署他们自己的私有注册中心来存储和下发私有容器，例如用于内网服务器的部署。工具生态圈。Docker定义了一个API来自动化和个性化的创建和部署容器。也因此催生了众多的工具集成到Docker，为之提供一些扩展特性。类PaaS的部署（Dokku，Deis，Flynn），多节点编排（maestro,salt,mesos,openstacknova），管理看板（docker-ui,openstackhorizon,shipyard），配置管理（chef,puppet)，持续集成（jenkins,strider,travis）等等。Docker正在迅速的建立以它本身为标准的基于容器的工具生态圈。 参考技术A 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的方法从安装和运行应用程序来完成任务，完成弹性扩容。

LXC 和 libcontainer 之间的区别 [关闭]

【中文标题】LXC 和 libcontainer 之间的区别 [关闭]

【英文标题】：Difference between LXC and libcontainer [closed]

【发布时间】：2016-03-13 03:57:49

【问题描述】：

在浏览 docker 文档时，我发现 docker 现在使用的是 libcontainer 而不是 LXC。有没有人知道 libcontainer 如何比 LXC 更好（如果是这样..）？

【参考方案1】：

Linux Containers (LXC) 在 docker 0.9 之前使用（在 March 13, 2014, with the release of version 0.9 上，Docker 放弃了 LXC 作为默认执行环境，并用自己的 libcontainer 库替换它）作为 docker 的一个执行驱动程序，并为Linux 内核包含特性。它非常特定于 Linux

libcontainer（现为opencontainers/runc）是一种抽象，以支持更广泛的隔离技术，如described in this article

这意味着 Docker 将自己从其原始实现中抽象出来，允许其他供应商（如 CoreOS）实现自己的容器版本。

---

注意：从那时起（What’s the difference between runc, containerd, docker?）显示：

在 2016 年，容器空间蓬勃发展，docker 决定将单体架构拆分为多个独立部分，其中一些甚至可以用于其他项目 — 这就是 containerd 发生的事情。那是 Docker 1.11（非常古老的历史）。 Containerd 是一个守护进程，充当各种容器运行时和操作系统的 API 门面。使用 containerd, 时，您不再使用系统调用，而是使用更高级别的实体，如快照和容器 — 其余部分被抽象出来。 如果您想更深入地了解 containerd，请在他们的 GitHub 存储库中找到 design documentation。在底层，containerd 使用 runc 完成所有 linux 工作 .

在“How containerd compares to runC”查看更多信息

【讨论】：

问题是关于 libcontainer，而不是关于 libnetwork

@ISanych 对，那我改写答案

@VonC 感谢您的回复。这意味着，现在 docker 有了命名空间、cgroups（来自 LXC）和来自 libcontainer 的附加内核特性 selinux、netlink、功能等。我是对的 VonC 吗？

@YogeshJilhawar 是的，这就是 SPEC 提到的（github.com/opencontainers/runc/blob/…：amespaces、标准文件系统设置、默认 Linux 功能集以及有关资源预留的信息）

【参考方案2】：

我宁愿建议你通过这个链接来全面了解 Docker 为什么启动 libcontainer

http://www.zdnet.com/article/docker-libcontainer-unifies-linux-container-powers/

【讨论】：

虽然此链接可能会回答问题，但最好在此处包含答案的基本部分并提供链接以供参考。如果链接页面发生更改，仅链接的答案可能会失效。

【参考方案3】：

据我所知.. LXC 是 docker 引擎执行其容器/命名空间等的默认执行驱动程序。 Docker 开发了“libcontainer”并添加到他们的 docker 引擎中。如果我错了，请纠正我。