2021-02-06, 10:00–10:30, D.infra
While we all probably think we're doing all the DevOps stuff the right way (and we do, don't we?), drift happens.
Even as an experienced Terraform user, as your infrastructure team and codebase grows, it often becomes harder to track drift.
I'll share here war stories from different teams, and show common pitfalls of popular commands we use when we want to know what's changed in our infrastructures.
There are a lot of juicy stories from the trenches to be told on infrastructure drift.
Sure enough, we all do GitOps by the book! Or we all have the right processes in place. But we also have to interact with other teams. We also have to grant some level of access to our infrastructures to some services or tools that may eventually generate uncontrolled changes. What if we couldn't catch them all? What if all drift reporting so far was faulty?
You can't efficiently improve what you don't track. We track coverage for unit tests, why not infrastructure as code coverage? How can we make sure our infrastructure code matches our actual infrastructure state? In this talk, using Terraform with AWS resources, I will show how infrastructure drift can go undetected despite our best efforts or tooling and cause issues and end the talk by showing our own tool driftctl, (just released under Apache-2.0 licence) that tracks IaC coverage and warns of infrastructure drift.
CTO and entrepreneur, I am building driftctl (Open Source CLI that measures infrastructure as code coverage, and tracks infrastructure drift) and am currently founder at CloudSkiff, empowering developers to make their infrastructure code better and safely ship infrastructures in short cycles. I am also the author of “Infrastructure-as-Code Cookbook” and have worked essentially remotely for the last 10+ years in Canada and Europe. Fun fact, I love ancient philosophy and also co-launched and run a community radio.