Fabio: Allow configuration via env vars

[doublerebel]

Since fabio is designed to be near-zero configuration, I assumed there must be a way to set (at least the main) options with environment variables. So I went looking, and there is! Multiple command line flags are available: -addr, -consul, -name, -prefix, -proto, -token [1]. However, these are not documented in the binary (in --help) or in the fabio docs.

I am happy to write the docs but wanted to leave a note here until then, if anyone else is looking for the same thing.

[magiconair]

The command line flags you've found belong to the demo server which I use for demonstration and testing. The only command line flags in fabio are in https://github.com/eBay/fabio/blob/master/main.go#L30-L32

Which values would you like to configure via environment variables?

[doublerebel]

Oh shoot, didn't double check my work on the go, you are quite right, thanks!

I think the most important flags are the addresses and secrets:

proxy.address
proxy.localip
proxy.header.clientip
consul.addr
consul.token
ui.addr

Since these can all change between machines/deploys with the rest of the config the same.

Also I would find runtime.gomaxprocs useful, since a VM can be resized to add procs.

Having these as flags would follow the pattern of Consul, Vault, and the other Hashicorp tools. Then envconsul (or my Solaris SMF) could be used to easily monitor and deliver the flags.

[magiconair]

runtime.gomaxprocs can already be configured via GOMAXPROCS. I'll have a look on how to come up with a generic method for configuring these values via environment variables.

[doublerebel]

Thanks! I'm looking at spf13/viper, it looks relatively straightforward to support env vars, flags, and config files.

[doublerebel]

Good news! Viper is able to load the Java properties config with minimal changes [1]. Working on the flags and env vars now.

[magiconair]

Thanks. I'll have a look. AFAIK, viper is using my properties library to load them :)

Usually, I try not to add additional libraries for simple tasks and would prefer to have a better idea about what is being submitted before the pull request arrives. Could you explain how the property values are overridden with the ENV vars and what changes are required?

Might be a good idea to add a Contributions section to the README and finally figure out the Contributors Agreement feature in github...

Since I'm also the author of the properties library I was thinking about adding a generic ENV var overrides to the lib later. General idea is to normalize the name of the keys by replacing dots with underscores and have a configurable prefix, e.g. routes.proxy could be overwritten with FABIO_routes_proxy

[magiconair]

Your change looks simple enough so I'm curious what the delta is. One comment about the vendoring approach. Please use party for now to copy the dependency into the _third_party directory using import path rewriting. This also works with Go 1.4 and 1.5 out of the box. I'll move to the new vendoring scheme once 1.6 is out. Also, keep the commit message for the vendored in library in the same format as the others, e.g. Vendoring in version xxx of github.com/spf13/viper since this is how I keep track of the versions.

[magiconair]

I've decided to implement it myself since I was working on a refactoring for issue #12 which required somewhat more control over the configuration. Adding the env var support was a trivial change there and I've pulled it into a separate commit. If this works then I'll merge it. Please have a look.

All config parameters can be configured via env vars by replacing the dots with underscores. So metrics.target=stdout becomes metrics_target=stdout ./fabio. Env vars take precedence over the config file but both can be specified. Since it then becomes difficult to determine the actual runtime configuration I've decided to log the final runtime configuration during startup.

[magiconair]

merged. closing.

[armand1m]

Is this defined anywhere in the docs? I couldn't find it there

[magiconair]

You're probably right. I'll have a look and add it next week if it's missing.

Frank Schröder

On 1. Apr 2017, at 21:33, Armando Magalhães [e-mail] wrote:

Is this defined anywhere in the docs? I couldn't find it there

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.