GET STARTED ON DRIFTCTL
This post is part of the walkthrough that will get you started on driftctl in a couple of steps. If you haven’t already done so, you should consider setting up your AWS authentication to use driftctl in a secure way and configuring your Terraform provider version as well.
Many of us have reasons to not target 100% IaC coverage of our AWS accounts. Some of us are moving to Terraform. In this case, driftctl continuously delivers drift notifications that we don’t care about. Behold! There’s a solution.
In this post, we’ll show how to start using driftctl with a clean state, by ignoring all the current resources that are not yet under control. This will be easily done in a couple of seconds by generating a .driftignore
file from a driftctl
JSON output.
We’ll start with a heavily drifted AWS account, and end up with a clean state so you can actually start tracking resources. We’ll do all the steps with both the CLI and Docker container version.
At this stage and before digging into the specifics of how to create a clean baseline, it is probably useful to list the type of messages you can expect to find in the CLI upon running a scan :
terraform apply
directly on your cloud console and will be provisioned again at your next apply
unless you modify your terraform code.Back to our tutorial : what are unmanaged resources? Those are simply resources (EC2 instances, Security Groups, S3 buckets…) that are not managed by Terraform. When we run driftctl
against a bunch of Terraform states, unmanaged resources will show up.
But in many cases, it’s perfectly understandable and acceptable for the time being to have unmanaged resources in the AWS account.
Many of us:
So, the driftctl
experience is quite frustrating for now in this mixed situation: while we have very good reasons to want to know what goes wrong from now on, we are still getting a ton of noise in the output that renders the tool almost useless.
Sure, there’s the .driftignore
file, that works similarly to the .gitignore
file, and we could still fill the file manually. But it works with a handful of resources, definitely not with a lot of resources.
The good news is that driftctl
v0.9.0 ships with a generator of .driftignore
, so we can get started in no time and ignore all the drifts!
If you’re like me, always trying stuff here and there, or if you are moving to Terraform, you’ll end up with a messy driftctl output like that:
It’s cool the first time we launch the tool, so we have a clear overview of drifted and unmanaged resources, based on the cumulative layers of Terraform states – but it’s pretty useless afterwards, as we won’t fix all the drifts right away.
So let’s start by creating a workable JSON output of this scan:
Take a look at this drifts.json
file. It contains the exact same output, but as a structured JSON:
Now we will simply use the new driftctl gen-drifignore
command to generate a .driftignore
file:
Take a look at the newly generated file, all the resources are now included with the proper format!
Finally, we can enjoy a driftctl
scan with all the drifts ignored, while keeping a complete list of them in the .driftignore
file, so we don’t forget about them.
Here’s a quick primer on how to achieve all the above steps very quickly using the official Docker image.
The pre-requisites for this example are:
~/.aws
contains the AWS profiles, so we can share one named AWS_PROFILE
/app
inside the container)~/.driftctl
to reuse the local provider cacheConfirm we can actually run a successful driftctl scan using Docker:
Now we can easily generate the JSON file:
Finally generate the .driftignore
file from the JSON:
We now have our .driftignore
file fully generated in seconds, using driftctl and Docker!
Now we’re starting from a clean state, the next step could be to generate your own HTML reports and quickly spot any relevant information easy to read and to share.
Get product updates and occasional news.