Question

我有一个使用以下程序的设置：

带有Spring Cloud版本Edgware.S3的Spring Boot 1.5.13
我有Spring Cloud Config Server，而我的Spring Boot应用程序是它的客户端
每个应用程序都带有带有配置服务器uri和一些其他属性的bootstrap.yml。
在Docker Swarm上运行容器

我目前正在通过自定义脚本将Swarm机密传递给客户端，该脚本读取放入/ run / secrets /的文件并创建/config/bootstrap.properties文件。最终看起来像这样：

spring.cloud.config.username=user
spring.cloud.config.password=password

那么我的Docker映像的默认命令就是这样：

java -Djava.security.egd=file:/dev/./urandom -jar /${appName}.jar --spring.cloud.bootstrap.location=file:/config/bootstrap.properties"

太好了。这没有问题。该应用看上去像是：

用于读取配置服务器凭据的外部bootstrap.properties
classpath bootstrap.yml以读取其余的配置客户端道具
获取并读取配置服务器的application-appName.yml
然后从类路径中读取捆绑的application.yml

现在。我正在使用Finchley.RELEASE将应用程序移至Spring Boot 2.0.3，好了，这很麻烦。

现在正在发生的事情是：

读取外部bootstrap.properties以获取配置服务器的凭据
classpath bootstrap.yml完全跳过（意外！）
获取并读取配置服务器的application-appName.yml
然后从类路径中读取捆绑的application.yml

问题是该应用程序现在缺少内部bootstrap.yml中设置的属性，因此它在启动时会崩溃。通过执行相同的操作，我已经能够在容器环境之外复制它。将应用程序指向外部bootstrap.properties。如果我将bootstrap.yml属性复制到bootstrap.properties中，则可以正常工作。另外，如果我不提供外部属性文件，则内部bootstrap.yml会正常启动。所以要么是另一个！

我还尝试了修改引导程序位置，使其包括默认位置，但没有运气：

-- spring.cloud.bootstrap.location=file:/config/bootstrap.properties,classpath:,classpath:/config,file:,file:config/

有什么主意下一步去看吗？也许我缺少一个新的spring.cloud.config属性？还是有人可以确认哪种行为是正确的行为？假设他们修复了Finchley的潜在漏洞，那么我就可以解决这个问题并寻找其他解决方案。如果在芬奇利（Finchley）被“破坏”，我猜是有问题的报告了吗？

Answer 1

更多的挖掘表明，这看起来像是新的行为：

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide

spring.config.location配置的行为已修复；它以前在默认位置列表中添加了一个位置，现在它替换了默认位置。如果您依靠以前的处理方式，那么现在应该改用spring.config.additional-location。

它看起来并不是特定于Spring Cloud的，但我没有什么可失去的。更改我的java命令以使用此新属性可以达到目的：

--spring.config.additional-location=file:/config/bootstrap.properties

谢谢。

Spring Cloud Config双引导文件行为

1 个答案: