fix template when running docker-gen and nginx in separate containers

[thomasleveil]

Since commit 658e20f, the template makes the assumption that the container running docker-gen is the container running nginx while checking that upstream containers are reachable.

By introducing the NGINX_CONTAINER environment variable, users are now able to indicate which container is actually running nginx.

[sjawhar]

When using docker-compose, the container name is based on the project name (unless you set the container_name key, which is not very future-proof). Wouldn't it make more sense to have docker-gen look for a container with the NGINX_CONTAINER environment variable set on it? Instead of telling docker-gen which container is the reverse proxy, you set an environment variable on the reverse proxy that lets docker-gen discover it.

If you did that, though, I suppose you'd also need a way to pass that container name to the sighup command programmatically.

[thomasleveil]

But then what about the case where you have multiple nginx-proxy containers?

[sjawhar]

If there are multiple because you're replicating them in a stack, we should be able to figure out a way to use the service name. Using the current 'container_name' based logic, this is impossible anyway, since you can't scale past one container with that property set.

Otherwise, I'm not sure it's an issue. Nonetheless, I have two more ideas:

1. maybe we set a matching environment variable on both the docker-gen service and the reverse-proxy service. Docker-gen looks for the reverse-proxy containers with the right value. A shared secret.
2. My PR Compose v3: Moved shared volume to top-level volumes entry #709 uses a shared named volume. Maybe docker-gen can look for the service that shares that volume, since they're both attached to it?

[thomasleveil]

In my use case I have two nginx/docker-gen instances, each one of them binded to a different network interface + different docker networks. In such a setup both instances aren't able to forward requests to all web containers but only those they can reach. Using container_name ends up being very practical and no-brainer Le sam. 8 avr. 2017 à 15:24, Sami Jawhar <notifications@github.com> a écrit :

…

If there are multiple because you're replicating them in a stack, we should be able to figure out a way to use the service name. Using the current 'container_name' based logic, this is impossible anyway, since you can't scale past one container with that property set. Otherwise, I'm not sure it's an issue. Nonetheless, I have two more ideas: 1. maybe we set a matching environment variable on both the docker-gen service and the reverse-proxy service. Docker-gen looks for the reverse-proxy containers with the right value. A shared secret. 2. My PR #709 <#709> uses a shared named volume. Maybe docker-gen can look for the service that shares that volume, since they're both attached to it? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#750 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAClPOkSES57Xu9J8sHDW90g2sy5cokjks5rt4qTgaJpZM4MN29l> .

[sjawhar]

All three of the ideas I proposed would work for your use case while not having the container_name limitation:

1. NGINX_CONTAINER on nginx service: Since you have two different setups, and since docker-compose creates a default network for each project, each nginx/docker-gen pair is on its own network. Docker-gen could look for the container with the NGINX_CONTAINER variable that's in the same network as docker-gen.
2. Shared secret: You set a different shared secret for each docker-gen/proxy pair.
3. Shared volume: Each nginx/docker-gen pair also has it's own shared volume. Nothing extra to add here to support this use case.

That said, the shared volume method seems hacky. The shared network in 1 makes more sense.

[sgabe]

Thanks @thomasleveil, this is very much needed when using separate containers. However, might be better to update the template in the docker-gen repository.