This is more like a feature request. Sorry for enlisting it under issues.
I just managed to host both Client and Server (Cloud Config) within the same Spring Boot application. I did this to avoid SPOF of our servers. The goal is to have configuration of a server refreshed via a remote repository, but not be dependent on an external server. This works fine.
As this might be unconventional (if I may), could you guys allow this approach to continue. As in, don't break the ability to have Cloud Config Server and Cloud Config Client on the same Spring Boot app?
Thanks in advance!
Comment From: dsyer
It's already a feature then (http://projects.spring.io/spring-cloud/spring-cloud.html#_embedding_the_config_server)? Why would we mess with that? Did you use spring.cloud.config.server.bootstrap=true? Also useful spring.cloud.config.server.prefix.
Comment From: akila-affle
@dsyer Yes. Thank you. Just wanted to also mention that having a central server triggers single point of failure. Hence the embedded approach is much safer.
Comment From: dsyer
Can you explain that a bit? What is the expected failure mode and how can you protect against it with an embedded server?
Comment From: akila-affle
Hope I'm being constructive :)
So, in our context (our company, and I guess is common): 1. Many independent systems (groups of machines) working on different projects. 2. Configuration is right now inside these servers.
Having a single config server externally implies, if it goes down, all these systems will be defunct.
However, if the config server is embedded in each of these systems, then there would not be such a case where all systems go down unless of course, the git repo server itself goes down (which won't be a big problem).
Comment From: dsyer
Thanks for the detail. So you don't need the config server at all (no endpoints).
I see how that solves your problem, but isn't it easier to just scale out the config server (3 instances would be kind of standard practice - one spare and one extra just in case)?
Comment From: ghost
I think it is a better option to introduce redundancy on the config server instead of duplicating all the properties in each application/service. We can setup load balancing among these instances for fault tolerance.
Comment From: piyusht007
@dsyer @akila-affle I was wondering what is the difference between a standalone config server and embedded config server. Looking at the discussion above I could get how embedded config server will be used. To draw my understanding on that, when we use embedded config server the service will make calls to the endpoints and get the configuration.
Whereas if we switch to a standalone config server, there will be no endpoints which exposes the properties. How will the clients get their configuration?
Could you guys shed some light on how a standalone config server is used in reality?
Comment From: dsyer
I think the term “embedded server” is an oxymoron, so I would avoid using that if I were you. It’s not a pattern that we’ve seen people using in practice (reality). The scenario envisaged by the OP has no clients and no server.
Comment From: piyusht007
Thanks @dsyer for the quick response. I am still confused about how to use a standalone config server. Most of the examples are making use of @EnableConfigServer annotation to showcase how a config server works.
Could you suggest an example (a git repository, blog etc..) where a config server is being setup without making use of @EnableConfigServer ?