This is a nginx-proxy capable of monitoring running
containers on its host and self-adjusting its configuration.
In other words, this funtions as a host-level automated
This is a derived work from "jwilder/nginx-proxy", but
with an extra effort to split nginx and dockergen into
different containers, sharing a volume that holds the
This is a good idea, because dockergen requires access
to its host's docker socket/binary. In this setup the
nginx container is as dumb as it gets (a good thing).
So here we have a "nginx-proxy" application made from
- andrefernandes/docker-nginx : generic nginx image
meant for reuse
- andrefernandes/docker-gen : specific-purpose image
meant to be plugged to a nginx image
- build.sh : builds the image locally (docker build)
- runbash.sh : convenient way to run commands on a new
container (fast-food, auto-destroy) or even to just
open a bash shell to play.
- runweb.sh : runs dockergen container as a daemon.
Please note that "runbash.sh" and "rungen.sh" assume that
there is a running "andrefernandes/docker-nginx" container
named "web" in order to mount its config volume.
Multi-container applications benefit a lot from a higher-level
descriptor that defines their plumbing and automates deployment.
This is a whole new ground and there are several tools for that.
Fig is one of them and now fig is also a Docker product.
The file "nginx-proxy.yml" serves as an example and is quite
handy to run this particular 2-container application.
How can I use it?
fig -f nginx-proxy.yml up
Can't get any simpler than that.
Well, actually it can, if you rename "nginx-proxy.yml" to just
How the magic works?
Any container that starts on the host is automagically
inspected for an environment variable named "VIRTUAL_HOST"
(this is the dockergen task).
For each group of containers with the same VIRTUAL_HOST a
"server" entry is generated for nginx config with a valid
reverse proxy setup (proxy_pass and upstream). Very cool.
The new nginx config is generated by the docker-gen container
and saved on a volume shared with the nginx container. This folder
is loaded by nginx itself when it starts and whenever nginx receives
a reload signal (SIGHUP) from dockergen.
The "nginx.tmpl" template used to generate the nginx config kinda
relies on the fact that every web app gets its own virtual host:
app1.domain.com, app2.domain.com etc.
There is an alternate "nginx-path.template" that can be used in
order to generate location-based (context-root) configs:
More info on docker-gen: https://github.com/jwilder/docker-gen
A very good article: http://jasonwilder.com/blog/2014/03/25/automated-nginx-reverse-proxy-for-docker/