golang aws templates refer to go1.x runtime which is being depreciated #12123
Comments
|
Here for this as well |
|
I second that as I received a deprecated notice from aws. |
|
As I tested so far, simply change the runtime can still make deployment succes, however, when I trying to test it by simply making http request to it, I got the following error. Errors{"message":"Internal Server Error"}Output logsServerless configuration file# Welcome to Serverless!
#
# This file is the main config file for your service.
# It's very minimal at this point and uses default values.
# You can always add more config options for more control.
# We've included some commented out config examples here.
# Just uncomment any of them to get that config option.
#
# For full config options, check the docs:
# docs.serverless.com
#
# Happy Coding!
service: myawesomeservice
# app and org for use with dashboard.serverless.com
app: myawesomeproject
org: myorg
configValidationMode: error
# You can pin your service to only deploy with a specific Serverless version
# Check out our docs for more details
frameworkVersion: '3'
provider:
name: aws
runtime: provided.al2
stage: dev
region: ap-southeast-1
# you can add statements to the Lambda function's IAM Role here
# iam:
# role:
# statements:
# - Effect: "Allow"
# Action:
# - "s3:ListBucket"
# Resource: { "Fn::Join" : ["", ["arn:aws:s3:::", { "Ref" : "ServerlessDeploymentBucket" } ] ] }
# - Effect: "Allow"
# Action:
# - "s3:PutObject"
# Resource:
# Fn::Join:
# - ""
# - - "arn:aws:s3:::"
# - "Ref" : "ServerlessDeploymentBucket"
# - "/*"
# you can define service wide environment variables here
# environment:
# variable1: value1
package:
patterns:
- '!./**'
- ./bin/**
functions:
hello:
handler: bin/hello
events:
- httpApi:
path: /hello
method: get
world:
handler: bin/world
events:
- httpApi:
path: /world
method: get
# The following are a few example events you can configure
# NOTE: Please make sure to change your handler code to work with those events
# Check the event documentation for details
# events:
# events:
# - http:
# path: users/create
# method: get
# - websocket: $connect
# - s3: ${env:BUCKET}
# - schedule: rate(10 minutes)
# - sns: greeter-topic
# - stream: arn:aws:dynamodb:region:XXXXXX:table/foo/stream/1970-01-01T00:00:00.000
# - alexaSkill: amzn1.ask.skill.xx-xx-xx-xx
# - alexaSmartHome: amzn1.ask.skill.xx-xx-xx-xx
# - iot:
# sql: "SELECT * FROM 'some_topic'"
# - cloudwatchEvent:
# event:
# source:
# - "aws.ec2"
# detail-type:
# - "EC2 Instance State-change Notification"
# detail:
# state:
# - pending
# - cloudwatchLog: '/aws/lambda/hello'
# - cognitoUserPool:
# pool: MyUserPool
# trigger: PreSignUp
# - alb:
# listenerArn: arn:aws:elasticloadbalancing:us-east-1:XXXXXX:listener/app/my-load-balancer/50dc6c495c0c9188/
# priority: 1
# conditions:
# host: example.com
# path: /hello
# Define function environment variables here
# environment:
# variable2: value2
# you can add CloudFormation resource templates here
#resources:
# Resources:
# NewResource:
# Type: AWS::S3::Bucket
# Properties:
# BucketName: my-new-bucket
# Outputs:
# NewOutput:
# Description: "Description for the output"
# Value: "Some output value" |
|
You have to name the binary specifically. Check that doc |
Regarding this. Would be great if Serverless allowed to rename the binary automatically. It's quite annoying to start managing it if you're deploying more than 1 binary and they are stored (typically) in the common |
|
I have the same concern. I'm creating different binary name per function like ./bin/func1 and ./bin/func2, and deploying them. However, |
|
Maybe we could just do |
|
Something like |
|
Using |
|
What is annoying about it? What folder structure locally would you propose? I understanding you have in mind that you could maybe have binaries |
|
Personally for me, the benefits are:
What is annoying is the (anticipated) absence of such benefits. Answering your question about proposed folder structure, the main thing I propose is to NOT make changes to folder structure, but serverless framework packaging function |
|
Agreed with the above 100%, just saying as a workaround is all. I hope serverless handles this in the build process |
|
I agree as well. For now, I'm developing Makefile to do above process as a workaround. |
|
I have updated my function to Aswell as my And updated my go build script to run: But I'm getting: |
|
From my understanding of the required migration you can no longer pass a binary into the runtime. This blogpost by @matthiasbruns helped me out a bunch (thanks!) changes to our build logic: GOOS=linux GOARCH=arm64 go build -ldflags -s -d -w -tags lambda.norpc -mod=readonly -o bin/function/bootstrap cmd/function/main.go
zip -j bin/function.zip bin/function/bootstrapchanges to our serverless files where below: provider:
name: aws
runtime: provided.al2
architecture: arm64
...
package:
individually: true
...
functions:
function:
handler: bootstrap
package:
artifact: bin/function.zip
... |
|
Thanks I actually managed to overcome my issues with the amazing serverless-go-plugin |
|
Can someone from serverless address this?! |
|
Can someone help me? build: And my serverless configuration function looks like this: functions: It builds and deploys normally, but I'm getting this error when accessing the route: How can I solve it? |
Are you certain it's a bug?
Is the issue caused by a plugin?
Are you using the latest v3 release?
Is there an existing issue for this?
Issue description
I got a message today that the existing "go1.x" runtime is being depreciated, and replaced with a new
provided.al2runtime. AWS has published instructions on how to migrate here - some of which would likely involve modifying how the handler and entrypoint are referred to in theserverless.yamlfile. I upgrade serverless to latest, but I still see that new projects are created with the old runtime, despite it being depreciated early next year.Service configuration (serverless.yml) content
N/ACommand name and used flags
N/A
Command output
Environment information
The text was updated successfully, but these errors were encountered: