[mschuster91]

Why use a cron job? I have certbot running in one Docker container, the .well-known route directing to the one dedicated Docker host running certbot, and whenever certbot renews the certificate, it writes the cert to the NAS share that is only mounted on the LBs and then triggers a SIGKILL to the haproxy docker containers (which causes haproxy to re-read the cert file and configuration).

Fully automated, no cronjobs to fail. In addition, I have a monitoring on all LBs that verifies the expiration time - it has never hit so far. That cronjob/monitoring is something everyone should have anyway because a well working monitoring system can alert you to so many other possible failure states...

[vog]

> I have certbot running in one Docker container, the .well-known route directing to the one dedicated Docker host running certbot, and whenever certbot renews the certificate, it writes the cert to the NAS share that is only mounted on the LBs and then triggers a SIGKILL to the haproxy docker containers (which causes haproxy to re-read the cert file and configuration).

Is this really more stable than a simple cronjob? It is far more complicated, for sure, so there should be significant benefits to make up for that.

[toomuchtodo]

You just described a far more complicated setup then a simple cron job.

[defined]

Well, depending on how you install certbot, it sets up a cron job automatically for you (on Debian, anyway). It's no big deal - it just creates the cron file /etc/cron.d/certbot.

I'm curious as to how you get certbot to renew automatically without a cron job or some sort of script in the Docker container that periodically runs 'certbot renew'.

[stevenwoo]

Thank you for explaining the details of an alternative method. I have not advanced that far in my deployment skills, yet!