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

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

容器的起源实际上能追溯到大型机时代，这并不是一个新技术，这一技术最终开始成熟并以惊人的速度获得用户关注和认可。容器使多个应用并行运行在单个操作系统之上，不管其是直接部署在物理服务器还是虚拟实例之上。这个是通过提供在“用户空间”(即应用运行的平台、系统或运行在内核上的代码)上执行多次拷贝的功能来实现的。

容器的当前反馈来自于运行虚拟实例相关的问题和开销，每个实例必须有专用的内存和存储资源。它们通常过大或不够，当对这些资源需求迅速扩展时，它运行会变得缓慢。

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

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

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

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

相比而言虚拟实例这种方式预计是短暂的。它应用于更好的存储分配，容器使用的功能被称为一个覆盖文件系统来实现一个写副本的过程中，与存储任何更新信息的主文件系统的容器相比，它是基于原始镜像。如果容器被删除，这些更改通常会丢失。因此容器默认不具有持久存储能力。

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

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

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

任何卷中的数据都能在主机操作系统中浏览和编辑及标准权限应用。然而，卷的使用有利有弊。由于数据存储在标准的文件系统中，它能被操作系统备份、复制、导入和导出。缺点还有卷的命名遵循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这种分布式方案中增加更多卷管理功能。

本文作者：吴锦晟

来源：51CTO