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/