[LRUG] Config

[Sasha Gerrand]

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. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20190227/51161a02/attachment-0001.html>