This content originally appeared on Level Up Coding - Medium and was authored by KBryan
Sharing what I found useful in understanding Spring Cloud Config with Spring Boot
Previously, I wrote about the order of precedence for properties files when developing with Spring Boot and Spring Cloud Config. Do check it out if you have yet to do so. In this article, I will share some tips that I found useful in helping me understand the order of precedence for properties files as well as ways to develop efficiently with Spring Cloud Config. Without further ado, let’s begin!
Tip #1: Debugging Property Sources Loading Precedence Order
The easiest way to debug the Spring Boot application’s property source loading precedence is by enabling the env endpoint in the Spring Boot Actuator API.
Add the actuator dependency above and set the configurations below in the application’s application.yaml to enable to env endpoint.
management.endpoints.web.exposure.include: env
Then, browse to http://localhost:8080/actuator/env to view the property sources’ information. You should get something like this.
The order of precedence is from top-down where index 0 has the highest priority. Besides properties files, you can also find properties that are set via command-line arguments, system properties, or environment variables. This can be useful in ensuring that the right properties are loaded for all of your deployment environments.
Tip #2: Localhost Development with Spring Cloud Config
When your Spring Boot application is loading properties from external sources (Eg. Spring Cloud Config Server), it can be frustrating and tedious to test your configurations when developing. This is because to update the properties, you will have to update the properties files, commit the change and push it to the remote git repository.
Using the above setup as an example, we will have a Spring Boot application (config-client) that loads properties from the Spring Cloud Config Server. To facilitate localhost development, we want to be able to update the properties and reflect the changes immediately. To do that, here are a couple of approaches we can use:
1 — Using Property “spring.cloud.config.allow-override”
If you refer to the Override the Values of Remote Properties section in the Spring Cloud documentation, you will find that it is possible to override remote properties with local properties by setting the following configurations in the application.yaml in the remote git repository.
# application.yaml
spring.cloud.config:
allow-override: true
override-none: true
override-system-properties: false
However, this only works if you are importing the properties from Spring Cloud Config Server using the bootstrap configurations (spring-cloud-starter-bootstrap). Eg.
# bootstrap.properties
spring.application.name=config-client
spring.cloud.config.fail-fast=true
spring.cloud.config.uri=http://localhost:8888 # Config Server URL
With Spring Boot 2.4 updates, the recommended way to import properties from Spring Cloud Config Server is to use the spring.config.import property in the application.yaml file instead of the spring.cloud.config.uri property in the bootstrap.properties file.
Because of this, the override-none property no longer works as intended since it is processed within the bootstrap configuration which is no longer the recommended approach. This issue is also highlighted in Spring Cloud Config’s Github Issues.
Hence, if you are not using the bootstrap configuration to import the properties from the Spring Cloud Config Server, the property spring.cloud.config.allow-override might not work for you.
2 — Using “local” Spring Profiles
As mentioned in my previous article, external properties files always override packaged files (profile-specific or not). Hence, we can exploit Spring Profiles to load environment-specific properties files. To do that, we will use a local Spring Profiles with a corresponding profile-specific properties file (application-local.yaml) in the project’s root.
Essentially, we are importing the remote properties files from Spring Cloud Config Server in the src/main/resource/application.yaml. Then we will create an application-local.yaml properties file in a config folder in the project’s root. With this folder structure set up, we can now run the Spring Boot application on the localhost machine:
gradle config-client:bootRun \
-Pargs=--spring.profiles.active=dev,local
The Spring Boot application will be executed with active Spring Profiles dev and local with the latter taking a higher priority. Hence, it will load the properties files in the following order (highest to lowest):
- application-local.yaml (Config Folder) — external (local)
- config-client-dev.yaml (Config Server) — external (remote)
- config-client.yaml (Config Server) — external (remote)
- application.yaml (Classpath) — internal (local)
As you can see, the application-local.yaml will have the highest priority which is useful when you are developing on the localhost machine.
Additionally, the config folder will not be included when we dockerize or build the Spring Boot application. Hence, it is safe to include the config folder in the git repository to facilitate localhost development for other developers.
3 — Connecting to a Localhost Spring Cloud Config Server
The last approach is to run a localhost Spring Cloud Config Server instance. Instead of loading the properties files from a remote git repository, we can locate the properties files locally in the file system. Thankfully, Spring Cloud Config Server provides us with the native profile mode which simplifies this configuration.
There are a couple of caveats to using a localhost Spring Cloud Config Server.
- Firstly, we will have to configure the Spring Boot application to point to the local Spring Cloud Config Server instance instead of the remote instance when we are developing locally. This can be achieved easily using different Spring Profiles.
- Secondly, we will have to manually update the configurations in the local file system to pull the latest from the remote git repository. This is exceptionally important when we are working in teams where the remote properties files can be updated anytime.
- Lastly, if the Spring Cloud Config Server is configured to load from multiple remote git repositories, this approach can be painful to manage.
Overall, this is an “okay” approach but I would recommend approach #2 instead as this approach requires lots of manual intervention from developers.
Tip #3: Refreshing Properties at Run-Time
The final tip is that Spring Cloud provides methods to allow Spring Cloud Config Clients to refresh their properties without restarting the client. To do that, simply enable the refresh endpoint of the Spring Boot Actuator API in the Spring Boot application (config-client).
Add the actuator dependencies above and set the configuration below in the application.yaml to enable the refresh endpoint.
management.endpoints.web.exposure.include: refresh
The /actuator/refresh endpoint only refreshes properties that are annotated by the @ConfigurationProperties. If we want to refresh properties that are annotated with the @Value, we will have to include the @RefreshScope annotation. Below is an example using a Restful API use case.
With the above example, whenever we update the property my.custom.property, we can trigger a refresh in the config-client using the actuator endpoint /actuator/refresh. To verify that the property has been updated, simply hit the API endpoint that we created /api/print. This is a simple use case and the purpose is to introduce you to the /refresh feature of Spring Cloud Config.
However, in a typical cloud environment, there will be multiple client instances, and refreshing each client’s configuration using the /actuator/refresh endpoint will be very tedious. Thankfully, there is Spring Cloud Bus which helps to automate the properties refresh through a lightweight message broker (Eg. Kafka / RabbitMQ). I will not be covering that in this article, but do check that out on your own :)
Conclusion
These are the 3 tips that I have learned when developing with Spring Cloud Config. Thank you for reading until the end. I hope you learned something new from this article. If you like this article, please follow me for more! Happy Learning :)
Level Up Coding
Thanks for being a part of our community! More content in the Level Up Coding publication.
Follow: Twitter, LinkedIn, Newsletter
Level Up is transforming tech recruiting 👉 Join our talent collective
3 Useful Tips for Developers when using Spring Cloud Config was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by KBryan
KBryan | Sciencx (2022-07-11T11:52:46+00:00) 3 Useful Tips for Developers when using Spring Cloud Config. Retrieved from https://www.scien.cx/2022/07/11/3-useful-tips-for-developers-when-using-spring-cloud-config/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.