4 ms·
While at it I’ve made it a practice to expose an internal endpoint for every service to output its config. It has saved me on numerous occasions to catch config
by vishnugupta 3y ago
While at it I’ve made it a practice to expose an internal endpoint for every service to output its config. It has saved me on numerous occasions to catch config related bugs.
- simply_seal 3y agoCould you explain a little more? I am not sure what exactly you mean by "exposing an internal endpoint" - do you mean that as a secured API endpoint which you can call? Isn't that hard to secure?
- delecti 3y agoDepending on your environment, endpoints might not default to exposed. As an example where I work, we have to explicitly enumerate endpoints to expose (potentially including wildcards, like admin/*), and anything else is only accessible with direct access to the pod.
- shrimpx 3y agoPresumably you can access it while on a secure VPN but not publicly. You can do this by serving the config route on an internal port.
- vishnugupta 3y agoIndeed, that’s exactly how my team did it.
- twic 3y agoThis is not an endorsement, but Spring Boot has this built in (but not enabled by default): https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.endpoints https://docs.spring.io/spring-boot/docs/current/reference/ht... I have been leaning towards a different approach. Rather than reading multiple config sources at runtime, read them at build time, and emit a single config file with everything fully resolved. Put that on the filesystem, and have the app read it. You have an easy canonical reference for the configuration, with no need to expose anything. The lifecycle of the config doesn't have to match that off the app binary, so it could (and probably should) have a separate build and release process.