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

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

🧱 धडा 02 — Resources आणि providers: आराखड्यात काय लिहिता येते

📍 तुम्ही इथे आहात: धडा 02 / 12 · मागे: lesson-01-why-iac · पुढे: lesson-03-plan-apply

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

धडा 01, आणि आराखड्याचा शब्दसंग्रह. एक resource block campus वरील एका गोष्टीचे वर्णन करतो. एका provider ला त्या प्रकारची गोष्ट कशी बांधायची ते माहीत असते आणि तो एक schema प्रसिद्ध करतो: कोणते arguments required आहेत, कोणत्यांना defaults आहेत, कोणते campus स्वतः भरतो (computed, जसे id), आणि कोणते नवीन object बांधल्याशिवाय बदलता येत नाहीत (ForceNew). iac/demo.py मधील resources(), iac/cloud.py मधील SCHEMAS आणि FakeCloud, iac/engine.py मधील to_hcl() आणि validate().

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

आराखडा एका खास form वर लिहिला जातो. 📋 Form वरील प्रत्येक चौकट काय बांधायचे ते सांगते:

Room called lab · name: chem-lab · floor: 2 · seats: 30

खोल्या बांधणाऱ्या कंत्राटदाराकडे एक नियम-पुस्तक असते. त्यात लिहिलेले असते:

name — हे तुम्ही लिहायलाच हवे. 🖊️
floor — रिकामे सोडले तर floor 1. आणि खोली एकदा बांधली की तुम्ही ती दुसऱ्या floor वर हलवू शकत नाही. त्यासाठी नवी खोली लागेल. 🧱
seats — काही न सांगितल्यास 30. हे नंतर बदलता येते.
id — हे लिहू नका. खोली बांधली की campus प्रत्येक खोलीला तिचा स्वतःचा नंबर देतो, जसे room-01. 🏷️

Gate च्या form मध्ये room नावाची एक चौकट असते. तिथे तुम्ही नंबर लिहीत नाही. तुम्ही "lab चा id" असे लिहिता, आणि lab तयार झाल्यावर कंत्राटदार खरा नंबर भरतो.

🗺️ आकृती

flowchart LR
    plans["📜 the plans<br/>resource school_room lab<br/>name, floor, seats"]
    schema["📖 provider schema<br/>name: required<br/>floor: default 1, ForceNew<br/>seats: default 30<br/>id: computed"]
    prov["👷 provider<br/>(a plugin)"]
    api["🏫 campus API<br/>POST /rooms"]
    plans --> prov
    schema --- prov
    prov -->|"create"| api
    api -->|"id = room-01"| prov

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

❓ काय

Resource block — resource "TYPE" "NAME" { ... }. TYPE सांगते कोणत्या प्रकारची गोष्ट (aws_s3_bucket, school_room), NAME हे तिच्यासाठी तुमचे स्थानिक लेबल (lab). दोन्ही मिळून address बनतो: school_room.lab. नाव फक्त आराखड्यासाठी असते; खऱ्या object ला cloud कडून id मिळतो.
Arguments — block च्या आत तुम्ही जे ठरवता ते (name = "chem-lab").
Attributes — object तयार झाल्यावर त्याच्याकडे असलेले सर्व काही, cloud निवडते ते computed सुद्धा (id, एक ARN, एक IP address).
Reference — दुसऱ्या block मधील school_room.lab.id चा अर्थ "lab तयार झाल्यावर तिचा id". खऱ्या HCL मध्ये तुम्ही ते सरळ लिहिता: room_id = school_room.lab.id. Lab ते Python string मध्ये "${school_room.lab.id}" असे लिहिते; अर्थ तोच.
Provider — एक API ओळखणारा plugin: hashicorp/aws, hashicorp/google, hashicorp/kubernetes, cloudflare/cloudflare आणि Terraform Registry वरील आणखी हजारो. Terraform core planning करते; provider create, read, update आणि delete calls करतो.
Schema — प्रत्येक resource type साठी provider चे नियम-पुस्तक: argument names, types, required की optional, defaults, computed, ForceNew (बदलले तर replace), sensitive (output मध्ये लपवा).
Data source — data "TYPE" "NAME" आधीच अस्तित्वात असलेली गोष्ट वाचते, तिचे व्यवस्थापन न करता (उदाहरणार्थ, सर्वात नवीन machine image). Lab मध्ये एकही नाही; धडा 09 import करण्याची संबंधित कल्पना दाखवतो.

