I could have avoided having to spin up a dummy python web server to serve the assets if this had been available - looking forward to having this feature merged in!

I'm still interested in seeing this merged in. I updated the branch to be up-to-date with the upstream branch.

Why this is not pulled in yet? is this project dead?

any updates?

The biggest problem I see with this attempt is that it still requires that the volume with the static content be mounted into the nginx-proxy container, which must happen manually; nginx-proxy can't dynamically add new volume/bind mounts to itself.

The end result is that you have configuration split between two containers (or docker-compose.yml files):

• nginx-proxy configuration determines where the static data is mounted
• The source app container sets VIRTUAL_ROOT which must match the above path

I love the automatic configuration that nginx-proxy provides, but I can't use it for Dockerized web-apps which have static content I want to serve with NGINX. I landed here looking for a solution to that problem, but unfortunately due to the limitations listed above, I don't think this helps. Thanks though, @Mactory.

I'm probably missing a point here, but what avantage does this approach have over serving those static files from another nginx container behind nginx-proxy ?

I'm probably missing a point here, but what avantage does this approach have over serving those static files from another nginx container behind nginx-proxy ?

The advantage is precisely that: avoiding the need to spin up another instance of nginx solely for the use-case of serving static assets.

I would imagine same argument could be made for the uWSGI/FastCGI backends - what advantage does including those directly within nginx-proxy have over simply running another nginx container behind nginx-proxy with the appropriate configuration?

This is exactly why I responded to the PR with:

I could have avoided having to spin up a dummy python web server to serve the assets if this had been available - looking forward to having this feature merged in!

I'm not sure what the limitations of the Docker client SDK are (I can dig more later), but is it possible for docker-gen to update the volume mounts for a running container? That could theoretically address the concern that @JonathonReinhart raised regarding having to manually mount volumes within the nginx-proxy container directly - I'm just not certain if it's technically feasible or not 🤷

is it possible for docker-gen to update the volume mounts for a running container?

@dhm116 I think it's easier to start with the question: "Is is possible to add a volume mount to a running container?"

The answer, I'm fairly certain, is unfortunately "No."

• How can I add a volume to an existing Docker container? -- The answers are discouraging:
  • Commit it and run a new container 👎
  • Use docker cp 👎 👎
  • Manually edit container config JSON and restart container 🤷‍♂️
• @jpetazzo has this interesting blog post: Attach a volume to a container while it is running but it's not exactly a clean, official, production-quality solution.

So unless you want docker-gen to modify the nginx container's config and restart it, I don't see how this is technically feasible.

I'm not sure what the limitations of the Docker client SDK are (I can dig more later), but is it possible for docker-gen to update the volume mounts for a running container? That could theoretically address the concern that @JonathonReinhart raised regarding having to manually mount volumes within the nginx-proxy container directly - I'm just not certain if it's technically feasible or not 🤷

Regarding this part, no there is no way to live update volumes on a running container. You have to stop it, re-create the container with the new volume and start it again.

Regarding docker-gen, it is not meant to change anything on running container beside signaling them after a template rendering.

Thanks for the insights @JonathonReinhart and @buchdag, very much appreciated. My gut was telling me that it wasn't possible, but I was hoping for something within the SDK that I was unfamiliar with 😞

I think I would tend to agree that having to explicitly mount volumes to the nginx-proxy configuration at runtime would not be very ideal or "clean".

Would an approach where nginx-proxy has standard, named volume(s) that could be utilized so that, rather than directly exposing the nginx certs or dhparam (or static assets) directories, these named volumes would become the interface used to mount certificates and, perhaps, static files? This should still enable the current pattern of being able to react to new containers starting with environment variables triggering template updates, with the named volumes being mapped to known destinations within the nginx-proxy container. Then anyone is free to create mount points to the named volumes however they choose, right? It was the first alternative that sprang to mind that might support the existing and static file hosting use-cases, so forgive me if I glossed over something or left anything important out 😊 Hopefully the underlying concept makes sense - but I can elaborate anything that may not.

The advantage is precisely that: avoiding the need to spin up another instance of nginx solely for the use-case of serving static assets.

I would imagine same argument could be made for the uWSGI/FastCGI backends

You still have to create a stopped container just to act as a support for the environment variable (if it's not stopped, I guess it kinda defeat the whole feature's point).

In contrast, if you're planning on using WSGI/FastCGI your backend container does exist and run, wether nginx-proxy is able to natively proxy this protocol to the backend or not.

I get that serving static file straight from nginx-proxy might be useful and the parallel made with the uWSGI/FastCGI backends but I'm really not sold on having to use stopped and/or useless containers to achieve this.

Regarding the volumes / VIRTUAL_ROOT issue pointed by @JonathonReinhart, correct me if I'm wrong but the FastCGI backend feature already work exactly this way, right ?