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

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

📜 धडा 01 — Infrastructure as code का: clicks विरुद्ध लिखित आराखडे

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

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

संपूर्ण कोर्स ज्या एका कल्पनेबद्दल आहे ती: शाळेचे बांधकाम कार्यालय खोल्या, gates आणि lockers बांधते. आतापर्यंत एक clerk ते हाताने बांधत असे, web console मध्ये click करत. आजपासून कार्यालय लिखित बांधकाम आराखडे ठेवते, आणि एक कंत्राटदार त्यावरून बांधकाम करतो. खऱ्या आयुष्यात आराखडा म्हणजे Terraform (किंवा OpenTofu) files, कंत्राटदार म्हणजे terraform program, आणि campus म्हणजे तुमचे cloud account. संपूर्ण कोर्सभर तुम्ही वापराल त्या खऱ्या files:

iac/cloud.py — campus: memory मधील एक बनावट cloud, तीन resource types सह (school_room, school_gate, school_locker)
iac/engine.py — कंत्राटदार: plan, apply, state, dependency graph, modules, कुलूप असलेला remote backend
iac/checks.py — तपासनीस: policy, cost, tests आणि एक CI pipeline
iac/demo.py — प्रत्येक धडा एक छोटा program म्हणून (python3 iac/demo.py <section>; sections: why resources plan variables state graph modules locking drift environments policy pipeline)
iac/test_iac.py — कंत्राटदाराच्या नियमांवरील 12 checks
demo-output.txt — निरोगी run काय print करतो ते

🎒 सुरू करण्याआधी: तुम्हाला फक्त Python 3 लागेल, बाकी काही नाही — cloud account नको, pip install नको, terraform binary नको. iac/ folder हे Terraform कसे काम करते याचे शिकवण्यासाठीचे model आहे, स्वतः Terraform नाही. Randomness seeded आहे, म्हणून प्रत्येक run तीच गोष्ट print करतो. खऱ्या account वर असे लिहिलेल्या commands साठी Terraform (1.5 किंवा नवीन) आणि खरे cloud account लागते, आणि त्यांचा खर्च येऊ शकतो.

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

शाळेला तीन गावांत एक नवीन science wing हवी आहे: एक chemistry lab, एक मुख्य gate आणि तीन lockers. तीच wing, तीन वेळा.

कतरिना, clerk, प्रत्येक wing हाताने बांधते. ती प्रत्येक तपशील एका form मध्ये टाइप करते: खोलीचे नाव, floor, seats ची संख्या, gate उघडण्याच्या वेळा. प्रत्येक site ला आठ fields. ती काळजीपूर्वक काम करते. पण तिसऱ्या site वर ती floor 2 ऐवजी floor 20 टाइप करते. कोणाच्याच लक्षात येत नाही. आता तिन्ही wings सारख्या नाहीत, आणि का ते कोणीच लिहून ठेवलेले नाही.

मग दीपिकाला एक कल्पना सुचते. "आपण आराखडा एकदाच लिहून ठेवू. 📜 मग कंत्राटदार आराखड्यावरून, जसा लिहिला आहे तसाच, दर वेळी बांधेल."

आता तिन्ही wings सारख्या आहेत. आणि कंत्राटदार त्याच आराखड्यासह पूर्ण झालेल्या wing ला पुन्हा भेट देतो तेव्हा तो म्हणतो: "काहीच करायचे नाही. Wing आधीच आराखड्याशी जुळते." 👷

🗺️ आकृती

flowchart LR
    subgraph hand["🖱️ by hand"]
      k["Katrina types 8 fields<br/>per site"] --> d1["dev ✅"]
      k --> s1["staging ✅"]
      k --> p1["prod ❌ floor 20"]
    end
    subgraph plans["📜 written plans"]
      f["one config file<br/>(in git)"] --> c["👷 the contractor<br/>(terraform apply)"]
      c --> d2["dev ✅"]
      c --> s2["staging ✅"]
      c --> p2["prod ✅"]
      c -.->|"run again"| n["No changes."]
    end

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

❓ काय

