Elastic Beanstalk crons on multi-instance environments

Wow. What a lot of pain.

So let me first confirm what won’t work. Whether Apache 1, Apache 2, leader_only or EB_IS_COMMAND_LEADER testing, you cannot consistenty get exactly one (not zero, or 2+) instances to run a cron job over a long period of time.

The issue is the the leader information isn’t safe. It’s only available during deployments, when you usually first set up the cron job. But when an instance replacement happens—for whatever reason—there is no related deployment, the test to check if the new instance is the leader fails, and you end up with no crons.

So for anything you do at the moment of deployment—database migrations, logging, whatever— that you only want to run once, even on multi-instance environments in an Elastic Beanstalk Application, you can use and trust the leader tests available to you.

But for anything you want to run regularly, on a schedule across weeks and months, you cannot trust those options.

After a lot of research, and trial and error there are two options available to you.

Worker environments

The ‘official’ way is probably via a worker environment. Essentially an instance set up specifically to schedule and run short or long lives processes.

You can learn more about them via the links below, but for the rest of this article we’ll be talking about the alternative option of ‘runtime leader testing’.

https://medium.com/@joelennon/running-cron-jobs-on-amazon-web-services-aws-elastic-beanstalk-a41d91d1c571

Runtime leader testing

This option means running the cron on every instance of an environment, but the initial section of the code being run checks the if the instance id that it’s running on is the first to be returned in the list of all instances. That is, only the first instance id returned by the aws elastic beanstalk api will continue to run the task.

Below the examples are in PHP, but it’s a valid method for other languages too.

We’re assuming you’ve already set up a cron and know how to alter it to make it run on all instances of your environment.

The steps in this guide:

  • Create an IAM user just for this process and give it limited read permissions
  • Add the credentials to EB configuration
  • Write code to check the instance id from the api against the current instance id

Adding the user

  • Open IAM in AWS console
  • Click Users
  • Click Add users
  • Type your User name – we used “[applicationCode]-eb-read-user”
  • Click the ‘Access Key’ access type
  • Click Next: Permissions
  • Click the ‘Attach existing policies directly’ tab
  • Type ‘AWSElasticBeanstalkReadOnly’ and select it
    • NB: This permission actually gives more access than is required and you could trim it further
  • Click Next: Tags
  • Click Next: Review
  • Click Create user
  • Take a copy of the KEY and SECRET

Storing the key and secret in the environment

  • Open your environment
  • Click configuration
  • Click ‘edit’ on the ‘Software’ section
  • Add two new items, one for the key (examples use AWS_KEY) and one for the secret (examples use AWS_SECRET)

The code

So this is php, but the basic idea is:

  • Install the aws library – here we use composer
  • Add some code to call the library
  • Compare the first returned instance id against the id of the instance running the code

Install the aws library

$composer require aws/aws-sdk-php

Add the code to do the check

$client = ElasticBeanstalkClient::factory([
    'credentials' => [
        'key' => $_ENV['AWS_KEY'],
        'secret' => $_ENV['AWS_SECRET'],
    ],
    'region'  => '[[your region]]',
    'version' => 'latest'
]);

Replace [[your_region]] above with your own

$result = $client->describeEnvironmentResources([
    'EnvironmentName' => '[[your_environment_name]]'
]);

Then load in the current instance’s id

$currentId = file_get_contents("http://instance-data/latest/meta-data/instance-id");

Then compare the API’s first result to the current one. If the same, so something, otherwise don’t.

if ($currentId == $result['EnvironmentResources']['Instances'][0]['Id'])
{
    // do something. Only one instance will get here
}
else
{
    // don't do anything. All other instances will be here
}

Other useful resources:

https://rotaready.com/blog/scheduled-tasks-elastic-beanstalk-cron

Check AWS Lightsail Bitnami WordPress PHP version

Before you spend time upgrading to a new lightsail instance in the hope of your PHP version meeting WordPress minimum requirements, it’s useful to know if the version available is high enough.

