本文介绍在生产级 docker 部署中，如何替代传统 `.env` 文件、通过环境变量注入配置，实现镜像一次构建、多环境复用，并保障敏感信息不硬编码、不泄露。
在将应用容器化并面向多节点、负载均衡的生产部署时，切勿将 .env 文件直接 COPY 进 Docker 镜像——这会导致配置与镜像强耦合，违反“不可变基础设施”原则，且存在严重安全风险（如密钥泄露、镜像复用困难、环境切换需重新构建）。
✅ 正确做法是：构建时剥离配置，运行时动态注入。即：
- 构建阶段：仅打包应用代码、依赖和运行时（如 PHP + Nginx），完全忽略 .env 文件（应在 .dockerignore 中明确排除）；
- 运行阶段：通过容器引擎（Docker CLI / Swarm / Kubernetes）或编排平台（如 ECS、K8s Secrets）将配置作为环境变量传入容器。
✅ 推荐实践方式
1. 应用层适配：统一读取环境变量
修改应用代码（如 PHP），直接从 $_ENV 或 getenv() 读取配置，而非解析 .env 文件。例如：
// config/database.php
return [
'host' => $_ENV['DB_HOST'] ?? 'localhost',
'database' => $_ENV['DB_NAME'] ?? 'app',
'username' => $_ENV['DB_USER'] ?? 'root',
'password' => $_ENV['DB_PASS'] ?? '',
];✅ 优势：零依赖、无额外包（如 vlucas/phpdotenv）、启动更快、更符合 12-Factor App 原则。
2. 构建与部署分离：.dockerignore 是关键
确保构建上下文中不包含敏感文件：
# .dockerignore .env .env.local .git .gitignore README.md
Dockerfile 示例（精简）：
FROM php:8.2-apache COPY --from=composer:2 /usr/bin/composer /usr/bin/composer COPY . /var/www/html RUN cd /var/www/html && composer install --no-dev --optimize-autoloader EXPOSE 80
3. 运行时注入：按环境灵活赋值
-
单机测试（Docker CLI）：
docker run -d \ --name my-app-prod \ -e DB_HOST=prod-db.example.com \ -e DB_NAME=main \ -e JWT_SECRET=7a9c2f... \ -p 8080:80 \ my-app:latest
-
集群部署（推荐）：
- Docker Swarm：使用 docker config 管理加密配置；
- Kubernetes：使用 Secret + EnvFrom 挂载；
- AWS ECS：通过 secrets 字段集成 Parameter Store 或 Secrets Manager；
- CI/CD 流水线（如 GitHub Actions）：在部署步骤中动态注入变量。
⚠️ 注意事项与最佳实践
- ❌ 不要使用 ENV 指令在 Dockerfile 中写死生产密钥（会残留于镜像层）；
- ✅ 敏感值（如数据库密码、JWT 密钥）必须通过运行时注入，永不提交到代码仓库；
- ✅ 使用 .env.example 提供配置模板，供开发者本地参考，但禁止将其用于生产；
- ✅ 在 CI/CD 中验证必需环境变量是否存在（如启动前执行 env | grep -E '^(DB_|JWT_|APP_)'）；
- ✅ 对于 PHP，建议禁用 putenv() 和 apache_setenv()，仅信任启动时注入的变量，提升可审计性。
总结
真正的云原生配置管理，不是把 .env 打包进镜像，而是让镜像成为“纯二进制载体”，所有差异化配置交由平台在运行时注入。这不仅提升安全性与可移植性，也使你的 my-app:latest 真正做到“一处构建、随处运行”——无论单节点服务器、Swarm 集群，还是跨云 K8s，只需变更环境变量即可无缝迁移。
