使用 Spring Cloud Config 进行属性版本控制 [英] Properties versioning with Spring Cloud Config

问题描述

我可能在这里遗漏了一些东西，但是属性版本控制的好解决方案是什么?

I am probably missing something here, but what is a good solution for properties versioning?

比如在一个属性值变化的蓝绿部署场景(旧版本的app消耗旧的值，新的版本需要新的值)，你如何保证你的两个版本的app可以成功共存(考虑潜在的重启和回滚)?

For example, in a blue-green deployment scenario with property value changes (old app version consumes the old value, new version requires the new value), how do you ensure both versions of your app can successfully co-exist (considering potential restarts and rollbacks)?

一种选择是为需要应用新值的属性创建新的属性名称.当然，这不是一个好的选择，因为我们需要在代码库中跟踪该属性的所有用法并相应地更新其引用.从概念的角度来看，这也不好.

One option would be to create new property names for the properties that need new values applied. This, of course, is not a good option as we need to track all the usages of that property in the code base and update its reference accordingly. It is also not nice from a conceptual perspective.

另一种选择是为每个版本创建一个分支.虽然这在这种情况下可以很好地工作，但我设想了一个分支/标签地狱，因为我们将配置存储库扩展到多个应用程序，并且它们各自的分支向不同的方向发展.

Another option is to have a branch for each release. While this could work very well for this scenario, I envisage a branch/tag hell as we scale to the config repo to multiple apps and their respective branches evolve into different directions.

分支地狱的解决方案是为每个应用程序设置一个单独的配置存储库.但是，我相信这在某种意义上违背了配置服务器的目的，因为它增加了开销.

A solution to the branch hell would be to have a separated config repo for each app. But, I believe this in some sense defeats the purpose of the config server as it adds overhead.

还有其他方法吗?

推荐答案

Spring Cloud Config 的 Environment 资源由三个变量参数化:

Spring Cloud Config's Environment resources are parametrized by three variables:

1. {application} 映射到客户端的 spring.application.name
2. {profile} 映射到客户端上的 spring.active.profiles
3. {label} 这是一个服务器端功能，标记了一个 versioned 集配置文件.

1. {application} maps to spring.application.name on the client side
2. {profile} maps to spring.active.profiles on the client
3. {label} which is a server side feature labelling a versioned set of config files.

因为在蓝绿部署的情况下，您在同一个配置文件中使用同一个应用程序，最好的选择是通过使用 git Tags 使用 Versioned 配置文件>.

Since in case of Blue-Green deployments, you're using the same application in the same profile, the best option is to use Versioned config files by using git Tags.

基本思想是为不同版本的配置文件创建标签，并在您的 bootstrap 中使用 spring.cloud.config.label 告诉您的应用程序使用与特定标签相关的配置.属性.

The basic idea is to create tags for different versions of config files and tell your application to use configurations related to an specific tag using spring.cloud.config.label in your bootstrap.properties.

例如，您可以使用 v1.0 和 v2.0 标记两个不同的提交:

For example, you can tag two different commits with v1.0 and v2.0:

旧实例使用spring.cloud.config.label=v1.0，新实例使用spring.cloud.config.label=v2.0.

And use spring.cloud.config.label=v1.0 for old instance and spring.cloud.config.label=v2.0 for new instance.

当我们将配置仓库扩展到多个应用程序及其各自的分支向不同方向演化.

as we scale to the config repo to multiple apps and their respective branches evolve into different directions.

为了避免这个问题，我建议只在 application-{profile}.properties 配置文件中保存通用和跨应用程序的属性.更好的方法是每个应用程序都有自己的配置文件，例如recommender.properties 用于推荐服务，search.properties 用于搜索服务.然后，您可以通过定义适当的 spring.application.name 来为它们中的每一个使用配置文件特定的和版本化的属性.通过这种方式，您可以在配置文件中达到某种程度的单一职责原则.

In order to avoid this problem, I suggest to only save common and cross application properties in application-{profile}.properties config files. The better approach is that to each application has its own config file, e.g. recommender.properties for recommender service and search.properties for search service. Then you can use profile specific and versioned properties for each of them by defining the appropriate spring.application.name. This way you can achieve to some level of Single Responsibility Principle in your configuration files.

这篇关于使用 Spring Cloud Config 进行属性版本控制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！