If you're asking, "What's Yii?" check out my earlier tutorial: Introduction to the Yii Framework, which reviews the benefits of Yii and includes an overview of what's new in Yii 2.0, released in October 2014.
In this Programming With Yii2 series, I'm guiding readers in use of the Yii2 Framework for PHP. In today's tutorial, I'll share with you how to take advantage of Yii's console capacity to run cron jobs.
In the past, I've used wget in my cron jobs—a web accessible URL would run my background tasks. This raised security issues and has some performance problems. While I addressed some ways to mitigate risks in our startup series' episodes on security, I had hoped to transition to console-driven commands. And with Yii2 it's fairly straightforward.
For today's example, I'll demonstrate console-based cron commands on my Twixxr site which I described in this Twitter API episode. Due to rate limits and performance management issues, the Twitter API is very dependent on efficient, reliable cron tasks. So it's a great example to share with you.
Before I get started, I'll reiterate: I am always appreciative of your ideas and feedback. If you have a question or topic suggestion, please post your thoughts in the comments below. You can also reach me on Twitter @reifman directly.
What Is Cron?
Wikipedia describes cron as "a time-based job scheduler in Unix-like computer operating systems." And that's pretty accurate. Basically, cron runs all of the background tasks we need to run web services, from log management and backups to API requests to database cleanup.
To see your existing cron jobs on a server, you usually type sudo crontab -l and see something like this:
# Edit this file to introduce tasks to be run by cron. # # Each task to run has to be defined through a single line # indicating with different fields when the task will be run # and what command to run for the task # # To define the time you can provide concrete values for # minute (m), hour (h), day of month (dom), month (mon), # and day of week (dow) or use '*' in these fields (for 'any').# # Notice that tasks will be started based on the cron's system # daemon's notion of time and timezones. # # Output of the crontab jobs (including errors) is sent through # email to the user the crontab file belongs to (unless redirected). # # For example, you can run a backup of all your user accounts # at 5 a.m every week with: # 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/ # # For more information see the manual pages of crontab(5) and cron(8) # # m h dom mon dow command */3 * * * * wget -O /dev/null http://meetingplanner.io/daemon/frequent */15 * * * * wget -O /dev/null http://meetingplanner.io/daemon/quarter 0 * * * * wget -O /dev/null http://meetingplanner.io/daemon/hourly 15 1 * * * wget -O /dev/null http://meetingplanner.io/daemon/overnight 40 2 * * * /usr/sbin/automysqlbackup 15 3 * * 5 wget -O /dev/null http://meetingplanner.io/daemon/weekly 30 2 * * 1 /opt/letsencrypt/letsencrypt-auto renew >> /var/log/le-renew.log
The left-hand side specifies to activate these tasks every 3 or 15 minutes or daily at midnight, etc., and the right-hand side is the script to run. See also Scheduling Tasks with Cron Jobs (Envato Tuts+).
Notice how the Let's Encrypt script is a unique console command. It runs from the command line on our server. However, all my Meeting Planner tasks above run via wget. That acts as if a robot was at a web browser at a specific time running requests against our web application that perform background tasks.
In addition to the overhead that an external web request requires and timeout limitations on scripts on servers, you have to secure these access points. Here's an example of how Meeting Planner does it:
// only cron jobs and admins can run this controller's actions
public function beforeAction($action)
{
// your custom code here, if you want the code to run before action filters,
// which are triggered on the [[EVENT_BEFORE_ACTION]] event, e.g. PageCache or AccessControl
if (!parent::beforeAction($action)) {
return false;
}
// other custom code here
if (( $_SERVER['REMOTE_ADDR'] == $_SERVER['SERVER_ADDR'] ) ||
(!\Yii::$app->user->isGuest && \common\models\User::findOne(Yii::$app->user->getId())->isAdmin()))
{
return true;
}
return false; // or false to not run the action
}
It verifies that the user is either logged in as an administrator or running locally on the server at an identical Internet IP address.
Implementing Console-Based Cron Commands
Alex Makarov, one of the lead volunteers behind the Yii Framework's development, has been helpful answering questions for me as I regularly write about the framework for Envato Tuts+. After reading my security episode, he asked why I wasn't using Yii2's inherent console capability for cron jobs. Basically, I didn't know about it.
Just as I had a /frontend/controllers/DaemonController.php, I created a /console/controllers/DaemonController.php. For this tutorial, I'll do this for the smaller, simpler Twixxr web service.
I'm used to using the console for running database migrations (e.g. ./yii migrate/up 7), but that's all. I was eager to try using it for background tasks.
As I wrote about in an earlier tutorial, my newborn site Twixxr requires extensive background processes to regularly rotate API calls for all of the user requests to befriend influential Twitter accounts held by women.
Here's what the home page looks like:
So I thought Twixxr would make a great testbed for running a console-based cron controller.
The New DaemonController.php
Here's the core of my new console-based DaemonController.php:
<?php
namespace console\controllers;
use Yii;
use yii\helpers\Url;
use yii\console\Controller;
use frontend\models\Twixxr;
/**
* Test controller
*/
class DaemonController extends Controller {
public function actionIndex() {
echo "Yes, cron service is running.";
}
public function actionFrequent() {
// called every two minutes
// */2 * * * * ~/sites/www/yii2/yii test
$time_start = microtime(true);
$x = new \frontend\models\Twixxr();
$x->process($time_start);
$time_end = microtime(true);
echo 'Processing for '.($time_end-$time_start).' seconds';
}
public function actionQuarter() {
// called every fifteen minutes
$x = new \frontend\models\Twixxr();
$x->loadProfiles();
}
public function actionHourly() {
// every hour
$current_hour = date('G');
if ($current_hour%4) {
// every four hours
}
if ($current_hour%6) {
// every six hours
}
}
Notice that it's pretty identical to the structure of my front-end based controller, but it's securely inaccessible to the web because it's in the /console tree. No Apache web server site is configured to browse this area.
So, in the example above, actionFrequent() will be called every two to three minutes. It processes another set of Twixxr friendship requests. On the other hand, actionQuarter() is called every 15 minutes and updates the profile information for browsing accounts. Let's look at how the scheduling works in the cron file.
The New Crontab File
Essentially, in my crontab file, I replace wget with a direct Linux script as shown above for Let's Encrypt renewals.
You type sudo crontab -e to edit or -l to list its contents. Here's my Twixxr cron file:
$ sudo crontab -l # m h dom mon dow command */3 * * * * /var/www/twixxr/yii daemon/frequent */15 * * * * /var/www/twixxr/yii daemon/quarter 0 * * * * /var/www/twixxr/yii daemon/hourly 15 1 * * * /var/www/twixxr/yii daemon/overnight 15 3 * * 5 /var/www/twixxr/yii daemon/weekly #40 2 * * * /usr/sbin/automysqlbackup 30 2 * * 1 /usr/bin/letsencrypt renew >> /var/log/le-renew.log
It's pretty simple. The left-hand side of /var/www/twixxr/yii daemon/frequent is the path where the yii interpreter lives, and the right-hand side is the console controller and method to call.
Everything worked pretty well switching over. I haven't switched Meeting Planner over just yet as I want to do more testing. When background tasks break, it's difficult to know and difficult to debug them (although Sentry error logging is helping a lot).
Issues to Consider
One element I ran into is that the console namespace is distinct from the front-end namespace—so, for example, the SiteHelper.php component I set up in my tutorial, which described running multiple sites from a single codebase, failed when I invoked it. Removing it worked, but I needed to run tests to make sure the underlying background code still functioned. However, mostly the switchover went smoothly.
As with any other code change, test and monitor thoroughly.
What's Next
Looking ahead, I will explore building REST APIs within the Yii2 Framework, which relies coincidentally on creating a distinct sub-tree like the console tree but for external APIs. Of course, this brings up complex authentication and security issues... so it will be fun to explore these with you. I'll be looking at APIs from several angles. I'm actually pretty excited about this.
Watch for upcoming tutorials in my Programming With Yii2 series as I continue diving into different aspects of the framework. Please also explore the Building Your Startup With PHP series, which documents the process of building Simple Planner and Meeting Planner.
If you'd like to know when the next Yii2 tutorial arrives, follow me @reifman on Twitter or check my instructor page for updates.
Related Links
- Yii2 Developer Exchange, my Yii2 resource site
-
Scheduling Tasks With Cron Jobs (Envato Tuts+)
- How to implement cron in Yii2 (Yii Documentation)
- Twixxr, the sample web service mentioned within
Comments