Docker对lxc-tools（用户空间LXC工具）添加了什么？

398

如果您看一下Docker的功能，大多数功能已经由LXC提供。

那么Docker添加了什么呢？为什么要在普通LXC上使用Docker？

docker lxc

— 弗利姆
source

550

从Docker FAQ中：

Docker不能替代lxc。“ lxc”是指linux内核（特别是名称空间和控制组）的功能，这些功能允许彼此进行沙盒处理并控制其资源分配。

在此低级内核功能基础之上，Docker提供了具有多种强大功能的高级工具：

跨机器的可移植部署。Docker定义了一种格式，用于将应用程序及其所有依赖项捆绑到一个对象中，该对象可以转移到任何启用了docker的计算机上，并在此处执行，并确保暴露给该应用程序的执行环境相同。Lxc实现了流程沙箱，这是便携式部署的重要先决条件，但仅此还不足以实现便携式部署。如果您将安装在自定义lxc配置中的应用程序的副本发送给我，几乎可以肯定它不会像在您的计算机上那样在我的计算机上运行，因为它与计算机的特定配置（网络，存储，日志记录，发行版，等等。Docker为这些机器特定的设置定义了一个抽象，以便完全相同的Docker容器可以在许多不同的机器上运行-不变-
以应用程序为中心。相对于机器，Docker针对应用程序的部署进行了优化。这反映在其API，用户界面，设计理念和文档中。相比之下，lxc帮助程序脚本将容器作为轻量级机器集中在容器上-基本上，服务器启动速度更快，所需内存更少。我们认为容器不仅限于此。
自动构建。Docker提供了一个工具，供开发人员从其源代码自动组装一个容器，完全控制应用程序依赖项，构建工具，打包等。他们可以免费使用make，maven，chef，puppet，salt，debian软件包，rpm，源代码tarball或以上各项的任意组合，而与机器的配置无关。
版本控制。多克尔包括混帐样的能力来跟踪集装箱的后续版本，检查版本之间的差异，提交新版本，回滚等历史还包括如何容器组装以及由谁，让你获得从生产服务器的完全可追溯一直回到上游开发人员。Docker还实现了增量上传和下载，类似于“ git pull”，因此可以通过仅发送差异来传输容器的新版本。
组件重复使用。任何容器都可以用作“基础映像”以创建更多专用组件。这可以手动完成，也可以作为自动构建的一部分来完成。例如，您可以准备理想的python环境，并将其用作10个不同应用程序的基础。您理想的postgresql设置可以在将来的所有项目中重复使用。等等。
分享。Docker可以访问公共注册表（https://registry.hub.docker.com/），其中成千上万的人上传了有用的容器：从redis，couchdb，postgres到irc bouncers到rails应用服务器再到hadoop到基础映像的任何内容各种发行版。该注册表还包括由Docker团队维护的有用容器的官方“标准库”。注册表本身是开源的，因此任何人都可以部署自己的注册表来存储和传输私有容器，例如用于内部服务器部署。
工具生态系统。Docker定义了一个API，用于自动和自定义容器的创建和部署。有大量工具与docker集成以扩展其功能。类似于PaaS的部署（Dokku，Deis，Flynn），多节点编排（大师，盐，mesos，openstack nova），管理仪表板（docker-ui，openstack Horizon，造船厂），配置管理（chef，puppet），持续集成（jenkins，strider，travis）等。Docker正在迅速将自己确立为基于容器的工具的标准。

我希望这有帮助！

— 所罗门·海克斯
source

3

当您说“任何容器都可以用作基本映像”时，我想您是指Docker容器，而不是独立于Docker创建的LXC容器。据我所知，不能从头创建一个Docker容器，它必须始终从另一个Docker容器继承（相关问题：stackoverflow.com/questions/18274088/…）。

— Flimm 2013年

18

您可以使用“ docker import”轻松地从任何压缩包创建新容器。例如：“ debootstrap raring ./rootfs; tar -C ./rootfs -c。| docker import flimm / mybase”。

— 所罗门·海克斯

3

