Having a timing task is a common requirement. Generally, select one or more machines and realize the timing tasks by using crontab. However, for large-scale or a large number of timing tasks, this method has many limits such as:
- Low reliability. If one machine goes down, all the timing tasks on this machine cannot be executed.
- No scheduling function. Loads among machines might not be balanced.
- No retry mechanism. Tasks might fail to be run.
- Cannot run large-scale distributed tasks.
On the basis of the offline tasks, Container Service provides the function of timing tasks, with which you can solve the preceding problems by some simple descriptions. For more information on offline tasks, see Run offline tasks.
Note: You can only use this function if you have upgraded your Agent since October 25th, 2016 or the cluster is newly created.
The same as offline tasks, timing tasks are also based on Docker Compose. You can realize the timing function by adding the
aliyun.schedule label in the orchestration template.
Note: When you create or update a timing task, the system will not pull the latest image. This is because using the latest image will make the same task use different images at different time, which might cause your troubleshooting complicated. We recommend that you update your timing task image by updating the image tag.
aliyun.schedule: "0-59/30 * * * * *"
aliyun.schedule: "0-59/30 * * * * *"indicates running this task every 30 seconds. The format of schedule is the same as that of crontab (but note that the format of schedule is
second minute hour day month week, and that of crontab on Linux is
minute hour day month week) and uses Beijing time.
- The timing function is only applicable to offline tasks. Therefore, the system automatically adds the
aliyun.project_type: "batch"label after you add the
aliyun.schedulelabel. So the
aliyun.project_type: "batch"label in the preceding example can be omitted.
- In addition, all the functions in offline tasks can still be used in timing tasks (for example,
remove_containers). For the specific meanings of these labels, see Run offline tasks.
After a timing task is created, the application is in the status of Waiting. When the specified time of the task is reached, the task is started. The subsequent status changes are the same as the offline applications. The application status repeats this process when the next execution time is reached.
For the same timing task, only a single instance can be executed at a time. If the task execution time is longer than the task execution period (for example, the execution time of the preceding task is longer than 30s), the next execution enters the execution queue. When the length of the execution queue is greater than 3, this execution will be discarded.
You can click the History tab on the application details page to view the execution history and results. Only the last 10 items of execution history are kept in the list.
The timing task controller adopts the master-slave mode. The control function is switched to the slave controller when the master controller malfunctions.
If the task execution time is in the master-slave switch period, the task will be executed until the switch is completed. If the task needs to be run for several times in the master-slave switch period, the task will be executed only once after the switch is completed. Therefore, to ensure that the task is not lost, do not design tasks with a repetition period less than one minute.