Changes between Version 1 and Version 2 of Ticket #1785, comment 1
- Timestamp:
- 06/19/20 07:24:38 (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #1785, comment 1
v1 v2 5 5 Sometimes (this is just one example, there are other use cases) rewrites to environment-specific services are required, eg. dev must proxy for "service-X-dev" in dev, test for "service-X-tst" in test, and so forth - "service-X" might not even be in kubernetes yet. If our nginx config could read environment values, this can become straightforward and easy to understand. 6 6 7 I'm not saying there aren't other solutions to the above, but ability to configure map{...} output or variable value on the basis of an env variable can make this a lot easier. We don't really want to have pre-launch init script which reads the environment and generates a fragment of Nginx config file from it, it's a hacky solution .7 I'm not saying there aren't other solutions to the above, but ability to configure map{...} output or variable value on the basis of an env variable can make this a lot easier. We don't really want to have pre-launch init script which reads the environment and generates a fragment of Nginx config file from it, it's a hacky solution and as the OP states, requires writing to the image filesystem. 8 8 9 9 We can't use the Lua module for info-security reasons - the whole point of choosing Nginx is for a small attack surface with minimal additional modules. 10 10 11 A directive something like this, in global context{...} scope, would probably suffice:11 A directive something like this, probably in outermost context{...} scope, would likely suffice: 12 12 {{{ 13 13 $variable = getenv('NAME', 'DEFAULT_VALUE'); 14 14 }}} 15 This would then only get evaluated once when first used after startup and be available therafter in all child scopes.