🤔 का

कारण schema मुळेच कंत्राटदार न बांधता plan करू शकतो. त्याला माहीत असते की seats जागीच बदलू शकते पण floor नाही, आणि id campus कडून येतो. तो कोणताही API call करण्याआधी चूक नाकारू शकतो: अनोळखी argument, हरवलेला required argument, आकड्याच्या जागी मजकूर. Provider वेगळा असल्यामुळे Terraform core तेच राहते आणि प्रत्येक API साठी एक plugin बोलण्याचे काम करतो.

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

iac/cloud.py मधील SCHEMAS हे तीन types साठीचे provider schema आहे. with_defaults() आराखड्याने सोडलेले defaults भरते. FakeCloud.create() object साठवते, room-01 सारखा id निवडते, आणि API call cloud.calls मध्ये नोंदवते. Engine चे validate() config ला SCHEMAS विरुद्ध तपासते. to_hcl() config dict HCL म्हणून print करते, म्हणजे तुम्ही ते खऱ्या .tf file शी ताडून पाहू शकता.

🧪 करून पाहा

python3 iac/demo.py resources
python3 - <<'EOF'
import sys; sys.path.insert(0, "iac")
from cloud import FakeCloud, with_defaults
from engine import plan, apply, validate
from demo import CAMPUS
print("defaults:", with_defaults("school_locker", {"room_id": "room-01", "label": "a"}))
cloud = FakeCloud(); st, steps, msg = apply(plan(CAMPUS, None, cloud), cloud)
print(msg)
for call in cloud.calls: print("  ", call)
print("gate points at:", st["resources"]["school_gate.main"]["attrs"]["room_id"])
print(validate({"resource": {"school_room": {"x": {"name": "x", "id": "room-99"}}, "school_pool": {"p": {}}}}))
EOF

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

resources असे print करते:

   name   required · string
   floor  default 1 · number · forces a new room if changed
   seats  default 30 · number
   tags   default {} · map
   id     computed · string
── apply → Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
   the provider called the campus API: ['POST /rooms → room-01']

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

defaults: {'room_id': 'room-01', 'label': 'a', 'size': 'm'}
Apply complete! Resources: 5 added, 0 changed, 0 destroyed.
   POST /rooms → room-01
   POST /gates → gate-01
   POST /lockers → locker-01
   POST /lockers → locker-02
   POST /lockers → locker-03
gate points at: room-01
['school_room.x: An argument named "id" is not expected here.', 'Invalid resource type: the provider does not support resource type "school_pool".']

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

आराखड्याने कधीच room-01 म्हटले नाही; campus ने ते निवडले, आणि खोली तयार झाल्यावर gate चा room_id त्याने भरला गेला. खोली gate आणि lockers च्या आधी तयार झाली (का ते धडा 06 समजावतो). आणि validate ने campus ला अजिबात call न करता दोन चुका नाकारल्या: id computed आहे, म्हणून आराखडा ते ठरवू शकत नाही, आणि school_pool हा provider ला माहीत असलेला type नाही.

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

reference ऐवजी id hard-code करणे (room_id = "room-01") — मग आराखड्याला क्रम कळत नाही, आणि पुन्हा बांधलेली खोली gate बिघडवते
resource चे नाव (lab, आराखड्यातील एक लेबल) आणि object चा name argument किंवा त्याचा id यांत गल्लत करणे
provider versions pin न करणे — नवी major version schemas आणि defaults बदलू शकते
computed attribute ठरवण्याचा प्रयत्न करणे
जिथे data source योग्य आहे तिथे resource वापरणे (तुम्हाला shared network वाचायचे आहे, त्याचे मालक व्हायचे नाही)

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

खऱ्या account वर — खरा provider आणि खरा resource. terraform init provider download करते आणि नेमकी version .terraform.lock.hcl मध्ये नोंदवते (ती file commit करा):

terraform {
  required_version = ">= 1.5"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"          # any 6.x, never 7.0 by surprise
    }
  }
}

provider "aws" {
  region = "ap-south-1"
}

