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

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

📋 धडा 03 — Plan आणि apply: फक्त फरक बांधा

📍 तुम्ही इथे आहात: धडा 03 / 12 · मागे: lesson-02-resources-providers · पुढे: lesson-04-variables-loops

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

धडे 01–02, आणि Terraform चे हृदय: plan. कंत्राटदार तीन गोष्टींची तुलना करतो — आराखडा (config), नोंदवही (state) आणि campus (खरे objects) — आणि प्रत्येक address चे तो काय करेल याची यादी करतो: create (+), जागीच update (~), replace (-/+, जेव्हा ForceNew argument बदलतो) किंवा destroy (-). मग apply नेमके तेच करते. iac/demo.py मधील plan_(), iac/engine.py मधील plan() आणि apply().

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

आराखड्याची version 1 बांधून झाली आहे: एक lab, एक art room आणि एक मुख्य gate.

आता ऐश्वर्या आराखड्याची version 2 लिहिते:

lab ला 30 ऐवजी 40 seats मिळतात,
art room floor 3 वर जाते,
gate आराखड्यातून काढून टाकले आहे,
आणि एक नवी library आहे.

कोणी एकही वीट हलवण्याआधी कंत्राटदार जागेवर फिरून एक यादी लिहितो: 📝

~ lab: फक्त 10 खुर्च्या वाढवा. तीच खोली.
-/+ art room: खोली उचलून दुसऱ्या floor वर नेता येत नाही. ती पाडा, floor 3 वर नवी बांधा.
+ library: बांधा.
- gate: काढून टाका.

ऐश्वर्या यादी वाचते. मग ती "हो" म्हणते. त्यानंतरच बांधकाम सुरू होते.

🗺️ आकृती

flowchart LR
    cfg["📜 plans v2"] --> diff{"👷 compare"}
    st["📒 register<br/>(state)"] --> diff
    campus["🏫 campus<br/>(refresh)"] --> st
    diff --> u["~ lab<br/>seats 30 → 40"]
    diff --> r["-/+ art<br/>floor 1 → 3<br/>forces replacement"]
    diff --> c["+ library"]
    diff --> d["- gate"]
    u & r & c & d --> sum["Plan: 2 to add,<br/>1 to change, 2 to destroy"]
    sum -->|"yes"| apply["apply"]

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

❓ काय

Plan — campus आराखड्याशी जुळवण्यासाठी करायच्या क्रियांची यादी. काहीही बांधले जात नाही. terraform plan ती दाखवते; terraform plan -out=tfplan ती file मध्ये साठवते.
Refresh — plan करण्याआधी कंत्राटदार नोंदवहीतील प्रत्येक object खऱ्या cloud मधून वाचतो, म्हणजे तो खरोखर जे आहे त्याविरुद्ध plan करतो (धडा 09).
Create + — आराखड्यात आहे, नोंदवहीत नाही.
जागीच update ~ — दोन्हींत आहे, काही arguments वेगळे आहेत, आणि ते सगळे चालू object वरच बदलता येतात. Id तोच राहतो.
Replace -/+ — provider ने ForceNew म्हणून खूण केलेला argument बदलला. जुना object destroy होतो आणि नव्या id सह नवा तयार होतो. Terraform त्या argument शेजारी # forces replacement print करते. Default ने ते आधी destroy करते; create_before_destroy lifecycle setting हा क्रम उलटा करते (+/-).
Destroy - — नोंदवहीत आहे, आराखड्यात आता नाही.
No-op — दोन्हींत आहे, काहीच वेगळे नाही. Print होत नाही.
सारांशाची ओळ — Plan: 2 to add, 1 to change, 2 to destroy. एक replace एक add आणि एक destroy म्हणून मोजला जातो, म्हणूनच 4 क्रियांमधून 2 + 1 + 2 येतात.
Apply — plan अमलात आणणे. terraform apply पुन्हा plan करते आणि yes विचारते; terraform apply tfplan साठवलेला plan नेमका तसाच apply करते.

🤔 का

कारण plan हा अनर्थ घडण्याआधी पकडण्याचा क्षण आहे. Database वर -/+ म्हणजे तुम्ही आधी योजना केली नसेल तर त्याचा data गेला. अनपेक्षित - destroy म्हणजे काहीतरी rename झाले किंवा काढले गेले. चांगली team प्रत्येक plan वाचते आणि replace किंवा destroy ला उत्तर हवा असलेला प्रश्न मानते. Plan मुळे बदल लहानही राहतात: कंत्राटदार फक्त फरक बांधतो, संपूर्ण campus पुन्हा नाही.

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

