🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧩 धडा 07 — Modules: एका wing चे design, दोनदा बांधलेले

📍 तुम्ही इथे आहात: धडा 07 / 12 · मागे: lesson-06-dependency-graph · पुढे: lesson-08-remote-state-locking

📦 या ब्रँचमध्ये काय आहे

धडे 01–06, आणि पुनर्वापर. Module म्हणजे inputs (variables) आणि outputs असलेला आराखड्याचा एक folder. बांधकाम कार्यालय एक wing एकदाच रेखाटते — एक hall, एक gate आणि N lockers — आणि वेगवेगळ्या inputs सह east wing आणि west wing साठी ते call करते. प्रत्येक call ला स्वतःचे addresses (module.east.school_room.this) आणि स्वतःचे outputs मिळतात. iac/demo.py मधील modules() आणि WING; iac/engine.py मधील expand() मधले module handling.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

शाळेची प्रत्येक wing सारखीच दिसते: एक मोठा hall, त्यात जाणारे एक gate, आणि lockers ची एक रांग. प्रत्येक wing साठी हे सगळे पुन्हा रेखाटणे कंटाळवाणे आहे, आणि एके दिवशी कोणीतरी gate चुकीचे काढते.

म्हणून दीपिका एका wing चे design 📐 रेखाटते, दोन रिकाम्या जागांसह: "wing चे नाव: ____" आणि "किती lockers: ____ (तुम्ही सांगितले नाही तर 2)". ती ते modules/wing नावाच्या folder मध्ये ठेवते.

आता संपूर्ण शाळेचा आराखडा छोटा आहे:

"east नावाची एक wing बांधा." (2 lockers)
"west नावाची एक wing बांधा, 3 lockers सह."

कंत्राटदार east साठी 4 गोष्टी आणि west साठी 5 बांधतो. West wing ला चौथा locker हवा असेल तेव्हा फक्त west wing बदलते. आणि design उत्तरे परत देऊ शकते — "east gate चा नंबर gate-01 आहे" — म्हणजे आराखड्याचा बाकीचा भाग ती वापरू शकतो.

🗺️ आकृती

flowchart LR
    root["📜 root plans"] -->|"wing = east"| e["🧩 module.east<br/>hall · gate · 2 lockers"]
    root -->|"wing = west, lockers = 3"| w["🧩 module.west<br/>hall · gate · 3 lockers"]
    design["📐 modules/wing<br/>inputs: wing, lockers<br/>outputs: gate_id, hall_id"] -.-> e
    design -.-> w
    e -->|"gate_id = gate-01"| out["root outputs"]
    w -->|"hall_id = room-02"| out

🗺️ रेखाटलेली आवृत्ती + एक lab: https://school-edh.pages.dev/terraform/lesson-diagrams.html#l07

❓ काय

Module — .tf files चा कोणताही folder. ज्या folder मध्ये तुम्ही Terraform चालवता तो root module; तो call करतो ते folders म्हणजे child modules.
Module block — module "east" { source = "./modules/wing" wing = "east" }. source सांगते module कुठे आहे: स्थानिक path, Terraform Registry (terraform-aws-modules/vpc/aws), एक git URL, एक S3 bucket.
Inputs — child चे variable blocks. Call करणारा ते arguments म्हणून ठरवतो.
Outputs — child चे output blocks. Call करणारा ते module.east.gate_id असे वाचतो. Module चे resources खाजगी असतात; outputs हा त्याचा सार्वजनिक चेहरा.
Module addresses — module.east.school_room.this. तेच resource नाव (this) प्रत्येक call मध्ये संघर्षाशिवाय राहते.
Versioning — registry आणि git sources pinned असायला हवेत (version = "~> 5.0", ?ref=v1.4.0), म्हणजे upstream बदल अचानक येऊन आदळत नाही.
Composition — modules इतर modules call करू शकतात. Tree उथळ ठेवा; खोल nesting मुळे plans वाचायला अवघड होतात.

🤔 का