既然Docker有了libcontainer（不是替代品），这仍然是真的吗？

— 加雷特·克拉伯恩

3

@GaretClaborn是的，因为libcontainer只是他们自己的用于访问名称空间和cgroup的库，所以所罗门所说的一切仍然适用。

— 约翰·莫拉莱斯

10

Linux容器是使用一组Linux设施（chroot，cgroup和名称空间）约束和隔离进程的结果。LXC是一种操纵这些功能的用户空间工具。libcontainer是LXC的替代品，它可以操纵那些相同的工具。Docker默认使用libcontainer，但可以改用LXC。就是说，Docker远远超出了libcontainer / LXC之上的兼容性层。它添加了其他答案列出的其他功能。

— user100464'2

71

让我们看一下Docker的技术功能列表，并检查LXC提供哪些功能，哪些不提供。

特征：

1）文件系统隔离：每个进程容器都在完全独立的根文件系统中运行。

提供普通LXC。

2）资源隔离：可以使用cgroup将cpu和内存之类的系统资源分配给每个进程容器。

提供普通LXC。

3）网络隔离：每个进程容器都在其自己的网络名称空间中运行，并具有自己的虚拟接口和IP地址。

提供普通LXC。

4）写时复制：根文件系统是使用写时复制创建的，这使得部署极其快速，内存便宜且磁盘便宜。

这由AUFS提供，AUFS是Docker依赖的联合文件系统。您可以使用LXC手动设置AUFS，但是Docker将其用作标准。

5）日志记录：收集并记录每个过程容器的标准流（stdout / stderr / stdin），以进行实时或批量检索。

Docker提供了这一点。

6）变更管理：可以将对容器文件系统的更改提交到新映像中，并重新用于创建更多容器。无需模板或手动配置。

“模板化或手动配置”是对LXC的引用，您需要在其中了解这两个方面。Docker允许您像对待虚拟机一样对待容器，而无需了解LXC配置。

7）交互式外壳：docker可以分配一个伪tty，并附加到任何容器的标准输入，例如运行一次性交互式外壳。

LXC已经提供了这一点。

我才刚刚开始学习有关LXC和Docker的知识，因此我欢迎进行任何更正或提供更好的答案。

— 弗利姆
source

35

恕我直言，这个答案没有重点。Docker不“提供”这些功能；它只是使它们简单易用。如果我们想挑剔，可以说LXC不提供隔离：名称空间提供了隔离，LXC只是一种商品用户界面工具，使它们比基本unshare工具（或直接与clone()syscall）更易于使用。同样，Docker使这些功能更易于使用（并在桌面上带来了更多功能，例如推/拉图像的功能）。我的2c。

— jpetazzo

6

@jpetazzo：LXC实际上非常简单，Docker如何使其变得更容易（除了添加其他功能（如推入和拉出图像））？

— Flimm

31

@Flimm：我喜欢《管理杂志》第16 页中的比较。34：Docker将LXC与其他一些支持技术捆绑在一起，并将其包装在易于使用的命令行界面中。使用容器有点像试图使用git与像刚才的命令update-index和read-tree，不喜欢熟悉的工具add，commit和merge。Docker在LXC的“管道”上提供了“瓷器”层，使您能够使用更高级别的概念，而不必担心低级细节。

— 0xC0000022L13年

4

我在运行相同操作系统的docker容器和LXC容器中运行了UnixBench基准测试，并且LXC在得分方面表现出色。作为基于LXC的码头工人，我对结果感到非常困惑。

— gextra

7

在我看来，Docker的性能下降与磁盘I / O有关，因此可能是由于采用AUFS引起的。

— gextra 2013年

16

随着LXD的发展继续增强LXC，以上的帖子和答案很快就过时了。是的，我知道Docker也没有停滞不前。

现在，LXD为LXC容器映像实现了一个存储库，用户可以从该存储库映像中进行推送/拉取以进行贡献或重用。

LXD的LXC REST API 现在可以使用非常简单的命令语法在本地和远程创建/部署/管理LXC容器。

