spring.cloud.config.label=myfeature,develop).If you use HTTP Basic security on the server, clients need to know the password (and username if it is not the default).
+For instance, you might want to align the config label with your branch but make it optional (in that case, use spring.cloud.config.label=myfeature,develop).
To ensure high availability when you have multiple instances of Config Server deployed and expect one or more instances to be unavailable from time to time, you can either specify multiple URLs (as a comma-separated list under the spring.cloud.config.uri property) or have all your instances register in a Service Registry like Eureka ( if using Discovery-First Bootstrap mode ). Note that doing so ensures high availability only when the Config Server is not running (that is, when the application has exited) or when a connection timeout has occurred. For example, if the Config Server returns a 500 (Internal Server Error) response or the Config Client receives a 401 from the Config Server (due to bad credentials or other causes), the Config Client does not try to fetch properties from other URLs. An error of that kind indicates a user issue rather than an availability problem.
If you use HTTP basic security on your Config Server, it is currently possible to support per-Config Server auth credentials only if you embed the credentials in each URL you specify under the spring.cloud.config.uri property. If you use any other kind of security mechanism, you cannot (currently) support per-Config Server authentication and authorization.
If you use HTTP Basic security on the server, clients need to know the password (and username if it is not the default). You can specify the username and password through the config server URI or via separate username and password properties, as shown in the following example:
bootstrap.yml.
spring: cloud: @@ -51,11 +51,11 @@ The following example works locally and for a user-provided service on Cloud Fou cloud: config: uri: ${vcap.services.configserver.credentials.uri:http://user:password@localhost:8888}
-
If you use another form of security, you might need to provide a RestTemplate to the ConfigServicePropertySourceLocator (for example, by grabbing it in the bootstrap context and injecting it).
The Config Client supplies a Spring Boot Health Indicator that attempts to load configuration from the Config Server. +
If you use another form of security, you might need to provide a RestTemplate to the ConfigServicePropertySourceLocator (for example, by grabbing it in the bootstrap context and injecting it).
The Config Client supplies a Spring Boot Health Indicator that attempts to load configuration from the Config Server.
The health indicator can be disabled by setting health.config.enabled=false.
The response is also cached for performance reasons.
The default cache time to live is 5 minutes.
-To change that value, set the health.config.time-to-live property (in milliseconds).
In some cases, you might need to customize the requests made to the config server from the client.
+To change that value, set the health.config.time-to-live property (in milliseconds).
In some cases, you might need to customize the requests made to the config server from the client.
Typically, doing so involves passing special Authorization headers to authenticate requests to the server.
To provide a custom RestTemplate:
PropertySourceLocator, as shown in the following example:CustomConfigServiceBootstrapConfiguration.java.
@Configuration @@ -71,13 +71,13 @@ To provide a customRestTemplate:
- In
resources/META-INF, create a file calledspring.factoriesand specify your custom configuration, as shown in the following example:spring.factories.
org.springframework.cloud.bootstrap.BootstrapConfiguration = com.my.config.client.CustomConfigServiceBootstrapConfiguration-
When using Vault as a backend to your config server, the client needs to supply a token for the server to retrieve values from Vault. +
When using Vault as a backend to your config server, the client needs to supply a token for the server to retrieve values from Vault.
This token can be provided within the client by setting spring.cloud.config.token
in bootstrap.yml, as shown in the following example:
bootstrap.yml.
spring: cloud: config: token: YourVaultToken
-
Vault supports the ability to nest keys in a value stored in Vault, as shown in the following example:
echo -n '{"appA": {"secret": "appAsecret"}, "bar": "baz"}' | vault write secret/myapp -
This command writes a JSON object to your Vault.
To access these values in Spring, you would use the traditional dot(.) annotation, as shown in the following example
@Value("${appA.secret}") String name = "World";
The preceding code would sets the value of the name variable to appAsecret.