Go to file
Joachim Lusiardi b5faa4c09e implement feature to add basic auth to containers via proxy variable 2020-05-29 19:38:50 +02:00
Dockerfile switch to updated base image 2020-05-29 18:56:20 +02:00
README.md implement feature to add basic auth to containers via proxy variable 2020-05-29 19:38:50 +02:00
index.html Add catch all server with default error page 2016-03-25 17:51:56 +01:00
nginx.conf move nginx conf files to /tmp/nginx/conf 2020-05-29 19:13:57 +02:00
nginx_proxy.py implement feature to add basic auth to containers via proxy variable 2020-05-29 19:38:50 +02:00
start.sh Converted into a docker container 2015-01-22 11:04:17 +01:00

README.md

Automated Nginx reverse Proxy for Docker Webservices

This image attaches to the docker event queue and creates/removes proxy settings in the contained nginx.

How it works

Containers that should be proxied need meta information in the environment variable PROXY_DATA available. This variable must be of the following format:

PROXY_DATA=server_names:test.com;www.test.com,port:80

Or written as regex:

PROXY_DATA=(KEY:VALUE,)*KEY:VALUE

The following options are possible:

  • server_names(required) the names of the virtual hosts separated by ";"
  • port(optional, defaults to 80) the port on the target container
  • ip(optional, defaults to listen on all IPs) the IP on which the proxy should listen.
  • location(optional) if the proxied web application is not running on the /-path
  • body_size(optional, defaults to 1MB) the allowed maximal body size as defined in http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
  • auth_data(optional, defaults to none) If set, the value must be constructed like Realm;Username;Password e.g. SecretWebsite;admin;$apr1$RR/RTfI.$s7mRx/yKay7g3Jxmg/eMT/. The crypted password can be created with htpasswd: htpasswd -n -b admin supersecret

Starting the container

Since the container uses Docker's internal event reporting, it needs access to the daemon. At the moment, only access via UNIX socket is possible. Because of that, the socket has to be handed into the container (-v /var/run/docker.sock:/var/run/docker.sock).

Single IP / All IPs

This option is used if your Docker Host has only one IP or if there is no need to differentiate between different IPs regarding wether a Web App is available on it.

Run the container like this: docker run --name auto_proxy -d -v /var/run/docker.sock:/var/run/docker.sock -p 80:80 docker_nginx_auto_proxy

That means that the container exposes all Web Apps on all IPs. Do not use the ip option from above on the target containers. The PROXY_DATA environment variables would be something like

PROXY_DATA=server_names:cooldomain.test.com,port:8080,location:/webApp

Multiple IPs

This option is used if your Docker Host has multiple IPs (perhaps a public IP in the internet and a private IP on a VPN). It is possible to expose some Web Apps only to the private network.

One container must be started for each IP that should host Web Apps. For example, if there is a public IP of 1.2.3.4 and a private IP 10.1.2.3, then 2 Containers would be started: docker run --name auto_proxy_public -d -v /var/run/docker.sock:/var/run/docker.sock -p 1.2.3.4:80:80 docker_nginx_auto_proxy docker run --name auto_proxy_private -d -v /var/run/docker.sock:/var/run/docker.sock -p 10.1.2.3:80:80 docker_nginx_auto_proxy

If a target container does not have the ip option set, it listens on all IP adresses and will be handled by both containers. If a container uses, e.g.,
PROXY_DATA=server_names:cooldomain.test.com,port:8080,location:/webApp,ip:10.1.2.3

then it will be only available on the private 10.1.2.3 IP (perhaps using a VPN).