Developing microservices using Spring Boot, and are currently working on containerizing our applications. However, I can't seem to figure out best practices for Cloud Config client.
How do I best update the cloud config server for the docker container?
Thanks!
In practice, the your containerized config application should be pulling the config from some centralized repository where configs are checked in and from there your microservices or containerized app will pull the config for further process.
Related
I am migrating a Spring Boot application from PCF to AWS ECS which is currently using cloud config server reading properties from git repo, and aws RDS. Now in ECS is there a way we can implement config servers along with refresh in ECS AWS.
I think ECS operates on a different level.
Spring Cloud Config server is a solution that works especially good with spring boot based applications. For example, a refresh option that you've mentioned is implemented as a special Scope which is purely a spring (applicative) thing.
On the other hand, AWS ECS (stands for Elastic Container Service) provides a way to work with containers in a general sense (with scaling and everything). It doesn't require the containers to be spring-based or even java based.
So, I think you might want to consider keeping a spring boot driven microservice for config server just like you have now, but wrap it into docker container and deploy it in AWS ECS
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 am confused when to use spring cloud config server and consul.
Both will read configurations files in their own ways.
Can you please let me know when use spring cloud config server and when to use consul?
Both serve configuration from remote servers to spring boot applications. Config Server aggregates configuration from multiple sources: git, svn, sql databases, vault and credhub. Spring Cloud Consul serves configuration to boot apps directly from the consul key-value store. If you already have consul in your infrastructure, it would simplify things by not having to run config server.
I am working on spring boot app which will be deployed in pcf and it will use pcf config server service which is backed by hashicorp vault. What I would like to know is which dependencies I should be adding in my spring boot app other that spring-cloud-config-client. Do I need to add spring-cloud-vault, if yes then why does it need to be added if app only talks to config server? I would like to know how this end to end interaction works.
I'm having a problem with how to use just Netflix Archaius to work as a config server for multiple Spring Boot microservices. Previously when I applied Eureka and Spring Cloud Config Server in my multiple-services project built with Spring Boot, each microservie would get its own .properties file from the Spring Cloud Config server through the discovery function of the Eureka service. But now I need to change the Spring Cloud Config Server into a Netflix Archaius service, from which the Spring Boot microservices will get .properties file, i have no idea about how to achieve it. Is there any good idea for my reference? Thanks in advance.
Finally I gave up using Netflix Archaius to pull properties file for microservices. Instead, I wrote down required key-value-pair properties into the application.properties of each springboot microservice. Since all the springboot microservices will be deployed in the DCOS platform in the form of docker containers, some inconstant properties were configured into the marathon deployment scripts, which could be populated into the springboot applet. In this way I managed to configure the key-value-pair properties from the outside instead of being hardcoded in the program codes.