Add LETSENCRYPT_HOST and VIRTUAL_HOST vars to docker-compose.yml

[Jan-NiklasB]

I would like to propose the addition of the mentioned env-vars to the docker-compose.yml file to enable the ability to use the file with Portainer with Repo-Mode when using a reverse proxy and Letsencrypt by jwilder/nginx-proxy and jrcs/letsencrypt-nginx-proxy-companion

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mgruner]

@Jan-NiklasB thank you so much for your suggestion and sorry for the long delay.

Would you be so kind to explain please in a little more detail what you want to achieve? The Zammad stack does not read the variable LETSENCRYPT_HOST AFAICT, so that I'm not sure why we should add it to the docker-compose.yml. With a separate yml file you can do all customizations that you want: https://docs.zammad.org/en/latest/install/docker-compose.html#customizing-the-zammad-stack

[Jan-NiklasB]

Hey,
thanks for the reply.

I or we are using zammad as support system in it's dockerized form, administrated via Portainer.
Since Portainer offers the option to use a repo-handle (as described here: https://docs.zammad.org/en/latest/install/docker-compose.html#deployment-with-portainer), we would like to use it.

The point where it's getting difficult is that we're running multiple services on one server on different subdomains routed via ngingx reverse proxy by their subdomain (see jwilder/nginx-proxy ).
Since we also need SSL we also use the LE-proxy-companion (see https://hub.docker.com/r/nginxproxy/acme-companion).

For these two containers to do the SSL certification and reverse-proxy setup, they need the mentioned env vars to be set accordingly.

So when using the Portainer github handle it's impossible (as far as I understand) to set these env vars without manuall editing.

Since I guess that we're not the only ones who use this setup I guess it would be a good idea to include these env vars into the default compose file, since there is no place where the docker-compose.overrides.yml can be placed in this mode.

Hope this is now a bit clearer.

[mgruner]

@Jan-NiklasB but these two containers don't run inside of the Zammad stack, do they?

With repo mode from Portainer, it's not possible to specify additional services for the current stack since you cannot specify additional .yml files, is it? That's what I don't understand. Did I miss something?

[Jan-NiklasB]

Hey,

yes, these containers run seperate, but read in the env-vars of the other containers to do their job.
So I have to specify these env-vars in the stack (at the moent I'm doing it by hand on every update).

Or to be more clear, when I have specified these env-vars in my compose file and start up the stack, ngingx and LE notice this (pls don't ask me how), read in the env-vars of the newly created containers and, if the mentioned vars are specified, setup the reverse proxy and LE certificate.

[mgruner]

Wow, now I see it - it reads the information from the mounted docker socket…

[mgruner]

Then I'm open to adding these variables in a section below the "regular" variables, with a comment above explaining the situation. Also, https://hub.docker.com/r/nginxproxy/acme-companion lists more variables that are possible in the last example.

$ docker run --detach \
    --name grafana \
    --env "VIRTUAL_HOST=othersubdomain.yourdomain.tld" \
    --env "VIRTUAL_PORT=3000" \
    --env "LETSENCRYPT_HOST=othersubdomain.yourdomain.tld" \
    --env "[email protected]" \
    grafana/grafana

Should we then add all of them?

Strange though - would it not be better to use labels for such meta information, rather than ENVs which actually get passed inside the container as well?

[Jan-NiklasB]

That sounds good.

For my case I don't need them, but maybe someone else does, so seems useful.

In fakt I'm not that experienced in this topic, but your point with the labels sounds right, although I guess they have their reasons for doing it this way...

[Jan-NiklasB]

@mgruner I updated the file in my fork, so it now contains all 4 vars and a short description with link to the github pages

[mgruner]

👏 thank you so much @Jan-NiklasB