问题背景
假设在一台 ubuntu 服务器上,我们有一个专门存放日频数据的路径:
这些数据过于庞大,我们无法将其全部保存在服务器中。对于这些数据,只有当天的路径,我们需要对其有「写」的权限,历史数据我们只读即可。
因此,假设今天是 20240717 ,那么,我们可以将小于 20240717 的数据软链接到一个 mount 到服务器上的分布式文件系统中,比如:
接下来,我们希望启动的 docker 容器可以访问 daily 数据,那么:
此时 my-service-container
报错:
但是当你进入容器:
那么,问题出在了哪里?
我估计读到这里的读者中,至少有一半已经知道了问题所在。
但是让我们先来看看一些错误的思路(也是困住了我的思路):
一、会不是文件系统权限问题?
- 显然, docker 容器在未开启
--privileged
,权限是不完整的 - 尤其是涉及到与 mount 分布式文件系统的交互,这其中是很容易出问题的
二、软链接的问题?
- 软链接本身不复杂,但是 docker 与软链接的结合,可能有点问题?
- 于是甚至很傻地去搜了 stackoverflow ,尝试类比 docker 、 softlink 、 mount 相关的问题
三、其他更复杂的原因导致的?
- 问问 ChatGPT 吧!免费版不聪明,再问问 ChatGPT-4o !
- 嗯...是我的 prompt 写得太差了?获得了一些正确的废话
如果你已经知道问题,你或许会嘲笑上述费力不讨好的一番折腾。但是为什么我(或者其他陷入误区的读者)会想到这些呢?
- 思维惯性。大多数日常使用 docker 的人(比如现在的我),对于 docker 的了解是不够深入的,在经历过一些 docker 的 bug 后,再遇到类似的问题,首先会顺其自然想到是不是 docker 本身的问题
- 所见即所得。我明明已经
ls
出了20240101 20240102 ... 20240716 20240717
,为什么还会出现no such file or directory: /data/daily/20240716
?显然,20240716
是软链接的、是来自/mnt/gfs-data/
的,而这个庞大的分布式文件系统很有可能存在一些兼容性问题
真正的解决之道
我在 docker 内部敲入下面的命令让我恍然大悟,甚至为自己的愚蠢发笑:
显然,软链接在 docker 内部链接到了 /mnt/gfs-data/
,那么,你也需要让 /mnt/gfs-data/
映射到本地的 /data/daily/
路径上!
增加一行挂载直接解决问题:
所以,既不是 docker 的问题,也不是权限的问题,更不是文件系统的问题。
为什么程序员的下班时间不同
所以,为什么有些程序员下班早,看起来还很轻松?
他可能并不是摸鱼大事。相反,他对于机器有更好的直觉与灵感,而这一切的前提是他积累了足够的知识与经验。
显然,对于 docker ,仅仅知道基本的 cgroups
实现原理是不够的。没有更扎实的基础知识与经验作为支撑,我们甚至总是焦头烂额地走向了错误的解决问题的方向。
细节决定浪费生命的时间。停下来,想一想自己是不是刚刚死脑筋了。