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

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

🌪️ धडा 09 — Drift आणि import: कोणीतरी console मध्ये click केले

📍 तुम्ही इथे आहात: 12 पैकी धडा 09 · मागील: lesson-08-remote-state-locking · पुढील: lesson-10-environments

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

धडे 01–08, आणि त्यासोबत खरे जग. लोक अजूनही console मध्ये click करतात. Campus आराखड्यापासून आणि नोंदवहीपासून drift होतो — दूर सरकतो. कंत्राटदार refresh करून drift शोधते, आणि पुढचा plan गोष्टी पूर्वीसारख्या करतो — जोपर्यंत तुम्ही त्याला ignore_changes सांगत नाही. हाताने बांधलेली गोष्ट import block ने स्वीकारता येते, आणि नाव बदललेला address पुन्हा बांधण्याऐवजी moved block ने टिकवता येतो. drift() हे iac/demo.py मध्ये आहे; refresh() आणि import / moved ची हाताळणी iac/engine.py मधील plan() मध्ये.

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

आराखड्यात lab मध्ये 30 seats आहेत असे लिहिले आहे. मंगळवारी दीपिकाला एका परीक्षेसाठी जास्त खुर्च्या हव्या असतात, म्हणून ती स्वतःच आणखी 15 खुर्च्या आत आणते. 🪑 आता lab मध्ये 45 आहेत. आराखड्यात अजूनही 30 लिहिले आहे. नोंदवहीतही अजून 30 आहे.

कंत्राटदार परत येते तेव्हा ती आधी जागा फिरून पाहते 👀: "Room-01 मध्ये 45 seats आहेत, नोंदवही 30 सांगते — कोणीतरी हाताने बदलले आहे." मग plan: "आराखडा 30 सांगतो. 15 खुर्च्या बाहेर काढा." खुर्च्या तिथेच राहाव्यात असे शाळेला वाटत असेल, तर आराखड्यात 45 लिहायला हवे — किंवा "या खोलीतील seats कडे लक्ष देऊ नका" असे सांगायला हवे (ignore_changes).

मग ऐश्वर्याला एक मागचे फाटक सापडते जे कोणीतरी मागच्या वर्षी हाताने बांधले होते. ते आराखड्यात नाही, नोंदवहीत नाही. तिने ते फक्त आराखड्यात जोडले, तर कंत्राटदार दुसरे मागचे फाटक बांधेल. त्याऐवजी ती लिहिते: "school_gate.back नावाची गोष्ट म्हणजेच gate-02 आहे." ✍️ यालाच import म्हणतात. आता नोंदवहीला ते माहीत आहे, आणि काहीही नवीन बांधले जात नाही.

🗺️ आकृती

flowchart LR
    click["🖱️ console click<br/>seats 30 → 45"] --> campus["🏫 room-01"]
    campus -->|"refresh"| drift["drift: seats 30 → 45"]
    drift --> plan["plan: ~ seats 45 → 30"]
    drift --> ign["ignore_changes = [seats]<br/>→ No changes"]
    hand["🖐️ gate-02 built by hand"] --> imp["import { to = school_gate.back<br/>id = gate-02 }"]
    imp --> p2["Plan: 1 to import, 0 to add"]
    ren["rename lab → science"] --> mv["moved { from, to }<br/>→ 0 to add, 0 to destroy"]

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

❓ काय

Drift — खरी वस्तू state मध्ये नोंदवलेल्यापेक्षा वेगळी असणे, कारण Terraform च्या बाहेरच्या कशाने तरी ती बदलली (console click, script, दुसरे tool, किंवा स्वतः cloud). Delete झालेल्या वस्तू हाही drift च आहे.
Refresh — state मधील प्रत्येक वस्तू cloud मधून वाचणे. साधा plan हे आधी करतो. terraform plan -refresh-only फक्त drift दाखवतो ("Objects have changed outside of Terraform"); terraform apply -refresh-only cloud न बदलता तो drift state मध्ये लिहितो.
Drift परत फिरवणे — साधा plan cloud पुन्हा config शी जुळवू पाहतो. कधी ते बरोबर असते. कधी click बरोबर होता आणि config बदलायला हवे.
lifecycle { ignore_changes = [...] } — या arguments साठी बदलांचा plan करू नका (दुसऱ्या system च्या मालकीच्या fields साठी, जसे autoscaler चा desired count).
import block (Terraform 1.5+) — import { to = ADDRESS id = "REAL-ID" }. Plan N to import दाखवतो; apply ती वस्तू state मध्ये लिहितो. त्या address साठी config अस्तित्वात असायलाच हवे. जुना terraform import ADDRESS ID CLI हेच काम plan शिवाय लगेच करतो.
moved block (Terraform 1.1+) — moved { from = OLD to = NEW }. State मधील नोंदीचे नाव बदलते, त्यामुळे config मधील नावबदल म्हणजे destroy + create होत नाही.
removed block (Terraform 1.7+) — वस्तू destroy न करता एखादा address manage करणे थांबवा (धडा 05).