Infrastructure — तुमचे software ज्यावर चालते त्या गोष्टी: networks, servers, databases, buckets, DNS records, permissions. इथे: खोल्या, gates आणि lockers.
ClickOps — web console मध्ये हाताने infrastructure बांधणे. पहिल्या वेळी जलद. पण पुन्हा करायला अवघड, review करायला अवघड, आणि एखादी setting तशी का आहे याची कुठेच नोंद नसते.
Infrastructure as Code (IaC) — तुम्ही infrastructure चे वर्णन text files मध्ये करता, त्या version control (git) मध्ये ठेवता, code प्रमाणेच बदलांचे review करता, आणि एखादे tool खऱ्या गोष्टी तयार करते व बदलते.
Declarative — files सांगतात काय असायला हवे ("30 seats असलेली एक lab"), तिथे पोहोचण्याच्या पायऱ्या नाही. पायऱ्या tool ठरवते. Terraform, OpenTofu, AWS CloudFormation आणि Pulumi (त्याच्या पद्धतीने) declarative आहेत. aws ec2 run-instances calls ने भरलेली shell script imperative असते: ती पायऱ्या सांगते.
Idempotent — काहीही न बदलता पुन्हा चालवले तर काहीच होत नाही. Demo तोच आराखडा दुसऱ्यांदा apply करतो आणि त्याला No changes. मिळते.
Terraform आणि OpenTofu — Terraform हे HashiCorp चे IaC tool आहे. 2023 मध्ये HashiCorp ने ते Business Source License (BUSL 1.1) खाली नेले. OpenTofu हा Linux Foundation खालील open-source fork (MPL 2.0) आहे. या कोर्समधील भाषा आणि workflow दोन्हींमध्ये सारखे आहेत: terraform plan किंवा tofu plan.

🤔 का

कारण हाताने बांधलेला campus कोणीच पुन्हा बांधू शकत नाही. रात्री 2 वाजता prod बिघडले की प्रश्न असतो "काय बदलले?" Clicks असतील तर उत्तर कोणाच्या तरी आठवणीत असते. Git मधील आराखड्यासह उत्तर म्हणजे author, तारीख आणि review असलेला एक commit. आराखड्यामुळे dev, staging आणि prod मध्ये तीच गोष्ट बांधता येते, म्हणून staging मधील test ला काहीतरी अर्थ असतो. आणि प्रत्येक click मागची छोटीशी चूक पटकन वाढत जाते: खालचा करून-पाहा दाखवतो की प्रत्येक field ला फक्त 2% चूक असली तरी दहापैकी एक site बिघडते.

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

iac/cloud.py मधील by_hand(cloud, rng, slip) म्हणजे console वरची कतरिना: प्रत्येक site ला 8 fields, आणि प्रत्येक field मध्ये चूक होण्याची slip शक्यता (एखादा आकडा ×10 टाइप होणे, दोन अक्षरांची अदलाबदल, एखादा locker विसरणे). fingerprint(cloud) campus ने निवडलेल्या ids शिवाय site चे वर्णन करते, म्हणून सारख्या पद्धतीने बांधलेल्या दोन sites जुळतात. iac/demo.py मधील why() तीन sites हाताने बांधते, मग तीन आराखड्यावरून (CAMPUS, एक config dict) iac/engine.py मधील plan() आणि apply() वापरून बांधते, आणि मग पूर्ण झालेल्या site विरुद्ध आणखी एकदा plan करते.

🧪 करून पाहा

python3 iac/demo.py why
python3 - <<'EOF'
import sys; sys.path.insert(0, "iac")
from cloud import FakeCloud, Rng, by_hand, fingerprint
from engine import plan, apply
from demo import CAMPUS
good = FakeCloud(); apply(plan(CAMPUS, None, good), good); want = fingerprint(good)
for slip in (0.0, 0.02, 0.05, 0.1, 0.2):
    rng, ok = Rng(5), 0
    for site in range(10):
        c = FakeCloud(); by_hand(c, rng, slip); ok += fingerprint(c) == want
    print(f"slip {slip:>4.0%} per field → {ok:>2} of 10 hand-built sites match the plans")