You can check which PHP version you’re going to end up with using the following steps:

  • Open your lightsail home page
  • Click the Create Instance button
  • Check the ‘Linux/Unix’ option is selected
  • Look for the ‘WordPress’ option and make a note of the number displayed underneath (Something like a.b.c-d)

Ok, next we’ll check the Bitnami WordPress changelog

  • Open the changelog file
  • Search for a matching number from your note above
  • Check for a bullet which begins Updated php to
  • If no match, keep reading down the file until you find the first match for Updated php to
  • That’s the current PHP version you’ll get if you spin up a new lightsail wordpress install

If it’s the same or higher than the message being shown inside WordPress you can go ahead. If it’s not then you need to set a reminder to check back regularly on the lightsail creation page to see when the version updates.

AWS don’t use the very latest version available from Bitnami.

The final thing to consider… strangely is if WordPress supports the PHP version you’ll be upgrading to. WordPress maintain a list of which versions of PHP they support (properly and in beta).


Work in a software agency where you struggle to delivery consistently to your unique clients and unique projects? I specialise in that challenge!

Follow me on X (formerly Twitter), Threads for insights, on Medium for thought pieces, or read about my agency focused workshops (UK only) for more information.

Command Line creation of DNS ‘A’ Record in AWS Route53

If you need to add a new record to a Route53 hosted Zone it can be clunky to log in, browse to the right place and manually add your record each time.

If you’re already using some elements of aws or eb command line functionality then this might just be a small step for you which simplifies a currently manual process.

The aws route53 tools are far more powerful than I will cover here. You could add multiple records in a single request. You could updated existing records, or even toggle certain records.

Hopefully this article and the links are enough to get you on your way.

Now the guides generally tell you to create and use a .json file to pull in your config when running the command line, but where the command is simple and you might want to document it, or share it, it’s easier if the whole thing is a single line. If you want to use a .json file then check out the AWS docs for that.

My initial need was to add a single new subdomain to a domain which has many records. Rather than log in and add the record each time, now it’s part of a flow of other command line requests and means less context switching. Opening a browser for any reason can lead to distraction.

I am however not adding a standard ‘A’ record. I’m actually pointing to an Application Load Balancer so I’ll show you the differences for that below.

The first thing you’ll need to do is confirm you have aws command line tools set up and with permissions for the account you’ll be making changes for. Confirmed? Continue…

aws route53 list-hosted-zones

Find the relevent zone in the list and make a note of the final part of the Id from the last forward slash.

Now we’re going to CREATE in our examples but you can also DELETE or UPSERT (update if exists, insert otherwise).

You can also CREATE all sorts of other records, but we’ll stick to ‘A’ for now as it’s a pretty popular record to add.

Take the following and replace the hosted zone id with the code part taken from above after the forward slash. Replace the domain name with yours, replace the subdomain with the one you want to add.

aws route53 change-resource-record-sets --hosted-zone-id BD55*****RS2 --change-batch '{"Changes": [{"Action": "CREATE","ResourceRecordSet": {"Name": "example.com","Type":"A","ResourceRecords": [{"Value": "subdomain.example.com"}]}]}'

And then run it. You can optionally add a comment, TTL and other details. See the docs for that.

Hopefully if you got the zone id right and the details in the right place, you’ll now have a new record in your route53. You can check with:

aws route53 list-resource-record-sets --hosted-zone-id BD55*****RS2

Aliases

If you want to point to an Alias—for example to point to a load balancer—you’ll first need to confirm the details of the loadbalancer to point to.

Here we’re specifically looking for the ‘hosted zone id’ and the ‘DNS Name’.

aws elbv2 describe-load-balancers --region [The Region]

… switch out the region above first. You should then be shown a list of your load balancers. Match the one you need to point to by its code. I actually looked at my existing DNS records to find that using the list-resource-record-sets method above. Then copy the Hosted Zone ID and the DNS Name for it somewhere safe.