iac/engine.py मधील plan(cfg, state, cloud) state refresh करते, config चे instances मध्ये विस्तार करते, आणि प्रत्येक address साठी हवे असलेले arguments (with_defaults) state च्या attributes शी ताडते. ज्याच्या schema मध्ये force_new आहे असा argument बदलला तर तो बदल replace ठरतो; नाहीतर तो update असतो. State मध्ये उरलेले addresses delete असतात. Plan.lines() diff print करते आणि Plan.summary() सारांशाची ओळ. apply(p, cloud) क्रिया चालवते आणि नवी state परत देते.

🧪 करून पाहा

python3 iac/demo.py plan
python3 - <<'EOF'
import sys; sys.path.insert(0, "iac")
from cloud import FakeCloud
from engine import plan, apply
base = {"name": "lab", "floor": 1, "seats": 30}
for change in ({}, {"seats": 40}, {"name": "science-lab"}, {"floor": 2}, {"seats": 40, "floor": 2}):
    cloud = FakeCloud()
    st, _, _ = apply(plan({"resource": {"school_room": {"lab": base}}}, None, cloud), cloud)
    p = plan({"resource": {"school_room": {"lab": dict(base, **change)}}}, st, cloud)
    print(f"{str(change):<28} → {p.changes[0]['action']:<8} {p.summary()}")
EOF

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

plan असे print करते:

     ~ school_room.lab  seats: 30 → 40
   -/+ school_room.art  floor: 1 → 3  # forces replacement
     + school_room.library (create)
     - school_gate.main (destroy)
   Plan: 2 to add, 1 to change, 2 to destroy.
── apply → Apply complete! Resources: 2 added, 1 changed, 2 destroyed.
   the art room is a NEW object: room-02 → room-03 · the lab kept its id room-01

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

{}                           → no-op    No changes. Your infrastructure matches the configuration.
{'seats': 40}                → update   Plan: 0 to add, 1 to change, 0 to destroy.
{'name': 'science-lab'}      → update   Plan: 0 to add, 1 to change, 0 to destroy.
{'floor': 2}                 → replace  Plan: 1 to add, 0 to change, 1 to destroy.
{'seats': 40, 'floor': 2}    → replace  Plan: 1 to add, 0 to change, 1 to destroy.

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

एकाच प्रकारचा बदल — एक आकडा बदलणे — निरुपद्रवी update (seats) असू शकतो किंवा पुन्हा बांधकाम (floor). बदल किती मोठा आहे यावरून नाही, schema ठरवते. ForceNew बदल आणि साधा बदल एकत्र आले तर संपूर्ण गोष्ट replace ठरते. आणि replace नंतर art room ला नवा id मिळाला (room-02 → room-03): आराखड्याबाहेरचे जे काही room-02 लक्षात ठेवून होते ते आता कशाकडेच निर्देश करत नाही.

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

आधी plan न वाचता terraform apply -auto-approve चालवणे
लांब plan मधील एकमेव -/+ ओळ नजरेतून सुटणे — plan मध्ये "forces replacement" आणि "destroy" शोधा
review झालेल्या plan ऐवजी वेगळा plan apply करणे (apply च्या वेळी ताडून न पाहता पुन्हा plan करणे — धडा 12)
आराखड्यात resource rename करणे आणि plan आता destroy + create म्हणतो हे लक्षात न येणे (धडा 09 हे moved ने सोडवतो)
data ठेवणाऱ्या कोणत्याही गोष्टीसाठी "replace" सुरक्षित आहे असे गृहीत धरणे — database, disk, bucket

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

खऱ्या account वर — plan साठवा, वाचा, नेमका तोच plan apply करा:

terraform plan -out=tfplan               # the plan, saved
terraform show tfplan                    # read it again, as text
terraform show -json tfplan > plan.json  # for tools: policy, cost, comments (lesson 11)
terraform apply tfplan                   # applies THIS plan — no new diff, no "yes" prompt

AWS provider कडून खऱ्या plan मधील एक replace (ami बदलल्यास नवा instance लागतो; instance_type जागीच बदलू शकतो):

  # aws_instance.web must be replaced
