Terraform Module Extraction Workflow
Identify repeated resource patterns, extract a module with clear inputs and outputs, migrate consumers one by one, and validate plans before moving state.
Objective
Extract a reusable Terraform module from duplicated configuration without breaking existing environments.
Environment
- Terraform state and configuration
- A versioned module repository
Steps
1. Identify the repeated pattern and define
Identify the repeated pattern and define the module interface.
Expected state: The module has a clear contract.
2. Implement the module with documented inputs
Implement the module with documented inputs and outputs.
Expected state: The module is usable and documented.
3. Migrate one consumer and validate
Migrate one consumer and validate the plan is a no-op after moving state.
Expected state: Migration does not change infrastructure.
4. Migrate the rest in small steps
Migrate the rest in small steps and remove the duplicated code.
Expected state: Duplication is gone.
Decision points
Move state or recreate resources?
- Move state
- Recreate
Move state to avoid downtime; recreate only for resources that are safe to rebuild and disposable.
Module granularity?
- One pattern per module
- Large multi-purpose module
One clear pattern each; multi-purpose modules grow confusing interfaces and hidden coupling.
Expected outcome
A versioned module with documented interface and all consumers migrated with no unintended infrastructure changes.
Verification
Confirm terraform plan after migration shows no changes for each consumer and that the module is pinned by version.
Cleanup
Archive the old configuration and document the module interface.
Overview
Extract a reusable Terraform module from duplicated configuration without breaking existing environments. Confirm terraform plan after migration shows no changes for each consumer and that the module is pinned by version.
Steps
- Identify the repeated pattern and define the module interface. Expected state: The module has a clear contract.
- Implement the module with documented inputs and outputs. Expected state: The module is usable and documented.
- Migrate one consumer and validate the plan is a no-op after moving state. Expected state: Migration does not change infrastructure.
- Migrate the rest in small steps and remove the duplicated code. Expected state: Duplication is gone.
module "service" {
source = "git::https://github.com/acme/tf-service.git?ref=v1.2.0"
name = "orders"
cpu = 512
}
# terraform state mv ... then plan must be empty
Verification
- A versioned module with documented interface and all consumers migrated with no unintended infrastructure changes.
Decision points
- Move state or recreate resources? Options: Move state; Recreate. Recommended: Move state to avoid downtime; recreate only for resources that are safe to rebuild and disposable.
- Module granularity? Options: One pattern per module; Large multi-purpose module. Recommended: One clear pattern each; multi-purpose modules grow confusing interfaces and hidden coupling.