<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Tools on Besterry — Linux &amp; DevOps Notes</title><link>https://besterry.com/categories/tools/</link><description>Recent content in Tools on Besterry — Linux &amp; DevOps Notes</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 18 Sep 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://besterry.com/categories/tools/index.xml" rel="self" type="application/rss+xml"/><item><title>Terraform State Locking: Why You Need It and How It Goes Wrong</title><link>https://besterry.com/posts/terraform-state-locking/</link><pubDate>Wed, 18 Sep 2024 00:00:00 +0000</pubDate><guid>https://besterry.com/posts/terraform-state-locking/</guid><description>&lt;p&gt;Terraform state without locking is a bug waiting to happen. Two engineers running apply simultaneously can corrupt state in ways that take hours to untangle. Here&amp;rsquo;s what I learned after one such incident.&lt;/p&gt;
&lt;h2 id="why-state-locking-matters"&gt;Why state locking matters&lt;/h2&gt;
&lt;p&gt;Terraform reads state, computes a plan, and writes new state. Without locking, two concurrent runs can:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Both read the same initial state&lt;/li&gt;
&lt;li&gt;Both compute their plans based on it&lt;/li&gt;
&lt;li&gt;Both write conflicting state — last one wins&lt;/li&gt;
&lt;li&gt;Now state doesn&amp;rsquo;t match real infrastructure&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;The symptoms are weird: resources exist but Terraform wants to create them again. Or state references resources that were already destroyed.&lt;/p&gt;</description></item></channel></rss>