Spring Cloud Config is Spring's client/server approach for storing and serving distributed configurations across multiple applications and environments.
This configuration store is ideally versioned under Git version control and can be modified at application runtime. While it fits very well in Spring applications using all the supported configuration file formats together with constructs like Environment, PropertySource or @Value, it can be used in any environment running any programming language.
A workshop uses Spring Cloud Config Server.
- Strategies for storing configuration properties
- Run Service
- Required Backend Configuration
- Create
- Resources
- TODO
Spring Cloud Config relies on three parameters to identify which properties should be returned to an application:
{application}: the name of the application.{profile}: client's current active application profile.{label}: a discriminator defined by the specific Environment Repository back-end. In the case of Git, a label can be a commit id, a branch name, or a tag.
The Git-backed configuration API provided by our server can be queried using the following paths:
/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{label}/{application}-{profile}.json
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties
| Path | Description |
|---|---|
| /{app}/{profile} | Configuration data for app in Spring profile (comma-separated). |
| /{app}/{profile}/{label} | Add a git label |
| /{app}/{profile}{label}/{path} | An environment-specific plain text config file (at "path") |
To complete our server, we have to initialize a Git repository under the configured url, create some new properties files and popularize them with some values.
The name of the configuration file is composed like a normal Spring application.properties, but instead of the word ‘application' a configured name, e.g. the value of the property ‘spring.application.name' of the client is used, followed by a dash and the active profile. For example:
$> git init
$> echo 'user.role=Developer' > config-client-development.properties
$> echo 'user.role=User' > config-client-production.properties
$> git add .
$> git commit -m 'Initial config-client properties'Assume the GIT REPO is used
curl --location --request GET 'http://localhost:8080/team-a-dev.json'
curl --location --request GET 'http://localhost:8080/team-a-dev.yml'
curl --location --request GET 'http://localhost:8080/team-a-dev.properties'
curl --location --request GET 'http://localhost:8080/team-a/mem-service'
curl --location --request GET 'http://localhost:8080/greeting-service-staging.json'
curl --location --request GET 'http://localhost:8080/team-a-userservice.json'
-p 8888Server port-v /configMounted configuration
JAVA_OPTSSpecify VM Options or System Properties
Spring Cloud Config Server is a normal Spring Boot application, it can be configured through all the ways a Spring Boot application can be configured. You may use environment variables or you can mount configuration in the provided volume. The configuration file must be named application and may be a properties or yaml file. See the Spring Boot documentation for further information on how to use and configure Spring Boot.
Spring Cloud Config Server requires that you configure a backend to serve your configuration files. There are currently 6 backends to choose from...
The Spring Boot actuator is
enabled by default. See the Spring Boot documentation
for configuration options. The actuator can be disabled entirely by including the no-actuator profile
Spring Cloud Bus links the nodes of a distributed system with a lightweight message broker. It allows clusters of applications configured with RefreshScope to automatically reload configuration without restarting.
See the Spring Cloud Conifg and Spring Cloud Bus documentation for more details
Create a repository using this template →
- Serve Private Resository
- Helm charts
- Example queries
- Tests
