Introducing Patcher, a new tool for keeping infrastructure code up-to-date!

I’m happy to announce the beta release of Gruntwork Patcher, a tool to automatically keep your infrastructure code up-to-date, even with breaking changes!

This first release of Patcher allows Gruntwork Compliance customers to upgrade their Reference Architecture from version 1.4 to 1.5 of the CIS AWS Foundations Benchmark, pulling in over 200 changes, and fixing 3 breaking changes—automatically. In our subsequent releases, our goal is to automate just about all upgrades for users of the Gruntwork Infrastructure as Code Library: e.g., you’ll be able to use Patcher to keep your infrastructure up-to-date with the latest version of all the tools and services you use (e.g., new releases of EKS / Kubernetes, Terraform, Terraform providers, Docker, Packer), as well as the latest bug fixes, security patches, tooling updates, and new best practices—automatically.

In the rest of this blog post, I’ll walk you through how Patcher works. If you’re interested in trying Patcher out, please contact the Gruntwork sales team.

A walkthrough of Patcher

Every modern software project is full of dependencies on open source code, vendor code (e.g: the Gruntwork Infrastructure as Code Library), and code from other internal teams. For example, you might have Terraform code that deploys a VPC in AWS using a vpc module:

module "vpc" {
  source = "github.com/gruntwork-io/example.git//vpc?ref=v1.0.8"

  vpc_name   = "example"
  cidr_block = "10.0.0.0/16"
}

You can see that this code pins the vpc dependency version to v1.0.8, which is best practice for reproducible builds and immutable infrastructure. But how do you keep your pinned dependency version up to date? For example, version 1.5.0 of the CIS AWS Foundations Benchmark introduced several new networking security recommendations. So if these recommendations were implemented in version 1.0.9 of the vpc module, how long would it be before you pulled in that update? And what if the new recommendations included breaking changes, so the new version was 2.0.0, indicating that the release was backwards incompatible. How long would it be before you took the time to update your code?

This is where Patcher shines. Here’s an outline of how Patcher helps you automate this process:

1. Install Patcher.
2. Discover and update dependency versions.
3. Apply patches for breaking changes.
4. Review the changes and deploy.

Install Patcher

Patcher is a CLI tool that can be easily installed from a GitHub repo (Note: at this point, you can only get access to the repo by contacting Gruntwork sales). Additionally Patcher takes advantage of Docker to execute patches in a secure, sandboxed environment, so make sure you have Docker installed locally as well.

Discover and update dependency versions

When you run patcher upgrade, Patcher analyzes your source code and automatically discovers dependencies, the versions those dependencies are at, and if new versions are available. Here’s an example of running Patcher to upgrade a Gruntwork Reference Architecture to the latest version of the CIS AWS Foundations Benchmark:

As you can see, Patcher automatically discovered 7 different modules, what versions they are at, and what new versions are available for them. If you enter y and hit enter, Patcher will automatically update those modules to the latest versions.

But what if some of those new latest versions have breaking changes? This is where Patcher gets interesting.

Apply patches for breaking changes

New versions of your dependencies often have breaking changes: for example, a module might have removed an input, or added a new required input, or renamed an output. When this happens, you need to not only update the version number, but also make other non-trivial changes to the rest of your code.

Patcher allows maintainers to include a patch with each new release, which is a YAML file that specifies how to programmatically transform the end-user’s code. For example, here’s a patch from the CIS 1.4 → 1.5 upgrade that updates the user’s code to run tflint as a way to enforce a new recommendation related to security groups that was added in version 1.5 of the benchmark (you’ll see the result of this patch a little later in the blog post):

name: "Add tflint hook to Terragrunt configuration for CIS compliance checks"
author: Gruntwork <gruntwork.io>
image: gruntwork/patcher_bash_env:v0.0.12
steps:
  - name: "Create tflint configuration"
    run: create_tf_lint_config.sh
  - name: "Add to the root terragrunt.hcl a hook for tflint"
    run: add_hook.sh

Patcher executes the steps defined in the patch, which can be arbitrary commands; the example above executes a couple Bash scripts. Patcher runs patches in the Docker image specified in the image param, which makes the patch code and its dependencies portable, and keeps you safe by limiting what the Docker container can see and do.

Here’s a snippet of the log output showing Patcher applying one of the 200 updates and 3 patches that were part of the CIS 1.4 →1.5 update:

After Patcher finishes, it shows you a summary of all the updates it made and patches it applied:

Now you can review the changes and deploy.

Review the changes and deploy

Patcher makes all of its changes on your local file system, so you can easily review what changed using the git diff command:

The screenshot above shows a couple of the changes Patcher has made as part of the CIS 1.4 → 1.5 upgrade: it not only updated the version numbers, but also applied patches, such as adding tflint as a before hook to enforce new CIS security recommendations.

If the changes look good, you can commit them, and deploy them, or let your CI / CD system (e.g., Gruntwork Pipelines) deploy them. If the changes don’t look good, you can edit them, or revert the whole thing; there’s no risk!

Give Patcher a shot

The first release of Patcher automates the CIS 1.4 → 1.5 upgrade, but our vision for the future is to automate all updates for the Gruntwork Infrastructure as Code Library and Reference Architecture. Our goal is to get you live on AWS in about a day, and once you’re on the Gruntwork infrastructure train, we aim keep that train rolling smoothly by keeping your code up-to-date with the latest fixes and best practices—automatically.

If you’re interested in trying Patcher out, then please contact Gruntwork sales.