存储在容器中是如何工作的



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

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

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

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

    为了解决存储问题,像Docker这样的工具,提供了两个新的[特性]https://docs.docker.com/userguide/dockervolumes/)来获得更加持久化的存储: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官方能够在存储管理上提供分布式解决方案。

    感谢魏星对本文的审校。

    转载自InfoQ


登录后回复
 

与 青云QingCloud 社区 的连接断开,我们正在尝试重连,请耐心等待