EOF
python3 iac/test_iac.py

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

why असे print करते:

── the works office builds the same campus 3 times BY HAND (8 fields per site, 10% chance of a slip per field)
   dev      8 fields typed · 5 objects · slips: none
   staging  8 fields typed · 5 objects · slips: none
   prod     8 fields typed · 5 objects · slips: floor typed 20 instead of 2
   do the 3 hand-built sites match? False
   do the 3 plan-built sites match? True
── apply the same plans to the dev site again → No changes. Your infrastructure matches the configuration.

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

slip   0% per field → 10 of 10 hand-built sites match the plans
slip   2% per field →  9 of 10 hand-built sites match the plans
slip   5% per field →  7 of 10 hand-built sites match the plans
slip  10% per field →  5 of 10 hand-built sites match the plans
slip  20% per field →  2 of 10 hand-built sites match the plans

Tests च्या शेवटी 12/12 passed येते.

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

आराखड्याने तीन एकसारख्या sites बांधल्या, आणि दुसऱ्या run ने काहीच बदलले नाही — आराखडा पुन्हा-पुन्हा सारखाच (repeatable) आणि idempotent आहे. हाताने बांधताना निकाल नशिबावर अवलंबून असतो: 10% slip rate ला 10 पैकी फक्त 5 sites बरोबर आल्या, आणि 2% ला सुद्धा दहापैकी एक site चुकीची होती. (हे slip rates काल्पनिक आहेत; मुद्दा हा आहे की प्रत्येक click मधील छोट्या चुका अनेक fields आणि अनेक sites मध्ये गुणाकाराने वाढतात.)

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

आराखडा लिहून मग console मध्ये "पटकन" काहीतरी दुरुस्त करणे (धडा 09 त्याची किंमत दाखवतो)
IaC files ना वरून खाली चालणाऱ्या scripts समजणे — त्या शेवटच्या स्थितीचे वर्णन करतात
आराखडा git मध्ये reviews सह ठेवण्याऐवजी एकाच laptop वर ठेवणे
संपूर्ण company च्या infrastructure पासून सुरुवात करणे — एका छोट्या, नव्या तुकड्यापासून सुरू करा
IaC मुळे cloud समजून घेण्याची गरज संपते असे वाटणे — आराखडा त्याच्या लेखकाइतकाच चांगला असतो

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

खऱ्या account वर — सर्वात छोटा खरा Terraform workflow. Terraform (किंवा OpenTofu) install करा, एक main.tf लिहा, आणि मग:

terraform init      # download the providers named in the config (lesson 02)
terraform plan      # show what would change — nothing is built yet (lesson 03)
terraform apply     # show the plan again, ask "yes", then build it
terraform apply     # run it again: "No changes. Your infrastructure matches the configuration."

OpenTofu मध्ये commands तशाच आहेत, फक्त terraform ऐवजी tofu. तुम्हाला भेटणारी इतर IaC tools:

AWS CloudFormation आणि AWS CDK — फक्त AWS; CloudFormation state तुमच्यासाठी सांभाळते.
Pulumi — आराखडा TypeScript, Python, Go किंवा C# मध्ये लिहिला जातो, plan/apply सारख्याच कल्पनेसह.
Ansible, Chef, Puppet — मुख्यतः configuration management: server च्या आत काय चालते. Terraform मुख्यतः servers, networks आणि services स्वतःच तयार करते.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: आज हाताने बांधलेला infrastructure चा एक तुकडा निवडा (एक bucket, एक DNS zone, एक छोटी service). तो code म्हणून लिहा, अस्तित्वात असलेले objects import करा (धडा 09), आणि त्या तुकड्यासाठी "console मध्ये बदल नाहीत" हा नियम करा.

⏭️ पुढे

आराखड्याला एक शब्दसंग्रह लागतो: resource म्हणजे काय, provider कोण, आणि आराखड्यात कोणती fields ठरवता येतात?

git checkout lesson-02-resources-providers

📜 Lesson 01 — Why infrastructure as code: clicks vs written plans

