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.
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.
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:
intervalexpressed in numbers or * which represents: minute hour day month dayofweek
userthat will execute the command
- The full
commandthat will be executed
In our example:
- The interval:
* * * * *which equals every minute
- The user: the
rootuser 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.
* * * * * root cd /opt/approot && your_command >/opt/approot/cron.log 2>&1>
If you want to skip the output capturing.
* * * * * 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 tasks 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.