strm/tasker repository overview

⁠Tasker, a 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.yml file

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:jessie image (and bash inside this image), to run the script defined inside script element.

⁠Configuration

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.yml in the container, or if you run it outside docker, map it to a file called application.yml in 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:
  - every: 5 minutes
    task: test
  - every: Saturday
    task: backup
  - cron: 0 0 13 * * *
    task: test

tasks:
  docker:
    - name: backup
      image: debian:jessie
      script-strict: true
      script:
        - echo Running the backup
      environment:
        - TEST=environment variable value    
      volumes:
        - someVolume:/whatWouldBeMappedInTheContainer

⁠Tasks

At this moment there is only one kind of task, docker tasks. 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 !

⁠Docker tasks

Configurations

• image - the image in the very same format as it is expressed for docker, in repo/image:tag for images in the default repository, of server/repo/image:tag for 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.yml file, a list of variable=value.

• volumes - An array, just like you map volumes in your docker-compose.yml.

• ports - An array, just like you map ports in 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.

⁠Entrypoint and Arguments

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/bash passing 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.

⁠Script directive

script directive is a facilitator to setting the entrypoint to /bin/sh and 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-strict property. 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

⁠Docker images and pulls

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=true in your docker task definition if you want to keep updating the local image everytime your task runs.

⁠Other considerations about docker tasks

• Tasker can run in a swarm or single instance, but it will schedule tasks to run in the current node.
• You can set DOCKER_HOST environment variable to this image, to make it run the scheduled tasks in a remote docker host.
• secrets aren't available at the moment

⁠Scheduler

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 schedule section of the configuration file. Example

schedule:
  - every: 10 minutes
    task: test
  - cron: 00 00 11 * * *
    task: test

schedule is an array of schedules. There are two ways to schedule an task. One is by giving it an interval using every property or cron. You can name a schedule with the name attribute, but it isn't mandatory, you can have anonymous schedules if you prefer.

⁠Every

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 cron directive. The every parameters can be:

• Minute - Every minute inside one hour period. For example, 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).
• Hour - Every hour inside one day period. For example, every: 6 hours will 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).
• Weekday - Every weekday as in the list (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday and Sunday). The task will be executed at the first minute of the first hour of the respective day. For example every: monday.
• Year - Will be executed in the very first second, of the first minute, of the first day, of the first month of the year.

⁠Cron

cron is another way to set the expected trigger to your scheduled task. It obey the standard unix cron format, but with the exception that it has one more field. Is a field representing seconds, and is the first field, from 00 to 59 are the accepted values.

⁠Notifications

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 notify section 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 task should 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.

⁠E-mail notifications

In Tasker, e-mail notifications are a sub-category of notifications. E-mail notifications are configured with email: field, inside the notify section. 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 FROM field 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 content of the message.

⁠Email Template

If you wish to use the template property, 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 true if the task was successful.
• error - (Boolean) Will be true if 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.

⁠Logging

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

⁠config aka 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 environment variables section of each task in case of a conflict.