🤔 का

कारण drift मध्येच incidents लपलेले असतात. पुढचे, काहीही संबंध नसलेले apply रात्री 2 वाजता कोणीतरी केलेला hotfix गुपचूप उलटवते, किंवा plan मध्ये कोणीच न लिहिलेला बदल दिसतो. Drift लवकर शोधल्याने (एक scheduled plan -refresh-only) त्याचे रूपांतर चर्चेत होते. Import मुळे जुने, हाताने बांधलेले infrastructure downtime शिवाय आराखड्याखाली येते. आणि moved ने तुम्ही पुन्हा न बांधता refactor करता — नाव बदलणे, module मध्ये हलवणे, count वरून for_each वर जाणे.

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

iac/engine.py मधील refresh(state, cloud) प्रत्येक id वाचते; गायब वस्तू state मधून काढल्या जातात, बदललेले attributes drift ओळी म्हणून नोंदवले जातात. plan(..., refresh_only=True) तिथेच थांबते. lifecycle.ignore_changes त्या keys diff मधून काढून टाकते. cfg["import"] diff आधी वस्तू id ने state मध्ये वाचते आणि बदलाला imported अशी खूण करते. cfg["moved"] इतर कशाच्याही आधी state नोंदींची नावे बदलते. iac/cloud.py मधील FakeCloud.click() आणि click_create() म्हणजेच console.

🧪 करून पाहा

python3 iac/demo.py drift
python3 - <<'EOF'
import sys, copy; sys.path.insert(0, "iac")
from cloud import FakeCloud
from engine import plan, apply
cfg = {"resource": {"school_room": {"lab": {"name": "chem-lab", "floor": 2, "seats": 30}},
                    "school_gate": {"main": {"name": "main-gate", "room_id": "${school_room.lab.id}"}}}}
def fresh():
    cloud = FakeCloud(); st, _, _ = apply(plan(cfg, None, cloud), cloud); return cloud, st
cloud, st = fresh(); cloud.delete(st["resources"]["school_gate.main"]["id"])
print("gate deleted by hand  →", plan(cfg, st, cloud, refresh_only=True).drift, "→", plan(cfg, st, cloud).summary())
cloud, st = fresh(); cloud.click(st["resources"]["school_room.lab"]["id"], floor=3)
p = plan(cfg, st, cloud)
print("floor clicked 2 → 3   →", p.summary())
for line in p.lines(): print("     ", line.strip())
cloud, st = fresh()
h = cloud.click_create("school_gate", name="side-gate", room_id="room-01", open_hours="07-19")
imp = copy.deepcopy(cfg)
imp["resource"]["school_gate"]["side"] = {"name": "side-gate", "room_id": "${school_room.lab.id}"}
imp["import"] = [{"to": "school_gate.side", "id": h}]
p = plan(imp, st, cloud)
print(f"import {h} (built with open_hours 07-19, plans say the default 08-18) →", p.summary())
for line in p.lines(): print("     ", line.strip())
EOF

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

drift हे छापते:

   plan -refresh-only → ['school_room.lab has changed outside of Terraform: seats 30 → 45']
   plan → ~ school_room.lab  seats: 45 → 30 → Plan: 0 to add, 1 to change, 0 to destroy.
   with lifecycle ignore_changes = [seats] → No changes. Your infrastructure matches the configuration.
   plan with the gate in the plans but no import → Plan: 1 to add, 0 to change, 0 to destroy.  (a second gate)
   Plan: 1 to import, 0 to add, 0 to change, 0 to destroy.
   Apply complete! Resources: 1 imported, 0 added, 0 changed, 0 destroyed.
   without a moved block → Plan: 3 to add, 0 to change, 3 to destroy.  (the lab AND both gates would be rebuilt)
   with moved { from = school_room.lab, to = school_room.science } → school_room.lab has moved to school_room.science · Plan: 0 to add, 0 to change, 0 to destroy.

