API-umbrella with settings in environment variables

[shaliko]

@GUI Do you have the plan for run API-umbrella with settings in environment variables?

We need avoid use a config file and instead use ENV variables for easy scale docker-swarm and kubernetis setup. Otherwise, require create persisted storage with api-umbrella.yml and then start the new instance of API-umbrella and mount volume with api-umbrella.yml.

I can contribute to that feature, but before want check it with you.

I have only one concern, that we somehow need to convert arrays to ENV variable.

[GUI]

I don't personally have plans to implement environment variable settings, but I think that's a feature we could accept, as long as it retains compatibility with the current YAML config.

Although, out of curiosity, is the current file-based approach preventing use with Kubernetes or Docker Swarm? I've just used other Docker containers that can use file-based config (eg, the official redis container or elasticsearch's container), but I haven't used Kubernetes or Swarm much, so I wasn't sure if this was an issue specific to those tools, or environment variables would just make things easier.

In any case, as you note, the array types are probably the trickiest thing to replicate in environment variables. I think for handling those in environment variables, we'd have to just pick some delimiter to split strings by. I'd normally recommend a simple comma, but we have some variables that accept commas inside a single value (eg, the mongodb.url when using multiple servers), so I'm not sure if there's a better solution other than picking some more exotic delimiter like ;; or limiting the fields that are treated as potential arrays (assuming none of those fields possibly contain commas).

And perhaps semi-related to this, one potential configuration change that has been on my mind is allowing flattened YAML keys, like elasticsearch does. I had mainly been thinking about this in terms of simplifying our documentation, since it's a lot easier to document mongodb.url and being able to use that key directly in the YAML, rather than knowing that needs to be translated to:

mongodb:
  url:

But flattening all our YAML keys could perhaps be related to this task, since it seems like you'd need flattened keys for environment variable names anyway.