Spring Cloud Config — Best Practices

I have been using the Spring Cloud Config to externalize the configuration from the micro services.

Here I am not giving details on how to configure Spring Cloud Config server. I am going to write the best practices in using it.

· Always run multiple instances of config server behind a load balancer(preferably internal ELB), as the configuration is key for all the services. The services will fail to start if they cannot fetch the required properties.

· Avoid using the API Keys. Use default credentials chain or IAM roles(Instance Profile credentials)

· The config server does not complain to start if you configure wrong Git uri. The clients will fail when they try to fetch the configuration. To avoid this, always enable clone-on-start property, so that you will realize the mistakes before it’s too late.

spring.cloud.config.server.git.clone-on-start=true

· The config server uses a temporary location(/temp) on the file system to clone the repository and refers the same all the time. The linux machines temporarily cleans this directory and the config server never fetches the configuration again.

It is going to be very difficult to diagnose the issue when you have multiple instances of config servers. You can override the cloning directory using the basedir property.

spring.cloud.config.server.git.basedir=/opt/yourconfigrepo

· Also, make force-pull value to true to make sure the server fetches the configuration when the local repository is corrupted.

spring.cloud.config.server.git.force-pull=true

· The config client just hangs or shutdowns if it fails to get configuration from config server. Enable retry using the below property, so that it retries 6 times with an initial back off interval of 1000ms and an exponential multiplier of 1.1 for subsequent back offs. You can take full control on the retry by overriding RetryOperationsInterceptor