谨慎在docker-compose.yml中使用$PWD变量

最近在使用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

2. 使用 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