在Windows上,我在docker-compose up上遇到错误,例如:
python: can't open file '/code/manage.py': [Errno 2] No such file or directory
字符串
这实际上发生在许多试图将它们部署到Docker中的项目上,所以我不认为这与python,django甚至路径位置有关-这似乎是一个远程文件系统Map问题。
我可以通过简单地将项目移动到本地磁盘(甚至不是WSL,只是普通的Windows文件夹)来修复它,而不是WiFi连接的(Linux Western Digital MyCloudX 2Ultra)NAS,其中所有项目文件当前都存储在NAS中。但这是不可行的,因为本地磁盘是小型SSD,而不是大型代码库-自然是常见的设置。
因此,当代码在NAS上时,Windows Docker似乎很难挂载卷:
Dockerfile:
# Pull base image
FROM python:3.10.4-slim-bullseye
# Set environment variables
ENV PIP_DISABLE_PIP_VERSION_CHECK 1
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1
# Set work directory
WORKDIR /code
# Install dependencies
COPY ./requirements.txt .
RUN pip install -r requirements.txt
# Copy project
COPY . .
型
Docker-compose.yml:
version: "3.9"
services:
web:
build: .
ports:
- "8000:8000"
command: python manage.py runserver 0.0.0.0:8000
volumes:
- .:/code
型
有很多关于这个“[错误2]没有这样的文件或目录”的帖子,但所有这些似乎都是兔子洞(我可能会站在纠正),因为我已经验证了这似乎只与NAS源位置有关,所以某种Map和/或权限问题(Windows和Linux之间并不奇怪)。
我使用相同的文件夹所有者和管理员用户从NAS和本地运行,但可能MapNAS路径有问题-可能是因为它是WindowsMap的驱动器“N:...”,而实际上驱动器当然是“<local IP>..."。应该不是问题...但它在某个地方!也许可以在docker文件中硬编码路径(当然不理想),但不确定最好的方法。
1条答案
按热度按时间wkyowqbh1#
好的,所以这与NAS无关。它是与代码重新定位有关。通过修改新位置上的docker-compose.yml修复了这个问题:
字符串
答对了所以我现在意识到,在构建时以及在Dockerfile和docker-compose.yml内部的句号“.”点微妙地依赖于总体父文件夹-即使虚拟环境.venv在子文件夹本身中(因此我认为“.”会将其作为“:/code”)以及所有CLI运行的位置。它可能是Visual Studio Code的事情,但可能不是-只是组合。
当我将项目移到本地磁盘时,它没有相同的更高级别的文件夹,但我认为它看起来都是独立的。
向任何硬核Dockers道歉,但至少我们这些可怜的Devs(与更有经验的DevOps相反)不必因为不变性而放弃容器-提供docker-compose(实际上V1已被新的V2“docker compose”Difference between "docker compose" and "docker-compose"弃用,奇怪的是我无法以同样的方式工作)继续伟大。