环境变量注入由gitlab ci自动提供并传递给docker构建或运行时，关键在于利用ci内置变量（如ci_commit_sha、ci_registry）配合--build-arg、variables块、.env动态生成及运行时-e注入，实现配置外置化与安全管控。
环境变量注入不是手动填配置，而是让 ci 流水线在运行时自动提供、校验并传递给 docker 构建或容器启动过程。关键在于利用 gitlab ci 的内置变量机制与 docker 构建上下文的协同设计。
用 CI 内置变量替代硬编码
GitLab CI 在每个作业启动时自动注入大量预定义变量，比如 CI_COMMIT_SHA、CI_ENVIRONMENT_NAME、CI_REGISTRY 等。这些变量可直接用于镜像标签、构建参数或容器运行时环境。
- 在
.gitlab-ci.yml中通过args或build-arg注入到 Docker 构建阶段：docker build --build-arg COMMIT_ID=$CI_COMMIT_SHA -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA . - 在 Dockerfile 中接收：
ARG COMMIT_IDENV APP_VERSION=$COMMIT_ID - 避免在 Dockerfile 里写死版本号或环境名，全部交由 CI 控制
通过 variables 块统一管理敏感与非敏感变量
在 .gitlab-ci.yml 的顶层 variables 区块中声明变量，既可覆盖默认值，也能为后续所有 job 提供一致上下文。
- 非敏感变量（如镜像命名规则）可明文定义：
DOCKER_IMAGE: "$CI_REGISTRY_IMAGE/app" - 敏感变量（如 API 密钥、数据库密码）必须设为 CI/CD Variables（GitLab 项目 Settings → CI/CD → Variables），并在 YAML 中引用：
DB_PASSWORD: $DB_PASSWORD - 变量支持层级覆盖：全局 variables → job-level variables → script 内 export，优先级逐级升高
构建时动态生成 ENV 文件并 COPY 进镜像
某些应用依赖 .env 文件加载配置。与其把敏感信息塞进镜像层，不如在 CI 中按需生成，并仅在构建阶段使用。
- 在
buildjob 的script中生成临时文件：echo "APP_ENV=$CI_ENVIRONMENT_NAME" > .envecho "API_TIMEOUT=5000" >> .env - Dockerfile 中只在构建阶段 COPY：
COPY .env /app/.env - 注意：该文件不会出现在最终镜像的运行时层（若用多阶段构建，可只在 builder 阶段使用）
运行时通过 docker run -e 或 kubectl env 注入
镜像构建完成后，部署阶段才是环境变量真正生效的地方。此时应避免在镜像中固化运行时配置。
- GitLab deploy job 中启动容器示例：
docker run -e "LOG_LEVEL=debug" -e "ENV=$CI_ENVIRONMENT_NAME" $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA - Kubernetes 部署时，用
envFrom引用 ConfigMap 或 Secret：envFrom: [{configMapRef: {name: $CI_ENVIRONMENT_NAME-config}}] - 确保所有环境相关字段都来自外部注入，而非镜像内 baked-in 值
