opsxcq/ tasker

Shell

Java

task-runner

Docker

View on GitHub

Need help with tasker?

Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

opsxcq

157 Stars

17 Forks

148 Commits

8 Opened issues

Description

Tasker is a multipurpose task runner

Services available

Need anything else?

Contributors list

opsxcq opsxcq

# 60,897

Perl

Visual ...

Courser...

Docker

146 commits

Readme

Tasker, a task runner

Name: tasker
Brand: tasker
SKU: //opsxcq/tasker
Rating: 2.1425 (157 reviews)

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

/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

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.