Follow up: Announcing Go Support for AWS Lambda

8th Feb 2018

I was pretty excited by the announcement two weeks ago from Amazon Web Services that AWS Lambda would support Go. Go support is fairly unique in it's implementation on AWS Lambda. Unlike other supported languages — NodeJS, Java, C# and Python — Go enjoys support for source code compiled against any 1.x version!

I read up on the announcement, and found a great post by Paul Maddox on the AWS Compute Blog. It's a perfect post if you want to deploy from terminal using the aws cli tool, but there are some steps that aren't well documented later in the post regarding AWS CodePipeline and AWS CodeBuild. I thought I'd post what I've found with the aim of helping others get quickly up to speed.

Code changes

Open the buildspec.yml file and make the following changes:

The original post describes well how to setup an AWS CodePipeline. AWS CodePipeline will create it's own S3 Bucket, and it makes sense to reuse this bucket, since this newly created Pipeline will have the IAM permissions to read and write from.

When I first ran the CodePipeline, the process ran as far as the CodeBuild job, which promptly failed. Fortunately, it's a quick fix. Adding the -t flag to the go get command instructs get to also download packages required to build tests for the specified packages. More information about go get flags can be found in the official documentation

Change Line 34:

- go get -t ./...

The last change required adding a flag to the aws cloudformation command line tool. This was required to provide the correct permissions to deploy the AWS CloudFormation template:

Other Gotchas

The Lambda article mentions in passing that the IAM role should be setup. Be sure to setup the IAM role as mentioned in the AWS Build Pipeline article. I didn't do this at first, and spent a long time watching the build process fail as the Build job made it's way from one permissin error to the next.

It's worth nothing that as I was working through the IAM permission issues, CloudFormation would get as far as creating a Stack, then it would fail to complete.

This would lead to CloudFormation kicking off a "ROLLBACK", which could not complete due to further permission errors.

Unfortunately, if a CloudFormation stack ever gets into a ROLLBACK_FAILED state, there's nothing to do but delete the stack and start over. Hooray for immutability!

Final feedback

The original article is a great starting point. I've made a Pull Request on GitHub to fix one of the issues I outlined above.