📍 You are here: Lesson 01 of 12 · Next: lesson-02-resources-providers

📦 What's in this branch

The one idea this whole course is about: the school's works office builds rooms, gates and lockers. Until now, a clerk built them by hand, clicking through a web console. From today the office keeps written building plans, and a contractor builds from them. In real life the plans are Terraform (or OpenTofu) files, the contractor is the terraform program, and the campus is your cloud account. Real files you will use all the way through:

iac/cloud.py — the campus: a fake cloud in memory with three resource types (school_room, school_gate, school_locker)
iac/engine.py — the contractor: plan, apply, state, the dependency graph, modules, a remote backend with a lock
iac/checks.py — the inspectors: policy, cost, tests and a CI pipeline
iac/demo.py — every lesson as a small program (python3 iac/demo.py <section>; sections: why resources plan variables state graph modules locking drift environments policy pipeline)
iac/test_iac.py — 12 checks on the contractor's rules
demo-output.txt — what a healthy run prints

🎒 Before you start: you need Python 3 and nothing else — no cloud account, no pip install, no terraform binary. The iac/ folder is a teaching model of how Terraform works, not Terraform itself. Randomness is seeded, so every run prints the same story. Commands marked on a real account need Terraform (1.5 or newer) and a real cloud account, and they can cost money.

🧒 Explain like I'm 5

The school needs a new science wing in three towns: a chemistry lab, a main gate and three lockers. Same wing, three times.

Katrina, the clerk, builds each one by hand. She types every detail into a form: the room name, the floor, the number of seats, the gate's opening hours. Eight fields per site. She is careful. But on the third site she types floor 20 instead of floor 2. Nobody notices. Now the three wings are not the same, and nobody wrote down why.

Then Dipika has an idea. "Let's write the plans down once. 📜 Then a contractor builds from the plans, exactly as written, every time."

Now the three wings are the same. And when the contractor visits a finished wing again with the same plans, it says: "Nothing to do. The wing already matches the plans." 👷

🗺️ Diagram

flowchart LR
    subgraph hand["🖱️ by hand"]
      k["Katrina types 8 fields<br/>per site"] --> d1["dev ✅"]
      k --> s1["staging ✅"]
      k --> p1["prod ❌ floor 20"]
    end
    subgraph plans["📜 written plans"]
      f["one config file<br/>(in git)"] --> c["👷 the contractor<br/>(terraform apply)"]
      c --> d2["dev ✅"]
      c --> s2["staging ✅"]
      c --> p2["prod ✅"]
      c -.->|"run again"| n["No changes."]
    end

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

❓ What

Infrastructure — the things your software runs on: networks, servers, databases, buckets, DNS records, permissions. Here: rooms, gates and lockers.
ClickOps — building infrastructure by hand in a web console. Fast the first time. Hard to repeat, hard to review, and there is no record of why a setting is what it is.
Infrastructure as Code (IaC) — you describe the infrastructure in text files, keep them in version control (git), review changes like code, and let a tool create and change the real things.
Declarative — the files say what should exist ("a lab with 30 seats"), not the steps to get there. The tool works out the steps. Terraform, OpenTofu, AWS CloudFormation and Pulumi (in its own way) are declarative. A shell script full of aws ec2 run-instances calls is imperative: it says the steps.
Idempotent — running it again with no changes does nothing. The demo applies the same plans a second time and gets No changes.
Terraform and OpenTofu — Terraform is HashiCorp's IaC tool. In 2023 HashiCorp moved it to the Business Source License (BUSL 1.1). OpenTofu is the open-source fork (MPL 2.0) under the Linux Foundation. The language and the workflow in this course are the same in both: terraform plan or tofu plan.

🤔 Why

Because a campus built by hand is a campus nobody can rebuild. When prod breaks at 2 a.m., the question is "what changed?" With clicks, the answer is in someone's memory. With plans in git, the answer is a commit with an author, a date and a review. Plans also let you build the same thing in dev, staging and prod, so a test in staging means something. And a small slip rate per click adds up fast: the Try-it below shows that even 2% per field breaks one site in ten.

