Another day, another Apex release. This time almost entirely brought to you by Maciej!
First is a small program called apex-shell, which is not actually part of core, but it allows you to execute commands in AWS Lambda and respond with the results in an interactive REPL.
This is useful to verify AWS IAM role permissions, inspecting environment variables, or inspecting binaries available to AWS Lambda functions.
This is just the beginning for (optional) Terraform integration, however we now have `apex infra` which delegates commands to Terraform. We wrap Terraform in order to provide the Lambda function ARNs, as well as providing environment support in the near future.
$ apex infra plan
Is equivalent to:
$ (cd infrastructure && terraform plan -var lambda_function_foo=ARN -var -var lambda_function_bar=ARN)
Later it will likely be equivalent to the following when environments are fully supported throughout Apex.
$ (cd infrastructure/<env> && terraform plan -var lambda_function_foo=ARN -var -var lambda_function_bar=ARN)
Later we’ll have more robust Terraform integration, as well as higher level abstractions or generators for common tasks like tying together functions via SNS, Kinesis, SQS, and so on.
The new `apex init` command allows you to generate a new Apex project with interactive prompts. Let’s run through a quick example with the Terraform support.
Enter the project name and description:
View the Terraform plan to see what it’ll create — in this case just a Lambda function role with access to CloudWatch logs.
Apply the changes to create the role:
Deploy your Apex Lambda function:
Now invoke it!
Zip files are now compressed, yielding much smaller files for faster deploys, hurrah!
We now always zero mtime, specifically for transpiler use-cases like CoffeeScript or Babel. This ensures that `apex deploy` will only deploy zips which have different content than the current AWS Lambda version.
Previously doing something like `coffeescript < in.coffee > out.js` would yield a different checksum, triggering a deploy each time.
We’ve added a number of new examples, as well as normalizing the ones that were previously there.
When using Node.js in Lambda functions it is useful to use a bundler, which effectively removes the need to run `npm install --production` before a deploy, as only the dependencies used will be compiled down.
See the browserify example here.
For the same reason as mentioned above, Webpack is useful to trim down your functions for deploy.
See the webpack example here.
One of the great things about writing tools in Go is binary distribution. This makes it very easy to `curl` Apex into a continuous integration container for continuous deployments. Thomas added an example for CD with Circle.
Maciej added VPC support, as AWS Lambda functions may now be run in your own VPC subnet(s). See the Project documentation for details.
Old Function Cleanup
Old functions are now removed automatically, by default Apex will retain 10 versions, however you may specify this number. This is because AWS has a hard limit on the amount of space used for all versions across your account, while large it is possible to hit it.
Additional changes or fixes:
- add one-liner install script
- add pattern parity with .gitignore for .apexignore
- add “default” AWS profile support
- change rollback version to flag instead of an argument
- change golang build hook to use “*.go” instead of “main.go”
- fix AWS credentials loading on Windows
As always to grab the latest update:
$ apex upgrade