Roshan Roy Jonnalagadda

Recently, we moved from hosting our app on Amazon EC2 instances to Elastic Beanstalk Service. For those who had a go at hosting their apps on Elastic Beanstalk, you would know the struggles with .ebextensions. There are far more documentation and examples available now than when it was first released into the market. One of the most challenging things to do in Beanstalk is running Cron. The recommended way of doing it is via the creation of worker environment that processes long-running workloads on demand or performs tasks on a schedule. It makes use of other Amazon services like SQS queuing.

This is okay for some people who have genuinely long-running processes but our PHP application was pretty straightforward. Most of the CRON jobs would be completed in seconds. For us, running a separate worker instance with all its resources was pointless and a waste of resources. So we need to come up with another way. The other way of running CRON is using something called “leader_only” declarations in the .ebextension file. By using that, you are asking Beanstalk to run the CRON Jobs only on the first instance. This avoids multiple instances running the same CRON jobs because that would really screw things up.

Anyway, we need to get the YAML right and there is a neat little utility online that lets you validate your files. It’s called YAMLlint.com. Check it out. To see if your CRON is running as it should, here is a neat little way to test it. Obviously, the whole point of using Beanstalk is to avoid having to manually edit code on single instance so it takes away the need to setup FTP or sFTP. I suggest you do set it up for your first instance so you can check if the CRON is running and if everything is deploying as it should. There is no harm done in double checking right 😉

1. Edit your CRONTAB or in Beanstalk’s case, add it to the .ebextension folder.

$ crontab -e

2. Add the following line inside your CRON which basically will append the current date to a log file every minute. The 6 fields of the crontab file are minute, hour, the day of the month, month, the day of the week, and the actual command.

* * * * * /bin/date >> /tmp/cron_output

3. Exit the editor and you should see an output something similar to this.

crontab: installing new crontab

4. Check if the CRON is running every minute as it should through running this command which grabs the output of the file being stored in /tmp directory.

tail -f /tmp/cron_output

You should see something similar to this as the output.

Mon Apr 23 00:01:01 PDT 2018
Mon Apr 23 00:02:01 PDT 2018
Mon Apr 23 00:03:01 PDT 2018
Mon Apr 23 00:04:01 PDT 2018
...

If you don’t see it regularly running every minute, then you know something is not right with the CRON service. If you don’t see the file at all, then you know the CRON is not running. This narrows down things down to what is working and what isn’t. Saves you some hours on figuring out whether its Elastic Beanstalk file playing around or your actual CRON commands or something else. Hope this helps 🙂

I will be writing the way we setup CRON in the future blog post. Watch the space!