Recurring jobs on Silverstripe Cloud can be configured in three ways:
- Using a cron task.
- Using queued jobs.
- Using server-defined cronjobs.
Using a cron task
As part of using Silverstripe Cloud, you should already have the silverstripe/crontask module installed. The dev/cron cron task is automatically set-up on your stack and utilises sera in order to ensure that only one server will run the task at any one time, regardless of how many servers are in-use on the current environment. This is important to note if you are migrating from a non-distributed system.
See the CronTask documentation for guidance on creating a new CronTask.
Using queued jobs
The symbiote/silverstripe-queuedjobs can be used to add the ability to run jobs on demand or on a schedule through the CMS interface. The module relies on a cronjob being set up to process the queue, which can be set up by adding a cronjob for your base stack and any virtual stack to your .platform.yml file:
crons:
queuedjobs_task:
time: '* * * * *'
sake_once: "dev/tasks/ProcessJobQueueTask"
vhost: "mysite"
<vstack>_queuedjobs_task:
time: '* * * * *'
sake_once: "dev/tasks/ProcessJobQueueTask"
vhost: "<vstack>"
See the Queued Jobs documentation for further guidance.
Using a cron job
The recommended method for running recurring tasks on Silverstripe Cloud is with a CronTask or queued jobs, however if this does not suit your needs you can specify cronjobs directly. Please note that this is considered advanced usage, so ensure that you understand the differences and factor in the possibility of the task running on multiple servers at once.
There are three types of cron you can choose to run:
| Key | Description |
|---|---|
| sake_once | A command that will run via Silverstripe Framework’s sake, and only be executed once, regardless of the number of servers in your stack. Best for isolated tasks and most common option. |
| sake_all | A command that will run via Silverstripe Framework’s sake on every server in the stack in parallel. Best for updating something on the filesystem that is otherwise not synced or shared. |
| command | (Advanced) A raw command - this can be anything you want to execute, and by default will run on every server at once. |
For example, to run a task at 20:00 (8pm) daily on one server:
crons:
mytask_at_eight:
time: '0 20 * * *'
sake_once: 'dev/tasks/MyTask'
vhost: 'mysite'
Where the vhost parameter matches your virtual stack name - or mysite for a base stack. This will automatically run as the webserver user and will log to Graylog with the logtype Silverstripe_cron_mytask_at_eight for easy filtering.
sake_once it is normal to see logs such as Timeout out trying to acquire the lock. each time the task runs. This message is logged because the task is triggered on both servers, but sake_once sets up a lock which only one server can acquire, and any other servers which cannot acquire this lock will log the timeout message.If you see these errors coming from all servers in the load balance pool it means that the task is taking longer to run than the time available between runs. In that case you should consider decreasing the frequency your task runs at or improving the speed of your task.