批量部署环境下的环境变量与自定义镜像分发

批量部署需环境变量与自定义镜像协同设计：镜像固化运行时结构并支持参数化（ARG/ENV），环境变量分层覆盖（-e > env_file > ENV默认值），配置外置、敏感信息不入镜像。

批量部署时，环境变量和自定义镜像不是两个孤立环节，而是需要协同设计的一体化方案。核心在于：镜像负责固化运行时结构，环境变量负责注入差异化配置；镜像应具备“可参数化”能力，而非硬编码所有值。

镜像构建阶段：用 ARG + ENV 实现参数化

Dockerfile 中需区分构建期变量与运行期变量：

• ARG 用于接收 docker build --build-arg 传入的值，仅在构建过程中有效，适合版本号、构建路径等不随环境变化的参数
• ENV 设置的变量会写入镜像层，容器启动后仍存在，适合默认值或通用配置（如 LANG=C.UTF-8）
• 推荐写法：先用 ARG 接收值，再用 ENV 赋默认或覆盖值，例如：
  

  ARG APP_ENV=prod<br>ENV APP_ENV=${APP_ENV}

容器运行阶段：分层覆盖环境变量

变量来源有优先级顺序，高优先级覆盖低优先级：

• 容器启动时 -e KEY=VALUE 指定的值（最高优先级）
• env_file 文件中定义的变量（常用于 docker-compose.yml）
• 镜像中 ENV 指令预设的默认值（最低优先级）

例如，在 CI/CD 流水线中，可统一使用 .env.production 和 .env.staging 文件，配合 docker-compose --env-file 切换环境，避免修改代码或镜像。

自定义镜像分发：保持镜像纯净，配置外置

真正可复用的镜像不应绑定具体环境值：

• 禁止在 Dockerfile 中直接写 ENV DB_HOST=10.0.1.5 这类生产地址
• 允许写 ENV DB_HOST=localhost 作为开发默认值，但必须能被运行时覆盖
• 若应用需动态替换配置文件（如 Nginx conf、Spring Boot 的 application.yml），建议搭配 ENTRYPOINT 脚本读取环境变量并渲染模板，而不是把配置 baked 进镜像

批量部署实践要点

面向多环境（dev/test/prod）批量部署时：

• 构建一次镜像，打一个 tag（如 myapp:v1.2.0），不为每个环境构建不同镜像
• 用部署工具（Ansible / Argo CD / Jenkins Pipeline）控制 --env-file 或 -e 参数，实现“同一镜像、不同配置”
• 敏感变量（密码、密钥）绝不进镜像、不进 Git，通过 Secret 对象（K8s）、Vault 或宿主机挂载方式注入