Tasker is a multipurpose task runner
Tasker is a task runner, plain and simple. Define tasks, schedule them, and that's it !
Give it a try ! Just create the following
docker-compose.ymlfile
version: "2"services: tasker: image: strm/tasker volumes: - "/var/run/docker.sock:/var/run/docker.sock" environment: configuration: | schedule: - every: minute task: hello tasks: docker: - name: hello image: debian:jessie script: - echo Hello world from Tasker
And that's it, now you have a task, running inside docker every minute, using the
debian:jessieimage (and bash inside this image), to run the script defined inside
scriptelement.
Configuration is segmented, the concept is, you first configure your tasks, and then you configure what will activate them. Then just map your configuration file to
/application.ymlin the container, or if you run it outside docker, map it to a file called
application.ymlin the same folder that you are running the application from.
Here is an example with several constructions:
config: global-environment: - http_proxy="http://yourproxy:8080"schedules:
tasks:
docker:
- name: backup
image: debian:jessie
script-strict: true
script:
- echo Running the backup
environment:
- TEST=environment variable value
volumes:
- someVolume:/whatWouldBeMappedInTheContainer
At this moment there is only one kind of task,
dockertasks. Those tasks ran inside docker containers, plain and simple as that. More task executers will be implemented in a near future, watch this repository to be sure you get the updates !
Configurations
image- the image in the very same format as it is expressed for docker, in
repo/image:tagfor images in the default repository, of
server/repo/image:tagfor images residing somewhere else.
environment- Define environment varibales to be used in the task execution, they follow the same pattern that you use in
docker-compose.ymlfile, a list of
variable=value.
volumes- An array, just like you map
volumesin your
docker-compose.yml.
ports- An array, just like you map
portsin your
docker-compose.yml.
network- If you wish to attach or use any other network that you have. If the desired network doesn't exist, it will be created.
Configurations regarding container life cicle:
keepContainerAfterExecution- Keep container after it executes, won't delete it, WARNING it can leave a lot of trash. USE IT FOR DEBUGING ONLY !
always-pull- A boolean (true/false) property, when it's true, Tasker will pull a newer image version updating it if there is a newer one available.
reuse-container- If the container doesn't exist, create it, if there is already a container with that name, reuse the container.
You can pass parameters to your task and set the entrypoint of the image as you pass in docker command line. Example:
tasks: docker: - name: hello image: debian:jessie entrypoint: /bin/bash arguments: -c,echo Aloha world
The example above execute
/bin/bashpassing as argument
-c echo Aloha world. Comma can be used to separate arguments in an inline array. It uses a YML structure, so you can rewrite it as you wish. For example, you can declare the parameter array as a list:
tasks: docker: - name: hello image: debian:jessie entrypoint: /bin/bash arguments: - -c - echo green bar
Both examples will produce the very same result.
scriptdirective is a facilitator to setting the
entrypointto
/bin/shand pass as arguments as a list of commands. It's syntax is just a list of commands like:
- name: helloScriptStrict image: debian:jessie script: - echo Hello from Docker
Commands will be executed sequentially, no matter the result. To enable the strict mode, where the next command will only be executed if the previous command was successful (exit status 0), you can use the
script-strictproperty. For example
- name: helloScriptStrict image: debian:jessie script-strict: true script: - echo This is the first line - echo This second line will only be executed if the above command properly runs
Tasker uses the concept of lazy loading, in other words, it will pull your image when it will run at the very first time. You can use
always-pull=truein your docker task definition if you want to keep updating the local image everytime your task runs.
DOCKER_HOSTenvironment variable to this image, to make it run the scheduled tasks in a remote docker host.
secretsaren't available at the moment
Scheduler configuration is an important aspect in Tasker. The scheduler is responsible to what it's name suggests, schedule tasks to be executed. It is defined in
schedulesection of the configuration file. Example
schedule: - every: 10 minutes task: test - cron: 00 00 11 * * * task: test
scheduleis an array of schedules. There are two ways to schedule an task. One is by giving it an interval using
everyproperty or
cron. You can name a schedule with the
nameattribute, but it isn't mandatory, you can have anonymous schedules if you prefer.
Every is a representation for a more simple understanding, like
every: minute, is far more readable, but won't give you the same power as the
crondirective. The
everyparameters can be:
every: 10 minutes, will result in 6 executions, at 00, 10, 20, 30, 40 and 50. Every minute scheduled task will start it's first execution at the first minute of the hour (00).
every: 6 hourswill result in 4 executions, at 00, 06, 12 and 18. Every hour scheduled task will start it's execution at the very first hour of the day (00 - midnight).
every: monday.
cronis another way to set the expected trigger to your scheduled task. It obey the standard
unixcron format, but with the exception that it has one more field. Is a field representing
seconds, and is the first field, from
00to
59are the accepted values.
Is possible to configure Tasker to notify other components when tasks finish. Notifications are triggered after the task is completed. Notifications are defined in the
notifysection of the configuration file, separated for each sub-type of notification, for example:
notify: email: - name: notifyEmailTest task: helloNotifyEmail when: always server: mail.gmail.com subject: Email subject sender: [email protected] content: Your message
Notifications need to be linked to a task, so a valid
taskshould be informed.
name- A name to identify the notification.
task- Which task will trigger this notification
when- When the trigger will run. There are three scenarios,
always- Is the default behavior, it will trigger the notification every time that the task runs.
on-success- Will trigger the notification only if the task is successful.
on-error- Will trigger the notification only if the task isn't successful.
In Tasker, e-mail notifications are a sub-category of notifications. E-mail notifications are configured with
email:field, inside the
notifysection. Bellow a simple example configuration using Gmail:
notify: email: - name: notifyEmailTest task: helloNotifyEmail server: smtp.gmail.com username: [email protected] password: yourpassword recipients: [email protected] subject: Email subject content: Your message
A complete example bellow
notify: email: - name: notifyMyTaskOnErrorOnly task: yourTaskName when: on-error server: localhost port: 3025 username: [email protected] password: yourUserPassword protocol: smtp starttls: true debug: true subject: Email subject recipients: - [email protected] - [email protected] content: | Multiline Task finished
Configuration parameters regarding the connection to the e-mail server:
server- Remote server where the email server is running. Default
localhost.
port- Remote port where the server is listening to. Default
587.
username- Username that will be used in the authentication with the server.
password- Password for the given username.
protocol- Protocol to use for e-mail transfer. Default
smtp.
starttls- Use TLS or not. Default is
true.
debug- Enable a more verbose output of the e-mail transfer process, use it only for troubleshooting. Default
false.
validate-server-on-configuration-load- Validate the e-mail configuration when Tasker startup, and abort it if isn't possible to connect to the e-mail server. Default
true.
Configuration parameters regarding the e-mail to be sent:
subject- The subject of the e-mail.
sender- The
FROMfield in the e-mail.
recipients- A list of e-mail addresses that will receive the e-mail.
content- The content of the e-mail.
template- A velocity template that will be rendered and will generate the
contentof the message.
### Email Template
If you wish to use the
templateproperty, you need to follow Velocity Template Language specification. There are some variables that can be accessed in the context of the execution of the template, and those are:
success- (Boolean) Will be
trueif the task was successful.
error- (Boolean) Will be
trueif the task wasn't successful.
log- (String) The output of the execution of the task.
task- (String) The name of the executed task.
start- (Date) The Java Date when the task started.
end- (Date) The Java Date when the task finished.
If you want to suppress some of the logging information, you can add the following to your configuration
logging: level: ROOT: WARN org.springframework.web: WARN
configaka Configuration of the Configuration section
Configuration is the place where additional components of Tasker can be configured.
global-environment- A list of environment variables that will be assigned to all tasks. Note that this variables are overwritten by
environmentvariables section of each task in case of a conflict.