कारण copy-paste ने बांधलेला तोच pattern हळूहळू वेगळा होत जातो: एका wing ला दुरुस्ती मिळते, बाकींना नाही. Module त्या pattern ला छोट्या interface सह एक review झालेली गोष्ट बनवते. त्यामुळे platform team चांगले defaults (encryption चालू, public access बंद) प्रसिद्ध करू शकते जे प्रत्येक product team ला फुकट मिळतात. किंमत म्हणजे अप्रत्यक्षपणा (indirection): plan आता module.east.… addresses दाखवतो, आणि module बदलला की प्रत्येक call करणारा बदलतो.

🔧 कसे (या repo मध्ये)

iac/engine.py मधील expand() module block हाताळताना त्याचा source एका modules dictionary मध्ये शोधते, inputs resolve करते, आणि module चे स्वतःचे config module.<name>. या address prefix सह विस्तारते. Module चे output blocks त्याच्या स्वतःच्या scope मध्ये ठेवले जातात; ${module.east.gate_id} तिथे resolve होते. शिकवण्यासाठी केलेले सोपे रूप: इथे module inputs variables, locals आणि literals वापरू शकतात, इतर resources नाही.

🧪 करून पाहा

python3 iac/demo.py modules
python3 - <<'EOF'
import sys; sys.path.insert(0, "iac")
from cloud import FakeCloud
from engine import plan, apply, show_outputs
from demo import WING
for n in (0, 1, 2, 3):
    root = {"module": {"north": {"source": "wing", "wing": "north", "lockers": n}},
            "output": {"gate": {"value": "${module.north.gate_id}"}}}
    cloud = FakeCloud(); p = plan(root, None, cloud, modules={"wing": WING}); st, _, msg = apply(p, cloud)
    print(f"lockers={n} → {msg} · {show_outputs(st)[0]}")
print([a for a in st["resources"]])
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

modules असे print करते:

   Plan: 9 to add, 0 to change, 0 to destroy.
   module.east: school_room.this, school_gate.this, school_locker.row[0], school_locker.row[1]
   module.west: school_room.this, school_gate.this, school_locker.row[0], school_locker.row[1], school_locker.row[2]
── apply → Apply complete! Resources: 9 added, 0 changed, 0 destroyed.
   output east_gate = "gate-01"
   output west_hall = "room-02"
── west asks for 4 lockers → + module.west.school_locker.row[3] (create) → Plan: 1 to add, 0 to change, 0 to destroy.

तुमचा snippet असे print करतो:

lockers=0 → Apply complete! Resources: 2 added, 0 changed, 0 destroyed. · gate = "gate-01"
lockers=1 → Apply complete! Resources: 3 added, 0 changed, 0 destroyed. · gate = "gate-01"
lockers=2 → Apply complete! Resources: 4 added, 0 changed, 0 destroyed. · gate = "gate-01"
lockers=3 → Apply complete! Resources: 5 added, 0 changed, 0 destroyed. · gate = "gate-01"
['module.north.school_room.this', 'module.north.school_gate.this', 'module.north.school_locker.row[0]', 'module.north.school_locker.row[1]', 'module.north.school_locker.row[2]']

🏁 तुम्ही आत्ताच काय सिद्ध केले

एक design, दोन calls, नावांच्या संघर्षाशिवाय 9 resources: दोन्ही wings मध्ये school_room.this आहे, जे module.east. आणि module.west. prefix ने वेगळे ओळखले जातात. एका call चा input बदलल्यावर फक्त त्याच call ला धक्का लागला (1 to add, module.west मध्ये). Outputs ने ids module बाहेर आणले, आणि lockers = 0 दाखवते की module input भाग पूर्णपणे बंद करू शकतो.

⚠️ नेहमीच्या चुका

एकाच resource भोवती गुंडाळलेला आणि काहीच न जोडणारा module — फक्त आणखी indirection
unpinned registry किंवा git sources — पुढच्या init वेळी module तुमच्या नकळत बदलतो
खूप जास्त inputs ("प्रत्येक argument साठी एक variable") — module ने निर्णय घ्यायला हवेत, सगळे पुढे ढकलू नये
moved blocks शिवाय module मधील resources rename करणे किंवा हलवणे — प्रत्येक call करणाऱ्याला destroy + create मिळते
दुसऱ्या module चे resources त्याच्या outputs मधून न वाचता थेट वाचणे

🏭 प्रत्यक्ष वापरात

खऱ्या account वर — एक स्थानिक module आणि एक pinned registry module:

