摘要在上篇文章中从“裸奔”到“装甲”基于 Docker Spring Boot 的企业级多环境安全架构实战我们实现了 Spring Boot 配置的“外部化”。但在微服务架构下分散在各个服务器上的.env文件依然难以维护。本文将带你完成从“静态环境变量”到“动态配置中心”的跃迁使用 Nacos 统一管理所有环境配置并实现配置热更新。前言当.env文件不再够用时在上一个方案中我们通过 Docker 的env_file注入了.env文件。这在单体应用中非常完美但当面临以下场景时它会显得力不从心配置散落10 个服务就有 10 个.env文件分布在 10 台服务器上。重启代价修改一个 Redis 地址必须docker restart。无版本管理谁改了配置什么时候改的回滚怎么办安全性焦虑虽然没进 Git但运维手里还是握着一堆密码。Nacos 的出现就是为了解决这些问题。它不仅是注册中心更是配置中心。第一章新架构全景图我们先来看一下引入 Nacos 后的架构变化。1.1 架构对比维度Docker Env 方案Nacos 方案存储位置服务器文件 (.env)Nacos Server 数据库更新机制重启容器实时推送 / 热更新管理方式分散管理统一 Web 控制台版本控制无自带历史版本与回滚适用场景单体应用微服务 / 分布式1.2 数据流------------------- 推送配置 ------------------- | Nacos Console | ----------- | Nacos Server | ------------------- ------------------ | | 监听变更 (Long Polling) v ------------------- | Spring Boot App | | (Nacos Config Client)| -------------------第二章Nacos 环境准备2.1 使用 1Panel 快速部署 Nacos如果你在用 1Panel部署 Nacos 非常简单。进入应用商店 - 搜索Nacos。选择单机模式Standalone。设置端口映射例如8848。启动。2.2 初始化命名空间 (Namespace)为了区分环境我们在 Nacos 中创建命名空间。Namespace IDName说明dev开发环境开发同学使用test测试环境测试同学使用prod生产环境线上环境第三章Spring Boot 接入 Nacos这是最核心的代码改造环节。3.1 依赖变更 (pom.xml)移除或保留原有的 Spring Cloud Alibaba 依赖。dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-config/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency3.2 配置文件大挪移我们要把原来写在application-dev.yml里的东西搬到 Nacos 里。本地只保留一个bootstrap.yml优先级最高用于连接 Nacos。# bootstrap.yml spring: application: name: shiyuan-admin cloud: nacos: discovery: server-addr: ${NACOS_SERVER_ADDR:127.0.0.1:8848} config: server-addr: ${NACOS_SERVER_ADDR:127.0.0.1:8848} file-extension: yaml # 关键指定命名空间dev/test/prod namespace: ${NACOS_NAMESPACE:dev} # 配置分组 group: DEFAULT_GROUP # 支持动态刷新 refresh-enabled: true3.3 Nacos 中的配置内容在 Nacos 控制台dev命名空间下创建配置shiyuan-admin.yaml。Data ID:shiyuan-admin.yamlGroup:DEFAULT_GROUP配置内容这就是你原来的application-dev.yml去掉占位符后的版本但密码等敏感信息依然用占位符或者直接用真实值放在 Nacos 里更安全spring: datasource: dynamic: datasource: master: url: jdbc:mysql://${DB_HOST}:3306/${DB_NAME}?useSSLfalse username: ${DB_USERNAME} password: ${DB_PASSWORD} data: redis: host: ${REDIS_HOST} password: ${REDIS_PASSWORD} # 邮件 mail: pass: ${MAIL_PASS} # 短信 sms: blends: aliyun: access-key-id: ${SMS_ALI_ACCESS_KEY} access-key-secret: ${SMS_ALI_SECRET}注意你会发现这里还是有${}。这是因为 Nacos 也支持从环境变量读取推荐或者你也可以直接在 Nacos 里写死值。第四章Docker 与 Nacos 的结合关键现在我们不再需要把大量的配置塞进.env只需要告诉 Spring BootNacos 在哪里。4.1 新的.env文件.env文件变得非常精简只负责“引导”应用。# 基础 CONTAINER_NAMEshiyuan-admin CODE_DIR/opt/apps/shiyuan-admin/target JAVA_APP_PORT9113 # Nacos 环境 NACOS_SERVER_ADDR172.17.0.1:8848 # Docker 网桥地址 NACOS_NAMESPACEdev # 敏感信息仅作为兜底 # 如果 Nacos 里的配置也用了变量这里需要提供 DB_PASSWORDYourStrongPassword REDIS_PASSWORDRedisPass4.2 新的 docker-compose.ymlnetworks: 1panel-network: external: true services: java-app: container_name: ${CONTAINER_NAME} image: bitnami/java:17 command: bash /run.sh env_file: - .env # 只注入 Nacos 地址和少量敏感变量 environment: - TZAsia/Shanghai # 这里不再需要 SPRING_PROFILES_ACTIVE由 Nacos Namespace 控制 networks: - 1panel-network ports: - ${HOST_IP}:${PANEL_APP_PORT_HTTP}:${JAVA_APP_PORT} restart: on-failure:5 volumes: - ${CODE_DIR}:/app - ./run.sh:/run.sh working_dir: /app4.3 改造 run.sh支持 JVM 参数从 Nacos 读取虽然配置在 Nacos但 JVM 参数通常还是在启动时确定。#!/bin/bash set -e cd /app echo Connecting to Nacos: $NACOS_SERVER_ADDR echo Namespace: $NACOS_NAMESPACE exec java \ -Xms512m \ -Xmx1024m \ -XX:UseG1GC \ -XX:HeapDumpOnOutOfMemoryError \ -Dspring.cloud.nacos.config.namespace${NACOS_NAMESPACE} \ -Dspring.cloud.nacos.server-addr${NACOS_SERVER_ADDR} \ -jar shiyuan-admin.jar第五章实现“配置热更新”RefreshScope这是 Nacos 最诱人的功能。5.1 代码示例假设你有一个读取 Redis 配置的 BeanRestController RequestMapping(/config) RefreshScope // 核心注解开启配置刷新 public class ConfigController { Value(${spring.data.redis.host}) private String redisHost; GetMapping(/redis-host) public String getRedisHost() { return Current Redis Host: redisHost; } }5.2 操作流程修改 Nacos 中shiyuan-admin.yaml的spring.data.redis.host。点击发布。无需重启应用再次访问/config/redis-host发现值已经变了。第六章Nacos 鉴权与安全Nacos 本身也需要安全加固。6.1 开启鉴权在 1Panel 部署 Nacos 时务必开启鉴权或手动修改application.propertiesnacos.core.auth.enabledtrue nacos.core.auth.system.typenacos6.2 配置 Docker 认证如果 Nacos 开了鉴权.env需要增加NACOS_USERNAMEnacos NACOS_PASSWORDYourNacosPassword并在bootstrap.yml中配置spring: cloud: nacos: username: ${NACOS_USERNAME} password: ${NACOS_PASSWORD}第七章迁移过程中的坑与解决方案坑 1配置加载顺序混乱现象本地配置覆盖了 Nacos 配置。解决记住 Spring Boot 配置优先级从高到低Command Line Arguments (--server.port8081)JNDI attributesJava System Properties (-Dpropertyvalue)OS Environment Variables (Docker env)Nacos Configapplication-{profile}.ymlapplication.ymlPropertySource经验不要把同样的配置写在application.yml里否则会覆盖 Nacos。坑 2Nacos 连不上现象java.net.ConnectException: Connection refused解决检查NACOS_SERVER_ADDR是否是 Docker 容器能访问到的地址。如果是 1Panel127.0.0.1可能不行要用宿主机的局域网 IP 或 Docker 网桥 IP如172.17.0.1。坑 3配置回滚操作在 Nacos 控制台 - 配置管理 - 历史版本 - 选择版本 - 回滚。第八章最终的安全架构评估经过这次改造我们的安全等级再次提升。资产存放位置安全性代码Git⭐⭐⭐⭐⭐ (无密码)Jar 包Docker Image⭐⭐⭐⭐⭐ (无密码)引导配置.env(Server)⭐⭐⭐⭐ (仅 Nacos 地址)业务配置Nacos Server⭐⭐⭐⭐⭐ (有权限控制、审计)数据库内网 VPC⭐⭐⭐⭐⭐结语从最初的“密码满天飞”到 Docker 环境变量隔离再到 Nacos 统一配置中心我们不仅解决了技术问题更完成了一次工程思维的升级。现在的架构优势在于运维友好运维只管 Nacos不用碰代码。开发友好开发只看 Git不用管密码。应急高效改配置不用重启秒级生效。审计合规谁改了什么一清二楚。如果你的项目正在从单体走向微服务或者正在为配置管理头疼强烈建议你试试这套方案。
架构进阶：从 Docker 环境变量到 Nacos 统一配置中心实战
摘要在上篇文章中从“裸奔”到“装甲”基于 Docker Spring Boot 的企业级多环境安全架构实战我们实现了 Spring Boot 配置的“外部化”。但在微服务架构下分散在各个服务器上的.env文件依然难以维护。本文将带你完成从“静态环境变量”到“动态配置中心”的跃迁使用 Nacos 统一管理所有环境配置并实现配置热更新。前言当.env文件不再够用时在上一个方案中我们通过 Docker 的env_file注入了.env文件。这在单体应用中非常完美但当面临以下场景时它会显得力不从心配置散落10 个服务就有 10 个.env文件分布在 10 台服务器上。重启代价修改一个 Redis 地址必须docker restart。无版本管理谁改了配置什么时候改的回滚怎么办安全性焦虑虽然没进 Git但运维手里还是握着一堆密码。Nacos 的出现就是为了解决这些问题。它不仅是注册中心更是配置中心。第一章新架构全景图我们先来看一下引入 Nacos 后的架构变化。1.1 架构对比维度Docker Env 方案Nacos 方案存储位置服务器文件 (.env)Nacos Server 数据库更新机制重启容器实时推送 / 热更新管理方式分散管理统一 Web 控制台版本控制无自带历史版本与回滚适用场景单体应用微服务 / 分布式1.2 数据流------------------- 推送配置 ------------------- | Nacos Console | ----------- | Nacos Server | ------------------- ------------------ | | 监听变更 (Long Polling) v ------------------- | Spring Boot App | | (Nacos Config Client)| -------------------第二章Nacos 环境准备2.1 使用 1Panel 快速部署 Nacos如果你在用 1Panel部署 Nacos 非常简单。进入应用商店 - 搜索Nacos。选择单机模式Standalone。设置端口映射例如8848。启动。2.2 初始化命名空间 (Namespace)为了区分环境我们在 Nacos 中创建命名空间。Namespace IDName说明dev开发环境开发同学使用test测试环境测试同学使用prod生产环境线上环境第三章Spring Boot 接入 Nacos这是最核心的代码改造环节。3.1 依赖变更 (pom.xml)移除或保留原有的 Spring Cloud Alibaba 依赖。dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-config/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency3.2 配置文件大挪移我们要把原来写在application-dev.yml里的东西搬到 Nacos 里。本地只保留一个bootstrap.yml优先级最高用于连接 Nacos。# bootstrap.yml spring: application: name: shiyuan-admin cloud: nacos: discovery: server-addr: ${NACOS_SERVER_ADDR:127.0.0.1:8848} config: server-addr: ${NACOS_SERVER_ADDR:127.0.0.1:8848} file-extension: yaml # 关键指定命名空间dev/test/prod namespace: ${NACOS_NAMESPACE:dev} # 配置分组 group: DEFAULT_GROUP # 支持动态刷新 refresh-enabled: true3.3 Nacos 中的配置内容在 Nacos 控制台dev命名空间下创建配置shiyuan-admin.yaml。Data ID:shiyuan-admin.yamlGroup:DEFAULT_GROUP配置内容这就是你原来的application-dev.yml去掉占位符后的版本但密码等敏感信息依然用占位符或者直接用真实值放在 Nacos 里更安全spring: datasource: dynamic: datasource: master: url: jdbc:mysql://${DB_HOST}:3306/${DB_NAME}?useSSLfalse username: ${DB_USERNAME} password: ${DB_PASSWORD} data: redis: host: ${REDIS_HOST} password: ${REDIS_PASSWORD} # 邮件 mail: pass: ${MAIL_PASS} # 短信 sms: blends: aliyun: access-key-id: ${SMS_ALI_ACCESS_KEY} access-key-secret: ${SMS_ALI_SECRET}注意你会发现这里还是有${}。这是因为 Nacos 也支持从环境变量读取推荐或者你也可以直接在 Nacos 里写死值。第四章Docker 与 Nacos 的结合关键现在我们不再需要把大量的配置塞进.env只需要告诉 Spring BootNacos 在哪里。4.1 新的.env文件.env文件变得非常精简只负责“引导”应用。# 基础 CONTAINER_NAMEshiyuan-admin CODE_DIR/opt/apps/shiyuan-admin/target JAVA_APP_PORT9113 # Nacos 环境 NACOS_SERVER_ADDR172.17.0.1:8848 # Docker 网桥地址 NACOS_NAMESPACEdev # 敏感信息仅作为兜底 # 如果 Nacos 里的配置也用了变量这里需要提供 DB_PASSWORDYourStrongPassword REDIS_PASSWORDRedisPass4.2 新的 docker-compose.ymlnetworks: 1panel-network: external: true services: java-app: container_name: ${CONTAINER_NAME} image: bitnami/java:17 command: bash /run.sh env_file: - .env # 只注入 Nacos 地址和少量敏感变量 environment: - TZAsia/Shanghai # 这里不再需要 SPRING_PROFILES_ACTIVE由 Nacos Namespace 控制 networks: - 1panel-network ports: - ${HOST_IP}:${PANEL_APP_PORT_HTTP}:${JAVA_APP_PORT} restart: on-failure:5 volumes: - ${CODE_DIR}:/app - ./run.sh:/run.sh working_dir: /app4.3 改造 run.sh支持 JVM 参数从 Nacos 读取虽然配置在 Nacos但 JVM 参数通常还是在启动时确定。#!/bin/bash set -e cd /app echo Connecting to Nacos: $NACOS_SERVER_ADDR echo Namespace: $NACOS_NAMESPACE exec java \ -Xms512m \ -Xmx1024m \ -XX:UseG1GC \ -XX:HeapDumpOnOutOfMemoryError \ -Dspring.cloud.nacos.config.namespace${NACOS_NAMESPACE} \ -Dspring.cloud.nacos.server-addr${NACOS_SERVER_ADDR} \ -jar shiyuan-admin.jar第五章实现“配置热更新”RefreshScope这是 Nacos 最诱人的功能。5.1 代码示例假设你有一个读取 Redis 配置的 BeanRestController RequestMapping(/config) RefreshScope // 核心注解开启配置刷新 public class ConfigController { Value(${spring.data.redis.host}) private String redisHost; GetMapping(/redis-host) public String getRedisHost() { return Current Redis Host: redisHost; } }5.2 操作流程修改 Nacos 中shiyuan-admin.yaml的spring.data.redis.host。点击发布。无需重启应用再次访问/config/redis-host发现值已经变了。第六章Nacos 鉴权与安全Nacos 本身也需要安全加固。6.1 开启鉴权在 1Panel 部署 Nacos 时务必开启鉴权或手动修改application.propertiesnacos.core.auth.enabledtrue nacos.core.auth.system.typenacos6.2 配置 Docker 认证如果 Nacos 开了鉴权.env需要增加NACOS_USERNAMEnacos NACOS_PASSWORDYourNacosPassword并在bootstrap.yml中配置spring: cloud: nacos: username: ${NACOS_USERNAME} password: ${NACOS_PASSWORD}第七章迁移过程中的坑与解决方案坑 1配置加载顺序混乱现象本地配置覆盖了 Nacos 配置。解决记住 Spring Boot 配置优先级从高到低Command Line Arguments (--server.port8081)JNDI attributesJava System Properties (-Dpropertyvalue)OS Environment Variables (Docker env)Nacos Configapplication-{profile}.ymlapplication.ymlPropertySource经验不要把同样的配置写在application.yml里否则会覆盖 Nacos。坑 2Nacos 连不上现象java.net.ConnectException: Connection refused解决检查NACOS_SERVER_ADDR是否是 Docker 容器能访问到的地址。如果是 1Panel127.0.0.1可能不行要用宿主机的局域网 IP 或 Docker 网桥 IP如172.17.0.1。坑 3配置回滚操作在 Nacos 控制台 - 配置管理 - 历史版本 - 选择版本 - 回滚。第八章最终的安全架构评估经过这次改造我们的安全等级再次提升。资产存放位置安全性代码Git⭐⭐⭐⭐⭐ (无密码)Jar 包Docker Image⭐⭐⭐⭐⭐ (无密码)引导配置.env(Server)⭐⭐⭐⭐ (仅 Nacos 地址)业务配置Nacos Server⭐⭐⭐⭐⭐ (有权限控制、审计)数据库内网 VPC⭐⭐⭐⭐⭐结语从最初的“密码满天飞”到 Docker 环境变量隔离再到 Nacos 统一配置中心我们不仅解决了技术问题更完成了一次工程思维的升级。现在的架构优势在于运维友好运维只管 Nacos不用碰代码。开发友好开发只看 Git不用管密码。应急高效改配置不用重启秒级生效。审计合规谁改了什么一清二楚。如果你的项目正在从单体走向微服务或者正在为配置管理头疼强烈建议你试试这套方案。