LXD的主要功能是：

通过设计确保安全（无特权的容器，资源限制等等）
可扩展（从笔记本电脑上的容器到数千个计算节点）
直观（简单，清晰的API和清晰的命令行体验）
基于图像（没有更多的分发模板，只有良好的，受信任的图像）实时迁移

OpenStack现在有NCLXD插件，允许OpenStack使用LXD将LXC容器作为OpenStack中的VM部署/管理，而不是使用KVM，vmware等。

但是，NCLXD还支持混合使用传统HW VM和LXC VM的混合云。

OpenStack nclxd插件支持的功能列表包括：

stop/start/reboot/terminate container
Attach/detach network interface
Create container snapshot
Rescue/unrescue instance container
Pause/unpause/suspend/resume container
OVS/bridge networking
instance migration
firewall support

到2016年4月发布Ubuntu 16.04时，将会有其他很酷的功能，例如块设备支持，实时迁移支持。

— 布姆兰
source

4

Docker使用分层构建的映像。这在可移植性，共享，版本控制和其他功能方面增加了很多。这些映像非常易于移植或传输，并且由于它们是分层的，因此后续版本的更改会以分层的形式添加到先前的层上。因此，在多次移植时，您无需移植基础层。Docker的容器可以在包含执行环境的情况下运行这些映像，它们作为新层添加了更改，从而提供了轻松的版本控制。

Docker Hub之外还有一个很好的注册表，其中包含数千个公共映像，您可以在其中找到已安装操作系统和其他软件的映像。因此，您可以为应用程序获得一个很好的开始。

— div
source

当您说“内置层”时-这是什么意思-（A）基本层的副本，已适应并提交给“ NEW”层。那么，基础层与下一层断开了吗？（B）基础层包含在“ NEW”层中并且也被链接。因此，对基础层的更改将自动反映到“ NEW”层。抱歉，如果要求的澄清太幼稚。:(卡皮尔

— 卡皮尔

Docker映像是分层构建的。总而言之，直到提交层为止的所有更改都在制作的图像层中存在，直到该点为止。此后所做的任何更改将添加到下一层和上一层。因此，新层链接到基础层。我不认为可以通过其他更改将同一新层添加到其他基础层。但是，如果多个实体要保持一致性并具有相同的基础层，则只需为这些实体提供新的层即可达到相同状态。

— div

但是，我对Docker的当前开发没有任何更新，并且可能对Docker映像实现进行了更改，但以上注释中未涉及。

— div

更具体地说，层是通过签名（我相信是SHA-something）来标识的，这意味着如果您更改层，则它是一个不同的层。 @Kapil：这意味着，尽管其行为在某种程度上更接近您的选项（B），但实际上您无法更改基础层。（或任何一层），图像是由层的列表构建而成的，每个层按顺序应用；不再需要时，可以清理层（我认为它们会由docker本身自动清理）；即，当所有参考图像都已删除时。

— codermonkeyfuel

@Kapil：老实说，您的问题可能最好作为一个新问题，而不是对此问题发表评论，因为它对于人们可以自行查找是一个有用的问题。如果您想提出一个新问题，我也会在那回答。

— codermonkeyfuel

0

为了保持这一点，上面已经有人问过并回答了。

但是，我退后一步，对它的回答略有不同，泊坞窗引擎本身将编排作为附加功能之一添加，这是破坏性的部分。一旦您开始将应用程序作为在多个容器引擎中“在某处”运行的容器的组合来运行，它将变得非常令人兴奋。鲁棒性，水平缩放，从底层硬件的完全抽象，我可以继续下去...

不仅是Docker为您提供了这一点，事实上事实上的容器编排标准是Kubernetes，它具有很多风味，例如Docker，还有OpenShift，SuSe，Azure，AWS ...

然后在K8S下方有替代的容器引擎；有趣的是Docker和CRIO-最近构建的无守护进程，旨在用作专门用于Kubernetes但不成熟的容器引擎。我认为它们之间的竞争将是容器引擎真正的长期选择。

— 罗斯威尔
source