resource "aws_s3_bucket" "timetables" {
  bucket = "school-timetables-example"   # changing a bucket's name forces a new bucket
  tags   = { owner = "works-office" }
}

resource "aws_s3_bucket_versioning" "timetables" {
  bucket = aws_s3_bucket.timetables.id  # a reference: plain HCL, no quotes
  versioning_configuration { status = "Enabled" }
}

terraform init            # installs hashicorp/aws 6.x, writes .terraform.lock.hcl
terraform providers       # which providers this config needs
terraform validate        # "Success! The configuration is valid."

registry.terraform.io वरील provider documentation म्हणजे वाचता येण्याजोग्या स्वरूपातील schema: प्रत्येक argument साठी ते Required/Optional सांगते आणि बदलामुळे नवीन resource केव्हा लागतो ते नोंदवते.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: resource लिहिण्याआधी provider docs मधील त्याचे पान वाचा: कोणते arguments replacement घडवतात, कोणते computed आहेत, आणि तो कोणता import id अपेक्षित धरतो. पुढचा बदल पटकन होणारा update असेल की पुन्हा बांधकाम, हे ते पानच ठरवते.

⏭️ पुढे

आता कंत्राटदाराला आराखड्याचा अर्थ कळतो. पुढे: तो काय करायचे ते कसे ठरवतो — म्हणजे plan: create, update, replace किंवा destroy.

git checkout lesson-03-plan-apply

🧱 Lesson 02 — Resources & providers: what the plans may say

📍 You are here: Lesson 02 of 12 · Previous: lesson-01-why-iac · Next: lesson-03-plan-apply

📦 What's in this branch

Lesson 01, plus the vocabulary of the plans. A resource block describes one thing on the campus. A provider knows how to build that kind of thing and publishes a schema: which arguments are required, which have defaults, which the campus fills in itself (computed, like the id), and which cannot be changed without building a new object (ForceNew). resources() in iac/demo.py, SCHEMAS and FakeCloud in iac/cloud.py, to_hcl() and validate() in iac/engine.py.

🧒 Explain like I'm 5

The plans are written on a special form. 📋 Each box on the form says what to build:

Room called lab · name: chem-lab · floor: 2 · seats: 30

The contractor who builds rooms has a rule book. It says:

name — you must write it. 🖊️
floor — if you leave it empty, it is floor 1. And once the room is built, you cannot move it to another floor. You would need a new room. 🧱
seats — 30 if you say nothing. You can change it later.
id — do not write this. The campus gives every room its own number, like room-01, when it is built. 🏷️

A gate form has a box called room. You don't write a number there. You write "the id of the lab", and the contractor fills in the real number after the lab exists.

🗺️ Diagram

flowchart LR
    plans["📜 the plans<br/>resource school_room lab<br/>name, floor, seats"]
    schema["📖 provider schema<br/>name: required<br/>floor: default 1, ForceNew<br/>seats: default 30<br/>id: computed"]
    prov["👷 provider<br/>(a plugin)"]
    api["🏫 campus API<br/>POST /rooms"]
    plans --> prov
    schema --- prov
    prov -->|"create"| api
    api -->|"id = room-01"| prov

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

❓ What

Resource block — resource "TYPE" "NAME" { ... }. TYPE says what kind of thing (aws_s3_bucket, school_room), NAME is your local label for it (lab). Together they make the address: school_room.lab. The name is only for the plans; the real object gets an id from the cloud.
Arguments — what you set inside the block (name = "chem-lab").
Attributes — everything the object has after it exists, including computed ones the cloud chooses (id, an ARN, an IP address).
Reference — school_room.lab.id in another block means "the id of the lab, once it exists". In real HCL you write it plainly: room_id = school_room.lab.id. The lab writes "${school_room.lab.id}" inside a Python string; it means the same.
Provider — a plugin that knows one API: hashicorp/aws, hashicorp/google, hashicorp/kubernetes, cloudflare/cloudflare and thousands more on the Terraform Registry. Terraform core does the planning; the provider does create, read, update and delete calls.
Schema — the provider's rule book for each resource type: argument names, types, required or optional, defaults, computed, ForceNew (changing it means replace), sensitive (hide it in output).
Data source — data "TYPE" "NAME" reads something that already exists, without managing it (for example, the newest machine image). The lab has none; lesson 09 shows the related idea of importing.

