Shoutout to @shakefu for his Nginx and Bash wizardry in figuring a lot of this stuff out. I’d like to take credit for this, but he’s the one who got a lot of it working originally.
Sometimes it can be useful to template Nginx files to use environment variables to fine tune and adjust control for various aspects of Nginx. A recent example of this idea that I recently worked on was a scenario where I setup an Nginx proxy with a very bare bones configuration. As part of the project, I wanted a quick and easy way to update some of the major Nginx configurations like the port it uses to listen for traffic, the server name, upstream servers, etc.
It turns out that there is a quick and dirty way to template basic Nginx configurations using Bash, which ended up being really useful so I thought I would share it. There are a few caveats to this method but it is definitely worth the effort if you have a simple setup or a setup that requires some changes periodically. I stuck the configuration into a Dockerfile so that it can be easily be updated and ported around – by using the nginx:alpine image as the base image the total size all said and done is around 16MB. If you’re not interested in the Docker bits, feel free to skip them.
The first part of using this method is to create a simple configuration file that will be used to substitute in some environment variables. Here is a simple template that is useful for changing a few Nginx settings. I called it nginx.tmpl, which will be important for how the template gets rendered later.
events {}
http {
error_log stderr;
access_log /dev/stdout;
upstream upstream_servers {
server ${UPSTREAM};
}
server {
listen ${LISTEN_PORT};
server_name ${SERVER_NAME};
resolver ${RESOLVER};
set ${ESC}upstream ${UPSTREAM};
# Allow injecting extra configuration into the server block
${SERVER_EXTRA_CONF}
location / {
proxy_pass ${ESC}upstream;
}
}
}
The configuration is mostly straight forward. We are basically just using this configuration file and inserting a few templated variables denoted by the ${VARIABLE} syntax, which are just environment variables that get inserted into the configuration when it gets bootstrapped. There are a few “tricks” that you may need to use if your configuration starts to get more complicated. The first is the use of the ${ESC} variable. Nginx uses the ‘$’ for its variables, which also is used by the template. The extra ${ESC} basically just gives us a way to escape that $ so that we can use Nginx variables as well as templated variables.
The other interesting thing that we discovered (props to shakefu for this magic) was that you can basically jam arbitrary server block level configurations into an environment variable. We do this with the ${SERVER_EXTRA_CONF} in the above configuration and I will show an example of how to use that environment variable later.
Next, I created a simple Dockerfile that provides some default values for some of the various templated variables. The Dockerfile aslso copies the templated configuration into the image, and does some Bash magic for rendering the template.
FROM nginx:alpine
ENV LISTEN_PORT=8080 \
SERVER_NAME=_ \
RESOLVER=8.8.8.8 \
UPSTREAM=icanhazip.com:80 \
UPSTREAM_PROTO=http \
ESC='$'
COPY nginx.tmpl /etc/nginx/nginx.tmpl
CMD /bin/sh -c "envsubst < /etc/nginx/nginx.tmpl > /etc/nginx/nginx.conf && nginx -g 'daemon off;' || cat /etc/nginx/nginx.conf"
There are some things to note. First, not all of the variables in the template need to be declared in the Dockerfile, which means that if the variable isn’t set it will be blank in the rendered template and just won’t do anything. There are some variables that need defaults, so if you ever run across that scenario you can just add them to the Dockerfile and rebuild.
The other interesting thing is how the template gets rendered. There is a tool built into the shell called envsubst that substitutes the values of environment variables into files. In the Dockerfile, this tool gets executed as part of the default command, taking the template as the input and creating the final configuration.
/bin/sh -c "envsubst < /etc/nginx/nginx.tmpl > /etc/nginx/nginx.conf
Nginx gets started in a slightly silly way so that daemon mode can be disabled (we want Nginx running in the foreground) and if that fails, the rendered template gets read to help look for errors in the rendered configuration.
&& nginx -g 'daemon off;' || cat /etc/nginx/nginx.conf"
To quickly test the configuration, you can create a simple docker-compose.yml file with a few of the desired environment variables, like I have below.
version: '3'
services:
nginx_proxy:
build:
context: .
dockerfile: Dockerfile
# Only test the configuration
#command: /bin/sh -c "envsubst < /etc/nginx/nginx.tmpl > /etc/nginx/nginx.conf && cat /etc/nginx/nginx.conf"
volumes:
- "./nginx.tmpl:/etc/nginx/nginx.tmpl"
ports:
- 80:80
environment:
- SERVER_NAME=_
- LISTEN_PORT=80
- UPSTREAM=test1.com
- UPSTREAM_PROTO=https
# Override the resolver
- RESOLVER=4.2.2.2
# The following would add an escape if it isn't in the Dockerfile
# - ESC=$$
Then you can bring up Nginx server.
docker-compose up
The configuration doesn’t get rendered until the container is run, so to test the configuration only, you could add in a command in the docker-compose file that renders the configuration and then another command that spits out the rendered configuration to make sure it looks right.
If you are interested in adding additional configuration you can use the ${SERVER_EXTRA_CONF} as eluded to above. An example of this extra configuration can be assigned to the environment variable. Below is an arbitrary snippet that allows for connections to do long polling to Nginx, which basically means that Nginx will try to hold the connection open for existing connections for longer.
error_page 420 = @longpoll;
if ($arg_wait = "true") { return 420; }
}
location @longpoll {
# Proxy requests to upstream
proxy_pass $upstream;
# Allow long lived connections
proxy_buffering off;
proxy_read_timeout 900s;
keepalive_timeout 160s;
keepalive_requests 100000;
The above snipped would be a perfectly valid environment variable as far as the container is concerned, it will just look a little bit weird to the eye.
That’s all I’ve got for now. This minimal templated Nginx configuration is handy for testing out simple web servers, especially for proxies and is also nice to port around using Docker.