Why Centralize Cron Jobs and Stop Fighting Configuration
Join the DZone community and get the full member experience.Join For Free
As most folks in the IT industry know, cron is a staple, but incredibly painful to work with. Setting up and configuring cron jobs is literally fighting with an arcane language. Then there’s the whole issue of knowing if your cron jobs ran, what their output was, and auditing them. People all across your organization end up putting cron jobs on your servers and some of them might conflict, overlap, or cause errors. Cron jobs are also relatively simplistic – you can’t trigger off of results or create event-based jobs without writing a lot of code. Cron was first written in the 1970s, so it’s not a surprise that it’s painful to work with. As surprising as it is, though, cron is a core part of most organization’s operations.
As a company focused on server management, we’ve been talking a lot about how we can help DevOps and IT pros automate tasks and generally make their lives easier. Many a customer have asked us to include scheduling of tasks into our product. So, this past week we just did that! Kudos to our dev team for cranking out some amazing functionality that we hope will help save IT folks a tremendous amount of time.
Here’s how our centralized task scheduling and job execution capabilities work. Decide on the task or group of tasks that you would like to execute. These can include a process or workflow – which is something that is much harder to do with cron! Write the job in whatever language that works for you – could be bash, perl, python, Ruby, Go, node.js, or any other language that your server supports. The task can be written in our task editor or you can upload a script. From there you schedule the task through our scheduler – which is a whole lot simpler than dealing with the arcane cron date and time scheduling apparatus! The task can now be run against a single server, a group or even groups of servers, or all of your servers. You decide through selecting a “tag” – which is our mechanism for creating a group of servers. As part of deciding where you will run these tasks, you get to also decide who these tasks are run as – this is critical for auditing purposes. Then you are all set. Simply save the task and it will execute for you!
Now, here’s where it gets exciting. After your job is complete, you’ll have full logging of the execution – i.e. what worked and didn’t work, reporting of the results, and auditing to confirm who ran the task, when it executed, and on which servers. This is all available in the JumpCloud UI. Far easier than grepping through log files to see if everything ran correctly and worse: doing that on a lot of machines. We’ve all had cron jobs fail and as a result our disk space filled up or our database wasn’t backed up, or n number of other things. One of the best things about this functionality is that you don’t need to worry anymore about that – if something fails you’ll know about it. If it ran properly you’ll have all of the history.
Another key benefit of our centralized server management approach is that as an admin, you’ll get to see all of the tasks or jobs across all of your servers. Your fellow admins can set up jobs themselves, but the nice part is that all of you can see what tasks and jobs are scheduled across your servers. This is far more usable and auditable than manually checking each server for what jobs it has scheduled, and whether they conflict.
Thanks to so many of you for requesting this functionality. We are excited to help save people time, give them better control over their environment, and increase predictability and reliability of their infrastructure. If this sounds better and easier to you, give it a shot! It only takes a few minutes to get JumpCloud up and running.
This is the way cron should be in 2014.
Published at DZone with permission of Topher Marie, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.