☰

“Docker”文件系统 - 与符号链接的兼容性

tag-icon • tag-icon ubuntu filesystems symlink docker
“Docker”文件系统 - 与符号链接的兼容性

如果您想跳过对我们情况的解释，则该问题会以粗体标记。

我是服务器网络的开发人员。我们部署服务器的多个实例。我们有 5 种服务器类型，每种类型有 3-5 个实例。我们使用带有 API 的独立服务器来开发附加组件。每种服务器类型都有一组不同的所需附加组件。

目前我们正在使用文件夹结构并手动运行实例，如下所示：

/servers
    /server1
        /instance1/.
        /instance2/.
    /server2
        /instance1/.

ETC...

每个实例都有一个名为 module\ 的文件夹，在该文件夹中我们有 jar 文件（系统在 Java 上运行）

每次我们的附加组件更新时，我们都需要将其复制到需要附加组件的服务器的所有实例中。我们希望使用符号链接 (ln -s ) 并仅存储每个附加组件的一个实例。这将是理想的，除了我们想要转向虚拟实例管理这一事实。我们对几个选项进行了排序，Docker 似乎是最适合我们需求的一个，因为它内置了负载平衡系统。

大多数虚拟平台还虚拟化文件系统，例如大多数虚拟机将创建一个包含有关该文件的所有信息的文件。

这里的问题是，Docker 是虚拟化文件系统，还是从本机 Ubuntu 文件系统挂载实例？我知道 Docker 在可用时使用 LXC，但是我不太熟悉 LXC 的工作原理以及符号链接是否可以在实例之间工作如果它确实虚拟化，那么显然意味着符号链接将不再是一个选项。如果是这种情况，那么我们最终不会使用 Docker，因为为了提高效率，将文件系统保存到单个文件或一组文件的系统也会增加对硬盘驱动器的写入量，因为文件任何更改都需要重新编写，并且服务器实例可能非常大（多个 GB）。

答案1

我不确定我是否正确理解了您的问题，但是使用 Docker，您可以将主机系统中的目录挂载到来宾/虚拟系统的文件系统内。您可以将同一目录从主机挂载到多个来宾系统。您可以在这里找到更多详细信息：https://docs.docker.com/userguide/dockervolumes/

它应该像这样工作：

docker create --name=instance1 -v /home/shared/addon/:/usr/local/addon/:ro ...
docker create --name=instance2 -v /home/shared/addon/:/usr/local/addon/:ro ...
docker create --name=instance3 -v /home/shared/addon/:/usr/local/addon/:ro ...

这里/home/shared/addon/是实例之间共享的，每个实例内部都可以访问它/usr/local/addon/，并且实例只能读取它（ro）。你甚至不需要ln -s。

这只是一种可能的方法，在文档中还有更高级的选项。

答案2

让我在这里分享一下我的经历。 Docker 似乎不能很好地处理符号链接。我以通常的方式将真实目录安装到容器目录（为了清楚起见，EXTERNAL_DATA 是一个环境变量：比如 /data/projectA）：

-v $EXTERNAL_DATA:/docker/data

我有一个符号链接文件如果你从外部视图看是

symlink_file -> /data/projA/somereal_file.txt

当您进入容器时，如果您在容器外部键入了该命令，则 ls 命令将准确显示该命令。 somereal_file.txt 与 symlink_file 位于同一目录中

您可以访问真实文件，但如果尝试使用符号链接，则会出现错误。

head symlink_file
head: cannot open 'simlink_file' for reading: No such file or directory

我在将我的一个应用程序迁移到 docker 容器时发现了这一点。不确定这是 docker 的设计缺陷，还是有办法解决这个问题，而无需重写原始应用程序来处理这种特殊情况。即使您可以更改应用程序，这也不是解决此问题的最佳方法。

我们应该称之为 docker 的基本符号链接缺陷吗？

相关内容