Aurora supports execution of scheduled jobs on a Mesos cluster using cron-style syntax.
A job is identified as a cron job by the presence of a
cron_schedule attribute containing a cron-style schedule in the
Job object. Examples of cron schedules
include “every 5 minutes” (*/5 * * * *), “Fridays at 17:00” (* 17 * * FRI), and
“the 1st and 15th day of the month at 03:00” (0 3 1,15 *).
Example (available in the Vagrant environment):
$ cat /vagrant/examples/jobs/cron_hello_world.aurora
# A cron job that runs every 5 minutes.
jobs = [
Job(
cluster = 'devcluster',
role = 'www-data',
environment = 'test',
name = 'cron_hello_world',
cron_schedule = '*/5 * * * *',
task = SimpleTask(
'cron_hello_world',
'echo "Hello world from cron, the time is now $(date --rfc-822)"'),
),
]
The cron_collision_policy field specifies the scheduler’s behavior when a new cron job is
triggered while an older run hasn’t finished. The scheduler has two policies available:
KILL_EXISTING: The default policy - on a collision the old instances are killed and a instances with the current
configuration are started.CANCEL_NEW: On a collision the new run is cancelled.Note that the use of CANCEL_NEW is likely a code smell - interrupted cron jobs should be able
to recover their progress on a subsequent invocation, otherwise they risk having their work queue
grow faster than they can process it.
Unlike with services, which aurora will always re-execute regardless of exit status, instances of
cron jobs retry according to the max_task_failures attribute of the
Task object. To get “run-until-success” semantics,
set max_task_failures to -1.
Most interaction with cron jobs takes place using the cron subcommand. See aurora cron -h
for up-to-date usage instructions.
Schedules a new cron job on the Aurora cluster for later runs or replaces the existing cron template with a new one. Only future runs will be affected, any existing active tasks are left intact.
$ aurora cron schedule devcluster/www-data/test/cron_hello_world /vagrant/examples/jobs/cron_hello_world.aurora
Deschedules a cron job, preventing future runs but allowing current runs to complete.
$ aurora cron deschedule devcluster/www-data/test/cron_hello_world
Start a cron job immediately, outside of its normal cron schedule.
$ aurora cron start devcluster/www-data/test/cron_hello_world
Cron jobs create instances running on the cluster that you can interact with like normal Aurora
tasks with job kill and job restart.
cron_schedule uses a restricted subset of BSD crontab syntax. While the
execution engine currently uses Quartz, the schedule parsing is custom, a subset of FreeBSD
crontab(5) syntax. See
the source
for details.
No failover recovery. Aurora does not record the latest minute it fired triggers for across failovers. Therefore it’s possible to miss triggers on failover. Note that this behavior may change in the future.
It’s necessary to sync time between schedulers with something like ntpd.
Clock skew could cause double or missed triggers in the case of a failover.
Aurora aims to always have at least one copy of a given instance running at a time - it’s an AP system, meaning it chooses Availability and Partition Tolerance at the expense of Consistency.
If your collision policy was CANCEL_NEW and a task has terminated but
Aurora has not noticed this Aurora will go ahead and create your new
task.
If your collision policy was KILL_EXISTING and a task was marked LOST
but not yet GCed Aurora will go ahead and create your new task without
attempting to kill the old one (outside the GC interval).
Cron timezone is configured indepdendently of JVM timezone with the -cron_timezone flag and
defaults to UTC.