[LRUG] Config

[Stuart Harrison]

Hey Patrick

Rails 5.2+ shipped with support for encrypted config variables in a YAML
file, which may be up your street:

https://medium.com/cedarcode/rails-5-2-credentials-9b3324851336

I like the approach, but as I tend to work exclusively in public repos, I’m
not 100% confident about using it yet, as it possible increases the risk of
all your variables, keys etc, being exposed.

Would welcome others thoughts on this, as currently, adding new ENV vars in
our Terraform setup is a real pain.

Cheers

Stuart

On Wed, 27 Feb 2019 at 10:55, 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!
>
> Best,
>
> Patrick
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20190227/7706793b/attachment-0001.html>