假设在一台 ubuntu 服务器上,我们有一个专门存放日频数据的路径:
ls /data/daily -lh202401012024010220240103...
这些数据过于庞大,我们无法将其全部保存在服务器中。对于这些数据,只有当天的路径,我们需要对其有「写」的权限,历史数据我们只读即可。
因此,假设今天是 20240717 ,那么,我们可以将小于 20240717 的数据软链接到一个 mount 到服务器上的分布式文件系统中,比如:
ls /data/daily -lh20240101 -> /mnt/gfs-data/daily/2024010120240102 -> /mnt/gfs-data/daily/20240102...20240716 -> /mnt/gfs-data/daily/2024071620240717
接下来,我们希望启动的 docker 容器可以访问 daily 数据,那么:
docker run / -v /data/daily:/data/daily / --name my-service-container / my-service-image run-service-command
此时 my-service-container
报错:
no such file or directory: /data/daily/20240716
但是当你进入容器:
docker exec -it my-service-container /bin/bash$ cd /data/daily$ ls20240101 20240102 ... 20240716 20240717# 数据似乎存在?$ ls -l 20240716no such file or directory: 20240716# 明明存在,却无法访问?
我估计读到这里的读者中,至少有一半已经知道了问题所在。
但是让我们先来看看一些错误的思路(也是困住了我的思路):
一、会不是文件系统权限问题?
--privileged
,权限是不完整的二、软链接的问题?
三、其他更复杂的原因导致的?
如果你已经知道问题,你或许会嘲笑上述费力不讨好的一番折腾。但是为什么我(或者其他陷入误区的读者)会想到这些呢?
ls
出了 20240101 20240102 ... 20240716 20240717
,为什么还会出现 no such file or directory: /data/daily/20240716
?显然, 20240716
是软链接的、是来自 /mnt/gfs-data/
的,而这个庞大的分布式文件系统很有可能存在一些兼容性问题我在 docker 内部敲入下面的命令让我恍然大悟,甚至为自己的愚蠢发笑:
docker exec -it my-service-container /bin/bash$ cd /data/daily$ ls -lh20240101 -> /mnt/gfs-data/daily/2024010120240102 -> /mnt/gfs-data/daily/20240102...20240716 -> /mnt/gfs-data/daily/2024071620240717
显然,软链接在 docker 内部链接到了 /mnt/gfs-data/
,那么,你也需要让 /mnt/gfs-data/
映射到本地的 /data/daily/
路径上!
增加一行挂载直接解决问题:
docker run / -v /data/daily:/data/daily / -v /mnt/gfs-data:/mnt/gfs-data / --name my-service-container / my-service-image run-service-command
所以,既不是 docker 的问题,也不是权限的问题,更不是文件系统的问题。
所以,为什么有些程序员下班早,看起来还很轻松?
他可能并不是摸鱼大事。相反,他对于机器有更好的直觉与灵感,而这一切的前提是他积累了足够的知识与经验。
显然,对于 docker ,仅仅知道基本的 cgroups
实现原理是不够的。没有更扎实的基础知识与经验作为支撑,我们甚至总是焦头烂额地走向了错误的解决问题的方向。
细节决定浪费生命的时间。停下来,想一想自己是不是刚刚死脑筋了。
本文链接:http://www.28at.com/showinfo-26-101715-0.html与机器打交道的工作:细节决定浪费生命的时间——记一次 Docker 与软链接的故障
声明:本网页内容旨在传播知识,若有侵权等问题请及时与本网联系,我们将在第一时间删除处理。邮件:2376512515@qq.com
上一篇: 我们如何管理软件项目的交付?
下一篇: Java 函数式接口,一文彻底剖析!