I currently have 2 lambda functions, and I'm trying to make a CI/CD process to them. So I have trying with 2 approaches:
two separate steps on my CI. I have tried to make CloudFormation package and then deploy each lambda, with each of those having their own SAM template and template. but the result is that the only one that will remain on the stack is the last one deployed. i understand that deploy is an smart way that AWS CLI create to do not use create/update stack actions. but it keeps overwriting between them (yes they have different resource name).
having a single sam template and one step in a single repo: I also attempt this in a single repo having both lambdas and a single sam file, but I have duplicate code on my lambdas the difference is that each of them have different set up for which handler to be used.
My goal is to have 2 lambdas in a single stack.
im going to answer my own question because I notice on the sam template was the key.
initially i was doing the sam template like this:
AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Description: An AWS Serverless Specification template describing your function.
Resources:
certainty:
Type: 'AWS::Serverless::Function'
Properties:
Handler: ./myfunc/index.handler
Runtime: nodejs8.10
CodeUri: .
Description: >-
here goes
my description
MemorySize: 128
Timeout: 20
Role: 'arn:aws:iam::116738426468:role/rolename'
Events:
Schedule1:
Type: Schedule
Properties:
Schedule: rate(1 day)
certaintyauxiliar:
Type: 'AWS::Serverless::Function'
Properties:
Handler: my-other-func/index.handler
Runtime: nodejs8.10
CodeUri: .
Description: >-
blabla
blabla.
MemorySize: 1152
Timeout: 300
Role: 'arn:aws:iam::116738426468:role/roleanme'
Events:
Api1:
Type: Api
Properties:
Path: /show-all
Method: POST
what was causing here a "duplicate of the code" was that the lambdas code uri was indicating that should grab all the stuff in the folder that cotained both repos. and telling to go deeper in directories to find the the handler.
so I changed the code uri and the handler and now the lambdas are grabbing just what should be in each lambda. now my sam template looks like this:
AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Description: An AWS Serverless Specification template describing your function.
Resources:
certainty:
Type: 'AWS::Serverless::Function'
Properties:
Handler: index.handler
Runtime: nodejs8.10
CodeUri: ./my-func
Description: >-
here goes
my description
MemorySize: 128
Timeout: 20
Role: 'arn:aws:iam::116738426468:role/roleName'
Events:
Schedule1:
Type: Schedule
Properties:
Schedule: rate(1 day)
certaintyauxiliar:
Type: 'AWS::Serverless::Function'
Properties:
Handler: index.handler
Runtime: nodejs8.10
CodeUri: ./my-other-func
Description: >-
bla bla
bla bla
MemorySize: 1152
Timeout: 300
Role: 'arn:aws:iam::116738426468:role/rolename'
Events:
Api1:
Type: Api
Properties:
Path: /path
Method: POST
sorry, now i can see that at the question I was not providing enough info, but i answer to my own question hoping I can help some as lost as I was. Serverless is a nice approach but it does have quiet a learning curves.
Regards, Daniel
I am trying to create a lambda function using SAM, however I can't work out how to add a custom domain to it. Do I need to add a whole ApiGateway to my CloudFormation template just to change the domain or is there is an easier way?
My domain is in Route53 and I have a certificate for it in ACM.
My template is currently as follows:
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: An AWS Serverless Application that uses the ASP.NET Core framework running in Amazon Lambda.
Resources:
ExampleWebApi:
Type: AWS::Serverless::Function
Properties:
Handler: Example.WebApi::Example.WebApi.LambdaEntryPoint::FunctionHandlerAsync
Runtime: dotnetcore2.1
CodeUri: ''
MemorySize: 128
Timeout: 10
Role: null
Policies:
- AWSLambdaFullAccess
Environment:
Variables: {}
Events:
PutResource:
Type: Api
Properties:
Path: "/{proxy+}"
Method: ANY
Yes, you need to use API Gateway in order to define a custom domain for a lambda function.
I'm finding it hard to understand the difference between SAM template and Cloudformation template. I know that SAM template can be used to define Serverless Applications like Lambda, but how does that make it different from Cloudformation template? Is the syntax different? I can still specify the Lambda definitions in cloudformation template. So, my question is why should I care about SAM? Won't knowing about just cloud formation template be sufficient?
From CloudFormation's perspective, SAM is a transform. Meaning: SAM templates are syntactically equivalent, but they allow you to define your serverless app with more brevity. The SAM template eventually gets expanded into full CFN behind the scenes. If you already know CFN, but want to write less YAML code, SAM may be beneficial to you. The idea is to reduce your effort.
SAM templates are a superset of Cloudformation. Any Cloudformation template can be run through SAM unchanged, and it will work. SAM supports all the types available in Cloudformation templates, so you can think of SAM as "CloudFormation++".
However, SAM also gives you additional "transforms" that allow you to define certain concepts succinctly, and SAM will figure out what you mean and fill in the the missing pieces to create a full, expanded, legal Cloudformation template.
Example: For SAM (and Serverless Framework) users, who deal mostly in Lambda functions, one of the more most useful transforms is the Events property on the Lambda function -- SAM will add all the objects needs to access that function through an API path in API Gateway.
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: HelloWorldFunction
Handler: app.lambdaHandler
Runtime: nodejs12.x
Events: # <--- "Events" property is not a real Cloudformation Lambda property
HelloWorld:
Type: Api
Properties:
Path: /hello
Method: get
The SAM template snippet shown above gets transformed/expanded into several API Gateway objects (a RestApi, a deployment, and a stage). The AWS::Serverless::Function type used in this snippet is not a real Cloudformation type -- you won't find it in the docs. SAM expands it into a Cloudformation template containing a AWS::Lambda::Function object and several different AWS::ApiGateway::* objects that Cloudformation understands.
To give you an idea of how much manual coding this saves you, here's what the expanded version of the above SAM template looks like as a full Cloudformation template:
Resources:
HelloWorldFunctionHelloWorldPermissionProd:
Type: AWS::Lambda::Permission
Properties:
Action: lambda:InvokeFunction
Principal: apigateway.amazonaws.com
FunctionName:
Ref: HelloWorldFunction
SourceArn:
Fn::Sub:
- arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${__ApiId__}/${__Stage__}/GET/hello
- __Stage__: "*"
__ApiId__:
Ref: ServerlessRestApi
HelloWorldFunctionRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Action:
- sts:AssumeRole
Effect: Allow
Principal:
Service:
- lambda.amazonaws.com
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
Tags:
- Value: SAM
Key: lambda:createdBy
ServerlessRestApiProdStage:
Type: AWS::ApiGateway::Stage
Properties:
DeploymentId:
Ref: ServerlessRestApiDeployment_NNN
RestApiId:
Ref: ServerlessRestApi
StageName: Prod
ServerlessRestApiDeployment_NNN:
Type: AWS::ApiGateway::Deployment
Properties:
RestApiId:
Ref: ServerlessRestApi
Description: 'RestApi deployment id: ???'
StageName: Stage
ServerlessRestApi:
Type: AWS::ApiGateway::RestApi
Properties:
Body:
info:
version: '1.0'
title:
Ref: AWS::StackName
paths:
"/hello":
get:
x-amazon-apigateway-integration:
httpMethod: POST
type: aws_proxy
uri:
Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${HelloWorldFunction.Arn}/invocations
responses: {}
swagger: '2.0'
HelloWorldFunction:
Type: AWS::Lambda::Function
Properties:
Code:
S3Bucket: aws-sam-cli-managed-default-samclisourcebucket-???
S3Key: temp/???
Tags:
- Value: SAM
Key: lambda:createdBy
Handler: app.lambdaHandler
Role:
Fn::GetAtt:
- HelloWorldFunctionRole
- Arn
Timeout: 3
Runtime: nodejs12.x
Previously, if you were authoring pure Cloudformation, you would have had to code all this by hand, over and over, for each API Gateway endpoint that you wanted to create. Now, with a SAM template, you define the API as an "Event" property of the Lambda function, and SAM (or Serverless Framework) takes care of the drudgery.
In the old days, when we had to do all this by hand, it totally sucked. But now, everything is glorious again.
Like #Luis Colon said, SAM is a transform. What that means, is that at the top of a SAM Template there is a Transform statement that lets CloudFormation know to run an intrinsic function, Transform, on this SAM template to turn it into a CloudFormation template. So, all SAM Templates will eventually be converted into CF templates, but for the end-user in most cases it is easier to just use the SAM template. For instance, for a simple application with Lambdas triggered by a new API you're creating, the SAM template will let you accomplish this in fewer lines than CloudFormation.
To extend this, the Serverless Framework behaves similarly. Serverless is designed to work across platforms (AWS, Azure, etc.). It's syntax looks very similar to SAM, and it too converts the template into the target platform's (ie. AWS) fuller version of the template (ie. CloudFormation template).
You can imagine SAM as an extended form of CloudFormation. SAM makes Serverless/Lambda deployments easier.
Even CloudFormation can deploy lambda scripts using inline scripts but it has a limitation of 4096 characters and you cannot pack custom dependencies, python libraries.
So to make Lambda/Serverless deployments easy SAM is used. SAM is a CLI tool. You cannot find SAM in AWS Console.
In case of python deployment, sam will read the requirements.txt file build a package, and will deploy the package when you wish to sam deploy
So at the end of the day you can write as much lengthy Lambda Code, use as many libraries you want and even import your custom libraries i.e. complete flexibility.
I'm trying to deploy AWS Lambda function by using SAM.
What I want to do is to update exsiting lambda function by deploying local source code.
In order to do that, I specified the existing lambda function name as 'FunctionName' in template.yaml like below.
However, 'FunctionName' does only support for creating new function, not updating to existing function.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html#cfn-lambda-function-functionname
Are there any ways to specify Function Name in SAM in order to update lambda function?
[template.yaml]
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
HelloWorld:
Type: 'AWS::Serverless::Function'
Properties:
FunctionName: 'hello_world'
Description: ''
Handler: index.handler
MemorySize: 256
Role: 'arn:aws:iam::368834739507:role/lambda_basic_execution'
Runtime: nodejs6.10
Timeout: 120
Using SAM (and/or CloudFormation), you cannot update existing resources.
SAM (and CloudFormation) create and manage their own resources. All resources specified in the template are going to be created when the stack is created. They cannot be "taken over".
Instead, you should allow SAM (or CloudFormation) to create the Lambda function for you, then update users to reference the new function. After that, you can update your code using SAM.
I'm trying the Create Your Own Serverless Application and I see that the name of the function is specified in the YAML template but when it gets deployed it creates a lambda with a composite name based on:
CloudFormation stack + Lambda function + Some Id.
My questions is: Is there a way to override the name of the function when using AWS SAM?
Thanks
Yes there is, take a look at https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
You need the FunctionName parameter in your YAML.
Similar to the following:
AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Resources:
samPocFunction:
Type: AWS::Serverless::Function
Properties:
FunctionName: samPoc
Description: This is my SAM POC function
Runtime: python2.7
CodeUri: ./functions/mycode
Handler: handler.handler
MemorySize: 128
Timeout: 3