我正在使用docker版本17.05.0。
我使用的是目录/var/lib/docker
,而不是使用Docker根目录/u01
,该目录是使用NFS共享安装在VM上的。
Docker根目录:/ u01 / docker
存储驱动程序:overlay2
# cat daemon.json
{
"data-root": "/u01/docker",
"storage-driver": "overlay2"
}
现在,当我启动守护程序时,docker pull命令可以正常工作,但是当我尝试构建映像时,它会引发以下错误:
Step 2/14 : MAINTAINER RK
error creating overlay mount to /u01/docker/overlay2/f5aebc4aa90797ccfab90bfb17a44314041b4694b26aa5a1e82eba95384f9924-init/merged: invalid argument
不确定这是怎么回事。
答案 0 :(得分:1)
您实际上不应该将NFS服务器作为后备文件系统运行docker。即使您可以使用它,它也会很慢,并且注册表服务器和可重用层已经解决了将图像分发到多个主机的问题。
overlay2文件系统本身被记录为要求使用ftype = 1或ext4的xfs作为后备文件系统,而不是NFS。
可以使用NFS的地方是将卷安装到容器中以存储持久性数据。这些卷将存在于容器外部,并且不会保存到注册表中,因此将它们推送到NFS是有意义的。以下是使用NFS挂载卷的不同方式的一些示例:
# create a reusable volume
$ docker volume create --driver local \
--opt type=nfs \
--opt o=nfsvers=4,addr=nfs.example.com,rw \
--opt device=:/path/to/dir \
foo
# or from the docker run command
$ docker run -it --rm \
--mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=nfs.example.com\",volume-opt=device=:/host/path \
foo
# or to create a service
$ docker service create \
--mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=nfs.example.com\",volume-opt=device=:/host/path \
foo
# inside a docker-compose file
...
volumes:
nfs-data:
driver: local
driver_opts:
type: nfs
o: nfsvers=4,addr=nfs.example.com,rw
device: ":/path/to/dir"
...
答案 1 :(得分:0)
让我们考虑几件事:
overlay2是默认的存储驱动程序,但正如您在docker storage driver documentation中所见,仅对 xfs(ftype = 1,ext4 )有效
也许您的/u01/docker
在另一个文件系统中。
如果您的/u01/docker
是ftype = 1或ext4类型的xfs,请检查selinux是否已禁用。
为了检查支持系统是否与overlay2兼容,可以执行:
$ docker info
Containers: 0
Images: 0
Storage Driver: overlay2
Backing Filesystem: xfs
<output truncated>
答案 2 :(得分:0)
对于我来说,解决方法出乎意料的是限制了“ RUN”泊坞窗构建命令/层的数量,因为如果数量超过60层/命令,则无论结果如何,它最终都会导致丢失“合并”文件夹错误该命令的内容是什么,即使简单的命令(例如RUN ls -la
)也以该错误结束,如果此类/任何命令的总数大于60,这很奇怪。 Merged
子文件夹始终丢失,尽管即使我自动生成了所有合并的子文件夹,也总是在运行时动态创建了一个带有新哈希的新层,但该子文件夹却丢失了。