4c8f22ebcc
Currently any ACME challenge for unknown virtual host returns 503. This is inconvenient because if the user does not use wildcard certificates, then the user must match the configuration of certificate renewal script to what virtual hosts are enabled at the time. This must be done automatically, because due to short certificate lifetime the renewal script runs automatically. Additionally, enabling a previously disabled virtual host forces certificate renewal. Accordingly, it's worthwhile supporting unknown virtual hosts for the purposes of passing ACME challenges. This is done by introducing a global ACME_HTTP_CHALLENGE_ACCEPT_UNKNOWN_HOST variable to control this.
nginx-proxy sets up a container running nginx and docker-gen. docker-gen generates reverse proxy configs for nginx and reloads nginx when containers are started and stopped.
See Automated Nginx Reverse Proxy for Docker for why you might want to use this.
Usage
To run it:
docker run --detach \
--name nginx-proxy \
--publish 80:80 \
--volume /var/run/docker.sock:/tmp/docker.sock:ro \
nginxproxy/nginx-proxy:1.7
Then start any containers (here an nginx container) you want proxied with an env var VIRTUAL_HOST=subdomain.yourdomain.com
docker run --detach \
--name your-proxied-app \
--env VIRTUAL_HOST=foo.bar.com \
nginx
Provided your DNS is setup to resolve foo.bar.com to the host running nginx-proxy, a request to http://foo.bar.com will then be routed to a container with the VIRTUAL_HOST env var set to foo.bar.com (in this case, the your-proxied-app container).
The containers being proxied must :
- expose the port to be proxied, either by using the
EXPOSEdirective in theirDockerfileor by using the--exposeflag todocker runordocker create. - share at least one Docker network with the nginx-proxy container: by default, if you don't pass the
--netflag when your nginx-proxy container is created, it will only be attached to the default bridge network. This means that it will not be able to connect to containers on networks other than bridge.
Note: providing a port number in VIRTUAL_HOST isn't suported, please see virtual ports or custom external HTTP/HTTPS ports depending on what you want to achieve.
Image variants
The nginx-proxy images are available in two flavors.
Debian based version
This image is based on the nginx:mainline image, itself based on the debian slim image.
docker pull nginxproxy/nginx-proxy:1.7
Alpine based version (-alpine suffix)
This image is based on the nginx:alpine image.
docker pull nginxproxy/nginx-proxy:1.7-alpine
Important
A note on
latestandalpine:It is not recommended to use the
latest(nginxproxy/nginx-proxy,nginxproxy/nginx-proxy:latest) oralpine(nginxproxy/nginx-proxy:alpine) tag for production setups.Those tags point to the latest commit in the
mainbranch. They do not carry any promise of stability, and using them will probably put your nginx-proxy setup at risk of experiencing uncontrolled updates to non backward compatible versions (or versions with breaking changes). You should always specify the version you want to use explicitly to ensure your setup doesn't break when the image is updated.
Additional documentation
Please check the docs section.
Powered by
