如何在Docker/devcontainer构建参数中读取.env文件的环境变量

Dev Containers扩展默认不会自动加载项目目录下的.env文件做变量替换，${localEnv:xxx}仅会读取本地系统全局环境变量，要实现从指定.env文件读取构建参数，可使用以下方案：

方案1：通过build.envFile配置实现（推荐，官方原生支持） #

Dev Containers扩展在build配置块中提供了原生的envFile字段，专门用于指定构建阶段需要加载的环境变量文件，加载后的变量可以直接在build.args中引用，无需额外依赖。
修改你的devcontainer.json配置如下：

{
  "name": "NodeJS & TypeScript",
  "build": {
    "dockerfile": "Dockerfile",
    // 指定构建阶段加载的.env文件，路径相对于devcontainer.json所在目录
    "envFile": ".env",
    "args": {
      "VARIANT": "16-bullseye",
      "NPM_PROXY": "http://proxy.domain.com:8080",
      // 直接引用envFile中加载的变量即可，无需写死值
      "HTTPS_PROXY": "${HTTPS_PROXY}",
      "HTTP_PROXY": "${HTTP_PROXY}"
    }
  },
  "settings": {},
  "extensions": [
    // ...
  ],      
  "remoteUser": "node",
  "runArgs": ["--env-file", ".devcontainer/.env"]
}

注意事项：

• build.envFile加载的变量仅在镜像构建阶段生效，和你原有runArgs中传入的--env-file互不干扰：后者负责容器运行时的环境变量注入，前者仅为构建阶段提供变量来源。如果要统一配置，也可以让两个配置指向同一个.env文件，减少重复维护。
• .env文件中的变量值不要包裹多余的引号，否则引号会被当作变量值的一部分传入构建流程，导致代理地址格式错误，建议直接使用无引号的键值对格式：

  HTTP_PROXY=http://proxy.domain.com:8080
  HTTPS_PROXY=http://proxy.domain.com:8080
  http_proxy=http://proxy.domain.com:8080
  https_proxy=http://proxy.domain.com:8080
  

• 该特性在Dev Containers扩展v0.180.0及以上版本默认支持，目前绝大多数用户的安装版本都满足要求。

方案2：在Dockerfile中直接加载.env文件（适合不想调整devcontainer配置的场景） #

如果不想修改devcontainer.json的变量引用逻辑，可以直接在Dockerfile的构建步骤中主动读取.env文件的变量，修改后的Dockerfile示例：

ARG VARIANT
FROM mcr.microsoft.com/vscode/devcontainers/typescript-node:0-${VARIANT}

# 把.env文件复制到构建临时目录
COPY .env /tmp/.env
# 加载.env变量后执行apt安装命令
RUN export $(grep -v '^#' /tmp/.env | xargs) && \
    apt-get update && export DEBIAN_FRONTEND=noninteractive \
    && apt-get -y install --no-install-recommends chromium

WORKDIR /usr/app

ARG NPM_PROXY
# 加载.env变量后执行npm相关配置和安装
RUN export $(grep -v '^#' /tmp/.env | xargs) && \
    npm config set https-proxy ${NPM_PROXY} -g && \
    npm i -g @angular/cli

# 构建完成后删除临时.env文件，避免敏感信息留在镜像层
RUN rm /tmp/.env

ENV CHROME_BIN=/usr/bin/chromium

注意事项：

• 该方案需要保证.env文件位于Docker构建的上下文路径内，否则COPY指令会报错。
• 每个需要用到代理变量的RUN指令都需要提前加载.env变量，Docker构建过程中变量不会跨RUN指令生效，配置相对繁琐，适合临时调整的场景。

方案3：通过initializeCommand预加载环境变量（适合自定义逻辑场景） #

devcontainer.json支持initializeCommand配置，该命令会在容器构建开始前在本地主机执行，可以在该步骤中把.env文件的变量加载到临时执行环境，再通过${localEnv:xxx}读取，配置示例：

{
  "name": "NodeJS & TypeScript",
  // 构建前在本地shell中加载.env文件的变量
  "initializeCommand": "export $(grep -v '^#' .devcontainer/.env | xargs)",
  "build": {
    "dockerfile": "Dockerfile",
    "args": {
      "VARIANT": "16-bullseye",
      "NPM_PROXY": "http://proxy.domain.com:8080",
      "HTTPS_PROXY": "${localEnv:HTTPS_PROXY}",
      "HTTP_PROXY": "${localEnv:HTTP_PROXY}"
    }
  },
  "settings": {},
  "extensions": [
    // ...
  ],      
  "remoteUser": "node",
  "runArgs": ["--env-file", ".devcontainer/.env"]
}

注意事项：

• 该方案依赖本地主机的shell环境，Windows系统使用PowerShell时需要改写为对应的PowerShell加载命令，跨平台协作场景不推荐使用。
• initializeCommand执行时的默认工作目录是项目根目录，写.env路径时需要注意相对路径的正确性。

内容的提问来源于stack exchange，提问作者Starfish