I propose adding support for environment variable config substitutions, using a bask-like syntax, to obviate the need for any external config template solutions when using brubeck in a container deployment, where environment variables are the norm.
This feature is toggled via BRUBECK_CONFIG_SUBSTITUTE_ENV so users may opt-in to this behavior, since any config using this syntax is not technically valid json and could theoretically be a breaking change, though unlikely in practice.
A simple local test case does the right thing, and is valgrind-clean:
$ GRAPHITE_SERVER=foo GRAPHITE_PORT=1234 BRUBECK_CONFIG_SUBSTITUTE_ENV=1 valgrind ./brubeck --conf brubeck.json
==21044== Memcheck, a memory error detector
==21044== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==21044== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==21044== Command: ./brubeck --conf brubeck.json
==21044==
instance=(null) replaced config GRAPHITE_SERVER with foo from environment
instance=(null) replaced config GRAPHITE_PORT with 1234 from environment
[FATAL]: failed to resolve address 'foo'
==21044==
==21044== HEAP SUMMARY:
==21044== in use at exit: 1,064,806 bytes in 206 blocks
==21044== total heap usage: 1,316 allocs, 1,110 frees, 1,152,072 bytes allocated
==21044==
==21044== LEAK SUMMARY:
==21044== definitely lost: 776 bytes in 1 blocks
==21044== indirectly lost: 4,930 bytes in 95 blocks
==21044== possibly lost: 1,232 bytes in 35 blocks
==21044== still reachable: 1,057,868 bytes in 75 blocks
==21044== suppressed: 0 bytes in 0 blocks
==21044== Rerun with --leak-check=full to see details of leaked memory
==21044==
==21044== For counts of detected and suppressed errors, rerun with: -v
==21044== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
I propose adding support for environment variable config substitutions, using a bask-like syntax, to obviate the need for any external config template solutions when using brubeck in a container deployment, where environment variables are the norm.
This feature is toggled via BRUBECK_CONFIG_SUBSTITUTE_ENV so users may opt-in to this behavior, since any config using this syntax is not technically valid json and could theoretically be a breaking change, though unlikely in practice.
A simple local test case does the right thing, and is valgrind-clean:
and