I am using the Spring Cloud Config Server and able to detect the changes from the git repository and pass it to the Config clients.
There are two ways, I have implemented it:
After making changes (commit and push) in the git repository, I make a curl request curl -X POST http://server:port/bus/refresh and it works fine. For this I am using RabbitMQ as the Spring Cloud Bus.
Reference:
http://tech.asimio.net/2017/02/02/Refreshable-Configuration-using-Spring-Cloud-Config-Server-Spring-Cloud-Bus-RabbitMQ-and-Git.html
After making changes (commit and push) in the git repository, I make a curl request curl -X POST http://server:port/refresh (with no /bus in the url) and it works fine. I am NOT using Spring Cloud Bus here.
Reference: https://spring.io/guides/gs/centralized-configuration/
So both works fine, so Is there any advantage of using Spring Cloud Bus, or in Production environment, will there be any issue with going without Spring Cloud Bus? As there will be extra effort needed to get setup the RabbitMQ Cluster (HA) as Spring Cloud Bus in production.
Thanks,
David
/refresh will only refresh the config client to whom the request was made. It only refreshes locally. Using /bus/refresh will refresh all clients connected to the bus. In other words it will refresh all bus clients (or a subset if the destination parameter is set).
Related
I mean spring cloud config server fetches all client api's configuration during startup ?
or
spring cloud config server fetch the client API configuration, when that client api calls the config server?
That behaviour is controllable via a property:
spring.cloud.config.server.git.clone-on-start
Flag to indicate that the repository should be cloned on startup (not on demand). Generally leads to slower startup but faster first query.
Default:
false
So the default behaviour is that the repo will only be cloned when a client first makes a request to the server, but if you set the property to true, then the server will clone the repository when it starts and the configuration will be available to the client's first request faster
I have two microservices. A Spring Cloud Config Server and another module that implements Spring Cloud Config Client. When I use the default configuration for the Spring Cloud Config Server service (localhost:8888) I can start it locally without any issues, after which I can start my other module as well, using a bootstrap.yml, it clearly finds the Config Server, fetches its properties and starts properly. All good. Now I'd like to push both of these services to Pivotal Cloud Foundry.
The Config Server service works just fine, service is up and running in my Space, and using the browser I can verify that it can still fetch the property files from the specific GitHub repository.
The problem is the other module, the client. I've replaced the default localhost:8888 in its bootstrap.yml file (spring.cloud.config.url parameter) to the now active service in the cloud using the Route bound to it and tried to start it locally. Unfortunately now it simply timeouts during startup. At this point I tried to specify longer timeouts but nothing helps.
Interesting thing is that if I directly copy the URL from the logs that timeouts I see it works properly in the browser locally. So why not in IntelliJ when I try to package the client with the changed parameter?
Sorry, I can't include much details here, but I hope maybe there is a straightforward solution that I've missed. Thanks!
Was wondering the recommended way of starting a spring boot app if the Spring cloud config server is temporarily down or unavailable. What would be the approach? I know of the retry configurations, but I am wondering if there is a way to have a 'replica' config server and use that as a failover (or something along those lines).
Sure, why not?
After all, spring-cloud-config server exposes rest API and all the interaction with spring boot microservices is done over HTTP.
From this point of view, you can scale out the spring cloud config server by providing more than one instance of it all are up-and-running and mapping them to one virtual IP.
If you're running in some kind of orchestrated environment (like kubernetes) it is a very easy thing to do.
I have spring web application (not spring boot) running in AWS. I am trying to create centralized configuration server. How to refresh the spring-cloud-client after the changing the properties? As per tutorial
Actuator endpoint by sending an empty HTTP POST to the client’s refresh endpoint, http://localhost:8080/refresh, and then confirm it worked by reviewing the http://localhost:8080/message endpoint.
But my aws Ec2 instances are behind the loadbalancer so i can't invoke the client url. I didn't understand the netflix Eureka and Ribbon much but it seems like adding another level of load balancer in the client side. I don't like this approach. Just to change a property i don't want to make the existing project unnecessarily complex. Is there any other way? or Am I misunderstood Eureka/Ribbon usage?
I have looked at the spring-cloud-config-client-without-spring-boot, spring-cloud-config-client-without-auto-configuration none of them have answer. First thread was answered in 2015. Wondering is there any update?
To get the configuration properties from a config server. You can do a http request. Example:
From the documentation we can see:
/{application}/{profile}[/{label}]
/{application}-{profile}.yml <- example
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties
So if you would do a request to http://localhost:8080/applicationName-activeProfile.yml you would receive the properties in .yml format for the application with that name and active profile. Spring boot config clients would automatically provide these values but you will have to provide em manually.
You don't need Eureka/Ribbon for this to work, it's a separate component.
More info: http://cloud.spring.io/spring-cloud-static/spring-cloud.html#_spring_cloud_config
Maybe you could even use spring-cloud-config but I'm not sure what extra configuration is needed without spring-boot.
https://cloud.spring.io/spring-cloud-config/
I created spring cloud config server and client and they work as expected. I have added #RefreshScope to my client and I am able to see the new properties getting fetched after hitting /refresh endpoint. But I was told that when I deploy it in cloud foundry environment , I must integrate it with RabbitMQ in order for all the instances to receive the refresh message. Is it possible to point me to a link which explains this problem and solution in detail?
Spring Cloud Bus
This is what you need in order to propagate configuration changes to all of your servers via a message broker such as RabbitMQ.
GitHub Project
Documentation
Follow the instructions in the links above you're good to go.
So I assume your application runs as single instance configuration. In that case, you don't need spring cloud bus based refresh and just hitting the {app}/actuator/refresh would be enough. Only if you scale out your app, we would need such setup with a queue like RabbitMQ or kakfa.