Terraform避坑指南

State Management

• - Local state gets corrupted/lost — use remote backend (S3, GCS, Terraform Cloud)
• Multiple people running simultaneously — enable state locking with DynamoDB or equivalent
• Never edit state manually — use terraform state mv, rm, INLINECODE2
• State contains secrets in plain text — encrypt at rest, restrict access

Count vs for_each

• - count uses index — removing item 0 shifts all indices, forces recreation
• INLINECODE4 uses keys — stable, removing one doesn't affect others
• Can't use both on same resource — choose one
• INLINECODE5 requires set or map — toset() to convert list

Lifecycle Rules

• - prevent_destroy = true — blocks accidental deletion, must be removed to destroy
• INLINECODE8 — new resource created before old destroyed, for zero downtime
• INLINECODE9 for external modifications — ignore_changes = [tags] ignores drift
• INLINECODE11 to force recreation — when dependency changes

Dependencies

• - Implicit via reference — aws_instance.foo.id creates automatic dependency
• INLINECODE13 for hidden dependencies — when reference isn't in config
• INLINECODE14 accepts list — INLINECODE15
• Data sources run during plan — may fail if resource doesn't exist yet

Data Sources

• - Data sources read existing resources — don't create
• Runs at plan time — dependency must exist before plan
• Use depends_on if implicit dependency not clear — or plan fails
• Consider using resource output instead — more explicit

Modules

• - Pin module versions — INLINECODE17
• INLINECODE18 to update — doesn't auto-update
• Module outputs must be explicitly defined — can't access internal resources from outside
• Nested modules: output must bubble up — each layer needs to export

Variables

• - No type = any — explicit type = string, list(string), INLINECODE21
• INLINECODE22 hides from output — but still in state file
• INLINECODE23 block for constraints — custom error message
• INLINECODE24 to reject null — default is nullable

Common Mistakes

• - terraform destroy is permanent — no undo, use -target carefully
• Plan succeeded ≠ apply succeeds — API errors, quotas, permissions discovered at apply
• Renaming resource = delete + create — use moved block or INLINECODE28
• Workspaces not for environments — use separate state files/backends per env
• Provisioners are last resort — use cloud-init, user_data, or config management instead

Import

• - terraform import aws_instance.foo i-1234 — imports existing resource to state
• Doesn't generate config — must write matching resource block manually
• INLINECODE30 block (TF 1.5+) — declarative import in config
• Plan after import to verify — should show no changes if config matches