We use the Perl Catalyst web framework at $work. A lot. It’s got most of the stuff you want for web sites and services, and it’s pretty solid and it’s lovely and stable.
As with most systems it has a well established method of configuration and it allows you to use configuration files. Theses are handy for all sorts of reasons, but in a docker environment most of the file system generally wants to be essentially static. If you need to change config files on every different deployment of your container you’re probably going to need to do something ugly. Docker is much happier with allowing you to push in settings via environment variables instead. This fits much more neatly into the 12 factor app methodology that using docker itself fits neatly into.
Of course Catalyst has a solution to that that doesn’t require wholesale change, you can just load the Catalyst::Plugin::ConfigLoader::Environment plugin to your application. That allows you to override parts of your configuration.
Perl modules generally have names like this, My::App, often (but not always) with capitalized names, and :: between words. The corresponding catalyst configuration file for that application would be named my_app.conf. It is simply a lowercase version of the app name, with :: replaced with _.
The environment variables you override the config with need to be an all uppercase version of the app name, again with :: replaced by ::. So it would start MY_APP. Then you put another _ after that, and then you specify the configuration section you want to override.
Let’s take a look at an example config,
using_frontend_proxy 1
<Model::Cabbages>
connect_info dbi:Pg:host=db;dbname=patch
connect_info someuser
connect_info averysecurepassword
<connect_info>
quote_char "\""
name_sep .
pg_enable_utf8 1
</connect_info>
</Model::Cabbages>
Note that catalyst config files can generally be in lots of different formats. This is kind of an apache like config style, but it can also be yaml and other formats. The configuration loaded Cataylst apps commonly use is very flexible.
If we want to change the using_frontend_proxy setting we can set the environment variable MY_APP_using_frontend_proxy to 0.
To set more complex data structures we can set a json value. This will get merged into the config, so if something exists in the hash/dictionary but isn’t overwritten then it will generally be left alone.
The configuration file above roughly translates to a dictionary looking like this in code (expressed in json),
{
"Model::Cabbages": {
"connect_info": [
"dbi:Pg:host=db;dbname=patch",
"someuser",
"averysecurepassword",
{
"name_sep": ".",
"pg_enable_utf8": "1",
"quote_char": "\""
}
]
},
"using_frontend_proxy": "1"
}
Note how the repeated connect_info were translated into an array, and then a dictionary. This may seem strange, but the connect_info block is a very common structure in the perl world as most if not all will be passed straight onto DBI, the workhorse doing most database work.
So to change the password in the database configuration we do,
MY_APP_Model__Cabbages=’{"connect_info":["dbi:Pg:host=db;dbname=patch","someuser","abetterpassword",{"pg_enable_utf8":"1","quote_char":"\"","name_sep":"."}]}’
Since that’s an array of configuration settings we end up having to specify the whole lot, otherwise we lose some of the configuration. Also note that we turned the :: into __. That is generally a good thing when working on the command line as putting :: into env variables via bash is tricky (if possible).
The one oddity is if you have a configuration key with more than 1 set of double colons. E.g. Model::Payment::Client. Then you just need to live with the :: otherwise your override will be interpreted in an odd fashion.
Perl and docker-compose configurations can set environment variables with :: easily though so this generally isn’t a big deal. env and set can confuse however as one will show environment variables with ::, and the other won’t.
TL;DR
Take the configuration filename, drop the extension, upper case it.
Add an underscore.
Take the first section or key, and append that to the environment variable.
That’s the variable that will target that config section.
Now set it’s value to either a string (if it’s a simple string value), or a json structure that matches the configurations effective structure.
Now you discover whether someones done something confusing and eschewed convention. Hopefully not.
There is something missing here, and it’s how to test changes, and generate the correct json easily. I have the tooling to make it reasonably simple, I just need to open source it.
