Running multiple RapidFTR containers on same server

[Subhas Dandapani]

Hi,

One of the occasional needs is to run multiple RapidFTR instances on the same server. We have some of these in production as well.

Right now, as we run Docker - we can expose ports 80/443 into the container. But unfortunately this doesn't scale beyond a single container.

So what we're trying to is:

* Make the core RapidFTR Docker container be a simple Unicorn/CouchDB/Solr image. It will still run RapidFTR right away, but it won't have HTTPS.

* For Cloud servers: Run one single Nginx container which routes incoming requests (based on their hostname) to the correct RapidFTR container. This should work regardless there is single or multiple RapidFTR containers. So Nginx will do all the SSL offloading, so SSL certificates will be in nginx alone.

Looks like Docker already supports runtime inspection, and there's this awesome docker-gen tool which listens to docker, runs a template (based on current containers) and produces configurations. We've tried using that (also deriving upon the nginx-proxy example) and it seems to work well.

Any thoughts on this approach? Should we use Unicorn or should we use a full fledged nginx inside the RapidFTR container as well? Any other suggestions?

- Subhas

[Subhas Dandapani]

Relevant nginx container: https://github.com/rapidftr/rapidftr-infrastructure/tree/master/docker/docker-nginx-proxy

--

- Subhas

[Subhas Dandapani]

Hi All,

After considering all possibilities, this would complicate Server-to-Server sync.

Server-to-Server sync happens over CouchDB. The URL for that depends on whether SSL is enabled or not in CouchDB, and it requires some trickery to find out when running inside a docker container proxied through Nginx. Its good to have a predictable container. Its not good to have some containers running without HTTPS (unicorn), and some running with HTTP (proxied thru nginx). Our original RapidFTR container simply has HTTPS always enabled, no matter what the scenario is. So we're not going to switch to Unicorn and then make a separate (outside) nginx handle SSL. It adds to state and makes things more complicated.

So the current plan is:

* Not to touch the current RapidFTR container. It will have nginx+ssl+couchdb+ruby+everything, and its the whole package.

* The separate Nginx proxy will proxy requests over SSL. This will be slow, but then as said above, we don't want to change the original container. Running multiple containers in one machine proxied by nginx is an extra feature, and we wouldn't want to sacrifice/change the normal container for sake of an extra feature. Nginx will remain just an optional wrapper, and we're not going to say "if you want SSL you must run a second proxy container".

Please let me know if this makes sense.

(Just for a background - the present container detects at startup whether a SSL certificate is provided or not, and if not provided, automatically prints a warning and generates a self-signed certificate. so yes, in the current container SSL is always availabe)

--

- Subhas