<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I think using ENV variable even in big applications is fine, but I would put my attention on how you set up and load them. The first distinction to make is if it is sensitive data or not, if the data is sensitive you have to store it in something like Vault (secrets management). For config coming from users, I would put it in a service like AWS Secrets Manager or AWS Config.<div><br></div><div>The way you set up and deliver your config depends on the infrastructure you are using, although you could use some custom Ruby code or gem as others have already mentioned.</div><div><br></div><div>Some secret management tools:</div><div>1. Vault, not easy to configure but can store many different types of data, including temporary SSH key to access servers.</div><div>2. SOPS (<a href="https://github.com/mozilla/sops">https://github.com/mozilla/sops</a>) can encrypt YAML files but it encrypts only the value and not the key, so it shows the data structure of the config file. It is integrated with several cloud providers (like AWS KMS) and PGP. It is often used with Kubernetes.</div><div>3, Chef encrypted data bags.</div><div>4. Ansible vault.</div><div>5. Kubernetes secrets.</div><div>6. Google Cloud KMS.</div><div>7. AWS Secrets Manager.</div><div><br></div><div>It is a very good idea that the app should fail to start if a config value is not present. Having a schema with the name of the expected keys and their type is even better, so I would use an equivalent of <a href="https://clojure.org/about/spec">https://clojure.org/about/spec</a> to validate the config.</div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 27 Feb 2019 at 13:14, Mark Blackman <<a href="mailto:mark@blackmans.org">mark@blackmans.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><br><div dir="ltr"><br>On 27 Feb 2019, at 10:52, Patrick Gleeson <<a href="mailto:patrick.c.gleeson@gmail.com" target="_blank">patrick.c.gleeson@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi LRUG,<div><br></div><div>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.</div><div><br></div><div>According to the 12 factor app (<a href="https://12factor.net/config" target="_blank">https://12factor.net/config</a>) 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:</div><div><br></div><div>(1) No easy way of seeing for any app what config needs to be set (cmd-shift-F 'ENV' anyone?)</div><div>(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.)</div><div>(3) No single place to put sensible defaults if an environment variable not set</div><div>(4) No namespacing or grouping except by prefixes</div><div>(5) No protection from typos when reading env vars</div><div>(6) Or when writing them</div><div>(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)</div><div>(8) Depending on where you deploy to, your UI for reading and writing env vars may be better or worse</div><div>(9) Depending on where you deploy to, your mechanism for cloning an environment's vars may be better or worse</div><div>(10) No revision history ("Hey Patrick, can we go back to using that redirect we were using last week?")</div><div><br></div><div>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:</div><div><br></div><div><font face="monospace, monospace">namespace :fulfilment_centre do</font></div><div><font face="monospace, monospace">  set :hours_of_operation, type: :integer, array: true, default: [9,17]<br></font></div><div><font face="monospace, monospace">end</font></div><div><br></div><div>And then I can call <font face="monospace, monospace">Config.fulfilment_centre.hours_of_operation</font> with some confidence</div><div><br></div><div>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?</div><div><br></div><div>Any thoughts welcome!</div></div></div></div></div></blockquote><br><div>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 </div></div>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Riccardo Tacconi<br></div><div dir="ltr"><br></div></div></div></div>