I am using quarkus with quarkus-amazon-lambda.
In the ./src/main/resources/application.properties I have following defined
quarkus.lambda.handler=mainHandler
aws.region.default=eu-central-1
aws.region=${AWS_REGION:${aws.region.default}}
And when I do "./gradlew clean build" it does not generate the required definition in "./build/sam.jvm.yaml"
So I need to manually add the missing definition of the environment variables to the .yaml:
Resources:
MyLambdaFunction:
Type: AWS::Serverless::Function
Properties:
Handler: io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest
Runtime: java11
CodeUri: function.zip
MemorySize: 256
Timeout: 15
Policies: AWSLambdaBasicExecutionRole
# ---this part is missing---
Environment:
Variables:
AWS_REGION:
I cannot find where else I need to define the expected environment variables so that it will be generated.
there are "quarkus.aws.*.region" properties for individual services, look for 'region' on https://quarkus.io/guides/all-config
If none match open a issue with a reproducer.
Related
I have Serverless Framework function for AWS Lambda. I have secrets in AWS Secrets Manager (SSM) Parameter Store and other environment variables in local .yml files, for separate deployments (dev, stg, prod).
How can I use environment variables from both file and SSM?
Only secrets work:
functions:
kinesisEvents:
handler: kinesis_events_processing.lambda_handler
name: kinesis-events-${self:provider.stage}
package: {}
maximumRetryAttempts: 2
events:
- stream:
type: kinesis
... # omitted a few things
environment:
DB_PASSWORD: ${ssm:/${self:provider.stage}/db/db_password}
API_KEY: ${ssm:/${self:provider.stage}/api/internal_api_key}
And only file also works:
functions:
kinesisEvents:
... # as above
environment:
${file(${self:provider.stage}.yml):}
But how can I combine those, so I have all those variables set as env vars in final deployment? I tried this, but it does not work and throws error during deploy:
functions:
kinesisEvents:
... # as above
environment:
DB_PASSWORD: ${ssm:/${self:provider.stage}/db/db_password}
API_KEY: ${ssm:/${self:provider.stage}/api/internal_api_key}
${file(${self:provider.stage}.yml):}
I found answers here, here and here. Basically, Serverless Framework has no particular support for this feature. However, it supports extended YAML syntax, which has anchor and dictionary merging capabilities.
So first I unpack the env vars from YAML config file, at the top of the file, and anchor it with &env_vars (like a variable for referencing, but in YAML):
env_vars: &env_vars
${file(${self:provider.stage}.yml):}
functions:
...
And then I use it, unpacking this dictionary:
environment:
<<: *env_vars
DB_PASSWORD: ${ssm:/${self:provider.stage}/db/db_password}
API_KEY: ${ssm:/${self:provider.stage}/api/internal_api_key}
I would like to build .NET HTTP API using aws lambdas. These lambdas will be called by UI and some other systems via api gateway. Obviously in local environment I would like to run/debug these.
What I have tried:
a) Using the mock tool that comes with AWS Visual Studio templates. You can call individual lambdas but I couldn't figure out how I can call them from e.g. postman using normal rest calls. I don't know how mock tool makes those calls as chrome/firefox doesn't show them.
b) Using sam local start-api. Here is what I did:
sam --version
SAM CLI, version 1.22.0
sam init (choose aws quick start template, package type Image and amazon/dotnet5.0-base as base image)
I can build the solution with sam build, run it wit sam local start-api and I can browse to http://localhost:3000/hello and it works. Problem is that I would need to do build in VS + do those steps every time I change code. Also no easy way to attach debugger.
So what is the recommended way to do this? I know you can run whole .NET web api inside lambda but that doesn't sound like a good technical solution. I am assuming I am not the first person building HTTP api using lambdas.
It might be worth considering running a lambda-like environment in Docker.
While including the dotnet tools you need might not be feasable in actual Lambda, It might be feasible to either include them in a Docker image, or bind mounted to a docker container. These images from lambci can help with that: https://hub.docker.com/r/lambci/lambda/
You can use sam local
https://github.com/thoeni/aws-sam-local
Create API with API gateway example
Resources:
ApiGatewayToLambdaRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Statement:
- Action: ['sts:AssumeRole']
Effect: Allow
Principal:
Service: ['apigateway.amazonaws.com']
Version: '2012-10-17'
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AWSLambdaRole
- arn:aws:iam::aws:policy/service-role/AmazonAPIGatewayPushToCloudWatchLogs
ApiGateway:
Type: AWS::Serverless::Api
Properties:
StageName: test
EndpointConfiguration: REGIONAL
DefinitionBody:
swagger: "2.0"
info:
title: "TestAPI"
description: TestAPI description in Markdown.
paths:
/create:
post:
x-amazon-apigateway-integration:
uri:
!Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${MyLambda.Arn}/invocations
credentials: !GetAtt ApiGatewayToLambdaRole.Arn
responses: {}
httpMethod: POST
type: aws
x-amazon-apigateway-request-validators:
Validate query string parameters and headers:
validateRequestParameters: true
validateRequestBody: false
LambdaRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Statement:
- Action: ['sts:AssumeRole']
Effect: Allow
Principal:
Service: [lambda.amazonaws.com]
Version: '2012-10-17'
Path: /
Policies:
- PolicyName: CodeBuildAccess
PolicyDocument:
Version: '2012-10-17'
Statement:
- Action:
- logs:*
- lambda:*
- ec2:CreateNetworkInterface
- ec2:DescribeNetworkInterfaces
- ec2:DeleteNetworkInterface
Effect: Allow
Resource: "*"
Version: '2012-10-17'
MyLambda:
Type: AWS::Serverless::Function
Properties:
Role: !GetAtt LambdaRole.Arn
Handler: myfunctionname.lambda_handler
CodeUri: ./src/myfunctionname
Events:
SCAPIGateway:
Type: Api
Properties:
RestApiId: !Ref ApiGateway
Path: /create
Method: POST
...
Build :
Time sam build --use-container --template backend/template.yam
Invoke Lambda Locally:
The command to invoke Lambda locally is sam local invoke and -e flag is used to specify the path to the Lambda event.
$ sam local invoke -e event.json
When it is run, it will look something like this:
$ sam local invoke MyLambda -e event.json
2021-04-20 11:11:09 Invoking index.handler
2021-04-20 11:11:09 Found credentials in shared credentials file:
~/.aws/credentials
https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-using-invoke.html
https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-using-start-api.html
https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-using-debugging.html
https://github.com/ashiina/lambda-local
In my previous application, I work with a serverless framework but now I want to use sam template.
when I used serverless I include secret.json in one section and used multiple places like this way ${self:custom.secrets.AWS_ID}.
My sample code:
custom:
secrets: ${file(secrets.json)}
tableName: ${self:custom.secrets.DB_TABLE_NAME}
provider:
name: aws
runtime: nodejs12.x
environment:
JWT_SECRET: ${self:custom.secrets.JWT_SECRET}
AWS_ID: ${self:custom.secrets.AWS_ID}
DB_TABLE_NAME: ${self:custom.secrets.DB_TABLE_NAME}
Now my question is, how can I include secret.json and use multiple places in sam template.yml file
My goal is allow several independent lambda resources (microservices) to share a common custom domain for test environment. Using the below template, deploying microservice #1 went off without issue. However, when deploying microservice #2, CloudFormation fails and rolls back because the domain name is assigned to microservice #1.
Surely it must be possible to share a common custom domain among several microservices with unique paths?
Service #1 template.yaml
Resources:
ApiGatewayApi:
Type: AWS::Serverless::Api
Properties:
StageName: !Sub ${apiGatewayStageName}
DefinitionBody:
swagger: "2.0"
info:
title: !Sub ${functionName}
paths:
"/service_one":
post:
responses: {}
x-amazon-apigateway-integration:
uri: !Sub "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${functionName}:live/invocations"
httpMethod: POST
type: aws_proxy
ApiGatewayCustomDomainName:
Type: AWS::ApiGateway::DomainName
Properties:
CertificateArn: !Sub "arn:aws:acm:${AWS::Region}:${AWS::AccountId}:certificate/${apiGatewayCDNCertificateId}"
DomainName: !Sub "${envName}.${apiGatewayCustomDomainNameSuffix}"
DependsOn:
- "LogsSubscriptionFilter"
- "ApiGatewayApi"
ApiGatewayBasePathMapping:
Type: AWS::ApiGateway::BasePathMapping
Properties:
DomainName: !Ref ApiGatewayCustomDomainName
RestApiId: !Ref ApiGatewayApi
Stage: !Ref apiGatewayStageName
DependsOn: "ApiGatewayCustomDomainName"
The Service #2 template is the same, except with a different path (.e.g. /service_two.
Worked with AWS support to get to the bottom of this one. In its current form (May 2018), if you want separate SAM templates for each lambda for deployment reasons, but have a shared API Gateway resource for those lambdas, then you must have a separate dedicated API Gateway SAM template. Additionally, the Events parameter in AWS::Serverless::Function must be excluded in favor of paths definitions in AWS::Serverless::Api.
Lastly, the AWS::Serverless::Function(s) must be exported under Output and then imported by the AWS::Serverless::Api resource.
I'm using SAM to deploy a Lambda function and make it callable over HTTP with via API Gateway using roughly this template snipplet:
MyFunction:
Type: AWS::Serverless::Function
Properties:
…
Events:
MyApi:
Type: Api
Properties:
Path: /
Method: any
This works, but it creates an API stage called "Prod", which has to be used as a prefix for all URLs. I don't want my URLs to be "https://something/Prod/foo", I want them to be "https://something/v1/foo", i.e. something that I choose.
How do I change the name of the stage?
I have tried declaring the API as a separate resource, and used the StageName property to set the name of the stage, however, that requires me to also set DefinitionBody, and that seems to be a deep rabbit hole.
MyFunction:
Type: AWS::Serverless::Function
Properties:
…
Events:
MyApi:
Type: Api
Properties:
Path: /
Method: any
RestApiId: !Ref MyApi
MyApi:
Type: AWS::Serverless::Api
Properties:
StageName: v1
DefinitionBody:
???
I know that ??? in the example above is supposed to be Swagger, but I would prefer to not have to write anything there, the template is getting verbose enough at is. Since I don't have to write this part if I can just live with the stage name "Prod" it seems to me that there must be a way to avoid having to write anything there and just set the stage name.
How can I change the name of the stage without having to write a lot of template code and/or Swagger?
SAM Version 1.7.0 removed the need to specify a DefinitionBody or DefinitionUri so you should now be able to do exactly what you mention on your second example without having to include a DefinitionBody:
MyFunction:
Type: AWS::Serverless::Function
Properties:
…
Events:
MyApi:
Type: Api
Properties:
Path: /
Method: any
RestApiId: !Ref MyApi
MyApi:
Type: AWS::Serverless::Api
Properties:
StageName: v1