|
1 |
| -  [](https://travis-ci.org/jwilder/nginx-proxy) [](https://hub.docker.com/r/jwilder/nginx-proxy 'DockerHub') [](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: |
2 | 2 |
|
| 3 | +https://www.atomicorp.com |
3 | 4 |
|
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. |
5 | 5 |
|
6 |
| -See [Automated Nginx Reverse Proxy for Docker][2] for why you might want to use this. |
| 6 | +Thanks: |
7 | 7 |
|
8 |
| -### Usage |
| 8 | +This project is a CentOS/RHEL based derivative of the project at: |
9 | 9 |
|
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