Chapter 3: How to Manage Terraform State
what is?
- terraform.tfsate JSON file
- output terraform plan is a «diff» with terraform.tfstate
- state file is a private API, for internal use of terraform and can change in any moment
- to modify, terraform import and terraform state
- share state in workgroups
- shared location
- not good idea to share in a git (manual errors, forget commit last update, no-locking, secrets exposed, etc)
- local backend VS remote backend (supported by Amazon S3, Azure Storage, Google Cloud Storage, Hashicorp's Terraform Cloud)
- locked
- -lock-timeout=10m waits for locked state to relaunch command
- isolation (big structures, environments)
- terraform backends limitations
- chicken-and-egg situation (create local backend to create the instrastructure needed for remote backend)
- no variables or references in backend block (copy-and-paste in all projects)
- be aware to use unique «key» (paths) to store terraform.tfstate of every project
- use backend.hcl for fixed information in backend block and backend.tf for variable informacion (like path), and
terraform init -backend-config=backend.hcl - use terragrunt
- Isolating State Files
- separate by environment
- what happens when terraform brokes: https://charity.wtf/2016/03/30/terraform-vpc-and-why-you-want-a-tfstate-file-per-env/
- by workspaces
terraform workspace showterraform workspace new <NAME>terraform workspace listterraform workspace select <NAME>- variables
terraform.workspace
- drawbacks1):
- all state files (for each workspace) are in the same backend → same crendentials/authentication
- workspaces are not visible in the code, more dificult to have a global point of view
- human errors applying changes on the incorrect workspace
- by Isolation via File Layout
1)
inconvenientes