Aws-sam-cli: Add support for Go runtime

[sgarcez]

Now that support for Golang in Lambda has been announced it would be great to see the new go1.x runtime also supported in SAM local.

I presume that a reasonable approach would be to use a linux based container to run a pre-built Go binary, but I haven't looked into the current runtime integrations in much detail yet. One requirement there would be for the binary to be compiled with a linux target of course.

I might have time to work on this, unless someone else is already on it.

[christianklotz]

All runtimes are using lambci/lambda:* images and it seems like @mhart has already started working on Go support 🎉.

https://github.com/awslabs/aws-sam-local/blob/bd1672469e85bf533ee10849773ee7c92a854411/runtime.go#L93-L100

[sanathkr]

mhart is already working on it. Once he adds the Go containers, we will make it available in SAM Local

[bscott]

Can't wait!

[mtojek]

@sgarcez in the mean time you can use the proxy to pass all Lambda events:
https://github.com/mtojek/aws-lambda-go-proxy

[terrywarwar]

@mhart added a PR, https://github.com/lambci/docker-lambda/pull/67

[PaulMaddox]

Reopening this. @mhart, i'm seeing an issue when testing with the runtime.

$ GOOS=linux go build -o main
$ sam local start-api
2018/01/23 06:36:28 Connected to Docker 1.35
2018/01/23 06:36:28 Fetching lambci/lambda:go1.x image for go1.x runtime...
go1.x: Pulling from lambci/lambda
Digest: sha256:03b3689fce5e6ec0079cf2b34fdb36423e04fbef67c4a6dc7fa1020710a87012
Status: Image is up to date for lambci/lambda:go1.x

Mounting main (go1.x) at http://127.0.0.1:3000/ [GET]
Mounting static files from public at /

You can now browse to the above endpoints to invoke your functions.
You do not need to restart/reload SAM CLI while working on your functions,
changes will be reflected instantly/automatically. You only need to restart
SAM CLI if you update your AWS SAM template.

2018/01/23 06:36:35 Invoking main (go1.x)
2018/01/23 06:36:35 Mounting /Users/pmaddox/dev/go/src/github.com/paulmaddox/test as /var/task:ro inside runtime container
START RequestId: 4a889cca-8d62-1368-fd97-aa2a390a57c5 Version: $LATEST
END RequestId: 4a889cca-8d62-1368-fd97-aa2a390a57c5
REPORT RequestId: 4a889cca-8d62-1368-fd97-aa2a390a57c5  Duration: 0.00 ms       Billed Duration: 0 ms   Memory Size: 0 MB       Max Memory Used: 0 MB
{
  "errorMessage": "2018-01-23T06:36:37.054Z 4a889cca-8d62-1368-fd97-aa2a390a57c5 Task timed out after 0.00 seconds"
}
2018/01/23 06:36:36 Function returned an invalid response (must include one of: body, headers or statusCode in the response object): unexpected end of JSON input

I suspect this is something up somewhere in SAM Local, as running manually with the runtime container works fine (with docker run -v $(pwd):/var/task -i -t --rm lambci/lambda:go1.x main).

I'm at a conference all day today, but will look into this as soon as possible.

[mhart]

The fact that it's timing out immediately makes me think that AWS_LAMBDA_FUNCTION_TIMEOUT is set incorrectly somewhere?

[PaulMaddox]

Yes, that looks like the case. The template I was testing with didn't specifically set a timeout value, so it should have defaulted to 3 seconds.

The codepath that handles halting function execution in SAM Local works correctly in this case, and defaults to 3 seconds, however if a timeout is not specified in the SAM template, then AWS_LAMBDA_FUNCTION_TIMEOUT is not set.

I'll fix this, but I'm surprised this didn't cause issues before with other runtimes.

[mhart]

Well it not being set should default it to 300 seconds (in docker-lambda that is) – so it must be specifically set to something else? Is it an empty string perhaps?

Maybe I should adjust https://github.com/lambci/docker-lambda/blob/master/go1.x/run/aws-lambda-mock.go#L193-L198 so that it returns the default on empty strings too

[mhart]

(I've done exactly that – it will now fallback on empty strings – building on docker hub now. Not sure if that was what was going on in this case, but I think it's the right thing to do regardless)

[mhart]

(Building has finished – feel free to retry and see if that changed anything – again, not entirely sure an empty string is the cause... but it might be!)

[lancerushing]

[edit] it's fixed now. ;) [/edit]

Maybe related. I'm installing sam-local on a new box. npm has the new release number 0.2.5 but github doesn't have the release yet.

$ npm install -g aws-sam-local

> [email protected] postinstall /opt/node-v6.9.5-linux-x64/lib/node_modules/aws-sam-local
> go-npm install

Downloading from URL: https://github.com/awslabs/aws-sam-local/releases/download/v0.2.5/sam_0.2.5_linux_amd64.tar.gz
Error downloading binary. HTTP Status Code: 404

When I check https://github.com/awslabs/aws-sam-local/releases , I don't see the release.

[terrywarwar]

v0.2.6 works fine with both sam local invoke and sam local start-api

[PaulMaddox]

Awesome - closing this issue now. Thanks for your help everyone!

[tausif-citrusPay]

Did anyone try debugging on JetBrains GoLand?

[uccmen]

does aws-sam-local local start-api hot reloads for changes in .go files? or is this feature for Go not supported yet?

[terrywarwar]

@uccmen you have to go build your changes.

[uccmen]

thanks for the quick reply @terrywarwar ! appreciate it. do you know if this is something that will be supported in the near future?

This is my current solution to hackishly re-build on changes.

[terrywarwar]

@uccmen I'm not sure if this will be supported in the near future.

[aripalo]

This thread suggest that the Golang is now implemented into SAM CLI, but the README does not state that: https://github.com/awslabs/aws-sam-cli#project-status

Is it just a missing info on README or is there still some functionality missing related to Golang support? I'm, just currently considering Lambda+Golang and figuring out all the options for development etc 🙂

[piotrkubisa]

@aripalo Haha, good catch. I suppose population of developers reading documentation/README thoroughly decreases each year by some percents :smile: I've added #631 regarding to this issue.