Schedule your platform actions like it's a cron

A new feature

We are excited to announce a new feature that will enable you to schedule platform actions. Right now, these platform actions exist of :

• Executing a scenario: Schedule when a scenario should be executed.
• Launching an application: Schedule to launch a application.
• Stopping an application: Schedule to pauze/stop a application.

There are two ways to define a scheduled action: once or recurring.

• Execute once: When you schedule your action to be executed once, it will be triggered at the time you have defined and will then be disabled so it won’t be executed again (unless it’s enabled again).
• Execute recurring: If you create a recurring schedule, you can define the intervals of execution by using the cron syntax.

How to

Schedules can be defined on application level (launch / stop) or on scenario level. To get an overview of all the scheduled actions of your application, open the application and go to Actions -> Schedule.

As you can see in the image above, all three types of actions you can schedule are shown here where you can disable, edit or delete them. This is also the place to create a new one. Clicking the + button will open a modal window for the configuration.

Timezones

In the screenshot of the modal window, you can see the timezone field. For schedules that need to be executed once, it’s possible to define in which timezone it has to be executed for the next execution date.

For recurring actions, keep in mind that the timezone for execution is in UTC. As can be seen in the screenshot of the schedule overview, the cron of the ‘Launch application’ action is set to 45 21 * * *. Tools like crontab.guru will tell you that the next execution date of this cron expression is set to 21:45. In the screenshot however, the next execution date is set to 25/07/2018 23:45, that is because the browser shows this time in the local timezone (GMT +02:00 in this case).

Scheduler vs Cron

It is still possible to use your good old regular cron inside the application. The platform provides a task to do this. All you have to do is clone the sample task CRON - SAMPLE - Set cron jobs which can be found under the Container utils. Edit and rename the cloned action to your needs with the desired cron syntax and shell commands to execute.

#-------------------------------------
# Cron jobs
#-------------------------------------
# minute hour day month dayofweek  user  command

# Sample every minute
* * * * *  root cd /opt/approot && your_command >/dev/null 2>&1

Typically a cron job contains 3 parts:

• The interval expressed in numbers or * which represents: minute hour day month dayofweek
• The user that will execute the command
• The full command that will be executed

In our example:

• The interval: * * * * * which equals every minute
• The user: the root user will execute the command
• The command: cd /opt/approot && your_command

When the command is related to manipulating files, that are used by the webserver, it is advised to use the "webserver" user (for example: when using Apache, this is `www-data`).

If you want to capture the output in a file, add the following >/opt/approot/cron.log 2>&1> after the command.

Example:

* * * * *  root cd /opt/approot && your_command >/opt/approot/cron.log 2>&1>

If you want to skip the output capturing.

Example:

* * * * *  root cd /opt/approot && your_command >/dev/null 2>&1

Advantages of scheduling actions

Why would you use the scheduler when you can still rely on a cron the server will execute? In fact, there are several reasons for it!

• It’s possible to run a complete scenario with actions that can be executed on different stack items. For example, first take a database backup on your MySQL instance before deploying the latest code on your PHP instance.
• You get to see the scenario result in the interface. The output of each finished task in a scenario is displayed in the interface whether the task ran successfully or unsuccessfully. Just go to the application history and check the logs of the executed scenario.
• You can target single or multiple nodes in your action. A database backup is not something you want to do on all MySQL instances when it’s running in a clustered setup for example. But having the latest code on all your PHP instances is a must.
• All team members of the application have access to the schedule through the interface. When instead you create a cron entry on the server, nobody will be able to see if something is scheduled, unless they SSH to each instance and check all cron files.