Assigning Environment Variables for Domain and Email


#1

I’m working on automating SSL provisioning and integrating it to our Docker Swarm stackfile. Everything works fine with regards to fetching the required certs. However, I’d like to use Environment Variables for the domain ($DOMAIN) and email ($EMAIL) fields so I can reuse the stackfile.yml as is just like a template.

Ex. This works fine.
entrypoint: [“certbot”, “certonly”, “–standalone”, “-d”, “app.domain.com”, “–non-interactive”, “–agree-tos”, “–email”, "myemail@domain.com", “–http-01-port=8888”, “–staging”]

This one isn’t:
entrypoint: [“certbot”, “certonly”, “–standalone”, “-d”, “$DOMAIN”, “–non-interactive”, “–agree-tos”, “–email”, “$EMAIL”, “–http-01-port=8888”, “–staging”]


#2

Hi,

Isn’t it should look like this?

(No " " for variables…)

Thank you


#3

Thanks for pointing out. You’re right. It should look like below. I just mistyped the whole line but my stackfile already contains “” for the ENVs.

entrypoint: [“certbot”, “certonly”, “–standalone”, “-d”, “$DOMAIN”, “–non-interactive”, “–agree-tos”, “–email”, “$EMAIL”, “–http-01-port=8888”, “–staging”]


#4

So even with the quoted ENV, I still couldn’t fetch the certs as if certbot couldn’t source the ENVs I defined.


#5

Hi @ramilbrion,

This might be a question that would receive better answers if you asked it in a Docker Swarm support channel. I believe the environment variable expansion you’re having trouble with would be done by that tool and isn’t specific to Certbot or Let’s Encrypt. Maybe someone in our community forums is familiar but if not I’d recommend asking elsewhere :slight_smile:

Good luck!


#6

Thanks for the comment.

I’ve actually managed to have a workaround.

It might not be specific to certbot/letsencrypt, but certainly it can be improved. As for the Docker Stack Entrypoint, it couldn’t parse the ENVs because it’s on exec form. I need to find a way for certbot to be run in shell form.

Therefore, I created a custom container based on certbot/certbot and baked a script that creates the “cli.ini” file to the default location. The values for the “email” and “domain” are sourced on the “env_file” I presented on the stackfile. At the end of the file, is the “cerbot” command that points to the cli.ini. So the entrypoint this time is just to run the script. Neat! I also have an extra container that cats/combine the pem files to be used by haproxy.

With the above solution, I managed to remove any static values within my stackfile and would then serve as a template that can be used for other domains.

If you have any other solution, feel free to share.


#7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.