Giters

cyber-dojo / commander

repo for the cyberdojo/commander Docker image and the cyber-dojo bash script

Home Page:https://cyber-dojo.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support for jwilder/nginx-proxy

TBBle opened this issue · comments

commented

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.

commented

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 ?

commented

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.

commented

Appreciate you looking into this :-)
Cheers

commented

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.

commented

Yes. Good point.

commented

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