The code when an alias is involved contains little more information. In the following you’ll need to replace…

  • the hosted-zone-id with that of your domain
  • the HostedZoneId with that of your load balancer
  • the domain Name
  • the DNSName of your load balancer
  • the true / false value for EvaluateTargetHealth
aws route53 change-resource-record-sets --hosted-zone-id BD55*****RS2 --change-batch '{"Changes": [{"Action": "CREATE","ResourceRecordSet":{"Name": "subdomain.example.com","Type": "A","AliasTarget":{"HostedZoneId":"AC22*****UE7","DNSName": "dualstack.awseb-awseb-Lptg*****fDJ-203*****13.eu-west-1.elb.amazonaws.com","EvaluateTargetHealth": false}}}]}'

Run the above and you’ll be shown basic details about the new record. Again you can run the list-resource-record-sets line above to confirm it’s been created.


Hopefully that’s enough to get you started and you can move on to other options using the official AWS docs. You can also put batches of changes into a .json file if you’d like to CREATE multiple records at a time.

Creating a scheduled Lambda or Lambda Cron

This guide revolves around a basic twitter bot implementation which posts a single tweet to the same twitter account every 6 hours.

It allows any Node script (or other if you fancy doing the work to get PHP/Python etc running) to be triggered on any schedule, from every minute to once every year.

Several steps are involved in getting this all up and running:

  • Get our Twitter auth details
  • Write our bot code
  • Create the Lambda in AWS Console
  • Add Environmental variables to keep our security details safe
  • Test our Lambda function
  • Set up a Cloudwatch trigger to act as the scheduler
  • Confirm the schedule is running as expected

Get our Twitter auth details

Open developer.twitter.com and consider which account you’re going to post tweets to.

You may need to sign up and verify your account. Do all that, or just login.

Once you’re in create a new app. Click to create or view keys / access details and ensure you have an App Token, App Secret, User Secret and User Token. So four hashes in total. Two tokens and two secrets.

Also check that your user details have read and write access so we can post tweet updates.

Continue reading

Updating PHP on an AWS Lightsail WordPress Stack

Updated 27th September 2020 to consider restart of all services where restarting just apache isn’t enough, and also to share choice when it comes to import first vs SSL first as you may lose permalinks. Thanks to Peter and Simon in the comments.

Updated 25th January 2021 to add an initial paragraph clarifying that you can’t ‘choose’ a PHP version on Lightsail and to further clarify that you must first check which version of PHP a new AWS Lightsail instance will be built with to confirm it will resolve the message being displayed in WordPress.

Updated 11th May 2021 to confirm that snapshots cannot be used to update the PHP version of a Lightsail Bitnami instance.

Updated 22nd September 2022 to add a link to a guide to check which PHP version you’ll get if you spin up a new Lightsail WordPress instance. Also added a note about WordPress supported PHP versions.

Updated 7th September 2023 to add a mention of the option to use Bitnami’s bncert tool to create an SSL certificate


NB: If you’re hoping for a way to click ‘update php’ or ‘use X version of PHP’ in Lightsail, it doesn’t (at time of writing) exist. This guidance will walk you though creating a new Lightsail instance with a newer version of PHP installed and moving everything over to it.

The AWS Lightsail service is great. Click a few buttons and you have a powerful VPS with WordPress up and running for only a few dollars a month. The Bitnami integration allows you to choose from a whole set of Stacks to include upon setup. The LAMP option allows a competent PHP developer to run almost anything on Lightsail.

But after a while running the Lightsail VPS the setup is going to get stale, and because Bitnami bundles everything up, it’s not recommended to go poking around with only a few parts of it.

That’s the challenge I was faced with. Logging into the WordPress admin console a message is displayed which is telling me WordPress would prefer a newer version of PHP please. My version was old and not receiving security updates.

I read a fair bit about my options, but after looking at the choices I decided the best thing was to do an export and import onto a new Lightsail instance.

Continue reading