I’m excited to say that a ton of great features has been added to lono with this major version bump. At this point, lono has grown to become a framework for managing CloudFormation templates. Let jump right into it and cover the major improvements.

Lono Structural Changes

To support the new features of lono, like layering, structural changes to lono projects had to be made. The Directory Structure docs give an overview of the new structure. Notably, there is no more config/lono.rb. file. Instead the main component folders are config/templates, config/variables, templates and params. Lono components are summarized in the Components docs.

Layering Support

As mentioned above there were structural changes to support layering. What is layering? Layering is lono’s way of merging multiple files together to produce a final result.

The point of layering is to allow you to build multiple environments like staging and production in a clean and organized manner. Layering allows you to override components for specific environments in a finely tuned way. A detailed description of how layering works is found on the official Layer Support docs. Here is a quick overview of layering though:

config/variables/base/variables.rb:

@ami = "ami-base"
@disk_size = 8

config/variables/prod/variables.rb:

@ami = "ami-deploy"
@disk_size = 80
@rolling_update = true

Lono will layer the prod/variables.rb on top of the base/variables.rb to produce:

@ami = "ami-deploy"
@disk_size = 80
@rolling_update = true

Layering is performed on these lono components: Template Configurations, Shared Variables and Param Files.

Shared Variable Support

Before, you could only specify variables in each template block. Variables are often common between stacks though. So this would result in the promiscuous use of the famous “copy and paste” programming technique. This would create duplicate declarations of template variables. Shared variables solve this problem.

Variables are declared in config/variables folder and are available in template configuration blocks, template views and param files.

Nested Stacks Support

Lono is now designed with nested stack templates in mind. Previously, lono would use the generated template file on the filesystem and feed that to the lono cfn create command. Lono still does this but it now also has the ability to upload the generated template to an s3 bucket. Additionally, it provides a helper method to reference the s3 path location of the uploaded template. There is also a template_params helper method that makes it easy to use parameters from the child stack to the parent stack. This is covered in detail in the Nested Stacks docs.

Format and Extension Detection

In prior versions of lono, you would have to explicitly specify the extensions of the output template files to be generated. You would also be required to specify extensions to the partial files being rendered. No more! Specifying extensions is no longer required. Lono smartly infers extensions. I was surprised by how much this little ability simplifies the code. How extension conventions work is covered in the official Conventions docs.

Custom Helper Support

You can now write your own custom helpers that get injected into the lono generation processing as first class citizens. That’s a bunch of fancy words to say that custom helpers have the same context and access to variables as built-in lono helpers. The custom helpers are covered in the official Custom Helpers docs.

Source Name Convention Support

Another small change which made a much bigger impact than I would have imagined. The default source name for a template is the output name you specify. So this:

template "example" do
  source "example"
end

Becomes this:

template "example"

Settings File Support

Lono can read a lono/settings.yml file which customizes lono’s behavior. An example of this is automatically mapping AWS_PROFILEs to LONO_ENVs so you always launch your stack in the right AWS account. More details are in the Settings docs.

Little Misc Things Matter

Here are some misc additional improvements.

• When a top level stack fails to create due to forgetting to specify IAM capabilities lono prompts you to confirm and reruns the command again. There’s also a --iam shortcut flag that adds the common IAM capabilities.
• There is --randomize-stack-name flag that speeds up your CloudFormation development workflow by appending a random string to your stack name. More details in the Settings docs.

Summary

Hope you enjoy these Lono improvements in version 3. It has been an incredibly helpful tool for managing CloudFormation templates.