容器相关

本篇博客将记述我看到的且对理解容器有益的

将应用程序运行在容器中已经成为一种趋势，但是容器的概念并不是才有的。容器的起源实际可以追溯到大型机，这项技术在最近逐渐成熟，并以惊人的速度获得用户的兴趣和接受。

容器被设计成运行在操作系统之上的虚拟实例，它包含了应用程序在用户空间（user space）所需的所有内容。同时，容器提供一定的隔离性，使得运行在同一个操作系统之上的容器看起来是独立的，并且拥有整个操作系统。这种隔离还支持容器和外接交互。

目前有少数针对容器的备份软件，有没有一种方法能够使用任何备份软件来备份容器呢？

为了实现写时复制（copy-on-write），容器会使用一种名为叠加（overlay）文件系统的特性。即需要对根镜像进行修改时，容器会利用这一特性，将变更内容写入到独立区域并“覆盖”原有内容。这种修改通常都是瞬时的，也就是说，通常情况下，当容器删除时，这些修改也将不复存在。因此，容器默认是没有永久存储的。

为了解决存储问题，像Docker这样的工具，提供了两个新的特性来获得更加持久化的存储：Docker卷和数据容器。

Docker卷允许将数据保存在容器的启动卷之外。容器可以在启动时，通过“-v”开关挂载多个独立的数据卷。该参数会在Docker的配置目录（/var/lib/docker）中创建一个实体，配置内容会保存在/var/lib/docker/volumes目录中。每个子目录由卷的UUID（universally unique identifier）命名，其中包含该卷的配置，如卷ID、路径、读写权限等。卷的数据内容存储在/var/lib/docker/vfs/dir目录中，同样由卷的UUID命名。

卷中的数据可以在主机上进行读写，并且有着标准的文件权限。然而，使用卷的方式，有其优点和缺点。优点是由于采用标准文件系统，对容器的数据的备份、复制、移动等操作，可以在主机操作系统上完成。缺点是卷的名字使用了UUID，并且和容器ID关联，导致卷路径很难和容器名称关联起来。目前，Docker提供了docker cp命令，可以将文件在主机和容器之前复制。

通过挂载外部卷的方式，还可以将存储放到NFS（Network File System）或者LUN（Logical Unit Number）上，这样可以方便的对容器数据进行备份。

另一种方式是采用数据容器。数据容器像Docker内部的NFS服务器一样，可以通过“--volumes-from”开关在容器启动时设置关联的数据容器。使用这种方式的优点是将应用数据独立抽取出来，而不必关心它实际存放的位置。

当然，使用卷和数据容器，可能会遇到一些问题：

• 孤立的存储：当前一般容器默认的设置是容器删除之后保留容器使用过的存储。这样可能会导致一些卷已经没有容器引用，但是要删除它们成本又非常高，需要遍历主机上所有容器的配置，确保没有容器还在使用才能执行删除。 
• 数据安全：挂载的卷除了操作系统本身的文件权限控制，没有其他安全措施。这些文件可能会被主机上的进程修改，同时容器中的进程访问共享文件，也需要按照主机上的文件权限设置进行配置（如用户和组信息）。 
• 数据完整性：共享数据在数据完整性上无法保证，容器中的应用程序需要自己控制。同时数据备份需要容器或者主机上的应用程序来完成。

最后，容器存储上还有一个问题，就是不同主机上容器之间的存储无法共享。即目前容器可以使用外部存储，但是无法使用在其他主机上的数据容器。目前，ClusterHQ公司开发了flocker，试图解决这一问题。也希望Docker官方能够在存储管理上提供分布式解决方案。

【编者的话】本文主要介绍了容器与虚拟机的区别，在策略、性能以及安全等方面，作者一一回答了目前人们对容器与虚拟机区别的疑问。

“Docker和虚拟机有什么不同？”，这似乎是我听到的有关容器最常见的问题之一，我一般给出的答案取决于提出此问题的不同方式。但是我喜欢这样开头：“容器和虚拟机仅仅相似于它们都提供了隔离环境。” 接着我阐述他们之间的差异，“容器能做的事少得多并且使用起来相当廉价。而虚拟机提供整个虚拟化硬件层，可以做更多的事情但是使用成本显著。“ 我想有人会有疑问的最大的原因是这两种技术在功能上似乎类似，至少在第一点看来。

“它如何影响我的部署策略？”

有人希望直接跳到结论或者他们想要的结果。 “这样会如何影响我的部署策略？我刚上云，难道真的要改变一切，重新来过？这要花费多少？这要花费多大精力来学习呢？“

