Skip to content

Commit 30138bd

Browse files
committed
Update readme
Signed-off-by: Scott R. Shinn <[email protected]>
1 parent 014c3cb commit 30138bd

File tree

1 file changed

+5
-357
lines changed

1 file changed

+5
-357
lines changed

README.md

+5-357
Original file line numberDiff line numberDiff line change
@@ -1,362 +1,10 @@
1-
![nginx 1.13](https://img.shields.io/badge/nginx-1.13-brightgreen.svg) ![License MIT](https://img.shields.io/badge/license-MIT-blue.svg) [![Build Status](https://travis-ci.org/jwilder/nginx-proxy.svg?branch=master)](https://travis-ci.org/jwilder/nginx-proxy) [![](https://img.shields.io/docker/stars/jwilder/nginx-proxy.svg)](https://hub.docker.com/r/jwilder/nginx-proxy 'DockerHub') [![](https://img.shields.io/docker/pulls/jwilder/nginx-proxy.svg)](https://hub.docker.com/r/jwilder/nginx-proxy 'DockerHub')
1+
This container implements the Free Atomicorp NGINX Web Application Firewall (ModSecurity v3) ruleset. The full commercial ruleset can be added from:
22

3+
https://www.atomicorp.com
34

4-
nginx-proxy sets up a container running nginx and [docker-gen][1]. docker-gen generates reverse proxy configs for nginx and reloads nginx when containers are started and stopped.
55

6-
See [Automated Nginx Reverse Proxy for Docker][2] for why you might want to use this.
6+
Thanks:
77

8-
### Usage
8+
This project is a CentOS/RHEL based derivative of the project at:
99

10-
To run it:
11-
12-
$ docker run -d -p 80:80 -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy
13-
14-
Then start any containers you want proxied with an env var `VIRTUAL_HOST=subdomain.youdomain.com`
15-
16-
$ docker run -e VIRTUAL_HOST=foo.bar.com ...
17-
18-
The containers being proxied must [expose](https://docs.docker.com/engine/reference/run/#expose-incoming-ports) the port to be proxied, either by using the `EXPOSE` directive in their `Dockerfile` or by using the `--expose` flag to `docker run` or `docker create`.
19-
20-
Provided your DNS is setup to forward foo.bar.com to the host running nginx-proxy, the request will be routed to a container with the VIRTUAL_HOST env var set.
21-
22-
### Image variants
23-
24-
The nginx-proxy images are available in two flavors.
25-
26-
#### jwilder/nginx-proxy:latest
27-
28-
This image uses the debian:jessie based nginx image.
29-
30-
$ docker pull jwilder/nginx-proxy:latest
31-
32-
#### jwilder/nginx-proxy:alpine
33-
34-
This image is based on the nginx:alpine image. Use this image to fully support HTTP/2 (including ALPN required by recent Chrome versions). A valid certificate is required as well (see eg. below "SSL Support using letsencrypt" for more info).
35-
36-
$ docker pull jwilder/nginx-proxy:alpine
37-
38-
### Docker Compose
39-
40-
```yaml
41-
version: '2'
42-
43-
services:
44-
nginx-proxy:
45-
image: jwilder/nginx-proxy
46-
ports:
47-
- "80:80"
48-
volumes:
49-
- /var/run/docker.sock:/tmp/docker.sock:ro
50-
51-
whoami:
52-
image: jwilder/whoami
53-
environment:
54-
- VIRTUAL_HOST=whoami.local
55-
```
56-
57-
```shell
58-
$ docker-compose up
59-
$ curl -H "Host: whoami.local" localhost
60-
I'm 5b129ab83266
61-
```
62-
63-
### IPv6 support
64-
65-
You can activate the IPv6 support for the nginx-proxy container by passing the value `true` to the `ENABLE_IPV6` environment variable:
66-
67-
$ docker run -d -p 80:80 -e ENABLE_IPV6=true -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy
68-
69-
### Multiple Ports
70-
71-
If your container exposes multiple ports, nginx-proxy will default to the service running on port 80. If you need to specify a different port, you can set a VIRTUAL_PORT env var to select a different one. If your container only exposes one port and it has a VIRTUAL_HOST env var set, that port will be selected.
72-
73-
[1]: https://github.com/jwilder/docker-gen
74-
[2]: http://jasonwilder.com/blog/2014/03/25/automated-nginx-reverse-proxy-for-docker/
75-
76-
### Multiple Hosts
77-
78-
If you need to support multiple virtual hosts for a container, you can separate each entry with commas. For example, `foo.bar.com,baz.bar.com,bar.com` and each host will be setup the same.
79-
80-
### Wildcard Hosts
81-
82-
You can also use wildcards at the beginning and the end of host name, like `*.bar.com` or `foo.bar.*`. Or even a regular expression, which can be very useful in conjunction with a wildcard DNS service like [xip.io](http://xip.io), using `~^foo\.bar\..*\.xip\.io` will match `foo.bar.127.0.0.1.xip.io`, `foo.bar.10.0.2.2.xip.io` and all other given IPs. More information about this topic can be found in the nginx documentation about [`server_names`](http://nginx.org/en/docs/http/server_names.html).
83-
84-
### Multiple Networks
85-
86-
With the addition of [overlay networking](https://docs.docker.com/engine/userguide/networking/get-started-overlay/) in Docker 1.9, your `nginx-proxy` container may need to connect to backend containers on multiple networks. By default, if you don't pass the `--net` flag 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`.
87-
88-
If you want your `nginx-proxy` container to be attached to a different network, you must pass the `--net=my-network` option in your `docker create` or `docker run` command. At the time of this writing, only a single network can be specified at container creation time. To attach to other networks, you can use the `docker network connect` command after your container is created:
89-
90-
```console
91-
$ docker run -d -p 80:80 -v /var/run/docker.sock:/tmp/docker.sock:ro \
92-
--name my-nginx-proxy --net my-network jwilder/nginx-proxy
93-
$ docker network connect my-other-network my-nginx-proxy
94-
```
95-
96-
In this example, the `my-nginx-proxy` container will be connected to `my-network` and `my-other-network` and will be able to proxy to other containers attached to those networks.
97-
98-
### SSL Backends
99-
100-
If you would like the reverse proxy to connect to your backend using HTTPS instead of HTTP, set `VIRTUAL_PROTO=https` on the backend container.
101-
102-
> Note: If you use `VIRTUAL_PROTO=https` and your backend container exposes port 80 and 443, `nginx-proxy` will use HTTPS on port 80. This is almost certainly not what you want, so you should also include `VIRTUAL_PORT=443`.
103-
104-
### uWSGI Backends
105-
106-
If you would like to connect to uWSGI backend, set `VIRTUAL_PROTO=uwsgi` on the
107-
backend container. Your backend container should then listen on a port rather
108-
than a socket and expose that port.
109-
110-
### Default Host
111-
112-
To set the default host for nginx use the env var `DEFAULT_HOST=foo.bar.com` for example
113-
114-
$ docker run -d -p 80:80 -e DEFAULT_HOST=foo.bar.com -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy
115-
116-
117-
### Separate Containers
118-
119-
nginx-proxy can also be run as two separate containers using the [jwilder/docker-gen](https://index.docker.io/u/jwilder/docker-gen/)
120-
image and the official [nginx](https://registry.hub.docker.com/_/nginx/) image.
121-
122-
You may want to do this to prevent having the docker socket bound to a publicly exposed container service.
123-
124-
You can demo this pattern with docker-compose:
125-
126-
```console
127-
$ docker-compose --file docker-compose-separate-containers.yml up
128-
$ curl -H "Host: whoami.local" localhost
129-
I'm 5b129ab83266
130-
```
131-
132-
To run nginx proxy as a separate container you'll need to have [nginx.tmpl](https://github.com/jwilder/nginx-proxy/blob/master/nginx.tmpl) on your host system.
133-
134-
First start nginx with a volume:
135-
136-
137-
$ docker run -d -p 80:80 --name nginx -v /tmp/nginx:/etc/nginx/conf.d -t nginx
138-
139-
Then start the docker-gen container with the shared volume and template:
140-
141-
```
142-
$ docker run --volumes-from nginx \
143-
-v /var/run/docker.sock:/tmp/docker.sock:ro \
144-
-v $(pwd):/etc/docker-gen/templates \
145-
-t jwilder/docker-gen -notify-sighup nginx -watch /etc/docker-gen/templates/nginx.tmpl /etc/nginx/conf.d/default.conf
146-
```
147-
148-
Finally, start your containers with `VIRTUAL_HOST` environment variables.
149-
150-
$ docker run -e VIRTUAL_HOST=foo.bar.com ...
151-
### SSL Support using letsencrypt
152-
153-
[letsencrypt-nginx-proxy-companion](https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion) is a lightweight companion container for the nginx-proxy. It allow the creation/renewal of Let's Encrypt certificates automatically.
154-
155-
### SSL Support
156-
157-
SSL is supported using single host, wildcard and SNI certificates using naming conventions for
158-
certificates or optionally specifying a cert name (for SNI) as an environment variable.
159-
160-
To enable SSL:
161-
162-
$ docker run -d -p 80:80 -p 443:443 -v /path/to/certs:/etc/nginx/certs -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy
163-
164-
The contents of `/path/to/certs` should contain the certificates and private keys for any virtual
165-
hosts in use. The certificate and keys should be named after the virtual host with a `.crt` and
166-
`.key` extension. For example, a container with `VIRTUAL_HOST=foo.bar.com` should have a
167-
`foo.bar.com.crt` and `foo.bar.com.key` file in the certs directory.
168-
169-
If you are running the container in a virtualized environment (Hyper-V, VirtualBox, etc...),
170-
/path/to/certs must exist in that environment or be made accessible to that environment.
171-
By default, Docker is not able to mount directories on the host machine to containers running in a virtual machine.
172-
173-
#### Diffie-Hellman Groups
174-
175-
Diffie-Hellman groups are enabled by default, with a pregenerated key in `/etc/nginx/dhparam/dhparam.pem`.
176-
You can mount a different `dhparam.pem` file at that location to override the default cert.
177-
To use custom `dhparam.pem` files per-virtual-host, the files should be named after the virtual host with a
178-
`dhparam` suffix and `.pem` extension. For example, a container with `VIRTUAL_HOST=foo.bar.com`
179-
should have a `foo.bar.com.dhparam.pem` file in the `/etc/nginx/certs` directory.
180-
181-
> NOTE: If you don't mount a `dhparam.pem` file at `/etc/nginx/dhparam/dhparam.pem`, one will be generated
182-
at startup. Since it can take minutes to generate a new `dhparam.pem`, it is done at low priority in the
183-
background. Once generation is complete, the `dhparams.pem` is saved on a persistent volume and nginx
184-
is reloaded. This generation process only occurs the first time you start `nginx-proxy`.
185-
186-
> COMPATIBILITY WARNING: The default generated `dhparam.pem` key is 2048 bits for A+ security. Some
187-
> older clients (like Java 6 and 7) do not support DH keys with over 1024 bits. In order to support these
188-
> clients, you must either provide your own `dhparam.pem`, or tell `nginx-proxy` to generate a 1024-bit
189-
> key on startup by passing `-e DHPARAM_BITS=1024`.
190-
191-
#### Wildcard Certificates
192-
193-
Wildcard certificates and keys should be named after the domain name with a `.crt` and `.key` extension.
194-
For example `VIRTUAL_HOST=foo.bar.com` would use cert name `bar.com.crt` and `bar.com.key`.
195-
196-
#### SNI
197-
198-
If your certificate(s) supports multiple domain names, you can start a container with `CERT_NAME=<name>`
199-
to identify the certificate to be used. For example, a certificate for `*.foo.com` and `*.bar.com`
200-
could be named `shared.crt` and `shared.key`. A container running with `VIRTUAL_HOST=foo.bar.com`
201-
and `CERT_NAME=shared` will then use this shared cert.
202-
203-
#### How SSL Support Works
204-
205-
The SSL cipher configuration is based on the [Mozilla nginx intermediate profile](https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx) which
206-
should provide compatibility with clients back to Firefox 1, Chrome 1, IE 7, Opera 5, Safari 1,
207-
Windows XP IE8, Android 2.3, Java 7. Note that the DES-based TLS ciphers were removed for security.
208-
The configuration also enables HSTS, PFS, OCSP stapling and SSL session caches. Currently TLS 1.0, 1.1 and 1.2
209-
are supported. TLS 1.0 is deprecated but its end of life is not until June 30, 2018. It is being
210-
included because the following browsers will stop working when it is removed: Chrome < 22, Firefox < 27,
211-
IE < 11, Safari < 7, iOS < 5, Android Browser < 5.
212-
213-
The default behavior for the proxy when port 80 and 443 are exposed is as follows:
214-
215-
* If a container has a usable cert, port 80 will redirect to 443 for that container so that HTTPS
216-
is always preferred when available.
217-
* If the container does not have a usable cert, a 503 will be returned.
218-
219-
Note that in the latter case, a browser may get an connection error as no certificate is available
220-
to establish a connection. A self-signed or generic cert named `default.crt` and `default.key`
221-
will allow a client browser to make a SSL connection (likely w/ a warning) and subsequently receive
222-
a 500.
223-
224-
To serve traffic in both SSL and non-SSL modes without redirecting to SSL, you can include the
225-
environment variable `HTTPS_METHOD=noredirect` (the default is `HTTPS_METHOD=redirect`). You can also
226-
disable the non-SSL site entirely with `HTTPS_METHOD=nohttp`, or disable the HTTPS site with
227-
`HTTPS_METHOD=nohttps`. `HTTPS_METHOD` must be specified on each container for which you want to
228-
override the default behavior. If `HTTPS_METHOD=noredirect` is used, Strict Transport Security (HSTS)
229-
is disabled to prevent HTTPS users from being redirected by the client. If you cannot get to the HTTP
230-
site after changing this setting, your browser has probably cached the HSTS policy and is automatically
231-
redirecting you back to HTTPS. You will need to clear your browser's HSTS cache or use an incognito
232-
window / different browser.
233-
234-
### Basic Authentication Support
235-
236-
In order to be able to secure your virtual host, you have to create a file named as its equivalent VIRTUAL_HOST variable on directory
237-
/etc/nginx/htpasswd/$VIRTUAL_HOST
238-
239-
```
240-
$ docker run -d -p 80:80 -p 443:443 \
241-
-v /path/to/htpasswd:/etc/nginx/htpasswd \
242-
-v /path/to/certs:/etc/nginx/certs \
243-
-v /var/run/docker.sock:/tmp/docker.sock:ro \
244-
jwilder/nginx-proxy
245-
```
246-
247-
You'll need apache2-utils on the machine where you plan to create the htpasswd file. Follow these [instructions](http://httpd.apache.org/docs/2.2/programs/htpasswd.html)
248-
249-
### Custom Nginx Configuration
250-
251-
If you need to configure Nginx beyond what is possible using environment variables, you can provide custom configuration files on either a proxy-wide or per-`VIRTUAL_HOST` basis.
252-
253-
#### Replacing default proxy settings
254-
255-
If you want to replace the default proxy settings for the nginx container, add a configuration file at `/etc/nginx/proxy.conf`. A file with the default settings would
256-
look like this:
257-
258-
```Nginx
259-
# HTTP 1.1 support
260-
proxy_http_version 1.1;
261-
proxy_buffering off;
262-
proxy_set_header Host $http_host;
263-
proxy_set_header Upgrade $http_upgrade;
264-
proxy_set_header Connection $proxy_connection;
265-
proxy_set_header X-Real-IP $remote_addr;
266-
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
267-
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
268-
proxy_set_header X-Forwarded-Ssl $proxy_x_forwarded_ssl;
269-
proxy_set_header X-Forwarded-Port $proxy_x_forwarded_port;
270-
271-
# Mitigate httpoxy attack (see README for details)
272-
proxy_set_header Proxy "";
273-
```
274-
275-
***NOTE***: If you provide this file it will replace the defaults; you may want to check the .tmpl file to make sure you have all of the needed options.
276-
277-
***NOTE***: The default configuration blocks the `Proxy` HTTP request header from being sent to downstream servers. This prevents attackers from using the so-called [httpoxy attack](http://httpoxy.org). There is no legitimate reason for a client to send this header, and there are many vulnerable languages / platforms (`CVE-2016-5385`, `CVE-2016-5386`, `CVE-2016-5387`, `CVE-2016-5388`, `CVE-2016-1000109`, `CVE-2016-1000110`, `CERT-VU#797896`).
278-
279-
#### Proxy-wide
280-
281-
To add settings on a proxy-wide basis, add your configuration file under `/etc/nginx/conf.d` using a name ending in `.conf`.
282-
283-
This can be done in a derived image by creating the file in a `RUN` command or by `COPY`ing the file into `conf.d`:
284-
285-
```Dockerfile
286-
FROM jwilder/nginx-proxy
287-
RUN { \
288-
echo 'server_tokens off;'; \
289-
echo 'client_max_body_size 100m;'; \
290-
} > /etc/nginx/conf.d/my_proxy.conf
291-
```
292-
293-
Or it can be done by mounting in your custom configuration in your `docker run` command:
294-
295-
$ docker run -d -p 80:80 -p 443:443 -v /path/to/my_proxy.conf:/etc/nginx/conf.d/my_proxy.conf:ro -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy
296-
297-
#### Per-VIRTUAL_HOST
298-
299-
To add settings on a per-`VIRTUAL_HOST` basis, add your configuration file under `/etc/nginx/vhost.d`. Unlike in the proxy-wide case, which allows multiple config files with any name ending in `.conf`, the per-`VIRTUAL_HOST` file must be named exactly after the `VIRTUAL_HOST`.
300-
301-
In order to allow virtual hosts to be dynamically configured as backends are added and removed, it makes the most sense to mount an external directory as `/etc/nginx/vhost.d` as opposed to using derived images or mounting individual configuration files.
302-
303-
For example, if you have a virtual host named `app.example.com`, you could provide a custom configuration for that host as follows:
304-
305-
$ docker run -d -p 80:80 -p 443:443 -v /path/to/vhost.d:/etc/nginx/vhost.d:ro -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy
306-
$ { echo 'server_tokens off;'; echo 'client_max_body_size 100m;'; } > /path/to/vhost.d/app.example.com
307-
308-
If you are using multiple hostnames for a single container (e.g. `VIRTUAL_HOST=example.com,www.example.com`), the virtual host configuration file must exist for each hostname. If you would like to use the same configuration for multiple virtual host names, you can use a symlink:
309-
310-
$ { echo 'server_tokens off;'; echo 'client_max_body_size 100m;'; } > /path/to/vhost.d/www.example.com
311-
$ ln -s /path/to/vhost.d/www.example.com /path/to/vhost.d/example.com
312-
313-
#### Per-VIRTUAL_HOST default configuration
314-
315-
If you want most of your virtual hosts to use a default single configuration and then override on a few specific ones, add those settings to the `/etc/nginx/vhost.d/default` file. This file
316-
will be used on any virtual host which does not have a `/etc/nginx/vhost.d/{VIRTUAL_HOST}` file associated with it.
317-
318-
#### Per-VIRTUAL_HOST location configuration
319-
320-
To add settings to the "location" block on a per-`VIRTUAL_HOST` basis, add your configuration file under `/etc/nginx/vhost.d`
321-
just like the previous section except with the suffix `_location`.
322-
323-
For example, if you have a virtual host named `app.example.com` and you have configured a proxy_cache `my-cache` in another custom file, you could tell it to use a proxy cache as follows:
324-
325-
$ docker run -d -p 80:80 -p 443:443 -v /path/to/vhost.d:/etc/nginx/vhost.d:ro -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy
326-
$ { echo 'proxy_cache my-cache;'; echo 'proxy_cache_valid 200 302 60m;'; echo 'proxy_cache_valid 404 1m;' } > /path/to/vhost.d/app.example.com_location
327-
328-
If you are using multiple hostnames for a single container (e.g. `VIRTUAL_HOST=example.com,www.example.com`), the virtual host configuration file must exist for each hostname. If you would like to use the same configuration for multiple virtual host names, you can use a symlink:
329-
330-
$ { echo 'proxy_cache my-cache;'; echo 'proxy_cache_valid 200 302 60m;'; echo 'proxy_cache_valid 404 1m;' } > /path/to/vhost.d/app.example.com_location
331-
$ ln -s /path/to/vhost.d/www.example.com /path/to/vhost.d/example.com
332-
333-
#### Per-VIRTUAL_HOST location default configuration
334-
335-
If you want most of your virtual hosts to use a default single `location` block configuration and then override on a few specific ones, add those settings to the `/etc/nginx/vhost.d/default_location` file. This file
336-
will be used on any virtual host which does not have a `/etc/nginx/vhost.d/{VIRTUAL_HOST}_location` file associated with it.
337-
338-
### Contributing
339-
340-
Before submitting pull requests or issues, please check github to make sure an existing issue or pull request is not already open.
341-
342-
#### Running Tests Locally
343-
344-
To run tests, you need to prepare the docker image to test which must be tagged `jwilder/nginx-proxy:test`:
345-
346-
docker build -t jwilder/nginx-proxy:test . # build the Debian variant image
347-
348-
and call the [test/pytest.sh](test/pytest.sh) script.
349-
350-
Then build the Alpine variant of the image:
351-
352-
docker build -f Dockerfile.alpine -t jwilder/nginx-proxy:test . # build the Alpline variant image
353-
354-
and call the [test/pytest.sh](test/pytest.sh) script again.
355-
356-
357-
If your system has the `make` command, you can automate those tasks by calling:
358-
359-
make test
360-
361-
362-
You can learn more about how the test suite works and how to write new tests in the [test/README.md](test/README.md) file.
10+
https://github.com/jwilder/nginx-proxy

0 commit comments

Comments
 (0)