This is a nice approach. It does have the problem that Jenkins is a single point of failure, but I think for those of us running tiny software companies, we can manage that.
I liked the idea in your blog post that servers are cattle, not pets.
Iâm probably late to the party, but in case the jury is still out I have a very simple and effective pattern for this:
- implement your job behind an HTTP endpoint so that you can trigger it by posting (with a secret key of course) to a URL in your app.
- set up a cron job to hit that URL through the load balancer. This ensures you only run on one node at a time and that youâre resilient against nodes failing.
Other advantages:
- Itâs all inside your app so you donât need to manage a separate set of config/db passwords.
- Easy to test because you can trigger the job yourself manually.
- Easy to disable
1 Like
So what to do if the whole node where cron is running is down?
Weâll yeah, you do have a potential single point of failure there. One additional point I shouldâve mentioned is that (provided what youâre scheduling isnât particularly time sensitive) you can run more than one cron node and stagger the timings.
Alternatively you can live with it being a single node and put a heartbeat monitor on it. Cron services tend to be fairly robust anyway and easy to fix or recommission if they do go wrong.
I think SPOF was the reason Steve created this thread.