AWS ECS部署Spring Boot：不启动新容器能否实现配置更新

你的初始判断完全正确：如果完全依赖ECS任务定义在容器启动时注入环境变量的方式加载配置，运行中的容器是不可能自动感知Parameter Store的参数更新的——容器启动后注入的环境变量已经被固化到进程的运行时上下文里，后续不管Parameter Store里的值怎么改，已经运行的JVM都读不到新值。这种模式下，更新任务定义后滚动启动新容器，是最稳妥、零额外维护成本的方案，也是云原生场景下配置发布的标准实践。

如果你确实需要不重启容器更新配置，也完全不需要上重量的Spring Cloud Config Server，也不用把所有配置迁移到Secrets Manager，有两个轻量方案可选：

• 轻量自实现方案：直接集成AWS SSM Java SDK
  给ECS任务绑定的IAM角色加好SSM参数读取权限，在代码里封装一层轻量的参数读取逻辑即可：既可以设置固定间隔轮询Parameter Store的参数版本，也可以配合AWS的事件通知，在参数更新时主动触发拉取。拿到最新值后，结合Spring自带的@RefreshScope注解或者自定义的Bean销毁重建逻辑，就能完成数据源这类依赖配置的资源热刷新。这个方案额外依赖极少，只需要自己做好拉取失败的容错、缓存过期逻辑即可，代码量很小。
• 低代码方案：使用Spring Cloud AWS的Parameter Store集成组件
  这个组件是Spring对AWS服务的官方轻量适配，不会引入Spring Cloud Config Server那套服务端、客户端全量依赖，整体包体积和额外开销非常小。引入后可以直接把Parameter Store的参数映射到Spring的配置环境，和你现在写${DB_URL}占位符的使用方式完全兼容，不需要改现有配置绑定代码。组件自带配置轮询刷新能力，配合@RefreshScope就能实现配置热更新，完全不需要迁移你已经存在Parameter Store里的配置。

这里要特意提一句：不要尝试进入运行中的容器修改环境变量来实现更新。Linux系统中进程的环境变量在进程启动时就已经固定，没有任何办法在不重启JVM进程的前提下修改它能读到的环境变量值，就算你改了容器内的环境变量配置文件，对已经启动的Spring进程也完全不生效，属于完全走不通的歪路。

最后给个选型参考：

• 如果你的配置更新频率很低（比如数月一次），完全没必要折腾热刷新逻辑，直接滚动重启任务即可，稳定性最高，没有额外的代码维护成本
• 如果确实有高频配置热更新的需求，优先选Spring Cloud AWS的集成方案，比自己封装SDK省很多事，也没有额外的服务端运维成本
• 只有当你后续需要做数据库密码这类敏感配置的自动轮转时，再考虑把对应敏感配置迁到Secrets Manager即可，普通非敏感配置可以继续存在Parameter Store，不需要做全量迁移。

内容的提问来源于stack exchange，提问作者BtySgtMajor