This article explains updating AWS Lambda configuration using a Jenkinsfile, focusing on environment variables via the AWS CLI for streamlined deployment.
In this article, we explain how to update the AWS Lambda configuration using a Jenkinsfile. We focus on updating environment variables through the AWS Lambda CLI rather than the console, streamlining the deployment process.
The AWS CLI command for updating Lambda function configuration is documented in the AWS CLI Command Reference. One key option in this command is “environment,” which accepts environment variables as key-value pairs. Below is an overview of the command syntax:
The environment variables are provided in JSON format. For more details on configuring Lambda functions using other methods (e.g., AWS SAM, SDKs, or the console), review the AWS documentation.
Here is an example snippet from an AWS SAM template showing a basic function configuration. Although our focus is on using the CLI, this template illustrates how a function is defined:
Copy
Ask AI
AWSTemplateFormatVersion: '2010-09-09'Transform: AWS::Serverless-2016-10-31Description: An AWS Serverless Application Model template describing your functionResources: my-function: Type: AWS::Serverless::Function Properties: CodeUri: '' Description: '' MemorySize: 128
Next, update your Jenkinsfile to reuse environment variables like Mongo username, Mongo password, and the Mongo URI. Below is an example snippet from the Jenkinsfile:
In the Jenkinsfile, the Lambda S3 upload and deploy stage proceeds in two steps: updating the function code and then updating the configuration using the AWS CLI. Here’s how the shell scripts are organized:
Zip the Application Files
Copy
Ask AI
sh """zip -qr solar-system-lambda-$BUILD_ID.zip app* package* index.html node*ls -ltr solar-system-lambda-$BUILD_ID.zip"""
In these scripts, environment variables from Jenkins are dynamically passed to the Lambda configuration. The JSON syntax ensures that AWS Lambda receives the key-value pairs in the expected format.
During the build process, you may encounter dependency issues. For example, the pipeline might initially fail due to a detected critical vulnerability in the “i18n” dependency. To temporarily bypass this issue, you can modify the dependency scanning stage in the Jenkinsfile by setting the stopBuild flag to false.
It is best practice to resolve such vulnerabilities rather than bypassing them. Use the bypass only as a temporary measure.
Here is an example of the modified dependency scanning stage:
The AWS CLI output confirms that sensitive credentials are masked and that the updated environment variables are correctly applied. Subsequently, the function code is refreshed with:
Finally, you can visit the AWS Lambda console to verify that the environment variables appear as expected:
After testing, the application should no longer return an internal server error. When you access the application endpoint, the response should be:
Copy
Ask AI
{ "status": "live"}
This confirms that the Jenkinsfile successfully updates both the Lambda configuration (environment variables) and the application code. In future stages, you might add integration testing to directly invoke the Lambda function from the Jenkinsfile.
This article has demonstrated how to update the AWS Lambda configuration using the Jenkinsfile by leveraging the AWS CLI. By updating both the environment variables and function code, you ensure that changes are effectively deployed. For additional details, visit the AWS Lambda Documentation.Thank you for following along.