Unit-testing Bref lambda handlers

Hopefully this helps someone out there unit-testing Bref lambda consumers (eg. AWS lambda handlers for SNS / EventBridge / SQS, etc) with PHPUnit;

Essentially this includes the consumer (which is essentially a PHP function), and calls the function with array of event-data (in the same format AWS would normally give it).

The function (handler) would then return a response (hopefully with no thrown errors), and any unit-testing on the result would be done.

public function testConsumeUpdatePerson() {
        $handler = include(__DIR__ . '/../bin/consume');

        $data = json_encode([
            'action' => 'update-person',
            'id' => 1234
        ]);
        $overallJson = '{
  "Records": [
    {
      "EventVersion": "1.0",
      "EventSubscriptionArn": "arn:aws:sns:us-east-2:123456678:sns-lambda:abc-123",
      "EventSource": "aws:sns",
      "Sns": {
        "SignatureVersion": "1",
        "Timestamp": "2019-01-02T12:45:07.000Z",
        "Signature": "aaaabbbb/ccccdddd/111111==",
        "SigningCertUrl": "https://sns.us-east-2.amazonaws.com/SimpleNotificationService-aaaabbbb.pem",
        "MessageId": "aaaabbbbb",
        "Message": "' . addslashes($data) . '",
        "MessageAttributes": {
          "Test": {
            "Type": "String",
            "Value": "TestString"
          },
          "TestBinary": {
            "Type": "Binary",
            "Value": "TestBinary"
          }
        },
        "Type": "Notification",
        "UnsubscribeUrl": "https://sns.us-east-2.amazonaws.com/?Action=Unsubscribe&SubscriptionArn=arn:aws:sns:us-east-2:111122222:test-lambda:aaaaa-bbbbb",
        "TopicArn" : "arn:aws:sns:ap-southeast-2:1111222222:topic-name-goes-here",
        "Subject": "TestInvoke"
      }
    }
  ]
}';
        $event = json_decode($overallJson, true);

        $response = $handler($event, new Context('', 300, '', ''));
        $this->assertEquals('OK', $response);
    }

More unit-tests can obviously be added below, but the basics of this test that there’s no errors, unhandled exceptions, etc which you hadn’t fully tested otherwise

Including the git tag as an environment var in AWS Lambda (via Bitbucket Pipeline Deployments & serverless)

When deploying with the Serverless framework (which Bitbucket Pipelines can do), I wanted to include a version number (or other vars & options passed in the Serverless CLI) which triggered the deploy (via Bitbucket Pipelines).

In my case, this is shown in the footer of a Symfony web-app (more on that below).

Here’s how this can be achieved;

Serverless

In serverless.yml, we need to define our env-var within the function (or as i’ve done, for all functions, by placing it in the ‘provider’ -> ‘environment’ variables);

DEPLOY_VERSION: ${opt:deploy-version, 'unknown'}

In the above example, my ENV file will be called ‘DEPLOY_VERSION’

The ‘${opt:…} basically gets an option we’ve specified in the serverless deploy command-line (eg. serverless deploy –deploy-version v1.2.3 )

This allows us to pass environment vars from the command line, to our functions (in our case, we’re saying version 1.2.3 of our software is getting deployed).

Then, in Bitbucket;

Next, in our bitbucket-pipelines.yml file, we need to include some extra vars in the ‘atlassian/serverless-deploy:…’ pipe – eg;

EXTRA_ARGS: '... --deploy-version $BITBUCKET_TAG'

Here, we just specify our own option called ‘deploy-version’ (eg. ‘–deploy-version’), and used a variable which bitbucket includes at deploy-time (in our case, it’s called BITBUCKET_TAG).

In my case, i’m using tags to deploy new version of an app (eg. v1.2.3)

Using it with Symfony

From there, it’s upto you how your AWS Lambda function actually uses the environment variable. In my case, i’m using Symfony (with Bref to run it on Lambda). This requires an additional couple of steps;

In the .env file, I need to specify my default value for the env file (eg. when i’m developing it locally, etc);

DEPLOY_VERSION=dev-master

From there, in my case I then include it as a global variable in my templates, by adding it to my ‘config/packages/twig.yaml‘ file;

parameters:
    deploy_version: '%env(DEPLOY_VERSION)%'

twig:
    globals:
        deploy_version: '%deploy_version%'

And then in the footer of my pages, I can include it (eg. base.twig.html);

<p><small>Version: {{ deploy_version }}</small></p>

Done!

In summary, now when we deploy via Bitbucket Pipelines, we’ll have the version number used in the tag, included in our Symfony app (or whatever Lambda function you have).

Of course this could be used for any variable available in Bitbucket Pipelines (or event via the command-line in the Serverless framework)

Enjoy!

Symfony with Bref (and AWS Lambda)

Bref is a serverless framework allowing you to use AWS Lambda with PHP sites, including Symfony apps.

In the serverless.yml file, include the following to allow the headers from the API Gateway to be picked up (eg. so Symfony knows you’re using https rather than http … and makes your absolute URLs with https accordingly);

provider:
  environment:
    TRUSTED_PROXIES: 127.0.0.1,127.0.0.2

Ref; https://symfony.com/doc/current/deployment/proxies.html

As part of this, some optimisations need to be made to the php.ini file, to get Symfony running a little faster;

; maximum memory that OPcache can use to store compiled PHP files
opcache.memory_consumption=256

; maximum number of files that can be stored in the cache
opcache.max_accelerated_files=20000

; don't check timestamps for php files in cache (comment out if php files are getting edited on the server)
; needs a clear-cache script prepared
opcache.validate_timestamps=0

; maximum memory allocated to store the results
realpath_cache_size=4096K

; save the results for 10 minutes (600 seconds)
realpath_cache_ttl=600

Ref; https://symfony.com/doc/current/performance.html