तुमचा snippet हे छापतो:

gate deleted by hand  → ['school_gate.main has been deleted outside of Terraform'] → Plan: 1 to add, 0 to change, 0 to destroy.
floor clicked 2 → 3   → Plan: 2 to add, 0 to change, 2 to destroy.
      -/+ school_room.lab  floor: 3 → 2  # forces replacement
      -/+ school_gate.main  room_id: 'room-01' → (known after apply)  # forces replacement
import gate-02 (built with open_hours 07-19, plans say the default 08-18) → Plan: 1 to import, 0 to add, 1 to change, 0 to destroy.
      ← school_gate.side will be imported (id gate-02)
      ~ school_gate.side  open_hours: '07-19' → '08-18'

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

Plan नेहमी खरा campus पाहूनच सुरू होतो, म्हणून drift दिसतोच — आणि "ते पूर्वीसारखे करणे" स्वस्त असू शकते (seats, एक update) किंवा महाग: ForceNew field परत फिरवणे म्हणजे replace, आणि त्या खोलीचा reference असलेले gate सुद्धा त्यासोबत replace होते (2 to add, 2 to destroy). (शिकवण्याचा campus console ला ForceNew field बदलू देतो; खऱ्या cloud वर असा बदल सहसा नव्या id सह हाताने केलेली पुनर्बांधणी असते, जी refresh ला "deleted" दिसते.) Import ने दुसरे gate बांधण्याऐवजी अस्तित्वात असलेले gate स्वीकारले — आणि plan ने हेही दाखवले की हाताने बांधलेले gate आराखड्यापेक्षा कुठे वेगळे आहे. moved block ने 3-आणि-3 पुनर्बांधणीचे रूपांतर शून्य बदलांत केले.

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

production console मध्ये "दुरुस्त" करणे आणि ते कधीच आराखड्यात परत न लिहिणे — पुढचे apply ते उलटवते
गोंगाट करणारा plan शांत करण्यासाठी ignore_changes = all — आता आराखडा काहीच manage करत नाही
जुळणारे config न लिहिता import करणे, आणि मग diff न वाचता apply करणे
moved blocks शिवाय resources ची नावे बदलणे किंवा त्यांना module मध्ये हलवणे
एखादा असंबंधित बदल त्यावर आदळेपर्यंत drift कधीच न तपासणे

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

खऱ्या account वर — drift शोधा, स्वीकारा, नाव बदला:

terraform plan -refresh-only                   # "Objects have changed outside of Terraform"
terraform apply -refresh-only                  # accept the drift into the state (no cloud changes)
terraform plan -detailed-exitcode              # exit 0 = no changes, 2 = changes: good for a nightly drift job

import {
  to = aws_s3_bucket.reports
  id = "school-reports-2019"       # the id format is on the resource's docs page, under "Import"
}

moved {
  from = aws_s3_bucket.locker[0]
  to   = aws_s3_bucket.locker["a"]
}

resource "aws_autoscaling_group" "web" {
  # ...
  lifecycle { ignore_changes = [desired_capacity] }   # the autoscaler owns this number
}

terraform plan -generate-config-out=generated.tf   # with import blocks: draft config for them (Terraform 1.5+, marked experimental)

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे आहे: प्रत्येक state साठी schedule वर terraform plan -detailed-exitcode चालवा आणि exit code 2 आला की alert द्या. प्रत्येक alert म्हणजे एकतर आराखड्यात लिहायचा बदल, किंवा थांबवायचा click.

⏭️ पुढे

आता त्याच आराखड्याने dev, staging आणि prod बांधायचे आहेत — एकाने दुसऱ्याला हात न लावता. पुढे: environments.

git checkout lesson-10-environments

🌪️ Lesson 09 — Drift & import: someone clicked in the console

📍 You are here: Lesson 09 of 12 · Previous: lesson-08-remote-state-locking · Next: lesson-10-environments

📦 What's in this branch

Lessons 01–08, plus the real world. People still click in the console. The campus drifts away from the plans and the register. The contractor finds drift with a refresh, and the next plan puts things back — unless you tell it to ignore_changes. A thing built by hand can be adopted with an import block, and a renamed address can be kept with a moved block instead of a rebuild. drift() in iac/demo.py; refresh() and the import / moved handling in plan() in iac/engine.py.

