Public | Automated Build

Last pushed: 2 years ago
Short Description
Short description is empty for this repo.
Full Description

docker-gen (nginx-proxy)

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

Useful scripts

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

Fig

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

fig up

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:
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/

Docker Pull Command
Owner
artificial
Source Repository