Define Your Lambda Target Infrastructure
Once you've added a Lambda Service to your Application, you can define Environments where your Service can be deployed. Within an Environment, you specify the following in an Infrastructure Definition:
- The Lambda Service that contains your functions zip file and functions specs. (Set up in Add Lambda Functions.)
- A deployment type. In this case, Lambda.
- The AWS Cloud Provider you set up in Connect to AWS for Lambda Deployments.
An Environment can be a Dev, QA, Production, or other Environment. You can deploy one or many Services to each Environment by creating an Infrastructure Definition in the Environment for each Service.
In this topic:
- Before You Begin
- Step 1: Create an Environment
- Step 2: Define the Lambda Infrastructure
- Option: Provision the Lambda Infrastructure
- Option: Override Service Settings
- Next Steps
Before You Begin
Step 1: Create an Environment
The following procedure creates an Environment for the Lambda Service type, as set up in Add Lambda Functions.
- In your Harness Application, click Environments. The Environments page appears.
- Click Add Environment. The Environment dialog appears.
- In Name, enter a name that describes the deployment environment, for example, Lambda.
- In Environment Type, select Non-Production.
- Click SUBMIT. The new Environment page appears.
Step 2: Define the Lambda Infrastructure
You must define one or more Infrastructure Definitions for the Environment.
A Harness Infrastructure Definition defines the AWS VPC, subnets, and security groups to use for the Lambda deployment.
To add the Infrastructure Definition:
- In the Harness Environment, click Add Infrastructure Definition. The Infrastructure Definition dialog appears.The Infrastructure Definition dialog appears.
- Enter a Name that will identify this Infrastructure Definition when you add it to a Workflow.
- In Cloud Provider Type, select Amazon Web Services.
- In Deployment Type, select AWS Lambda. This expands the Infrastructure Definition dialog to look something like this:
- Select Use Already Provisioned Infrastructure, and follow the Define a Provisioned Infrastructure steps below.
Define a Provisioned Infrastructure
The Infrastructure Definition dialog's lower section defines settings similar to the
‑‑vpc-config options in the
aws lambda create-function command. For example:
$ aws lambda create-function --function-name ExampleApp-aws-lambda-Lambda-my-function \
--runtime nodejs8.10 --handler index.handler --zip-file lambda/function.zip \
--role execution-role-arn \
To fill out the Infrastructure Definition dialog's lower section:
- In Cloud Provider, select the AWS Cloud Provider you added in Connect to AWS for Lambda Deployments.
- In IAM Role, select IAM role that AWS Lambda assumes when it executes your function.
- In Region, select the AWS region where your function will be used.
- In VPC, select the virtual private cloud to which the function will connect in your account.
- In Subnets, select the subnet IDs for the subnets (within the VPC) where the Lambda function will access resources. AWS recommends that you choose at least two subnets for Lambda to run your functions in high availability mode.
- In Security Groups, select the security group ID(s) for the Lambda function. When you set a VPC for your function to access, your Lambda function loses default Internet access. If you require external Internet access for your function, make sure that your security group allows outbound connections, and that your VPC has a NAT gateway.
- Enable Scope to Specific Services, and use the adjacent drop-down to select the Harness Lambda Service you created in Add Lambda Functions.
When you are done, the dialog will look something like this:
- Click Submit. The new Infrastructure Definition is added to the Harness environment.
Option: Provision the Lambda Infrastructure
With Harness, you can use a CloudFormation template to provision the Lambda infrastructure. For more information, see Map an AWS Lambda Infrastructure.
Option: Override Service Settings
Your Environment can overwrite Service Config Variables, Config Files, and other settings. This enables you to maintain a Service's native settings, but change them when the Service is used with this Environment.
For more information, see Override a Service Configuration.