In this series, learn to build microservices using Go and add integrations to help them run on Docker Swarm within a Spring Cloud/Netflix OSS landscape.
Just so I understand your criticism - do you dislike the concept of a centralized configuration server in general, or is it the functionality that enables on-the-fly reloading of configuration you're opposed to?
Regarding the latter - I can certainly agree with you for the reasons you stated. Perhaps the Spring people had more traditional deployments in mind when they added the @RefreshScope and "push" mechanisms to Spring Boot / Spring Cloud config server.
On the topic of using centralized configuration as described in this post, loading the configuration from a given git repository/branch/tag through the Spring Cloud config server provides something very similar to deploy-time injection from a versioned source.
I'm also doing quite some work on OpenShift these days where configuration is handled quite differently, with "config maps" and "secrets" being injected as file system resources as specified in deployment configurations. At some point I'll probably port the Go microservice landscape into OpenShift or K8S which will probably make the config server superfluous and change how Viper loads config into the Go runtime.
Hi @Satish. To be honest, I'm not sure. I've been using OpenShift quite extensively lately and there you can configure liveness and health probes on their "deployment configuration" level that does _not_ rely on having curl or a custom (as in this blog post) executables linking Docker HEALTHCHECK mechanics to the running service.
It's possible Docker in Swarm mode has received more functionality regarding this since I wrote the original blog post, but that's an unknown for me at this moment.
Comments
Mar 15, 2018 · Arran Glen
Hi Robert, thank you for your comment.
Just so I understand your criticism - do you dislike the concept of a centralized configuration server in general, or is it the functionality that enables on-the-fly reloading of configuration you're opposed to?
Regarding the latter - I can certainly agree with you for the reasons you stated. Perhaps the Spring people had more traditional deployments in mind when they added the @RefreshScope and "push" mechanisms to Spring Boot / Spring Cloud config server.
On the topic of using centralized configuration as described in this post, loading the configuration from a given git repository/branch/tag through the Spring Cloud config server provides something very similar to deploy-time injection from a versioned source.
I'm also doing quite some work on OpenShift these days where configuration is handled quite differently, with "config maps" and "secrets" being injected as file system resources as specified in deployment configurations. At some point I'll probably port the Go microservice landscape into OpenShift or K8S which will probably make the config server superfluous and change how Viper loads config into the Go runtime.
Mar 13, 2018 · Arran Glen
Hi @Satish. To be honest, I'm not sure. I've been using OpenShift quite extensively lately and there you can configure liveness and health probes on their "deployment configuration" level that does _not_ rely on having curl or a custom (as in this blog post) executables linking Docker HEALTHCHECK mechanics to the running service.
It's possible Docker in Swarm mode has received more functionality regarding this since I wrote the original blog post, but that's an unknown for me at this moment.