最近在应用Docker Compose部署服务时，我在docker-compose.yml文件中应用了$PWD变量来指定HOST门路。然而，我发现指定的门路并没有达到预期成果。

问题复现

先来看一段docker-compose.yml的配置文件：

version: "3.9"services:  xui:    image: enwaiax/x-ui    container_name: xui    volumes:      - $PWD/db/:/etc/x-ui/      - $PWD/cert/:/root/cert/    restart: unless-stopped    network_mode: host

我将docker-compose.yml放到了/data/apps/x-ui目录下，下面的配置文件看起来并没有任何问题，应用了$PWD变量来示意当前目录，那么依照预期的话，HOST相对挂载门路为：

  • /data/apps/x-ui/db/
  • /data/apps/x-ui/cert/

当我执行sudo docker-compose up -d运行容器的时候，并没有报错，然而HOST挂载门路并未依照预期的工作，理论的HOST相对挂载门路确变成了：

  • /db/
  • /cert/

看起来仿佛$PWD变量丢了或者没有失效？

问题剖析与解决

于是我把这个问题抛给了ChatGPT征询了下，给我的答案是：

看起来你的问题的确是 $PWD 变量没有失效。这可能是因为你在应用 sudo 时，环境变量未能传递给 docker-compose 命令。

要解决这个问题，你能够尝试以下办法：

  1. 将 $PWD 替换为绝对路径。例如，将 /data/apps/x-ui 作为挂载门路的前缀：
version: "3.9"services:  xui:    image: enwaiax/x-ui    container_name: xui    volumes:      - /data/apps/x-ui/db/:/etc/x-ui/      - /data/apps/x-ui/cert/:/root/cert/    restart: unless-stopped    network_mode: host
  1. 应用 sudo -E 选项来保留环境变量：
sudo -E docker-compose up -d

这将确保 $PWD 变量在执行 docker-compose 命令时放弃失效。不过须要留神的是，应用 -E 选项可能存在肯定的平安危险，因为它会将以后用户的所有环境变量传递给 sudo 命令。请确保你理解可能的危险，并确保以后环境中没有蕴含敏感信息的变量。

解决方案补充

在下面的问题中，ChatGPT给出了2种解决方案都能解决$PWD变量生效的问题，其实还有另一种计划就是应用相对路径，比方：

version: "3.9"services:  xui:    image: enwaiax/x-ui    container_name: xui    volumes:      - ./db/:/etc/x-ui/      - ./cert/:/root/cert/    restart: unless-stopped    network_mode: host

而后再进入/data/apps/x-ui目录下执行sudo docker-compose -d即可。

结语

在应用 sudo 命令时，局部环境变量可能无奈正确传递给后续命令。为了解决这个问题，咱们能够应用 sudo -E 参数来保留环境变量，或者防止依赖环境变量，转而应用绝对路径或相对路径。这一点须要特地留神，尤其是当普通用户通过 sudo 命令操作 Docker 时。

此文章首发于我的独立博客：https://blog.xiaoz.org/archives/18657