Added label-based mechanism to identify docker-gen container. This is needed w…

[chicco785]

Added label-based mechanism to identify docker-gen container. This is needed when using docker compose or other container mechanisms that define dynamically container's name.

[helderco]

You're making changes to app/nginx_location.conf, which is out of scope here.

[helderco]

There's the assumption here that you always have separate containers, but you could have jwilder/nginx-proxy instead. So this needs to be optional.

[chicco785]

the change to app/nginx_location.conf may not be required. it's the results of different attempts to fix the issues i was facing in getting the certificate created. but the problem indeed was all related to the impossibility of connecting to the correct container due to the dynamic naming. the com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_gen label can be optional of course. let me know what you think.

[helderco]

There's the assumption here that you always have separate containers, but you could have jwilder/nginx-proxy instead. So this needs to be optional.

[helderco]

I think this should be:

[[ -z "${NGINX_DOCKER_GEN_CONTAINER:-}" ]] && get_nginx_gen_cid

to allow still using a manual environment variable when you do have access to a static name.

[helderco]

Remove this condition to make it optional, don't error out. Document it instead.

[helderco]

Out of scope, changes should be discarded.

[helderco]

I need this, if you hadn't, I would! 👍

[helderco]

I found an issue with containers getting redeployed during letsencrypt lifecycle, so I made my own attempt with #231. It's working in production right now, with the helder/letsencrypt-nginx-proxy-companion fork (temporary until the PR is merged).

[helderco]

#231 was merged so this can be closed.

[JrCs]

Closed by #231