module "east" {
  source  = "./modules/wing"
  wing    = "east"
  lockers = 2
}

module "network" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"            # pin the major version you tested
  name    = "campus"
  cidr    = "10.20.0.0/16"
  azs     = ["ap-south-1a", "ap-south-1b"]
  private_subnets = ["10.20.1.0/24", "10.20.2.0/24"]
}

output "east_gate" {
  value = module.east.gate_id
}

terraform init -upgrade              # fetch modules and providers again, within the pins
terraform get                        # download modules only
terraform state list | grep '^module.east'

बहुतेक teams module साठी वापरत असलेली folder रचना: main.tf, variables.tf, outputs.tf, versions.tf, एक README.md, आणि एक examples/ folder जो त्याचा test म्हणूनही काम करतो (धडा 11).

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: प्रत्येक shared module ला version, changelog आणि tests द्या. Prod मध्ये module upgrade करणे म्हणजे एक pull request असायला हवा ज्याचा plan तुम्ही इतर कोणत्याही plan सारखाच वाचता.

⏭️ पुढे

आतापर्यंत एकच व्यक्ती कंत्राटदार चालवते. एकाच वेळी दोन लोक, प्रत्येकीकडे laptop वर एक नोंदवही — असेच campuses हरवतात. पुढे: remote state आणि locking.

git checkout lesson-08-remote-state-locking

🧩 Lesson 07 — Modules: one wing design, built twice

📍 You are here: Lesson 07 of 12 · Previous: lesson-06-dependency-graph · Next: lesson-08-remote-state-locking

📦 What's in this branch

Lessons 01–06, plus reuse. A module is a folder of plans with inputs (variables) and outputs. The works office draws a wing once — a hall, a gate and N lockers — and calls it for the east wing and the west wing with different inputs. Each call gets its own addresses (module.east.school_room.this) and its own outputs. modules() and WING in iac/demo.py; the module handling in expand() in iac/engine.py.

🧒 Explain like I'm 5

Every wing of the school looks the same: a big hall, a gate into it, and a row of lockers. Drawing all of it again for every wing is boring, and one day someone draws the gate wrong.

So Dipika draws one wing design 📐 with two blanks: "wing name: ____" and "how many lockers: ____ (2 if you don't say)". She puts it in a folder called modules/wing.

Now the plans for the whole school are short:

"Build a wing called east." (2 lockers)
"Build a wing called west, with 3 lockers."

The contractor builds 4 things for east and 5 for west. When the west wing needs a fourth locker, only the west wing changes. And the design can hand back answers — "the east gate's number is gate-01" — so the rest of the plans can use them.

🗺️ Diagram

flowchart LR
    root["📜 root plans"] -->|"wing = east"| e["🧩 module.east<br/>hall · gate · 2 lockers"]
    root -->|"wing = west, lockers = 3"| w["🧩 module.west<br/>hall · gate · 3 lockers"]
    design["📐 modules/wing<br/>inputs: wing, lockers<br/>outputs: gate_id, hall_id"] -.-> e
    design -.-> w
    e -->|"gate_id = gate-01"| out["root outputs"]
    w -->|"hall_id = room-02"| out

🗺️ Drawn version + a lab: https://school-edh.pages.dev/terraform/lesson-diagrams.html#l07

❓ What

Module — any folder of .tf files. The folder you run Terraform in is the root module; folders it calls are child modules.
Module block — module "east" { source = "./modules/wing" wing = "east" }. source says where the module lives: a local path, the Terraform Registry (terraform-aws-modules/vpc/aws), a git URL, an S3 bucket.
Inputs — the child's variable blocks. The caller sets them as arguments.
Outputs — the child's output blocks. The caller reads them as module.east.gate_id. A module's resources are private; outputs are its public face.
Module addresses — module.east.school_room.this. The same resource name (this) lives in each call without clashing.
Versioning — registry and git sources should be pinned (version = "~> 5.0", ?ref=v1.4.0) so an upstream change does not arrive by surprise.
Composition — modules can call modules. Keep the tree shallow; deep nesting makes plans hard to read.

🤔 Why

Because the same pattern built by copy-paste drifts: one wing gets the fix, the others do not. A module makes the pattern one reviewed thing, with a small interface. It also lets a platform team publish good defaults (encryption on, public access off) that every product team gets for free. The cost is indirection: a plan now shows module.east.… addresses, and changing the module changes every caller.

