While being a wonderful idea AWS Lambda lacks in terms of continous devlivery tooling and configuration externalisation. In current state Lambda offers us the same codeline and aliases, but there is no way to create a notion of 12Factor app configuration. We could either hardcode (supposedly secret) configuration into lambda code, or store it in some external location (S3), but it brings issues in terms of env specific setup, and managing it along with software releases.
This is an attempt to make configuration and pipelines management of lambdas a little bit less painful. The idea is to use Heroku dyno as a basis for lambda creation. Here is how the whole thing works:
deployprocess type in
heroku run deploy, that does:
env.propertiesfile is being added to lambda artifact (this file should be used in lambda code to retrieve configuration)
$ heroku buildpacks:set https://github.com/kubek2k/heroku-aws-lambda-buildpack
_LAMBDA_FUNCTION_ARN- the ARN of lambda that is going to be deployed to
_AWS_ACCESS_KEY_ID- AWS access key id used for deployment
_AWS_SECRET_ACCESS_KEY- AWS secret key used for deployment
_AWS_DEFAULT_REGION- AWS region to be used
All env variables starting with
_ sign are not injected into
URGENT: The user owning the AWS access key ☝️ should have permissions to update function code (
_LAMBDA_JAR_FILE- path to .jar artifact that is a product of mvn invocation (normally it should be something like "target/lambda-with-dependencies.jar")
$ git push heroku master
$ heroku run deploy
Pipelines should work out of the box, but after each
promote you have to remember to invoke
heroku run deploy on application that was promoted to, so that changes are reflected on AWS (see What could be done better ).
As well as promotion, configuration changes require
heroku run deploy to be ran after (see What could be done better ).
First of all - this solution shouldn't be treated as neither something permanent nor final.
heroku run deployafter each deploy/configuration change/promotion. This is something that is really hard to automate within heroku. One way to somehow deal with it is to scale deploy worker to 1
Freedyno - it will cause the deploy to be run multiple times within the day, but its
Copy the snippet above into CLI.