我通过使用 docker-compose 将 docker.sock 从我的主机系统安装到我的容器中来使用 DinD。
services:
dw-app:
build: .
ports:
- "127.0.0.1:8500:8500"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- ./uploads:/app/uploads
- ./db:/app/db
- ./flask-logging.log:/app/flask-logging.log
- ./gunicorn-logging.log:/app/gunicorn-logging.log
- ./flask-config.cfg:/app/flask-config.cfg
environment:
- UPLOAD_PATH=/mnt/c/Users/<user>/OneDrive/Dokumente/<company>/docker-workflow-web-app
#- UPLOAD_PATH=/app
- FLASK_CFG_PATH=/app/flask-config.cfg
stdin_open: true
tty: true
在我的程序中,我正在运行
HOST_UPLOAD_DIR = os.path.join(os.environ.get('UPLOAD_PATH'), dir_path)
print(HOST_UPLOAD_DIR)
if not zotero_used:
docker_command = ["docker", "run","--rm", "--volume", f"{HOST_UPLOAD_DIR}:/app/files", "d2md-debug", doc_file_name]
result = subprocess.run(docker_command)
d2md-debug
容器已正确创建,但是HOST_UPLOAD_DIR中挂载的文件夹为空,因此找不到文件。问题是,如果我使用相同的路径在主机系统上运行该命令,一切都会正常工作。所以,我认为这与主机文件系统的权限有关?但为了调试,它们确实都有 777,甚至是通过将上传文件夹从我的主机挂载到容器来从主机系统上的容器内创建的(这工作正常,我可以在我的主机上创建文件)通过安装目录在容器内)。另一个奇怪的事情是,几个月前我在一个稍微不同的环境中使用这个函数/方法,一切都运行得很好。我首先认为这可能与文件当前位于 Onedrive 上的事实有关,但如果我使用 /home/<user>/uploads
作为挂载目录(在 Windows 11 上使用 WSL/Ubuntu),它也不起作用。
谢谢您的帮助!
使用 DavidMaze 建议解决了问题(请参阅评论):使用
/c/Users/...
而不是 /mnt/c/User/..
解决了问题(我正在使用适用于 Windows 的 Docker Desktop)。
您已正确识别出
docker run -v
绑定挂载选项使用来自“主机系统”的路径,即使您在容器内运行 docker
命令也是如此。不过,在 Docker Desktop 上,Docker 在隐藏的 Linux 虚拟机内运行,而用于这些绑定安装的“主机系统”就是 Linux VM。 Docker Desktop 可以通过一些路径到达真实的主机系统,但它确实需要了解它们。
Docker Desktop FAQ 建议,在 Windows 系统上,
C:\
驱动器的子集可在 Docker Linux VM 中的 Linux 路径 /c/
上使用。如果您在 /c/Users/...
值中使用 UPLOAD_PATH
,而不是 /mnt/c/Users/...
,则这应该有效。这仍然受到 Docker Desktop 对 Docker 可见路径的限制,但默认情况下,您自己的主目录中的路径将可见。