docker容器启动时动态拉取配置需通过entrypoint.sh脚本实现，而非dockerfile：镜像仅预置应用、jdk、bootstrap.yml及拉取脚本；启动时由entrypoint.sh调用curl请求nacos/apollo/config接口获取配置，覆盖本地文件后以-dspring.config.location指定路径启动java应用。
要让 Docker 容器在启动时动态拉取分布式配置中心（如 Nacos、Apollo、Spring Cloud Config）的配置，关键不是在 Dockerfile 里“写死”配置，而是通过启动阶段的初始化逻辑实现配置拉取与注入。Dockerfile 本身是构建镜像的静态描述，不负责运行时行为；真正的动态拉取需交由容器启动命令（ENTRYPOINT 或 CMD）或应用启动前的 shell 脚本完成。
明确职责：Dockerfile 只做准备，不执行拉取
Dockerfile 的作用是把应用、JDK、配置模板、拉取脚本等打包进镜像，为运行时动态拉取做好环境准备。它不应尝试在构建阶段连接远程配置中心（网络不可控、密钥泄露风险高）。
- 基础镜像选带 curl / wget / jq 的（如
openjdk:17-jre-slim，再 apt/yum 安装必要工具） - 把应用 JAR、预置的 bootstrap.yml（含配置中心地址、namespace、dataId 等）一并 COPY 进镜像
- 编写一个
entrypoint.sh脚本，赋予可执行权限，并设为 ENTRYPOINT
编写拉取脚本：用 shell 实现配置中心对接
以 Nacos 为例，在 entrypoint.sh 中实现：先调用 Nacos OpenAPI 拉取配置，再覆盖本地 bootstrap.yml 或生成临时配置文件，最后启动 Java 应用。
- 脚本开头检查必要环境变量：
NACOS_SERVER_ADDR、DATA_ID、GROUP、NACOS_NAMESPACE_ID - 用 curl 请求：
curl -s "$NACOS_SERVER_ADDR/nacos/v1/cs/configs?dataId=$DATA_ID&group=$GROUP&tenant=$NACOS_NAMESPACE_ID" - 将返回内容写入
/app/config/application.yml，再通过 JVM 参数指定配置路径：-Dspring.config.location=file:/app/config/ - 最后执行
exec java -jar /app/app.jar "$@"启动应用（注意 exec 保证 PID 1 正确）
适配不同配置中心的要点
Apollo 和 Spring Cloud Config 接口风格不同，但思路一致：用脚本封装 HTTP 请求 + 配置落地。
- Apollo：请求
http://<host>:8080/configs/<appid>/<clustername>/<namespace>?ip=<ip></ip></namespace></clustername></appid></host>，响应是 JSON，需提取configurations字段 - Spring Cloud Config：GET
http://<server>/<application>/<profile>[/<label>]</label></profile></application></server>，返回标准 Spring Boot 配置格式（YAML/Properties） - 无论哪种，建议在脚本中加入重试机制（如 curl -f --retry 3）、超时控制（--max-time 10）、失败退出（set -e），避免静默失败
安全与生产建议
动态拉取涉及敏感地址和凭证，不能硬编码在脚本或镜像中。
- 配置中心地址、token、namespace 等全部通过
docker run -e或 Kubernetes Secret 注入环境变量 - 若需认证（如 Nacos accessKey/secretKey），用 curl 的
-H "Authorization: Bearer $TOKEN"或参数方式传入，禁止写死 - 镜像内不要保留调试工具（如 vim、bash），最小化攻击面；生产环境推荐使用 distroless 基础镜像 + 单独添加 ca-certificates 和 curl
- 配合健康检查（livenessProbe），验证配置是否成功加载（例如检查某配置项是否存在或访问 /actuator/env）
