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!
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.
Platform used : Kubernetes.
I have an issue with Spring cloud stream url. I am launching my spring cloud tasks using spring cloud stream. Streams are deployed in kubernetes platform. Stream contains http-kafka as source and taskLauncerKafka as sink. I used http-kafka kubernetes service url to launch tasks. Kubernetes service url changes after each deployment which causes problem.The changes in the service name after each stream deployment is difficult to manage. I have tried enabling loadbalacer also. In that case also external ip-address changed after each stream roll-out.
I am using skipper for managing the deployments. Every time stream is deployed stream version changes which also changes stream url.
In my case , I have multiple instances from where I can launch spring-cloud task. If the stream url changes I need to make changes in the configmap of the deployment project for all instance and need to redeploy all instance.
Any solution ? I am thinking of centralised configuration management using spring-cloud-config server or zookeeper. In this case also I need to update the url. I can avoid deploying multiple instances using centralised configuration management.
Skipper server version : 2.4.1.RELEASE
Dataflow server version : 2.5.1.RELEASE
Which version of SCDF/Skipper you are running?
This looks similar to the issue https://github.com/spring-cloud/spring-cloud-skipper/issues/953 which was subsequently addressed in Skipper 2.6.0.
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?
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.