Configuring Lambda application
Deploying a Lambda application requires a function.yaml
file placing inside the application directory. That file contains values to be used to deploy Lambda function on your AWS cluster.
Currently, Piped supports deploying all types of Lambda deployment packages:
- container images (called container image as Lambda function)
.zip
file archives (which stored in AWS S3)
Besides, Piped also supports deploying your Lambda function directly from the function source code which is stored in a remote git repository.
Deploy container image as Lambda function
A sample function.yaml
file for container image as Lambda function used deployment as follows:
apiVersion: pipecd.dev/v1beta1
kind: LambdaFunction
spec:
name: SimpleFunction
image: ecr.ap-northeast-1.amazonaws.com/lambda-test:v0.0.1
role: arn:aws:iam::76xxxxxxx:role/lambda-role
# The amount of memory available to the Lambda application
# at runtime. The value can be any multiple of 1 MB.
memory: 512
# Timeout of the Lambda application, the value must
# in between 1 to 900 seconds.
timeout: 30
tags:
app: simple
environments:
FOO: bar
# ephemeralStorage is optional value. If you define a ephemeral storage to lambda, you can
# use this field. The value must be in between 512 to 10240 MB.
ephemeralStorage:
size: 512
# vpcConfig is optional value. If you define a vpc configuration to lambda, you can
# use this field.
vpcConfig:
securityGroupIds:
- sg-01234
- sg-56789
subnetIds:
- subnet-01234
- subnet-56789
Except the tags
and the environments
field, all others are required fields for the deployment to run.
The role
value represents the service role (for your Lambda function to run), not for Piped agent to deploy your Lambda application. To be able to pull container images from AWS ECR, besides policies to run as usual, you need to add Lambda.ElasticContainerRegistry
read permission to your Lambda function service role.
The environments
field represents environment variables that can be accessed by your Lambda application at runtime. In case of no value set for this field, all environment variables for the deploying Lambda application will be revoked, so make sure you set all currently required environment variables of your running Lambda application on function.yaml
if you migrate your app to PipeCD deployment.
Deploy .zip file archives as Lambda function
It’s recommended to use container image as Lambda function due to its simplicity, but as mentioned above, below is a sample function.yaml
file for Lambda which uses zip packing source code stored in AWS S3.
apiVersion: pipecd.dev/v1beta1
kind: LambdaFunction
spec:
name: SimpleZipPackingS3Function
role: arn:aws:iam::76xxxxxxx:role/lambda-role
# --- 3 next lines allow Piped to determine your Lambda function code stored in AWS S3.
s3Bucket: pipecd-sample-lambda
s3Key: pipecd-sample-src
s3ObjectVersion: 1pTK9_v0Kd7I8Sk4n6abzCL
# ---
handler: app.lambdaHandler
runtime: nodejs14.x
memory: 512
timeout: 30
environments:
FOO: bar
tags:
app: simple-zip-s3
Value for the runtime
field should be listed in AWS Lambda runtimes official docs. All other fields setting are remained as in the case of using container image as Lambda function pattern.
Deploy source code directly as Lambda function
In case you don’t have a separated CI pipeline that provides artifacts (such as container image, built zip files) as its outputs and want to set up a simple pipeline to deploy the Lambda function directly from your source code, this deployment package is for you.
apiVersion: pipecd.dev/v1beta1
kind: LambdaFunction
spec:
name: SimpleCanaryZipFunction
role: arn:aws:iam::76xxxxxxx:role/lambda-role
# source configuration use to determine the source code of your Lambda function.
source:
# git remote address where the source code is placing.
git: git@github.com:username/lambda-function-code.git
# the commit SHA or tag for remote git. Use branch name means you will always use
# the latest code of that branch as Lambda function code which is NOT recommended.
ref: dede7cdea5bbd3fdbcc4674bfcd2b2f9e0579603
# relative path from the repository root directory to the function code directory.
path: hello-world
handler: app.lambdaHandler
runtime: nodejs14.x
memory: 128
timeout: 5
tags:
app: canary-zip
All other fields setting are remained as in the case of using .zip archives as Lambda function pattern.
Quick sync
By default, when the pipeline was not specified, PipeCD triggers a quick sync deployment for the merged pull request. Quick sync for a Lambda deployment will roll out the new version and switch all traffic to it.
Sync with the specified pipeline
The pipeline field in the application configuration is used to customize the way to do the deployment. You can add a manual approval before routing traffic to the new version or add an analysis stage the do some smoke tests against the new version before allowing them to receive the real traffic.
These are the provided stages for Lambda application you can use to build your pipeline:
LAMBDA_CANARY_ROLLOUT
- deploy workloads of the new version, but it is still receiving no traffic.
LAMBDA_PROMOTE
- promote the new version to receive an amount of traffic.
and other common stages:
WAIT
WAIT_APPROVAL
ANALYSIS
See the description of each stage at Customize application deployment.
Here is an example that rolls out the new version gradually:
apiVersion: pipecd.dev/v1beta1
kind: LambdaApp
spec:
pipeline:
stages:
# Deploy workloads of the new version.
# But this is still receiving no traffic.
- name: LAMBDA_CANARY_ROLLOUT
# Promote new version to receive 10% of traffic.
- name: LAMBDA_PROMOTE
with:
percent: 10
- name: WAIT
with:
duration: 10m
# Promote new version to receive 50% of traffic.
- name: LAMBDA_PROMOTE
with:
percent: 50
- name: WAIT
with:
duration: 10m
# Promote new version to receive all traffic.
- name: LAMBDA_PROMOTE
with:
percent: 100
Reference
See Configuration Reference for the full configuration.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.