By Bart Smeets
Soo... I got asked by Virginie Marelli to explain what
cheek is. Here goes:
cheek is an approach at building a simple job scheduler that just works for the simple stuff. If you would look at Airflow as
crontab on steroids, you can look at
crontab with a bit of sugar sprinkled on top.
The original name of this small side project was Better Unified Time-driven Tasks. Such a self exploratory name would have removed the need for any explanation on what the package does. However, it was hard to create an acronym from that name which would withstand the test of time.
But, silliness aside, when would you use this?
- You want an easy to containerize, self-contained job scheduler.
- Robustness is secondary to ease of implementation & use.
- You want to actively be notified if sh&t hits the fan.
- You want to configure your jobs through a simple YAML.
- Tasks should respect your timezone.
- You just wanna look cool by using
So how to use it? First and foremost, when in doubt, you can always fall back on RTFM mode.
Given the README is pretty much self-explanatory I'll focus here on how to define a task schedule. You basically configure
cheek through a yaml that defines the specs of your task schedule. At its most basic it looks as follows:
jobs: foo: command: echo bar
This config defines a job called
foo that will execute the command
echo bar when triggered. However, it does not define a cron string. So the only way to trigger this job is to trigger it manually. You can do so as follows:
cheek trigger my_schedule.yaml foo 6:03PM INF Job triggered job=foo trigger=manual bar
To schedule this job to run at specific interval we use cron strings. Check out crontab guru for a bit of cron definition support. We can define the
foo job to run every day at 8AM as follows. We can also add the timezone that we prefer, to make sure that 8AM is our 8AM regardless of where in the world your job runs.
tz_location: Europe/Brussels jobs: foo: command: echo bar cron: 0 8 * * *
You can start this schedule by running below command. This will start the cheek process that will run indefinitely.
cheek run my_schedule.yaml
Check out the example Dockerfile if you want to know how you can set this up in a container.
Let's look at some extra sugar you can sprinkle on top of your tasks:
tz_location: Europe/Brussels jobs: foo: command: echo bar cron: 0 8 * * * on_success: trigger_job: - rick ricky: command: echo roll failing_job: command: this_command_fails cron: 0 9 * * * on_error: notify_webhook: - https://my_webhook_url/
on_errorallow you to define actions that need to occur after one of the post job run events
trigger_joballows you trigger a job to be run
notify_webhookwill send the result of your job run to a web hook
on_errorcan be specified on a global level
Cool thing about these web hooks is that you can easily hook them up to something like Slack. This allows you to specify certain jobs about which you want to receive active notifications. If you wanna go this route, make sure to check out Webhook.site for testing the output and something like Zapier for hooking this up to things like Slack.
Ow yes, there is also a TUI, made possible by the fine folks over at Charm. I mean, that's just cool, right?
What we do with this at Dataroots you might wonder? We have an actively evolving set tools, bots, platforms and data storages that we use for our day to day operations.
cheek basically runs a bunch of tasks to keep stuff in sync and, arguably more important, people happy.
cheek for this you might wonder? The official reason is that I was frustrated by the huge gap between simplistic crontab installations and the (very) robust Airflow/Flyte/Prefect setups.
cheek tries to fill a gap between these types of solutions. The unofficial answer is that I wanted a cool side project and that I needed a job scheduler for our internal tooling, that made me think of a good official reason for doing this.
All information you actually need about cheek you can find in its repository.