liveBook · Manning

Source of truth

As explained in Infrastructure as Code, Patterns and Practices: With examples in Python and Terraform

A source of truth is the authoritative representation against which the actual state of a system or resource is reconciled.

A source of truth is the single, consistent representation of infrastructure state and desired configuration. In infrastructure as code, version-controlled configuration declares the desired end state, while automation determines how to reach it. section 2.1

Treat the source of truth as the ownership boundary for changes. Manual changes create drift; reconciling the actual resource with version-controlled configuration restores reproducibility and supports repeatable, idempotent deployment. section 2.2.1 section 2.4

Use the pattern operationally by:

  • Declaring the desired infrastructure state in version-controlled configuration rather than recording a sequence of manual steps. section 2.1
  • Reconciling any out-of-band change by updating the configuration immediately after changing the live resource. section 2.2.1
  • Migrating brownfield infrastructure from base resources and dependencies outward, matching existing state before applying IaC. section 2.2.2
  • Removing refactored resources from the old configuration and state so two IaC definitions cannot manage the same resource. section 10.2.1
  • Using commits and ticket identifiers to preserve change context, traceability, and a reproducible history. section 2.3.1

Migrating an existing environment

For a brownfield environment containing networks, servers, load balancers, firewalls, and DNS entries, first reconstruct the networks in IaC. Match their names and CIDR blocks to the live resources, then migrate dependent resources. If the configuration differs from reality, applying it may damage the network and the resources running on it. During refactoring, import existing resources, verify that planning reports no differences, and remove their definitions and state entries from the former monolith. section 2.2.2 section 10.2.1

Figure 2.6 The decision workflow for migration helps you decide how to import your infrastructure with a provisioning tool, re-create a resource, or build conditional statements to check for resource existence. No matter which option, you must rerun your IaC and reconcile any drift.

Use the migration decision workflow to choose whether to import a resource, recreate it, or conditionally check for its existence before rerunning IaC and reconciling drift. section 2.2.2

How Infrastructure as Code, Patterns and Practices: With examples in Python and Terraform covers it

How deep it goes
Explains declaration, drift remediation, migration order, imports, state removal, and change history, but defers provider-specific implementation details.
Examples
Uses database discovery, network migration, IAM refactoring, Terraform plans, state commands, and descriptive Git commits.
What it assumes
Assumes familiarity with infrastructure resources and version control while defining declarative configuration, drift, immutability, and reconciliation.
What you can do after
Operate/configure infrastructure by reconciling live resources, migrating brownfield environments, and preventing conflicting IaC ownership.
How it connects
Connects declarative infrastructure as code with immutability, configuration drift, version control, reproducibility, idempotency, and GitOps.

Also explained in

Compare how 8 books explain source of truth →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Infrastructure as Code, Patterns and Practices: With examples in Python and Terraform. The section links point to the parts of the book it draws on.