Open and3rson opened 2 years ago
I have the same problem... if we don't use serverless offline --useDocker
the offline plugin try to build the folder project as project.go
My current workaround for this is to have a serverless.yml
for local development, then create a serverless.prod.yml
.
I can't seem to find any docs on how to do substitutions nicely in these yaml files, or maybe I'm just new to all this, but I extrapolated from the documentation provided about how to create multiple files for the functions
list here:
# serverless.yml
---
functions:
- ${file(./foo-functions.yml)}
- ${file(./bar-functions.yml)}
And then applied the syntax used in this GitHub issue comment to create my serverless.yml
:
service: ${file(serverless.prod.yml):service}
frameworkVersion: ${file(serverless.prod.yml):frameworkVersion}
provider: ${file(serverless.prod.yml):provider}
plugins:
- serverless-offline
functions:
- ${file(functions/serverless.yml)}
I've then got my serverless.prod.yml
pointing to a different yaml file for my functions:
service: my-service
frameworkVersion: '3'
provider:
name: aws
runtime: go1.x
stage: dd-dev
region: eu-west-2
functions:
- ${file(functions/serverless.prod.yml)}
I can then do the following command for dev:
sls offline
And for prod I run my makefiles and then do:
sls deploy -c serverless.prod.yml
if anyone could look into this and create a PR that would be appreciated. I'm guessing the (initial) implementation was done by (a) contributor(s).
@dnalborczyk The root of the issue here seems to be that the serverless framework expects binaries for its handlers when you're using Go, but there's no way to express how those binaries should be created in the serverless.yml
.
The standard way this is dealt with is by providing a makefile that needs to be run before sls deploy
. You can see makefiles are provided in all the serverless examples for Go, and here's a blog post on the serverless website for Go support where a makefile is used before running sls deploy
: https://www.serverless.com/blog/framework-example-golang-lambda-support/
These makefiles usually output the binaries to a bin
directory to which the handler
option in the serverless.yml
points, however the current golang runner in the serverless-offline plugin expects the handler
option to point to a single Go source file (.go
) that can be copied to a tmp
directory and then built with go build
.
I think the correct approach would be to change the golang runner to use binary handlers instead, and expect people to run their makefiles before doing sls offline
. The drawback of this is that we'd lose hot reloads - developers would have to run their makefiles manually to update the binaries after every code change. 😔
In order to keep the hot reloads, we could add a "build step"(?) option to the serverless-offline plugin which developers could point to their makefiles. The go runner could then execute the makefile on every invocation, and then execute the binary handlers. This would mean the binary is executed always up to date with the latest code changes.
@dnalborczyk The root of the issue here seems to be that the serverless framework expects binaries for its handlers when you're using Go, but there's no way to express how those binaries should be created in the
serverless.yml
.The standard way this is dealt with is by providing a makefile that needs to be run before
sls deploy
. You can see makefiles are provided in all the serverless examples for Go, and here's a blog post on the serverless website for Go support where a makefile is used before runningsls deploy
: https://www.serverless.com/blog/framework-example-golang-lambda-support/These makefiles usually output the binaries to a
bin
directory to which thehandler
option in theserverless.yml
points, however the current golang runner in the serverless-offline plugin expects thehandler
option to point to a single Go source file (.go
) that can be copied to atmp
directory and then built withgo build
.I think the correct approach would be to change the golang runner to use binary handlers instead, and expect people to run their makefiles before doing
sls offline
. The drawback of this is that we'd lose hot reloads - developers would have to run their makefiles manually to update the binaries after every code change. 😔In order to keep the hot reloads, we could add a "build step"(?) option to the serverless-offline plugin which developers could point to their makefiles. The go runner could then execute the makefile on every invocation, and then execute the binary handlers. This would mean the binary is executed always up to date with the latest code changes.
Hot reloads are ok to lose, but what about debugging? :(
There doesn't seem to be a way to make the project runnable in both AWS and offline.
Attempt 1 (from
aws-go
)So I have this config (from
aws-go
template):This works on AWS and with
--useDocker
, but fails locally with an error:Please note the path above: it's pointing to an unexisting
serverlessapp.go
file (which in fact is a folder of my project,serverlessapp
)Attempt 2 (from PR #1320)
I've checked #1320 and that PR contains a different config, so I've rewritten my config by changing
handler
string:Now, local execution succeeds:
However, now the code does not work when deployed to AWS:
Question: What is the correct way to configure my project? I cannot seem to find a way to run a project with the same config both locally and on AWS. Config 1 works on AWS only, config 2 works locally only...
Thanks in advance!