Cómo puedo usar variables de entorno en Nginx.conf

Desde el archivo docker oficial de Nginx:

Usando variables de entorno en la configuración de nginx:

Por defecto, Nginx no admite el uso de variables de entorno dentro de la mayoría de los bloques de configuración.

Pero envsubst se puede usar como una solución alternativa si necesita generar su configuración de nginx dinámicamente antes de que nginx se inicie.

Aquí tienes un ejemplo usando docker-compose.yml:

image: nginx
volumes:
 - ./mysite.template:/etc/nginx/conf.d/mysite.template
ports:
 - "8080:80"
environment:
 - NGINX_HOST=foobar.com
 - NGINX_PORT=80
command: /bin/bash -c "envsubst < /etc/nginx/conf.d/mysite.template > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'" 

El archivo mysite.template puede contener referencias de variables como esta:

listen ${NGINX_PORT};

Actualización:

Pero sabes que esto causó que sus variables de Nginx como esta:

proxy_set_header        X-Forwarded-Host $host;

se dañaran:

proxy_set_header        X-Forwarded-Host ;

Entonces, para evitar eso, uso este truco:

Tengo un script para ejecutar Nginx, que se usa en el archivo docker-compose como opción de comando para el servidor Nginx, lo llamé run_nginx.sh:

#!/usr/bin/env bash
export DOLLAR='$'
envsubst < nginx.conf.template > /etc/nginx/nginx.conf
nginx -g "daemon off;"

Y debido a la nueva variable DOLLAR definida en el script run_nginx.sh, ahora el contenido de mi archivo nginx.conf.template para la variable de Nginx en sí es como esto:

proxy_set_header        X-Forwarded-Host ${DOLLAR}host;

Y para mi variable definida es como esto:

server_name  ${WEB_DOMAIN} www.${WEB_DOMAIN};

También aquí, está mi caso de uso real para eso.

La imagen oficial de nginx recomienda usar envsubst, pero como señalan otros, también reemplazará $host y otras variables, lo cual no es deseable. Sin embargo, afortunadamente envsubst puede tomar como parámetro los nombres de las variables a reemplazar.

Para evitar un comando de parámetro muy complejo en el contenedor (como en el ejemplo vinculado), puedes escribir un script de entrada de Docker que complete las variables de entorno antes de ejecutar el comando. El script de entrada también es un buen lugar para validar los parámetros y establecer valores predeterminados.

Aquí tienes un ejemplo de un contenedor de nginx que toma los parámetros de API_HOST y API_PORT como variables de entorno.

nginx-default.conf.template

resolver  127.0.0.11 valid=10s;  # recuperarse del cambio de IP del backend

server {
  listen  80;

  location / {
    root  /usr/share/nginx/html;
  }

  location /api {
    proxy_pass  http://${API_HOST}:${API_PORT};
    proxy_set_header  Host $http_host;
  }
}

docker-entrypoint.sh

#!/usr/bin/env sh
set -eu

envsubst '${API_HOST} ${API_PORT}' < /etc/nginx/conf.d/default.conf.template > /etc/nginx/conf.d/default.conf

exec "$@"

Dockerfile

FROM nginx:1.15-alpine

COPY nginx-default.conf.template /etc/nginx/conf.d/default.conf.template

COPY docker-entrypoint.sh /
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["nginx", "-g", "daemon off;"]

envsubstr ahora es manejado automáticamente por la imagen de nginx.

Desde la documentación:

Por defecto, nginx no admite variables de entorno dentro de la mayoría de los bloques de configuración. Pero esta imagen tiene una función que extraerá las variables de entorno antes de que nginx se inicie.

De forma predeterminada, esta función lee archivos de plantilla en /etc/nginx/templates/*.template y produce el resultado de ejecutar envsubst en /etc/nginx/conf.d.

Hacer esto con Lua es considerablemente más fácil de lo que parece:

server {
    set_by_lua $server_name 'return os.getenv("NGINX_SERVERNAME")';
}

Encontré eso aquí:

https://docs.apitools.com/blog/2014/07/02/using-environment-variables-in-nginx-conf.html

Editar:

Aparentemente, esto requiere instalar el módulo lua: https://github.com/openresty/lua-nginx-module

Editar 2:

Tenga en cuenta que con este enfoque debe definir la variable de env en Nginx:

env ENVIRONMENT_VARIABLE_NAME

Debe hacer esto en el contexto de nivel superior en nginx.conf ¡o no funcionará! No en el bloque del servidor o en la configuración de algún sitio en /etc/nginx/sites-available, porque se incluye en nginx.conf en el contexto de http (que no es un contexto de nivel superior).

También tenga en cuenta que con este enfoque si intenta hacer una redirección por ejemplo:

server {
    listen 80;
    server_name $server_name;
    return 301 https://$server_name$request_uri;
}

tampoco funcionará:

2016/08/30 14:49:35 [emerg] 1#0: the duplicate "server_name" variable in /etc/nginx/sites-enabled/default:8

Y si le da un nombre de variable separado:

set_by_lua $server_name_from_env 'return os.getenv("NGINX_SERVERNAME")';

server {
    listen 80;
    server_name $server_name_from_env;
    return 301 https://$server_name$request_uri;
}

Nginx no lo interpretará y lo redirigirá a https://%24server_name_from_env/.