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 reverse proxy.

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 dockergen output.

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 2 containers:

• 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.

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 "fig.yml":

fig up

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: domain.com/app1, domain.com/app2.

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/