🧒 Explain like I'm 5

The plans say the lab has 30 seats. On Tuesday, Dipika needs more chairs for an exam, so she carries in 15 more herself. 🪑 Now the lab has 45. The plans still say 30. The register still says 30.

When the contractor comes back, she walks the site first 👀: "Room-01 has 45 seats, the register says 30 — someone changed it by hand." Then the plan: "The plans say 30. Take 15 chairs out." If the school wants the chairs to stay, the plans must say 45 — or say "don't watch the seats in this room" (ignore_changes).

Then Aishwarya finds a back gate that someone built by hand last year. It's not in the plans, not in the register. If she just adds it to the plans, the contractor will build a second back gate. Instead she writes: "the thing called school_gate.back is gate-02." ✍️ That's an import. Now the register knows it, and nothing new is built.

🗺️ Diagram

flowchart LR
    click["🖱️ console click<br/>seats 30 → 45"] --> campus["🏫 room-01"]
    campus -->|"refresh"| drift["drift: seats 30 → 45"]
    drift --> plan["plan: ~ seats 45 → 30"]
    drift --> ign["ignore_changes = [seats]<br/>→ No changes"]
    hand["🖐️ gate-02 built by hand"] --> imp["import { to = school_gate.back<br/>id = gate-02 }"]
    imp --> p2["Plan: 1 to import, 0 to add"]
    ren["rename lab → science"] --> mv["moved { from, to }<br/>→ 0 to add, 0 to destroy"]

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

❓ What

Drift — the real object differs from what the state recorded, because something outside Terraform changed it (a console click, a script, another tool, the cloud itself). Deleted objects are drift too.
Refresh — reading every object in the state from the cloud. A normal plan does it first. terraform plan -refresh-only only shows the drift ("Objects have changed outside of Terraform"); terraform apply -refresh-only writes it into the state without changing the cloud.
Reverting drift — the normal plan wants to make the cloud match the config again. Sometimes that is right. Sometimes the click was right and the config must change.
lifecycle { ignore_changes = [...] } — don't plan changes for these arguments (for fields another system owns, like an autoscaler's desired count).
import block (Terraform 1.5+) — import { to = ADDRESS id = "REAL-ID" }. The plan shows N to import; apply writes the object into the state. The config for the address must exist. The older terraform import ADDRESS ID CLI does the same immediately, without a plan.
moved block (Terraform 1.1+) — moved { from = OLD to = NEW }. The state entry is renamed, so a rename in the config is not a destroy + create.
removed block (Terraform 1.7+) — stop managing an address without destroying the object (lesson 05).

🤔 Why

Because drift is where incidents hide. The next unrelated apply quietly reverts a hotfix someone made at 2 a.m., or a plan shows a change nobody wrote. Finding drift early (a scheduled plan -refresh-only) turns it into a conversation. Import is how old, hand-built infrastructure comes under the plans without downtime. And moved is how you refactor — rename, move into a module, switch count to for_each — without rebuilding.

🔧 How (in this repo)

refresh(state, cloud) in iac/engine.py reads every id; missing objects are dropped from the state, changed attributes are recorded as drift lines. plan(..., refresh_only=True) stops there. lifecycle.ignore_changes removes those keys from the diff. cfg["import"] reads the object by id into the state before the diff and marks the change imported. cfg["moved"] renames state entries before anything else. FakeCloud.click() and click_create() in iac/cloud.py are the console.

🧪 Try it

python3 iac/demo.py drift
python3 - <<'EOF'
import sys, copy; sys.path.insert(0, "iac")
from cloud import FakeCloud
from engine import plan, apply
cfg = {"resource": {"school_room": {"lab": {"name": "chem-lab", "floor": 2, "seats": 30}},
                    "school_gate": {"main": {"name": "main-gate", "room_id": "${school_room.lab.id}"}}}}
def fresh():
    cloud = FakeCloud(); st, _, _ = apply(plan(cfg, None, cloud), cloud); return cloud, st
