本文讲的是探索 | 容器存储有哪些问题和机遇， 【编者的话】在容器技术流行的背景下，随之而来出现了一些应用上的问题。本文介绍了容器存储方面所出现的一些问题。对这些问题进行了详细的描述，同时也给出了几种解决方案。

作者：尼克格拉斯马托斯，FICO 云服务工程高级总监，致力如何为Docker卷和数据容器缺乏持久化存储提供解决方案。

在容器内运行应用的想法并不新颖。是的，这是一个趋势，无数人研究容器这一热门主题，似乎发现了解决问题的方法。 容器将解决一切 。

容器的起源实际上能追溯到大型机时代，这并不是一个新技术，最终这一技术开始成熟并以惊人的速度获得用户关注和认可。

容器使多个应用并行运行在单个操作系统之上，不管其是直接部署在物理服务器还是虚拟实例之上。这个是通过提供在“用户空间”（即应用运行的平台、系统或运行在内核上的代码）上执行多次拷贝的功能来实现的。

容器的当前反馈来自于运行虚拟实例的故障和运营经费相关问题，因为我们必须为每个实例提供专用内存和存储资源。这些实例通常过大或不够，当需要进行迅速扩展时，运行速度非常缓慢。

虚拟实例具有隔离性和独立升级每个实例的能力，但在运行类似或相同版本的操作系统的大环境中，每个虚拟实例都运行相同的进程，都占用内存和保留一个近似的启动卷。

面向一个基于Web可扩展的网络计算架构目标时，传统的虚拟化可以说非常低效，浪费物理资源，比如内存、处理器、存储、机架空间、电力、冷却系统和通用资源（如管理系统、IP地址）等。

容器提供了一定程度的分离，因为它们独立于与其临近的容器，这样容器看起来似乎拥有整个操作系统。而且这种隔离允许它们与外部进行交互。

在2014年指数级的增长趋势下，2015年容器和整个生态系统在企业环境中得到长足发展，但是它仍然远未普及。虽然有极少的备份软件供应商能够提供容器备份的支持，但是有没有办法能实现任何备份软件都能备份容器呢？

相比虚拟实例而言，容器通常较为短暂，分配到他们之上的存储也是这样，容器利用覆盖文件系统功能来实现copy-on-write进程，与其所依赖的原始镜像相比，容器将每个更新信息写入到root文件系统中。如果容器被删除，这些更改通常会丢失。因此 容器默认不具有持久存储能力 。

然而，类似Docker这种分布式方案提供两种特性用于访问持久化存储资源：Docker卷和数据容器。

一个Docker卷允许数据被存储在启动卷之外的容器中，在root文件系统中可可从多个方面实现。一个容器可以通过提供一个共享名传给“-v”切换参数创建一个或多个卷。

Docker配置文件夹（ /var/lib/docker ）中创建一个实体代表该卷的内容。卷上的配置数据存储在 /var/lib/docker/volumes 文件夹，每个子目录代表一个基于通用且唯一的标识符（UUID）卷名。数据本身存储在基于UUID命名的文件夹 /var/lib/docker/vfs/dir 中。

任何卷中的数据都能在主机操作系统中浏览和编辑，都是标准权限应用。然而， 卷的使用有利有弊 。由于数据存储在标准的文件系统中，它能被操作系统备份、复制、导入和导出。

缺点还有卷的命名遵循UUID规范，这使它很难与容器名称联系在一起。Docker通过提供“docker cp”命令解决了这个问题，通过指定容器的名称，即可将文件和文件夹从主机目录中拷贝到该容器目录中。这与rsync类似。

通过使用卷选项访问在外部存储上创建的主机共享，有可能实现在NFS共享或LUN上访问外部共享存储，虽然并不推荐这样做。

一个Docker卷也可以与主机目录有关。这里要再次用到“-v”切换，格式如下：“-v /host:/container”。这种方法允许容器访问主机上的持久数据。

因此通过使用卷选项访问在外部存储上创建的主机共享，有可能实现在NFS共享或LUN上访问外部共享存储。这种方法也可以用来备份由容器访问的数据。

Docker中管理数据的 另一选择是Docker数据容器 。这个概念是指一个或多个卷在内的一个休眠容器。这些卷可以导出到一个或多个其它容器中，当启动附加的容器时，使用‘-volumes-from’切换。数据卷容器就像是内部的Docker NFS服务器，从中心点提供访问容器的支持。

这种方式的优点是它从原始数据的位置抽象出来，让数据容器变为一个逻辑中心点。当在专用容器中保持数据的持续性时，它还允许“应用”容器访问数据容器卷来实现创建和销毁。

在使用卷和数据容器中有一些问题需要了解。

独立存储

目前在没有删除相关卷的情况下是可以删除容器的。事实上，这是默认的行为，除非重写。最终它可以很容易地结束没有相关引用容器的独立卷。

清除独立存储是一项很艰巨的任务，因为它需要通过查阅容器配置文件，来匹配容器及其相关的卷。

安全

对于容器卷和数据，除了标准文件权限和配置“只读”或者“读写”访问，没有其他别的安全性问题。这意味着用户在容器上的文件访问权限需要匹配主机设置。

数据完整性

使用卷和数据容器共享数据，能够保护数据的完整性。如文件锁定需要容器本身的管理功能。这是一个额外的开销，必须添加到应用程序中。

容器没有提供数据保护设施，如快照或复制，因此数据管理必须由主机或容器来处理。

外部存储也缺乏支持。除了系统操作系统中提供的功能外，Docker并没有在外部存储中提供特定的支持。

容器卷默认存储在 /var/lib/dockerdirectory 目录中，这可能会成为一个性能瓶颈。然而，在Docker启动进程中转换容器卷默认存储位置是可行的。

最后一个点突出了当前容器存储的问题： 无法管理那些在分离的物理主机上运行的容器间的数据共享 。

数据卷可以置于外部存储中，但是当前的设计不具备使用卷从一台主机转移到另一台主机的能力。为了解决这个问题，Flocker提供的解决方案从ClusterHQ正在尝试解决卷移植带来的地址问题。也有提出改变类似Docker这种分布式方案中增加更多卷管理功能。

原文链接：How storage works in containers（翻译：吴锦晟）

原文发布时间为：2015-10-10 

本文作者：吴锦晟

本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。

原文标题：探索 | 容器存储有哪些问题和机遇？