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:promotenow 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 100To follow logs produced by all lambda invocations:
$ lambdoku logs -f To invoke lambda to test if it works, you can use:
lambdoku invokeYou can also pass parameters to the function invocation:
lambdoku invoke '{"param1": "value1" ... }'-
Prerequisite: AWS Environment variables
- Set required variables:
AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEYAWS_DEFAULT_REGION
- ... or use the
~/.aws/configfile to configure aws-sdk by settingAWS_SDK_LOAD_CONFIGenv variable to something truthy
- Set required variables:
-
Prerequisite: Node and npm (ES6 support required)
- On OS X with homebrew:
brew update && brew install node
- On OS X with homebrew:
-
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
rollbackandpromoteoperations retrieve code from AWS and uploads it in place of current one - pipelines use special env variable (please 🙏 don't use it :))
DOWNSTREAM_LAMBDASto 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