cloud, st = fresh(); cloud.delete(st["resources"]["school_gate.main"]["id"])
print("gate deleted by hand  →", plan(cfg, st, cloud, refresh_only=True).drift, "→", plan(cfg, st, cloud).summary())
cloud, st = fresh(); cloud.click(st["resources"]["school_room.lab"]["id"], floor=3)
p = plan(cfg, st, cloud)
print("floor clicked 2 → 3   →", p.summary())
for line in p.lines(): print("     ", line.strip())
cloud, st = fresh()
h = cloud.click_create("school_gate", name="side-gate", room_id="room-01", open_hours="07-19")
imp = copy.deepcopy(cfg)
imp["resource"]["school_gate"]["side"] = {"name": "side-gate", "room_id": "${school_room.lab.id}"}
imp["import"] = [{"to": "school_gate.side", "id": h}]
p = plan(imp, st, cloud)
print(f"import {h} (built with open_hours 07-19, plans say the default 08-18) →", p.summary())
for line in p.lines(): print("     ", line.strip())
EOF

✅ Verify — what you should see

drift prints:

   plan -refresh-only → ['school_room.lab has changed outside of Terraform: seats 30 → 45']
   plan → ~ school_room.lab  seats: 45 → 30 → Plan: 0 to add, 1 to change, 0 to destroy.
   with lifecycle ignore_changes = [seats] → No changes. Your infrastructure matches the configuration.
   plan with the gate in the plans but no import → Plan: 1 to add, 0 to change, 0 to destroy.  (a second gate)
   Plan: 1 to import, 0 to add, 0 to change, 0 to destroy.
   Apply complete! Resources: 1 imported, 0 added, 0 changed, 0 destroyed.
   without a moved block → Plan: 3 to add, 0 to change, 3 to destroy.  (the lab AND both gates would be rebuilt)
   with moved { from = school_room.lab, to = school_room.science } → school_room.lab has moved to school_room.science · Plan: 0 to add, 0 to change, 0 to destroy.

Your snippet prints:

gate deleted by hand  → ['school_gate.main has been deleted outside of Terraform'] → Plan: 1 to add, 0 to change, 0 to destroy.
floor clicked 2 → 3   → Plan: 2 to add, 0 to change, 2 to destroy.
      -/+ school_room.lab  floor: 3 → 2  # forces replacement
      -/+ school_gate.main  room_id: 'room-01' → (known after apply)  # forces replacement
import gate-02 (built with open_hours 07-19, plans say the default 08-18) → Plan: 1 to import, 0 to add, 1 to change, 0 to destroy.
      ← school_gate.side will be imported (id gate-02)
      ~ school_gate.side  open_hours: '07-19' → '08-18'

🏁 What you just proved

A plan always starts by looking at the real campus, so drift shows up — and "putting it back" can be cheap (seats, an update) or expensive: reverting a ForceNew field is a replace, and the gate that references the room is replaced with it (2 to add, 2 to destroy). (The teaching campus lets the console change a ForceNew field; on a real cloud, such a change is usually a hand-made rebuild with a new id, which a refresh sees as "deleted".) Import adopted an existing gate instead of building a second one — and the plan also showed where the hand-built gate differs from the plans. A moved block turned a 3-and-3 rebuild into zero changes.

⚠️ Common mistakes

"fixing" production in the console and never writing it back into the plans — the next apply reverts it
ignore_changes = all to make a noisy plan go quiet — now the plans manage nothing
importing without writing matching config, then applying the diff without reading it
renaming resources or moving them into a module without moved blocks
never checking for drift until an unrelated change hits it

🏭 In production

On a real account — find drift, adopt, rename:

terraform plan -refresh-only                   # "Objects have changed outside of Terraform"
terraform apply -refresh-only                  # accept the drift into the state (no cloud changes)
terraform plan -detailed-exitcode              # exit 0 = no changes, 2 = changes: good for a nightly drift job

import {
  to = aws_s3_bucket.reports
  id = "school-reports-2019"       # the id format is on the resource's docs page, under "Import"
}

moved {
  from = aws_s3_bucket.locker[0]
  to   = aws_s3_bucket.locker["a"]
}

resource "aws_autoscaling_group" "web" {
  # ...
  lifecycle { ignore_changes = [desired_capacity] }   # the autoscaler owns this number
}

terraform plan -generate-config-out=generated.tf   # with import blocks: draft config for them (Terraform 1.5+, marked experimental)

🏭 Why this matters in production: run terraform plan -detailed-exitcode on a schedule for every state and alert on exit code 2. Every alert is either a change to write into the plans or a click to stop.

⏭️ Next

The same plans now need to build dev, staging and prod — without one touching another. Next: environments.

git checkout lesson-10-environments

← Previousremote state locking Next →environments

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