🤔 Why

Because the schema is what lets the contractor plan without building. It knows that seats can change in place but floor cannot, and that id comes from the campus. It can also reject a mistake before any API call: an unknown argument, a missing required one, text where a number belongs. The provider split means Terraform core stays the same while one plugin per API does the talking.

🔧 How (in this repo)

SCHEMAS in iac/cloud.py is the provider schema for the three types. with_defaults() fills in defaults the plans left out. FakeCloud.create() stores the object, chooses an id like room-01, and records the API call in cloud.calls. The engine's validate() checks a config against SCHEMAS. to_hcl() prints a config dict as HCL, so you can compare it with a real .tf file.

🧪 Try it

python3 iac/demo.py resources
python3 - <<'EOF'
import sys; sys.path.insert(0, "iac")
from cloud import FakeCloud, with_defaults
from engine import plan, apply, validate
from demo import CAMPUS
print("defaults:", with_defaults("school_locker", {"room_id": "room-01", "label": "a"}))
cloud = FakeCloud(); st, steps, msg = apply(plan(CAMPUS, None, cloud), cloud)
print(msg)
for call in cloud.calls: print("  ", call)
print("gate points at:", st["resources"]["school_gate.main"]["attrs"]["room_id"])
print(validate({"resource": {"school_room": {"x": {"name": "x", "id": "room-99"}}, "school_pool": {"p": {}}}}))
EOF

✅ Verify — what you should see

resources prints:

   name   required · string
   floor  default 1 · number · forces a new room if changed
   seats  default 30 · number
   tags   default {} · map
   id     computed · string
── apply → Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
   the provider called the campus API: ['POST /rooms → room-01']

Your snippet prints:

defaults: {'room_id': 'room-01', 'label': 'a', 'size': 'm'}
Apply complete! Resources: 5 added, 0 changed, 0 destroyed.
   POST /rooms → room-01
   POST /gates → gate-01
   POST /lockers → locker-01
   POST /lockers → locker-02
   POST /lockers → locker-03
gate points at: room-01
['school_room.x: An argument named "id" is not expected here.', 'Invalid resource type: the provider does not support resource type "school_pool".']

🏁 What you just proved

The plans never said room-01; the campus chose it, and the gate's room_id was filled in with it after the room existed. The room was created before the gate and the lockers (lesson 06 explains why). And validate refused two mistakes without calling the campus at all: id is computed, so the plans may not set it, and school_pool is not a type the provider knows.

⚠️ Common mistakes

hard-coding an id (room_id = "room-01") instead of a reference — then the plans do not know the order, and a rebuilt room breaks the gate
confusing the resource name (lab, a label in the plans) with the object's name argument or its id
not pinning provider versions — a new major version can change schemas and defaults
trying to set a computed attribute
using a resource where a data source is right (you want to read a shared network, not own it)

🏭 In production

On a real account — a real provider and a real resource. terraform init downloads the provider and records the exact version in .terraform.lock.hcl (commit that file):

terraform {
  required_version = ">= 1.5"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"          # any 6.x, never 7.0 by surprise
    }
  }
}

provider "aws" {
  region = "ap-south-1"
}

resource "aws_s3_bucket" "timetables" {
  bucket = "school-timetables-example"   # changing a bucket's name forces a new bucket
  tags   = { owner = "works-office" }
}

resource "aws_s3_bucket_versioning" "timetables" {
  bucket = aws_s3_bucket.timetables.id  # a reference: plain HCL, no quotes
  versioning_configuration { status = "Enabled" }
}

terraform init            # installs hashicorp/aws 6.x, writes .terraform.lock.hcl
terraform providers       # which providers this config needs
terraform validate        # "Success! The configuration is valid."

The provider documentation on registry.terraform.io is the schema in readable form: for each argument it says Required/Optional and notes when a change forces a new resource.

🏭 Why this matters in production: before writing a resource, read its page in the provider docs: which arguments force replacement, which are computed, and what import id it expects. That page decides whether a later change is a quick update or a rebuild.

⏭️ Next

The contractor now knows what the plans mean. Next: how it decides what to do — the plan: create, update, replace or destroy.

git checkout lesson-03-plan-apply

← Previouswhy iac Next →plan apply

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