In the last 2 months I have stored configuration details in multiple ways and this post is a reflection of those methods and what I default to now - I have seen the light.
As a developer trying to improve and follow well known best practices. The 12 factor app is usually where you would want to go to when looking for best practices as per production systems, chapter III speaks specifically on configuration management and the advice there is straight forward : Use environment variables.
To solve this previously, I have used the popular
.env file strategy where some initialization code pulls
out the content of the file and write to the the environment using
setenv. I have also used
While it works and common place, it is extremely easy to screw things up by checking in a copy of the config file into source control.
I have also tried POSIX flags but I can confirm that verbosity isn’t a feature.
In one of the projects I am currently working on, we started with just flags. It started small
but kept on growing large that flags started depending on flags 😔😔. For example, we had a
store flag that takes in storage
provider types ( file or minio), we would use file for local development and our minio instance in production.
store flag is
minio, it means 4 other flags have to be present (
with or without ssl ?). We felt the verbosity and moved to a mixture of flags and environment variables,
we moved most of the flags into a
env.csv file and we just loaded those into the env.
All was good until that I started to fill the fragility of this approach kicking in as I will sometimes have
servers running on different config values.
But this project is actually a medium scale distributed system and having to deal with deployment just wasn’t
as fun as it used to be. Having to push a new/updated configuration file,
or having to do
echo export NEWCONFIG_VALUE="oops" >> ~/.bashrc && source ~/.bashrc on all servers, nah!!!.
I looked for alternatives and since the system we are talking about is distributed in nature,
etcd was the next thing I looked into. This would make applications run a pull based
configuration system, once the server is starting up, it pulls it’s config from
consul and automatically configure it self.
For example, we have 4 servers and a load balancer. The actual application is actually spread across two servers which are behind the
load balancer. The other servers are for consul and other supporting services.
With this, deployment has been a breeze. It is as simple as throwing a binary in some server and just hit
Kapice, all is done.
Basically, consul is a distributed key value store that provides a reliable way to save data across a
single machine or cluster of machines. It allows for high availability of data.
Internally, you organize your keys in a tree like status e.g
Below is an example of what I implemented :
The icing on the cake would be automatic reconfiguration of the application by watching for changes in the kv store. I did not implement this because config values in this application does not change often since most of this values are 3rd party api keys, dsn strings for mysql, mongodb ( atlas ), memcached e.t.c, rules to configure some internal services.
Consul has turned out to be a key infrastructure for the team I work on and I couldn’t have settled on anything less.comments powered by Disqus