Support for gateway timeout setting

[mishak87]

It would be useful to have option (env variable) that could turn off timeout or set it to different value.
VIRTUAL_TIMEOUT=0|<secs>

It would be useful for ie. database administration when processing time expensive queries.

[md5]

This can be achieved using custom config files: https://github.com/jwilder/nginx-proxy#custom-nginx-configuration

If you want to adjust the timeout proxy-wide, add your proxy_*_timeout settings in a proxy-wide config. If you want to do so for a single backend, use a per-site config.

[mishak87]

You are right. But is current feature set frozen? Timeout and client_max_body_size are useful mostly for containers that manage databases, process or receive large amounts of data. Personally I spawn such containers ad-hoc to complement other containers usually they have "random" names - writing and using special configs just for such occasions seems bit tedious and requires to have mounted volume for proxy and some additional orchestration.
I admit, using just environment variables for configuration is pretty addictive but also more error prone.

[thaJeztah]

Perhaps a "use template" option can be added; e.g. PROXY_USE_TEMPLATE=template-a, which will make the proxy use /etc/nginx/vhost.d/templates/template-a for that host.

This will prevent people from setting these values in the global config (which is not always the smartest thing to do), but does allow to make those changes once and re-use them for multiple back ends.

[md5]

I'm not opposed to configuring more stuff from the backend container. What
I am opposed to is more and more environment variables. I think it would be
fine to support more settings via a VIRTUAL_HOST_CONFIG variable with a
JSON payload, especially if a formulaic way to expose all Nginx variables
could be found (or at least most common variables).
On Mar 30, 2015 2:10 AM, "Sebastiaan van Stijn" notifications@github.com
wrote:

Perhaps a "use template" option can be added; e.g.
PROXY_USE_TEMPLATE=template-a, which will make the proxy use
/etc/nginx/vhost.d/templates/template-a for that host.

This will prevent people from setting these values in the global config
(which is not always the smartest thing to do), but does allow to make
those changes once and re-use them for multiple back ends.

—
Reply to this email directly or view it on GitHub
#134 (comment).

[jwilder]

@mishak87 You could also just create a derived image FROM jwilder/nginx-proxy and add your config options in there.

@md5 @thaJeztah Haven't thought too much about this but what about some kind of naming convention for variables that would get included in the templates if present. The format would be something like <prefix>_<context>_<varname>=<value>.

For example, NGINX_LOCATION_CLIENT_MAX_BODY_SIZE=10m would add a client_max_body_size=10m in this containers location section. We could support http, server and location contexts. Any env variable w/ a NGINX prefix would be used automatically to generate that containers template and the suffix portion would just be lowercased and used as the config variable.

I am generally opposed to adding a bunch of additional env vars since nginx has so many options but I'm not opposed to adding solutions that make the container easy to use and extend.

[md5]

I could see quoting of values being tricky or hard to explain possibly, but your suggestion sounds fine. One other issue that comes to mind is what the behavior should be if there are conflicting values for “http" or “server" settings. I'd probably also use “NGINX_PROXY_" as the prefix.

[thaJeztah]

My main idea here was to not introduce too many ENV variables; being able to create some reusable templates could possibly achieve that (just like the "per virtual host" configuration files allows).

[mishak87]

@jwilder I know. I created this issue to see if I am alone or it makes sense to other people aswell, before writing pull.

Reusable templates would be good enough solution for my usecase. But I really like the NGINX_PROXY_<context>_<varname> idea.

[cutec-chris]

I would like to have that too als ENV Variable

[eloyekunle]

Okay, guys.
Let's pick up where we left off.
What's the update?

[tkw1536]

Closed in favor of #106.