8 ms·
I don't understand why people use config servers like this, instead of keeping it in version control. Keeping it in the repository allows me audit changes of e
by munro 6y ago
I don't understand why people use config servers like this, instead of keeping it in version control. Keeping it in the repository allows me audit changes of everything. If you move it to an external service, you lose that. And even if the external service has an audit trail, now you have two sources of version control. My assumption why people would do this is because 1) they're told that's how it should be done 2) they have a slow deployment processes, where it takes too long to get the change merged & deployed. Anyway, I've very happily never used a config service, and I still remain unconvinced. :)
- axlee 6y agoDo you keep your API keys and other sensitive data in the git repo as well, visible to all git contributors regardless of their credential level?
- makach 6y agoBeat me to it! ;-)
- munro 6y agoVault/k8s secrets for sensitive data--but you know, it really depends on the context for sensitive data, there isn't a simple answer to say what I've done across the board
- camsjams 6y agoDo you store your API keys and other sensitive data with a site that doesn't even have a page discussing their encryption or security practices? Their privacy policy mentions they secure data with SSL protocol... Who has access to each client's database? Is it audited? Is it encrypted at rest? I'm sure it is, but Config.ly would be wise to add this information to avoid fears. Also you can store encrypted secrets in Git just fine, there are a number of methods to do so very safely.
- munro 6y agoOhhh, that's such a great idea. I've done that before for TravisCI, now that I remember, it's really slick. https://docs.travis-ci.com/user/environment-variables/#defining-encrypted-variables-in-travisyml https://docs.travis-ci.com/user/environment-variables/#defin...
- jeremyis 6y agoThanks for the feedback. The goal right now is not to store sensitive data in Config.ly - your read API keys will be on your clients - and so in theory anyone who can read that source code can fetch your keys. > Who has access to each client's database? Is it audited? Is it encrypted at rest? I'm sure it is, but Config.ly would be wise to add this information to avoid fears. This is great feedback, thank you.
- seer 6y agoBerglas is great in that regard, as you can keep the unique names to the sensitive data in version control, but have the actual values sit in behind an acl in a secure location. You’re able to guard secretes as need, but keep the audit-ability of version control.
- dharmab 6y agoWe store the vault paths/fields/versions in git and they're dereferenced outside of git (either directly in the software or in an intermediate deploy step).
- rad_gruchalski 6y agoYes! Ansible Vault encrypted. sops is an alternative.
- makach 6y agoDo you check in passwords into your version control? How do you differentiate between different deployment settings?
- crispyporkbites 6y agoSecrets should be in env vars or secret storage like hashicorps vault You set those on deployment so your engineering team never see production secrets
- lukerohde 6y agosops is a great tool for version-controlled secrets - plaintext keys and encrypted values using remote KMS to do the encryption. https://github.com/mozilla/sops https://github.com/mozilla/sops
- kall 6y agoIf you deploy to app stores you have a slow deployment process and there is not much you can do about it.
- munro 6y agoOh yea, mobile apps are totally a great use case. But honestly I would probably just toss a quick route for `/config` in my backend server that returns my config JSON for the app--and then boom we're back to having version controlled configs in my git repos. And obviously, make sure in the app to cache the last version incase there's no internet connection, unless maybe the app requires an internet connection.
- jeremyis 6y agoMakes sense and you could definitely do that. I could be wrong, but I think some folks would want their other clients -- even their server -- retrieving that value from that one single source. So when you roll an Android app, you'd also want to implement HTTP + caching... And basically you're on the path to building your own Configly.
- kall 6y agoIt’s really not so hard to roll yourself IF you don’t need a web interface. In my GraphQL api I have a resolver called appConfig. That enables me to fetch the config I need for a screen in the same request as the data and to reuse any caching/offline/http logic the app already has. Zero added latency. No service can beat that, but then it‘s also just me editing postgres to change the config.
- michaelmior 6y agoI think even if you do need a web interface, there are enough plug and play tools that will give you something that works reasonably well. That isn't to say that a service like Config.ly couldn't do a much better job.
- asutekku 6y agoI’m just saying that if a non-developer needs to config something, they for sure would like to have a web interface.
- jeremyis 6y agoHey thanks for the insightful comment! I'm sympathetic to your thought here on having an external service and going with a simple approach. Situations with a slow deployment process has been a big motivator for building Config.ly -- and I've seen it happen at companies with medium-sized eng teams (taking hours to swap values during incident fires), and I know it's a problem _all_ iOS developers have due to the app store deploy process. I also think there's other value here... For instance having a UI means non-technical folks can update it. A lot of my time as an engineer has been spent making copy tweaks (I've felt existing CMS products were too heavy-weight and difficult to plugin). Also, having turn-key libraries mean you don't have to copy/paste hardcoded values among many clients (or store on the server build an API for _every_ constant). I'm a big fan of DRY.
- bawejakunal 6y agoBig +1 for making it easier for non engineering folks to update the copy strings via UI. This is something very useful for product teams at mid size companies
- jeremyis 6y agoThanks! Curious - why do you state mid sized companies specifically?
- bawejakunal 6y agoSome sort of dynamic config management existing via spring cloud or homegrown systems like configbus - easier to implement for larger tech companies, but the small and mid sized may benefit a lot f in their development speed from this off the shelf solution I believe as it evolves further
- jeremyis 6y agoGot it. thanks!
- specialist 6y agoFurther, a lot of "configuration" can just be the environment (context). Isn't that precisely what DNS is for? An instance of an app (process, service, whatever) doesn't need to know that it's "dev", "test", "prod". Just have it look for "the database" and change the /etc/hosts (or equiv) as needed. My impression is that istio (?) is supposed to formalize this approach. That'd be nice. I'm so done having this conversation with teammates. Yet another reenactment of the "why use version control" war. There's always some stubborn refusal to join the third millennium. Because reasons. It's too complicated. No one knows how to do that. It's hard to debug. Whatever. Every new cohort believes they're the first to invent configuration management.
- rad_gruchalski 6y agoYou can implement the best of both worlds. Have new writes and updates always go through ci/cd but reads from all services.
- bluehatbrit 6y agoWe do both, to a point. We use Hashicorp's Consul to push config changes to running systems, but we sync it from a repo using an internal git2consul type thing. It's nice to be able to push things into the system while it's running without hopping through all the hoops of qa, staging, etc. We then usually move it into the applications base configs in the app repo if it's going to stick around for more than a day or two to keep things tidy. There's nothing wrong with a service to push config into a system at run-time, and you don't have to throwaway the benefits of the git history.