Skip to content

node-lambda.md

Latest commit

 

History

History
87 lines (62 loc) · 3.35 KB

node-lambda.md

File metadata and controls

87 lines (62 loc) · 3.35 KB

Deploying Lambdas with node-lambda

We MUST use the node-lambda (github/npm) tool to deploy lambdas.
node-lambda's README is a good primer on its commands & configuration files.

Because of a wonky interaction between the aws-sdk and dotenv node modules. Developers MUST NOT have a [default] environment in their files located in ./.aws/. See this PR-38 for a full discussion.

Standards

  • Lambdas SHOULD get their description from the 'description' attribute of package.json, not from the DESCRIPTION variable in .env.

  • Each app MUST bring in its own version of node-lambda as a devDependency. It MUST NOT rely on a globally installed node-lambda.

  • Deployments MUST be done through pre-baked commands in the 'scripts' block of package.json that follow the following rules:

    • The command will be named 'deploy-[ENVIRONMENT-NAME]'

    • The command will pass environment-specific info as flags to the node-lambda deploy command.

    • The command uses the locally packaged node-lambda

    • The command knows which AWS account / credentials to use via the --profile flag

    • Because we don't put secrets in .env (IAM credentials get read via the --profile flag), we MUST keep .env in source control.

    • Use the -e flag for environment, which appends the environment name to the name of the function created.

  • That is to say, .env MUST NOT contain tier / environment specific configuration. Those must be passed in via flags to node-lambda deploy.

Examples

A package.json that looks like:

{ //...snip!
  'scripts': {
    'deploy-production': './node_modules/.bin/node-lambda deploy -e production -f ./config/prod.env -S config/event_sources_prod.json -b subnet-id1,subnet-id2 -g sg-id --role arn:aws:iam::[some-id]:role/[rolename] --profile our-profile-name'
  },
  // ...snip!
}

Allows you to have a .env, in source control that looks like:

AWS_REGION=us-east-1
AWS_FUNCTION_NAME=MyFunctionName
AWS_HANDLER=index.handler
AWS_MEMORY_SIZE=768
AWS_TIMEOUT=30
AWS_RUNTIME=nodejs6.10
EXCLUDE_GLOBS="event.json"
PACKAGE_DIRECTORY=build

The above is much slimmer than the boilerplate .env generated by node-lambda setup and allows:

  • .env to define stage/environment independent variables.

  • pass environment specific variables as flags to the node-lambda deploy calls in scripts.

  • Finally - since the only secrets are IAM key/secret & those are brought in via the --profile flag, .env can be in source control.

An example of what config/event_sources_prod.json might look like:

{
  "EventSourceMappings": [
    {
      "EventSourceArn": "arn:aws:kinesis:us-east-1:[alongid]:stream/[streamname]",
      "StartingPosition": "LATEST",
      "BatchSize": 50,
      "Enabled": true
    }
  ]
}

Finally, each repo MUST contain an example environment-name.env file (-f flag) that contains names of the RUN TIME env vars and explanatory text as its values. The README MUST include instructions on putting those config files in their appropriate place (e.g. running cp or some other command to move the example into a git ignored place)