Introduction
Packer is a tool for building machine images. It was created by HashiCorp, and like everything else HashiCorp builds it “just works”.
Packer focuses on creating your machine image by installing the software and security updates you specify.
However, until now I was only ever building Linux images. I recently found that building Windows images with Packer was not the same smooth journey.
During this article I will give my experience of switching from Packer to EC2 Image Builder for the first time.
EC2 Image Builder
EC2 Image Builder is a service AWS offer that allows you to automate the process of building custom Amazon Machine Images (AMIs). Unlike Packer, it also handles the full pipeline for creating, testing and even distributing the machine images.
Vendor Lock-in
Let’s get this out of the way early. Vendor lock-in is a valid concern, and if you are worried about it then do not use EC2 Image Builder. Simple!
Packer is a solid tool and works with every major cloud provider I know.
However, if you’re already commited to AWS then Image Builder is a really interesting option.
Golden Image
Let’s look at the infrastructure for building a golden image.
A golden image is essentially a bespoke base image you create for your instances. It should come pre-baked with the latest software and security patches you need.
Building a golden image is a deceptively tricky problem. I have borrowed this old diagram from a 2017 AWS blog post to give you an idea of complexity involved in running Packer:
While the implementation will vary, this would be the typical architecture you would find.
The problems with this approach are:
- How do we schedule the image builds?
- How do we test the image still works?
- How do we distribute the AMI after it has been created?
The real power of EC2 Image Builder is that it encompasses all of these features into a single managed service.
Testing Images
I find that people rarely test the machine images that Packer creates. Whereas EC2 Image Builder has excellent support for this out of the box.
There are two stages in EC2 Image Builder:
- Build stage (pre-snapshot)
- Test stage (post-snapshot)
So the build stage works much the same as Packer, but the Test stage is where things get interesting. Image Builder launches an EC2 instance from the snapshot that was created as the final step of the build stage.
Tests run on the new instance to validate settings and ensure that the instance is functioning as expected.
You don’t need to stitch together lambdas, pipelines or any other solution to manually test these instances. AWS give you this out of the box.
The only downside is that you can’t turn off the Test stage, so this can increase the time it takes to have an AMI distributed.
Build Speed
On the face of it Packer is much quicker than EC2 Image Builder. Infact, I was finding it would take 60 minutes for Image Builder to create my Windows Server instance, while Packer would take only 20 minutes. That’s 3x faster!
The difference is that packer is only carrying out one part of the puzzle.
Using Packer the real flow would be:
- Run custom CI/CD pipeline, install packer and run (5 minutes)
- Execute Packer to build the machine image (20 minutes)
- Run custom CI/CD pipeline to launch the instance (5 minutes)
- Run custom tests to confirm the image works and passes all relevant tests (20 minutes)
- Run custom CI/CD pipeline to update the launch template AMI (5 minutes)
And we’re almost back to the 1 hour mark that I found EC2 Image Builder takes.
So yes, Packer is faster. But EC2 Image Builder handles the full pipeline, and not just the build stage.
Launch Template
EC2 Image Builder has a concept of “Distribution”, you can use this to automatically update the AMI in your launch template after the image has been created.
When you’re using Packer this process of updating the launch template is 100% manual, and often cobbled together by your DevOps team in a non-standard way.
Infact, even more often I would wager there is no automated process to update the launch template at all.
Component Documents
Need somewhere to place your custom bash/powershell scripts? Just use a component.
These are no more complicated than Packer, both use yaml - and in both I add the bare minimum amount of yaml so I can write my own bash/powershell scripts instead.
There are also lots of managed action modules that you can leverage if you don’t feel like coding.
Cleanup
The biggest downside I have found to using Image Builder is that it doesn’t clean up it’s own mess. And while packer doesn’t do this either, it is a feature I would expect to see in a managed service like Image Builder.
You need to write your own lambda to clean up the AMIs and Snapshots it creates.
Summary
If you’re committed to AWS then EC2 Image Builder can be a really interesting alternative to Packer. Especially when building Windows images.
It allows you to schedule, test and distribute the images in a seamless fashion while still offering features comparitive to Packer.
Just watch out for those build times!