我遇到了一个问题，希望得到一些关于如何正确解决“docker”问题的反馈。我认为这是 Docker for Mac 特有的，因为绑定挂载使用 osxfs，并且 inode 是 64 位，而不是 32 位。与允许使用“noserverino”的 cifs 等文件系统不同，osxfs 似乎没有办法让客户端而不是挂载的系统确定 inode。
我已经基于 Ubuntu 16.04 创建了一个基本的 docker 镜像
FROM ubuntu:16.04@sha256:ea1d854d38be82f54d39efe2c67000bed1b03348bcc2f3dc094f260855dff368
RUN dpkg --add-architecture i386
RUN apt-get update && apt-get install -y \
bzip2 \
expect \
file \
gtk2-engines-murrine:i386 \
libgtk2.0-0:i386 \
libxtst6:i386 \
lib32stdc++6 \
libxt6:i386 \
libdbus-glib-1-2:i386 \
libasound2:i386 \
make \
maven \
openjdk-8-jdk \
patch \
python \
rsync \
swig \
unzip \
vim \
wget \
&& rm -rf /var/lib/apt/lists/*
此镜像的目的是为开发人员提供通用的构建环境。它还包括一个用于较旧的 32 位嵌入式设备的商业交叉编译器。为了便于解释，docker 镜像被命名为“crosscompiler”
对于开发人员来说，在虚拟机中使用 Ubuntu（特别是 16.04）不是问题，但 Docker 的诸多优势超过了 VM 方法。因此，这个 Docker 映像将取代 VM。
所以问题是：因为交叉编译器是一个 32 位工具链，它依赖于 i386 库，我已将其包含在上面的 Dockerfile 中。
要使用此图像来编译代码，我们可能需要运行以下命令：
docker run --rm -ti --volume=/path/to/source/code/to/build:/root/workspace crosscompiler /bin/sh -c “cd /root/workspace && ./build.sh”
build.sh 运行一个构建所有代码的脚本。问题是，因为这是一个 32 位交叉编译器，它执行类似 stat 的操作（在我们较旧的交叉编译器中，它不支持大文件；即 64 位 inode）。当 Ubuntu 容器挂载包含源代码的主机目录时，inode 都是 64 位的，而 32 位 GNU Tools 将这些文件视为Value too large for defined data type。目前，我不知道有什么办法可以告诉osxfs（即与 Docker for Mac 一起使用的 macOS 文件系统共享）。
解决此类问题的建议方法是什么？
- 将我们的源复制到每次旋转的容器中？
- 以某种方式使用 Docker‘卷’以便容器自己构建文件？
- 有没有办法为 osxfs 配置类似“noserverino”的挂载？
- 还有其他选择吗？
这里的目标是允许在主机上轻松编译本地源代码更改。这将在本地或持续构建环境中使用，因此提出一个优雅且可持续的解决方案是有利的。
答案1
最近遇到了类似的问题。为了解决这个问题，我尝试按照以下说明将我的工作区安装为 32 位 nfs 卷本文经过一些调整。我将nfsvers挂载选项更改为 2，以确保文件系统是 32 位（inode）。
以下是 docker-compose.yml 的片段，供您参考。
workspace_nfs:
driver: local
driver_opts:
type: nfs
o: "addr=host.docker.internal,rw,nolock,hard,nointr,nfsvers=2"
device: ":${PWD}"
希望这有帮助。