-/+ resource "aws_instance" "web" {
      ~ ami = "ami-0aaa..." -> "ami-0bbb..." # forces replacement

lifecycle block ने replacement नियंत्रित करा:

resource "aws_instance" "web" {
  ami           = var.ami
  instance_type = "t3.small"
  lifecycle {
    create_before_destroy = true   # build the new one first, then remove the old one
    prevent_destroy       = false  # set true on things that must never be destroyed by a plan
  }
}

terraform plan -replace=aws_instance.web मुद्दाम replace घडवते (बिघडलेल्या server साठी), आणि terraform destroy state मधील सर्व काही काढून टाकण्याचा plan करते.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: "-/+ आणि - ओळी मोजा" हे प्रत्येक review चा भाग बनवा. Data ठेवणाऱ्या databases आणि buckets वर prevent_destroy = true लावा, म्हणजे त्यांना destroy करणारा plan त्याऐवजी fail होईल.

⏭️ पुढे

एक lab सोपी आहे. अनेक गावांसाठी, थोड्या वेगळ्या आकारांच्या अनेक labs साठी variables, outputs आणि loops लागतात.

git checkout lesson-04-variables-loops

📋 Lesson 03 — Plan & apply: build only the difference

📍 You are here: Lesson 03 of 12 · Previous: lesson-02-resources-providers · Next: lesson-04-variables-loops

📦 What's in this branch

Lessons 01–02, plus the heart of Terraform: the plan. The contractor compares three things — the plans (config), the register (state) and the campus (the real objects) — and lists what it would do to each address: create (+), update in place (~), replace (-/+, when a ForceNew argument changes) or destroy (-). Then apply does exactly that. plan_() in iac/demo.py, plan() and apply() in iac/engine.py.

🧒 Explain like I'm 5

Version 1 of the plans is built: a lab, an art room and a main gate.

Now Aishwarya writes version 2 of the plans:

the lab gets 40 seats instead of 30,
the art room moves to floor 3,
the gate is gone from the plans,
and there is a new library.

Before anyone touches a brick, the contractor walks the site and writes a list: 📝

~ lab: just add 10 chairs. Same room.
-/+ art room: you can't lift a room to another floor. Knock it down, build a new one on floor 3.
+ library: build it.
- gate: take it down.

Aishwarya reads the list. Then she says "yes". Only then does the building start.

🗺️ Diagram

flowchart LR
    cfg["📜 plans v2"] --> diff{"👷 compare"}
    st["📒 register<br/>(state)"] --> diff
    campus["🏫 campus<br/>(refresh)"] --> st
    diff --> u["~ lab<br/>seats 30 → 40"]
    diff --> r["-/+ art<br/>floor 1 → 3<br/>forces replacement"]
    diff --> c["+ library"]
    diff --> d["- gate"]
    u & r & c & d --> sum["Plan: 2 to add,<br/>1 to change, 2 to destroy"]
    sum -->|"yes"| apply["apply"]

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

❓ What

Plan — the list of actions that would make the campus match the plans. Nothing is built. terraform plan shows it; terraform plan -out=tfplan saves it to a file.
Refresh — before planning, the contractor reads every object in the register from the real cloud, so it plans against what is really there (lesson 09).
Create + — in the plans, not in the register.
Update in place ~ — in both, some arguments differ, and all of them can be changed on the living object. The id stays.
Replace -/+ — an argument that the provider marks ForceNew changed. The old object is destroyed and a new one is created, with a new id. Terraform prints # forces replacement next to that argument. By default it destroys first; the create_before_destroy lifecycle setting reverses the order (+/-).
Destroy - — in the register, no longer in the plans.
No-op — in both, nothing differs. Not printed.
The summary line — Plan: 2 to add, 1 to change, 2 to destroy. A replace counts as one add and one destroy, which is why 4 actions give 2 + 1 + 2.
Apply — carry out the plan. terraform apply plans again and asks for yes; terraform apply tfplan applies a saved plan exactly.

🤔 Why

Because the plan is the moment to catch a disaster before it happens. -/+ on a database means its data is gone unless you planned for it. A surprise - destroy means something was renamed or removed. A good team reads every plan and treats a replace or a destroy as a question that needs an answer. The plan also makes changes small: the contractor builds only the difference, not the whole campus again.

🔧 How (in this repo)

plan(cfg, state, cloud) in iac/engine.py refreshes the state, expands the config into instances, and for each address compares the wanted arguments (with_defaults) with the state's attributes. A changed argument whose schema has force_new makes the change a replace; otherwise it is an update. Addresses left in the state are delete. Plan.lines() prints the diff and Plan.summary() the summary line. apply(p, cloud) runs the actions and returns the new state.

🧪 Try it

python3 iac/demo.py plan
python3 - <<'EOF'
import sys; sys.path.insert(0, "iac")
from cloud import FakeCloud
from engine import plan, apply
base = {"name": "lab", "floor": 1, "seats": 30}
for change in ({}, {"seats": 40}, {"name": "science-lab"}, {"floor": 2}, {"seats": 40, "floor": 2}):
    cloud = FakeCloud()
    st, _, _ = apply(plan({"resource": {"school_room": {"lab": base}}}, None, cloud), cloud)
    p = plan({"resource": {"school_room": {"lab": dict(base, **change)}}}, st, cloud)
    print(f"{str(change):<28} → {p.changes[0]['action']:<8} {p.summary()}")
EOF

✅ Verify — what you should see

plan prints:

     ~ school_room.lab  seats: 30 → 40
   -/+ school_room.art  floor: 1 → 3  # forces replacement
     + school_room.library (create)
     - school_gate.main (destroy)
   Plan: 2 to add, 1 to change, 2 to destroy.
── apply → Apply complete! Resources: 2 added, 1 changed, 2 destroyed.
   the art room is a NEW object: room-02 → room-03 · the lab kept its id room-01

Your snippet prints:

{}                           → no-op    No changes. Your infrastructure matches the configuration.
{'seats': 40}                → update   Plan: 0 to add, 1 to change, 0 to destroy.
{'name': 'science-lab'}      → update   Plan: 0 to add, 1 to change, 0 to destroy.
{'floor': 2}                 → replace  Plan: 1 to add, 0 to change, 1 to destroy.
{'seats': 40, 'floor': 2}    → replace  Plan: 1 to add, 0 to change, 1 to destroy.

🏁 What you just proved

The same kind of edit — change one number — can be a harmless update (seats) or a rebuild (floor). The schema decides, not the size of the edit. When a ForceNew change and a normal change come together, the whole thing is a replace. And after the replace, the art room had a new id (room-02 → room-03): anything outside the plans that remembered room-02 now points at nothing.

⚠️ Common mistakes

running terraform apply -auto-approve without reading a plan first
missing the one -/+ line in a long plan — search the plan for "forces replacement" and "destroy"
applying a different plan from the one that was reviewed (plan again at apply time without comparing — lesson 12)
renaming a resource in the plans and not noticing the plan now says destroy + create (lesson 09 fixes this with moved)
assuming "replace" is safe for anything that holds data — a database, a disk, a bucket

🏭 In production

On a real account — save the plan, read it, apply exactly that plan:

terraform plan -out=tfplan               # the plan, saved
terraform show tfplan                    # read it again, as text
terraform show -json tfplan > plan.json  # for tools: policy, cost, comments (lesson 11)
terraform apply tfplan                   # applies THIS plan — no new diff, no "yes" prompt

A replace in a real plan, from the AWS provider (changing ami forces a new instance; instance_type can change in place):

  # aws_instance.web must be replaced
-/+ resource "aws_instance" "web" {
      ~ ami = "ami-0aaa..." -> "ami-0bbb..." # forces replacement

Control replacement with the lifecycle block:

resource "aws_instance" "web" {
  ami           = var.ami
  instance_type = "t3.small"
  lifecycle {
    create_before_destroy = true   # build the new one first, then remove the old one
    prevent_destroy       = false  # set true on things that must never be destroyed by a plan
  }
}

terraform plan -replace=aws_instance.web forces a replace on purpose (for a broken server), and terraform destroy plans the removal of everything in the state.

🏭 Why this matters in production: make "count the -/+ and - lines" part of every review. Put prevent_destroy = true on databases and buckets that hold data, so a plan that would destroy them fails instead.

⏭️ Next

One lab is easy. Many labs, for many towns, with slightly different sizes, need variables, outputs and loops.

git checkout lesson-04-variables-loops

← Previousresources providers Next →variables loops

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