views:

58

answers:

3

The scenario I am particularly interested is multiple servers having daemons that run on certain configuration parameters. (since, this is a learning exercise. i welcome any thought beyond this particular case) The question is, where should the configuration parameters sit.

A. a central database table

B. a config file pushed to each of the boxes

These are the most common I've come across. The notable others being, in code constants (needs recompile to deploy. so bad option unless they really are constants), config file mounted on a shared location.

Just wanted to know from the community on how you go about making the choice.

+4  A: 

It all depends on the scale of the operation you're managing.

If the number of locations is large and/or changes are frequent, use a database.

Otherwise, use configuration files.

If access to a centralized database is too slow or unacceptably a point of failure, but the scale is still large, use an automated system like Puppet.

Borealid
the last point can be mitigated with a slave and query cache.
neal aise
+1  A: 

Most companies with a need to share configuration parameters between servers/applications end up creating their own configuration mechanisms and storing them in a home-rolled relational database. I would argue that the scale doesn't even matter. Having to log into multiple servers in order to check a configuration on the file system is a nightmare. However, even when managing configuration in a central database, you still have to make sure that the configuration is easy to access. I've seen this type of configuration used at 3 different companies, and the only place that it was used in a truly successful manner, was where the application exposed a simple user interface allowing system administrators to tweak the settings. If it's only accessible by using a SQL client, you'll find that configurations will easily get "lost" or worse, duplicated.

The above poster mentioned Puppet, which I've never used, but it looks VERY interesting. However it doesn't look like it supports Windows yet [1]: http://www.puppetlabs.com/puppet/requirements/

warriorpostman
agree on having a user interface/ or at least an api for accessing the parameters. it restricts the way you can get/set config params and of course allows you to switch back n forth between config files and db tables :)
neal aise
A: 

If the config properties can be updated at runtime, centralizing the properties in the DB will make life easier.

btreat