如果你从头到尾的解释给他们听，通常他们会由怀疑变成好奇。向他们展示那些项目，比如Docker，如何更简单地使用容器，如何将已经实现的项目与他们在使用的工具整合。他们会明白的，虽然还是有一些工作要做，但是学习和整合很容易。他们仍会希望得到更多的细节。

“它的性能如何？”

“它的性能如何？” 这个问题甚至比第一个还要常见。我不确定他们希望听到什么，还有为什么他们会这样问，但是答案会让他们吃惊：性能非常接近裸机（直接地/非虚拟化）的性能。他们不会相信，但是原因就是隔离并不是虚拟化。

Docker volumes只是绑定挂载文件（文件就像指针指向磁盘上的一个位置，它创建一个绑定挂载仅仅是创建一个指向同一地点的另一个文件而已）。读取或写入该文件基本上像裸机操作的那样廉价。另一方面，读取或写入 Volume以外的Docker容器文件系统比较昂贵。所以说不要那样做。

Docker networking就像裸机的网络。有一组用于每个容器而创建的虚拟（即逻辑的）以太网接口。任何网络性能下降是由于额外的内部跳动，比如：NAT。

容器的建立在一组Linux内核提供的功能墙壁上。对于IO（如果有的话）很少需要额外的处理或重定向。容器是廉价的。因为 使它们工作的软件是内置于操作系统中的，因此你可以停止（或至少减少）虚拟化软件的开支（或云实例）。

“它是不是比虚拟机更不安全呢？”

当然，精明健谈的会问，“它是不是比虚拟机更不安全呢？” 目前来说也许是的......。

这个比较复杂，因为它取决于你正在拿它们做什么。为了全面了解请参考 PPT - Docker，Linux容器（LXC）与安全 by Jérôme Petazzoni。我会尽力来总结概括。

容器使用由Linux内核提供的命名空间。大多数人把命名空间认为是一个上下文或域的授权决定（进程X有权访问资源Y）。

如果容器内的进程扫描文件系统来寻找要窃取的东西，它只能找到容器内明确可见的文件。如果容器内的进程中想尝试做一些恶意的事情，比如打开端口31337后门服务，它不会有多大好处，因为这个端口实际上不会暴露在容器外的任何地方。容器内部的恶意进程不能访问的任何容器外的其他进程的内存。

有几个方法可以摆脱容器的束缚，但这些通常需要容器的root访问权限。不要以root运行应用程序。通过简单的几个步骤稳固root访问权限。

容器使用 cgroup来提供与虚拟机相同级别的资源使用保护机制。容器和虚拟机都可以获取整个网络链接。

有些人会指出并非所有的Linux内核是命名空间的。这意味着有一些资源尚未隔离。这可能是真的，但它正在发生变化。集成的其他稳固的工具,像AppArmor或SELinux，可以帮助你构建一些真正的堡垒。如果有额外的工作来使容器达到与虚拟机相同的安全级别，那么它是值得的。

• 容器提供的隔离对于更密切的软件集成可以声明性地减少。虚拟机则是刚性的。
• 容器运行的是不完整的操作系统（尽管它们可以）。虚拟机必须运行完整的。
• 容器比虚拟机使用更少的闲置资源。它们不运行完整的操作系统。
• 容器在在云硬件（或虚拟机）中可以被复用，就像虚拟机在裸机上可以被复用。所不同的是...
• 容器需要毫秒分配。虚拟机需要几分钟。所以，你可以另配、重新平衡、释放以及使用容器比虚拟机的迭代更加迅速。

老实说，我感觉大多数傻傻的。以我的经验最常见的原因是人们提供硬件（虚拟或物理）是提供的隔离。

隔离

如果每个容器运行的只有一个服务或者数据库，这是比较容易管理的。而且比较容易监控性能，了解故障的影响，并预测成本。像亚马逊公司，团队拥有他们自己的软件和硬件，隔离是其中的关键。你有没有与其他团队分享过一个负载均衡的重要资源？那么，当因为你的服务把他们的VIP设置为激增队列来代替外溢，它们会失败或者在半夜你被叫醒，你就会渴望有隔离了。

离目标进程越远，隔离会变得更昂贵。虚拟机是伟大的，它通过抽象来增加并行，服务于多操作系统的使用情况以及业界最好的安全性。但对于隔离，它们相当的昂贵。

容器提供的隔离就便宜。趁热得到它。

如果你想到阅读更多有关Docker和容器的内容，请查阅我的书 《Docker in Action》。目前可以在 Manning Early Access Program浏览电子版。

原文链接：Containerization is not Virtualization （翻译：田浩浩 ）