[LRUG] Config

[Mark Blackman]

> On 27 Feb 2019, at 10:52, Patrick Gleeson <patrick.c.gleeson at gmail.com> wrote:
> 
> Hi LRUG,
> 
> After the awesome discussion on 'Continuous *' back in January, I wondered if this might be a place to ask another broad question I've been mulling for a while now.
> 
> According to the 12 factor app (https://12factor.net/config) we should store our config in environment variables, and in Ruby that means we access it via ENV. I get the benefit of orthogonal config, but ENV always ends up feeling pretty unsatisfactory to me for config-heavy apps, for the following reasons:
> 
> (1) No easy way of seeing for any app what config needs to be set (cmd-shift-F 'ENV' anyone?)
> (2) Everything is stringly typed (How many times have I forgotten that 'false' is truthy? And what if a config var is going to be, say, either an array of integers or null? "&.split(',')&.map(:to_i)" is not my favourite thing.)
> (3) No single place to put sensible defaults if an environment variable not set
> (4) No namespacing or grouping except by prefixes
> (5) No protection from typos when reading env vars
> (6) Or when writing them
> (7) No fine-grained access control to env vars (occasionally useful if someone semi-technical wants direct control over something set in config but you don't want them touching the database credentials)
> (8) Depending on where you deploy to, your UI for reading and writing env vars may be better or worse
> (9) Depending on where you deploy to, your mechanism for cloning an environment's vars may be better or worse
> (10) No revision history ("Hey Patrick, can we go back to using that redirect we were using last week?")
> 
> For 1 - 5 I normally end up writing a wrapper around ENV with a little DSL to define the keys the app uses, so that I end up with file with a list of things like:
> 
> namespace :fulfilment_centre do
>   set :hours_of_operation, type: :integer, array: true, default: [9,17]
> end
> 
> And then I can call Config.fulfilment_centre.hours_of_operation with some confidence
> 
> But I don't really know how best to get round 6 - 10. I sort of feel like I want a Config-as-a-Service platform with web/RESTful interfaces for defining environments and their config, so that my apps can pull in config on deploy. Does something like that exist? Or (more likely, I would imagine) do I want the wrong thing? And if so why?
> 
> Any thoughts welcome!

I agree that env variables are inappropriate for large/nested configuration. If you need more than a handful of non-optional configuration items, then the environment variable should just refer to a location, usually a file, often yaml, where the full configuration is specified 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20190227/0718afdb/attachment-0001.html>