Spring cloud Spring云配置服务器-服务器端占位符扩展替代方案

Spring cloud Spring云配置服务器-服务器端占位符扩展替代方案,spring-cloud,spring-cloud-config,Spring Cloud,Spring Cloud Config,我有以下情况: 带有Git后端的Spring云配置服务器 客户端使用各自的标签/配置文件查询配置服务器,在客户端展开相关占位符(即some.property=${spring.application.name}) 这正如预期的那样有效。但是,由于Git后端的性质,有一个额外的运行时(或至少是启动)依赖项,它以可访问Git存储库的形式存在,必须包含敏感信息(加密或不加密) 我想为一个在构建期间复制到配置服务器旁边的文件后端切换此选项。最后,我希望有一个Docker映像,其中的配置已经位于Confi

我有以下情况:

  • 带有Git后端的Spring云配置服务器
  • 客户端使用各自的标签/配置文件查询配置服务器,在客户端展开相关占位符(即
    some.property=${spring.application.name}
  • 这正如预期的那样有效。但是,由于Git后端的性质,有一个额外的运行时(或至少是启动)依赖项,它以可访问Git存储库的形式存在,必须包含敏感信息(加密或不加密)

    我想为一个在构建期间复制到配置服务器旁边的文件后端切换此选项。最后,我希望有一个Docker映像,其中的配置已经位于ConfigServerJAR文件旁边,并带有运行它的环境的占位符

    其想法是通过环境变量扩展这些占位符。比如说:

    config/application.yaml

    spring.datasource.username=${environment.db.user}
    spring.datasource.password=${environment.db.password}
    
    secrets.env

    ENVIRONMENT_DB_USER="..."
    ENVIRONMENT_DB_PASSWORD="..."
    
    这并没有像预期的那样起作用。首先,似乎正是这个用例被认为是后来才出现的

    我现在有点不确定下一步最好的办法是什么。我可以理解其中的原因,-不管安全含义如何,即使它有效,我意识到我在服务器端还有其他占位符(例如,像上面提到的
    some.property=${spring.application.name}
    ),这些占位符肯定应该在客户端得到解决,因为它们是特定于客户端的。但是,我不希望为所有客户端多次输入共享凭据(即外部AWS服务或其他类似服务)

    可以说,不同的客户端不应该有共享的凭据,但这是一个单独的讨论


    在这种情况下,基于文件后端的配置服务器方法的最佳方式是什么?是否有一种——或者我应该更喜欢JDBC后端之类的替代方法?

    这是一种不寻常的情况。这将适用于所有后端,而不仅仅是git。我们可以考虑选择增强。
    docker run --env-file=secrets.env ...