Currently I have Caddy deployed as a Docker service in the engine swarm. All is good and well, but whenever I want to change the configuration I’m rebuilding the Docker image and updating the service (applying the new image on it). This causes the service to be offline for up to 15 seconds, which isn’t ok with frequent deploys.
My initial plan is to move the Caddyfile to a path outside the container, the deploy process would simply update this file on the server. The Docker image that runs Caddy would be modified to trigger the SIGUSR1 every 1 minute or so, to ensure the latest Caddyfile is always loaded.
Couple questions:
Is it a problem to run SIGUSR1 every 1 minute?
If the Caddyfile has some syntax error or have a domain for whose obtaining certificate fails, what will happen?
This should be fine. Let us know if you encounter problems!
Any error in the process of reloading (syntax error, failure to obtain cert, etc) will cause the reload to abort and “roll back” (it doesn’t technically roll back since it hasn’t rolled out the new configuration yet). In other words, no downtime, just log entries.
I implemented it and it has been running fine since. Awesome!
For others, this is what I did:
startup sh -c 'while [ true ]; do sleep 60; kill -s USR1 1; done' &
It takes 5 seconds from printing [INFO] SIGUSR1: Reloading to printing [INFO] Reloading complete, so I guess as long as I don’t trigger this more frequently than 10 seconds, it will be ok. (I’m using 60 seconds).
It should be fine even if it happens multiple times during a reload. It queues up the reloads to ensure that every change is loaded, as you commanded. The ~5s is attempting to gracefully end connections. You can change that with a CLI flag.
But probably a cleaner solution is to only reload when changes actually happen.