Support for jwilder/nginx-proxy

[TBBle]

Since I'm playing with this setup on a shared container sandbox, I can't give it exclusive use of external port 80.

I'm planning to use https://github.com/jwilder/nginx-proxy on this box to support running fairly random things.

I'm locally modifying the commander image to support this, the two main things I need to do:

• Remove the nginx container from docker-compose.yml
• Get the VIRTUAL_HOST environment variable passed into the web container

The latter looks feasible using a web.env the same way grafana.env works. I can also give the grafana instance a name this way.

The former could be done with an extending docker-compose config file. I can't see a better way to override a listed service in docker-compose.yml.

I also need to attach the nginx-proxy to the relevant app_default network but I feel that's something that nginx-proxy should be able to take care of. Right now after I attach the network, I need to restart nginx-proxy, due to nginx-proxy/docker-gen#190.

[JonJagger]

Random thought, and it might not be possible, but could you make the port an optional command-line parameter (that defaults to 80) when bringing up the server? Then you could choose your port. I'm just wondering if there is a way that does not involves modifying commander's docker-compose.yml ?

[TBBle]

I'm not sure if that would work. I'll give it a try next time I get to this. That would mean nginx in-front of nginx in this case, but it's also generally usable for other shared-host situations beyond the automatic nginx-proxy use-case. I'd hence have an nginx.env file to pass the VIRTUAL_HOST environment variable through to NGINX.

This might have the advantage of not needing to mess with the app_default network too. The network part of nginx-proxy (and Docker Compose) is mostly magic for me right now.

The only blocker would be if the nginx-proxy setup won't proxy for published ports, and since (by my limited understanding of Docker) published ports are a subset of exposed ports, I don't imagine that's a blocking issue.

I'll probably try out both methods, since I think the non-hacky version of my current effort won't be too bad.

[JonJagger]

Appreciate you looking into this :-)
Cheers

[TBBle]

Ah, just noticed the front-page images live in the nginx instance, not the 'web' instance. So it's serving a purpose other than reverse-proxy.

[JonJagger]

Yes. Good point.

[TBBle]

I've got the first step up in #10. This is basically enough for now. I was considering trying to get a non-published port working but for my use-case, having people able to bypass nginx isn't a problem.

The only wart remaining is that startup-ordering is fraught with peril:

• Create jwilder/nginx-proxy container
• Start cyber-dojo on port other than 80
• Add nginx-proxy container to app_default network
• Restart cyber-dojo so nginx-proxy regenerates its configuration.

My leaning is two-fold right now:

• See if I can get nginx-proxy to react to having a network added (may depend on newer Docker API per Listen for network (dis)connect events (API v1.22+) nginx-proxy/docker-gen#190.)
• Consider whether I can add another command-line option to cyber-dojo for optionally binding nginx to another network (in this case, the default 'bridge' would work).