4 ms·
From experience, it's good to support multiple ways of configuring an app. Depending on your case, this could become hard or requires naming conventions. This
by xiwenc 6y ago
From experience, it's good to support multiple ways of configuring an app. Depending on your case, this could become hard or requires naming conventions.
This way you can move secret data to files if needed depending on the deployment choice.
My own rule of thumb is:
1) sensible default value
2) read from file
3) read from env
Examples:
- https://github.com/spf13/viper https://github.com/spf13/viper
- https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-external-config https://docs.spring.io/spring-boot/docs/current/reference/ht...
- djsumdog 6y agoWhen I was doing Scala development, we went the same route using TypeSafe Config. Default/file in the src/resources which could be overridden by ENV. It seems like secrets aren't orchestration agnostic. You can't seem to use Docker secrets without being in swarm mode, and k8s has its own secrets management system (or if you're running on AWS, you can use pod2iam and ssm to store/get encrypted parameters). I've been at places that use k8s+vault as well.