Up 0.2.0 — Stack updates, cost metrics, deploy size and more
Hello! This is the next release of Apex Up, a tool for deploying serverless apps and apis written in Golang, Node.js, Python or others in seconds to your own AWS infrastructure.
If this is the first time hearing about it, you may want to check out the Introduction blog post first.
This version introduces some necessary features for real production applications, such as modifying resources, because things change :), let’s take a look!
A small but nice addition is cost metrics for your application, calculating how much was spent on the HTTP requests, Lambda invocations, and Lambda duration, which all contribute to the total cost.
In many cases this will simply be $0.00, so don’t be alarmed :). The total duration of time spent processing requests has also been added (“Duration (sum)”).
This release allows you to make changes to your stack resources. After tweaking your `up.json` configuration, running
up stack plan will create a CloudFormation change set, you’ll see how the change would be applied.
For example suppose you added a DNS zone and records, you’d see that they will be created, however running
up stack plan does not perform the changes. As mentioned in my initial post, this style of “infrastructure as code” is generally superior to CRUD-style commands, which are error-prone and cannot be reviewed.
If you were to remove a record, and modify one, you’ll see output like this:
By-design Up does not allow you to make changes to the stack without first previewing them, you’ll just receive an error.
Once previewed, you can apply the changes with:
up stack apply
This feature is still a work-in-progress — the output will be improved to display less ugly resource names, property changes (CloudFormation makes this non-trivial), support for named change-sets will be added, as well as the ability for a team member to review them easily!
Inspecting deployment size
A new command named
up build lets you generate the zip file used for deployment, and also allows you to quickly view which files are contributing the most to its size.
out.zip simply execute:
$ up build
Or if you’d prefer you can output to a specific file:
$ up build > /tmp/out.zip
--size flag will output a sorted list of the files included, letting you quickly see if any libraries you’re utilizing are problematic, this also helps highlight files which could be added to
.upignore for omission if they’re unnecessary in production.
Aside from refactoring, here are some smaller additions and fixes:
- add support for
~/.aws/configregion for profiles (thanks Francisco Guimarães)
- add support for configuring the proxy timeout (thanks Adam Syed)
- add ignoring of dotfiles by default (thanks Stephen Mathieson)
- add support for ensuring Up’s files (./main, etc) cannot be ignored (thanks Henry Snopek)
- add support for
**in ignore files
- add environment variables to hooks (access while building etc)
- add support for python requirements.txt
- add stage name validation
- add more examples, such as Node 8
- validate the size of zip before attempting to deploy
- validate stage name before attempting to deploy or copy url etc
- removed .npmignore support
- fix greedy default error page, add option to explicitly enable. Closes #233
- fix support for Windows (forcing exec permissions at the zip level)
Keeping in mind that everything pre-1.0 is subject to breaking change, and since the CloudFormation Stack parameters have changed, you may have to first delete the stack:
up stack delete
Then re-deploy the stack again:
If you have Up already installed, just run
up upgrade or check out the Installation docs to get started :). The next release will include some obvious things, such as custom domain mapping, purchasing of domain names from the CLI, among others — make sure to follow the apex/up repo for updates as well!