← Workflows

阅读中文版本

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.

advanced~150 minterraformiacrefactoring

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

  1. Identify the repeated pattern and define the module interface. Expected state: The module has a clear contract.
  2. Implement the module with documented inputs and outputs. Expected state: The module is usable and documented.
  3. 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 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.