🔧 How (in this repo)

by_hand(cloud, rng, slip) in iac/cloud.py is Katrina at the console: 8 fields per site, and each field has a slip chance of a mistake (a number typed ×10, two characters swapped, a locker forgotten). fingerprint(cloud) describes a site without the ids the campus chose, so two sites built the same way match. why() in iac/demo.py builds three sites by hand, then three from the plans (CAMPUS, a config dict) with plan() and apply() from iac/engine.py, and then plans once more against a finished site.

🧪 Try it

python3 iac/demo.py why
python3 - <<'EOF'
import sys; sys.path.insert(0, "iac")
from cloud import FakeCloud, Rng, by_hand, fingerprint
from engine import plan, apply
from demo import CAMPUS
good = FakeCloud(); apply(plan(CAMPUS, None, good), good); want = fingerprint(good)
for slip in (0.0, 0.02, 0.05, 0.1, 0.2):
    rng, ok = Rng(5), 0
    for site in range(10):
        c = FakeCloud(); by_hand(c, rng, slip); ok += fingerprint(c) == want
    print(f"slip {slip:>4.0%} per field → {ok:>2} of 10 hand-built sites match the plans")
EOF
python3 iac/test_iac.py

✅ Verify — what you should see

why prints:

── the works office builds the same campus 3 times BY HAND (8 fields per site, 10% chance of a slip per field)
   dev      8 fields typed · 5 objects · slips: none
   staging  8 fields typed · 5 objects · slips: none
   prod     8 fields typed · 5 objects · slips: floor typed 20 instead of 2
   do the 3 hand-built sites match? False
   do the 3 plan-built sites match? True
── apply the same plans to the dev site again → No changes. Your infrastructure matches the configuration.

Your snippet prints:

slip   0% per field → 10 of 10 hand-built sites match the plans
slip   2% per field →  9 of 10 hand-built sites match the plans
slip   5% per field →  7 of 10 hand-built sites match the plans
slip  10% per field →  5 of 10 hand-built sites match the plans
slip  20% per field →  2 of 10 hand-built sites match the plans

The tests end with 12/12 passed.

🏁 What you just proved

The plans built three identical sites, and a second run changed nothing — the plans are repeatable and idempotent. By hand, the result depends on luck: at a 10% slip rate only 5 of 10 sites came out right, and even at 2% one site in ten was wrong. (The slip rates are made up; the point is that small per-click errors multiply over many fields and many sites.)

⚠️ Common mistakes

writing plans, then "just quickly" fixing something in the console (lesson 09 shows the cost)
treating IaC files as scripts that run top to bottom — they describe the end state
keeping the plans on one laptop instead of in git with reviews
starting with the whole company's infrastructure — start with one small, new piece
thinking IaC removes the need to understand the cloud — the plans are only as good as their author

🏭 In production

On a real account — the smallest real Terraform workflow. Install Terraform (or OpenTofu), write a main.tf, then:

terraform init      # download the providers named in the config (lesson 02)
terraform plan      # show what would change — nothing is built yet (lesson 03)
terraform apply     # show the plan again, ask "yes", then build it
terraform apply     # run it again: "No changes. Your infrastructure matches the configuration."

With OpenTofu the commands are the same, with tofu instead of terraform. Other IaC tools you will meet:

AWS CloudFormation and AWS CDK — AWS only; CloudFormation keeps the state for you.
Pulumi — the plans are written in TypeScript, Python, Go or C#, with a similar plan/apply idea.
Ansible, Chef, Puppet — mostly configuration management: what runs inside a server. Terraform mostly creates the servers, networks and services themselves.

🏭 Why this matters in production: pick one piece of infrastructure that is built by hand today (a bucket, a DNS zone, a small service). Write it as code, import the existing objects (lesson 09), and make "no console changes" the rule for that piece.

⏭️ Next

Plans need a vocabulary: what is a resource, who is the provider, and which fields may the plans set?

git checkout lesson-02-resources-providers

← Course homeall lessons Next →resources providers

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