Heroku-like experience with AWS Lambdas.

$ lambdoku init <ARN-of-your-lambda-function>

this allows you to omit the -a param for all commands below

$ lambdoku push hello.zip

$ lambdoku config:set ONE=1 TWO=2

$ lambdoku config
ONE='1'
TWO='2'

$ lambdoku config:get ONE
ONE='1'

$ lambdoku releases
22 | Setting env variables AA | 2016-11-26T21:12:46.894+0000
21 | Unsetting env variables XY | 2016-11-26T21:10:04.302+0000
20 | Setting env variables BB,XY | 2016-11-26T20:57:57.340+0000
...

$ lambdoku rollback 18

$ lambdoku releases
23 | Rolling back to version 18 | 2016-11-26T21:35:45.952+0000
22 | Setting env variables AA | 2016-11-26T21:12:46.894+0000
21 | Unsetting env variables XY | 2016-11-26T21:10:04.302+0000
20 | Setting env variables BB,XY | 2016-11-26T20:57:57.340+0000
...

in the example ☝️ both code and configuration is rolled back from version 18.

(actually the main reason why lambdoku was created)

$ lambdoku init lambdaDev

$ lambdoku pipeline:add lambdaStage

$ lambdoku pipeline:add lambdaProd -a lambdaStage

$ lambdoku pipeline
lambdaStage

$ lambdoku pipeline:promote

now lambdaDev and lambdaStage have the same codebase. lambdaStage can be promoted to lambdaProd with command lambdoku downstream:promote -a lambdaStage.

To get 100 latest log lines from all lambda invocations:

$ lambdoku logs -n 100

To follow logs produced by all lambda invocations:

$ lambdoku logs -f 

To invoke lambda to test if it works, you can use:

lambdoku invoke

You can also pass parameters to the function invocation:

lambdoku invoke '{"param1": "value1" ... }'

1. Prerequisite: AWS Environment variables

   • Set required variables:
     • AWS_ACCESS_KEY_ID
     • AWS_SECRET_ACCESS_KEY
     • AWS_DEFAULT_REGION
   • ... or use the ~/.aws/config file to configure aws-sdk by setting AWS_SDK_LOAD_CONFIG env variable to something truthy

2. Prerequisite: Node and npm (ES6 support required)

   • On OS X with homebrew: brew update && brew install node

3. Then, simply:

   npm install -g lambdoku

• it's simply an abstraction layer over AWS Lambda API effectively invoking aws-sdk
• each change applied to lambda is finished with lambda version publication
• the rollback and promote operations retrieve code from AWS and uploads it in place of current one
• pipelines use special env variable (please 🙏 don't use it :)) DOWNSTREAM_LAMBDAS to the dowstreams

Due to the nature of AWS Lambda API most of the operations can't be considered atomic, like:

• the change in configuration has to first retrieve current configuration - which may be change in the meantime
• the rollback can be infected with change done in configuration in the 'meantime'
• the pipelines promote can be infected by changes done at the same time on downstream