We plan to move from a series of static configuration files related to the deployment of each client.
All client data is stored in MySQL, metadata for client deployment is in a static text file: which database / shard to use, the directory / location of the storage for the file storage and a bunch of more information, such as the default pagination, speed and modules.
We want to move away from these static & mdash configuration files, which are currently larger than key-value pairs, and use Perl hashes and arrays, but can be simplified in this way with some effort and use something that can live in a responsive database , LDAP, or another repository. Flexible LDAP & mdash structures that allow nesting / hierarchy of data, I think, look attractive, but I was wondering if there are any other tips on the best way to do this. I do not think that LDAP was really designed for this, and it has been around for a long time.
The “key” that we will use to determine the deployment path, database, repository, and other variables will be the deployment “domain” (they will be unique), and ideally we would like the configuration storage solution to be a central point or an integrated service which several servers can request very quickly (on a local network).
Based on this data, very few “updates” will be made, but the read speed will be very very frequent, so the read speed is crucial.
Any tips?
Jeff
user87422
source
share