6 State Management
This chapter covers
- Reasons that State exist
- Considerations when Managing State
- Storing State in Centralized Backends
- Understanding how State is Structured
- Fixing common State errors
- Cross Project State Access
- Resources that exist only in State
When using Terraform the concept of state comes up quite often. We’ve talked about it a little bit so far, defining it back in Chapter 1 as “a collection of metadata about the resources that Terraform manages”. What is “state” though, and why do we need it?
One of the easiest ways to talk about state is to talk about what it looks like to have a system without state (also referred to as a stateless system). When you’re working with programming languages and protocols a stateless system is one that has no memory of past runs. Every interaction is a standalone interaction that does not depend on the interactions before it. If you’ve ever worked with web based APIs you may be familiar with the HTTP based REST Protocol, which is a stateless system: every request to the API has to contain everything it needs for that request.
Systems that have state are a bit different. Stateful systems have a memory of what has happened before that they used to drive their current actions. This means that they have to keep track of the current state of the system (hence the name). Terraform is an example of a stateful system: it keeps a record of all the resources under its control and refreshes that record as part of every plan.