🔧 How (in this repo)

expand() in iac/engine.py handles a module block by looking up its source in a modules dictionary, resolving the inputs, and expanding the module's own config with the address prefix module.<name>.. The module's output blocks are kept in its own scope; ${module.east.gate_id} resolves there. A teaching simplification: here module inputs may use variables, locals and literals, not other resources.

🧪 Try it

python3 iac/demo.py modules
python3 - <<'EOF'
import sys; sys.path.insert(0, "iac")
from cloud import FakeCloud
from engine import plan, apply, show_outputs
from demo import WING
for n in (0, 1, 2, 3):
    root = {"module": {"north": {"source": "wing", "wing": "north", "lockers": n}},
            "output": {"gate": {"value": "${module.north.gate_id}"}}}
    cloud = FakeCloud(); p = plan(root, None, cloud, modules={"wing": WING}); st, _, msg = apply(p, cloud)
    print(f"lockers={n} → {msg} · {show_outputs(st)[0]}")
print([a for a in st["resources"]])
EOF

✅ Verify — what you should see

modules prints:

   Plan: 9 to add, 0 to change, 0 to destroy.
   module.east: school_room.this, school_gate.this, school_locker.row[0], school_locker.row[1]
   module.west: school_room.this, school_gate.this, school_locker.row[0], school_locker.row[1], school_locker.row[2]
── apply → Apply complete! Resources: 9 added, 0 changed, 0 destroyed.
   output east_gate = "gate-01"
   output west_hall = "room-02"
── west asks for 4 lockers → + module.west.school_locker.row[3] (create) → Plan: 1 to add, 0 to change, 0 to destroy.

Your snippet prints:

lockers=0 → Apply complete! Resources: 2 added, 0 changed, 0 destroyed. · gate = "gate-01"
lockers=1 → Apply complete! Resources: 3 added, 0 changed, 0 destroyed. · gate = "gate-01"
lockers=2 → Apply complete! Resources: 4 added, 0 changed, 0 destroyed. · gate = "gate-01"
lockers=3 → Apply complete! Resources: 5 added, 0 changed, 0 destroyed. · gate = "gate-01"
['module.north.school_room.this', 'module.north.school_gate.this', 'module.north.school_locker.row[0]', 'module.north.school_locker.row[1]', 'module.north.school_locker.row[2]']

🏁 What you just proved

One design, two calls, 9 resources with no name clashes: both wings have a school_room.this, told apart by the module.east. and module.west. prefix. Changing one call's input touched only that call (1 to add, in module.west). The outputs carried ids out of the module, and lockers = 0 shows a module input can switch parts off entirely.

⚠️ Common mistakes

a module that wraps a single resource and adds nothing — just more indirection
unpinned registry or git sources — the module changes under you on the next init
too many inputs ("a variable for every argument") — a module should make decisions, not pass everything through
renaming or moving resources inside a module without moved blocks — every caller gets destroy + create
reading another module's resources directly instead of through its outputs

🏭 In production

On a real account — a local module and a pinned registry module:

module "east" {
  source  = "./modules/wing"
  wing    = "east"
  lockers = 2
}

module "network" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"            # pin the major version you tested
  name    = "campus"
  cidr    = "10.20.0.0/16"
  azs     = ["ap-south-1a", "ap-south-1b"]
  private_subnets = ["10.20.1.0/24", "10.20.2.0/24"]
}

output "east_gate" {
  value = module.east.gate_id
}

terraform init -upgrade              # fetch modules and providers again, within the pins
terraform get                        # download modules only
terraform state list | grep '^module.east'

The folder layout most teams use for a module: main.tf, variables.tf, outputs.tf, versions.tf, a README.md, and an examples/ folder that doubles as its test (lesson 11).

🏭 Why this matters in production: give each shared module a version, a changelog and tests. Upgrading a module in prod should be a pull request whose plan you read like any other.

⏭️ Next

So far one person runs the contractor. Two people at once, each with a register on a laptop, is how campuses get lost. Next: remote state and locking.

git checkout lesson-08-remote-state-locking

← Previousdependency graph Next →remote state locking

This page is the lesson's README from the lesson-07-modules branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.