I've built up a Spring Cloud Config Server integrated using Spring Cloud Bus via Kafka for refreshing properties dynamically. I've another application that is Spring Cloud Gateway that consumes those properties and refreshes them dynamically.
One of the things I'm struggling with is if I (unintentionally) update a bad property (for example: spring.cloud.gateway.routes[0].predicates[0]=Path=/demo/{demoId\:[0-9]+}, here backslash is something that is wrong here) in a Spring Gateway route.
The routing breaks in Spring Cloud Gateway with the error something like unable to initialize bean GatewayProperties and things starts behaving weirdly.
Two questions:
Is there a way to ignore bad config refresh events? Probably skipping refresh event that has a bad config.
If it's possible, Is there a way to evaluate those properties even before those are applied to the Spring context?
Related
Is it possible to make auto-refresh properties for Spring Cloud clients in a multi-pod environment (Google Kubernetes Engine)?
I found several work arounds:
Using Spring Cloud Bus (too heavy solution).
Running refresh inside code using RefreshEvent and #Schedule it (not recommended by Spring).
Creating a new endpoint in Config Server to perform a refresh on all Spring Cloud clients.
Spring Cloud Config uses Spring Cloud Bus uses Spring Cloud Stream to push configuration change events to clients.
My question - since I was yet to find it - is: what kind of queues does Spring Cloud Config create when it starts up? I noticed that it creates topics/queues automatically, but are they temporary, i.e. bound to the lifecycle of the server/client or durable. Do they have to be removed manually?
EDIT: I am using Spring Cloud Hoxton.SR3 with Spring Boot 2.2.5.RELEASE (or higher)
Thanks in advance!
We are using spring cloud sidecar with a node.js application. It would be extremely useful if we could serve up configuration from the spring configuration server and make that configuration available to the node application.
I would like the sidecar to resolve any property place holders on behalf of the node application.
The sidecar already hits the configuration server and I know that the Environment in the sidecar WILL resolve all the property place holders. My problem is, how do I efficiently expose all those properties to the node application? I could create a simple rest endpoint that accepts a key and then returns environment.getProperty(key) but that would be extremely inefficient.
I am thinking that I could iterate over all property sources (I know that not all property sources can be enumerated), collect a unique set of the names and then turn around and call environment.getProperty() for each name....
But is there a better way?
I have to imagine this is functionality that others have needed when using Spring Cloud in a polyglot environment?
I'm doing a proof of concept at my company with Spring Cloud Config, using a GIT repository. Since I have a pretty fixed infrastructure, I can't have a RabbitMQ broker for Spring Cloud Bus, therefore I'm thinking of embedding the Spring Cloud Config Server in our apps and calling RefreshEndpoint.refresh() every couple of minutes.
One of the main things I'd like to know is what are the concurrency implications of calling RefreshEndpoint.refresh()? If there is a request already going on, could it have any issues?
I want to add some lookup before the Spring context is loaded, which is ideally on the bootstrap phase of Spring Cloud (When it lookup for Configuration Server, Cloud connectors etc). How can I make my code to be executed on that phase ?
What I want to do is query Vault to get all my databases secrets and api keys and set the properties, I know I can encrypt with Spring Cloud Config, but I liked the strong box of Vault. (The integration with Vault part I can handle)
As I saw in the code of Spring Cloud Config, the bootstrap configuration is auto-configured by using the class org.springframework.cloud.bootstrap.BootstrapConfiguration on the resources/META-INF/spring.factories file, the same which you can use to register new auto configuration classes for Spring Boot, as reference you can refer to the file on the project here. This will make your configuration be started and registered before the "normal" application context.