[LRUG] Config

[James Turley]

You may find the Prius <https://github.com/gocardless/prius> gem handy for
dealing with some of these issues. You can declare the variables you depend
on in advance, along with their types. It's certainly handy for a big
codebase like ours ... We basically have an initializer that loads all the
variables and aborts if any required ones are missing.

Secrets are a whole other thing and I'm intrigued by vault ...


On Wed, Feb 27, 2019 at 12:26 PM Sasha Gerrand <
chat-lists.lrug.org at sgerrand.com> wrote:

> I can tell you what works for me, YMMV.
>
> For brevity on points 4-10, I would simply say to use a .env file for
> environment variables in development and https://vaultproject.io for any
> production environment (i.e. not development or test).
>
> As a longer answer:
>
> On Wed., 27 Feb. 2019, 10:55 Patrick Gleeson, <patrick.c.gleeson at gmail.com>
> wrote:
>
>>
>> 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?)
>>
>
> I start with a .env file and use that as a cannibal place to define env
> vars that the app requires.
>
> (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.)
>>
>
> I try to keep environment variables as either strings (e.g. database
> credentials) or feature flags (e.g. log to standard output). A shell
> environment only supports string values, so put complex types in a place
> which supports it (e.g. a database).
>
> (3) No single place to put sensible defaults if an environment variable
>> not set
>>
>
> I make an application crash if it can't access a env var that it needs
> (e.g. use ENV.fetch).
>
> (4) No namespacing or grouping except by prefixes
>>
>
> Use a product which provides isolation, like Very.
>
> (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
>>
>
> Use a product which provides these features, such as Vault.
>
> (10) No revision history ("Hey Patrick, can we go back to using that
>> redirect we were using last week?")
>>
>
> That's probably a bigger process issue. :)
>
>
> _______________________________________________
> 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/ce207a48/attachment-0001.html>