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

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

🏘️ धडा 10 — Environments: त्याच आराखड्यावरून dev आणि prod

📍 तुम्ही इथे आहात: 12 पैकी धडा 10 · मागील: lesson-09-drift-import · पुढील: lesson-11-testing-policy

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

धडे 01–09, आणि त्यासोबत अनेक जागा. तोच आराखडा एक लहान dev campus आणि एक मोठा prod campus बांधायला हवा, आणि एकातला बदल दुसऱ्याला कधीच हात लावता कामा नये. याचे तीन नेहमीचे मार्ग: workspaces (एक config, एक backend, प्रत्येक workspace ची वेगळी state), वेगळ्या directories (प्रत्येक environment साठी एक folder, प्रत्येकाची स्वतःची backend key, modules सामायिक) आणि वेगळे accounts (शिवाय वेगळी state आणि वेगळे CI roles). environments() हे iac/demo.py मध्ये आहे; Backend.path() हे iac/engine.py मध्ये.

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

शाळेकडे एक सरावाचा campus (dev) आहे जिथे नव्या कल्पना करून पाहिल्या जातात, आणि एक खरा campus (prod) जिथे मुले असतात. 🏫🏫 आराखडा तोच, आकार वेगळे: सरावाच्या lab मध्ये 10 seats आणि 1 locker; खऱ्या lab मध्ये 40 seats आणि 3 lockers. हे आकार दोन लहान कार्डांवर लिहिलेले असतात: dev.tfvars आणि prod.tfvars. 🃏

मार्ग 1 — workspaces. एकच नोंदवही, पण तिला दोन tabs: "dev" आणि "prod". काम करण्याआधी तुम्ही योग्य tab उघडता. कतरिना prod tab उघडते पण चुकून dev चे कार्ड उचलते. कंत्राटदार plan मोठ्याने वाचतो: "खरी lab: 40 seats → 10. 2 lockers काढून टाका." नशीब, कतरिना हो म्हणण्याआधी plans वाचते. 😅

मार्ग 2 — वेगळे folders. dev साठी एक folder, prod साठी एक folder, प्रत्येकाची स्वतःची नोंदवही. तुम्ही "चुकीच्या tab मध्ये" असूच शकत नाही — तुम्ही वेगळ्याच खोलीत उभे असता.

मार्ग 3 — वेगळे campuses. dev आणि prod या वेगवेगळ्या जागा आहेत, वेगवेगळ्या किल्ल्यांसह. सराव करणाऱ्या बांधकाम करणाऱ्यांच्या किल्ल्या खऱ्या campus चे फाटकही उघडत नाहीत. 🔑

🗺️ आकृती

flowchart LR
    plans["📜 one set of plans + modules"]
    plans -->|"workspace dev + dev.tfvars"| d["📒 env:/dev/campus.tfstate<br/>dev-lab · 10 seats · 1 locker"]
    plans -->|"workspace prod + prod.tfvars"| p["📒 env:/prod/campus.tfstate<br/>prod-lab · 40 seats · 3 lockers"]
    oops["⚠️ prod selected + dev.tfvars"] --> bad["~ seats 40 → 10<br/>- 2 lockers"]

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

❓ काय

Environment — एका उद्देशासाठी system ची पूर्ण प्रत: dev, test, staging, prod. रचना तीच, आकार, data आणि access वेगळे.
CLI workspaces — terraform workspace new dev, select dev, show. एक config, एक backend, प्रत्येक workspace ची वेगळी state. terraform.workspace मध्ये नाव असते. S3 backend सोबत, default नसलेले workspaces env:/<workspace>/<key> खाली साठवले जातात (हा workspace_key_prefix, default म्हणून env:).
प्रत्येक environment साठी .tfvars — terraform plan -var-file=prod.tfvars. Config तेच राहते; मूल्ये बदलतात.
प्रत्येक environment साठी directory — envs/dev/main.tf आणि envs/prod/main.tf, प्रत्येक एक लहान root module जे स्वतःच्या मूल्यांसह सामायिक modules बोलावते आणि ज्याचा स्वतःचा backend block असतो. प्रत्येक directory स्वतंत्रपणे initialise आणि apply केली जाते.
प्रत्येक environment साठी account — dev आणि prod वेगवेगळ्या cloud accounts मध्ये (किंवा subscriptions, projects), वेगवेगळ्या credentials सह. सर्वात मजबूत वेगळेपणा: dev role prod ला अजिबात हात लावू शकत नाही.
HCP Terraform workspaces — त्याच नावाची पण वेगळी गोष्ट: HCP Terraform मध्ये workspace म्हणजे स्वतःची state, variables, permissions आणि run history असलेले पूर्ण एकक.

🤔 का

कारण "staging मध्ये test केले" याला अर्थ तेव्हाच असतो जेव्हा staging त्याच आराखड्यावरून बांधलेले असते. आणि कारण IaC मधील सर्वात महागड्या चुका म्हणजे चुकीच्या environment वर apply केलेले आराखडे. HashiCorp चे स्वतःचे documentation सांगते की environments ना वेगळे credentials किंवा access controls हवे असतील, तेव्हा CLI workspaces योग्य नाहीत. Environments त्यांना कोण बदलू शकते यात जितके वेगळे, तितकी त्यांना वेगळ्या directories, backends आणि accounts ची जास्त गरज.

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

iac/engine.py मधील Backend.path(workspace) default साठी campus.tfstate आणि इतरांसाठी env:/<workspace>/campus.tfstate परत देते. plan(..., workspace=ws) मुळे ${terraform.workspace} चे मूल्य workspace चे नाव होते. iac/demo.py मधील ENV lab चे नाव ${terraform.workspace}-lab ठेवते आणि seats व lockers TFVARS मधून घेते. Demo dev आणि prod apply करतो, मग dev च्या मूल्यांनी prod चा plan करतो.

🧪 करून पाहा

python3 iac/demo.py environments
python3 - <<'EOF'
import sys; sys.path.insert(0, "iac")
from cloud import FakeCloud
from engine import plan, apply, Backend
from demo import ENV
cloud, be = FakeCloud(), Backend()
vars = {"dev": {"seats": 10, "lockers": 1}, "staging": {"seats": 20, "lockers": 2}, "prod": {"seats": 40, "lockers": 3}}
for ws, v in vars.items():
    st, _, msg = apply(plan(ENV, be.read(be.path(ws)), cloud, vars=v, workspace=ws), cloud, backend=be, key=be.path(ws))
    names = [r["attrs"]["name"] for r in st["resources"].values() if r["type"] == "school_room"]
    print(f"{ws:<8} {be.path(ws):<27} {len(st['resources'])} resources · room {names}")
print("campus objects:", len(cloud.inventory()), "· default workspace empty:", be.read(be.path())["resources"] == {})
EOF

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

environments हे छापते:

   the backend now holds ['env:/dev/campus.tfstate', 'env:/prod/campus.tfstate'] · the campus has 6 objects
── Katrina forgets `workspace select dev` and plans with dev.tfvars while prod is selected:
     ~ school_room.lab  seats: 40 → 10
     - school_locker.row[1] (destroy)
     - school_locker.row[2] (destroy)
   Plan: 0 to add, 1 to change, 2 to destroy.  ← prod shrinks to dev's size

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

dev      env:/dev/campus.tfstate     2 resources · room ['dev-lab']
staging  env:/staging/campus.tfstate 3 resources · room ['staging-lab']
prod     env:/prod/campus.tfstate    4 resources · room ['prod-lab']
campus objects: 9 · default workspace empty: True

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

एकाच आराखड्याने तीन वेगळे environments बांधले, प्रत्येकाची स्वतःची नोंदवही key आणि स्वतःचा आकार — आणि default workspace रिकामे राहिले. पण तिन्ही एकाच campus मध्ये आणि एकाच backend मध्ये राहतात, आणि निवडलेल्या workspace शिवाय त्यांना काहीच वेगळे करत नाही: चुकीच्या workspace सोबत चुकीच्या .tfvars ने prod लहान करण्याचा plan केला (1 to change, 2 to destroy). त्या आणि outage च्या मध्ये फक्त plan review उभा होता.

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

त्याच credentials सह CLI workspaces म्हणून dev आणि prod — prod पासून फक्त एका चुकीच्या select चे अंतर
copy-paste केलेले environment folders जे हळूहळू वेगळे होत जातात — modules सामायिक करा, folders पातळ ठेवा
सगळीकडे शिंपडलेले count = terraform.workspace == "prod" ? 3 : 1 — आकार .tfvars मध्ये ठेवा
सगळ्या environments साठी एकच state — प्रत्येक dev बदल prod ला lock करतो आणि धोक्यात घालतो
plan output मध्ये environment ची कोणतीही दिसणारी खूण नसणे (ती names आणि tags मध्ये ठेवा)

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

खऱ्या account वर — CLI workspaces, जेव्हा environments चा access सामायिक असतो:

terraform workspace new staging
terraform workspace select staging
terraform workspace show                          # always check before apply
terraform plan -var-file=staging.tfvars -out=tfplan

प्रत्येक environment साठी एक directory, प्रत्येकाची स्वतःची backend key, सामायिक modules बोलावणारी:

infra/
├── modules/wing/                 # the shared design
└── envs/
    ├── dev/   main.tf  backend.tf (key = "dev/campus.tfstate")   dev.tfvars
    └── prod/  main.tf  backend.tf (key = "prod/campus.tfstate")  prod.tfvars

# envs/prod/main.tf
module "east" {
  source  = "../../modules/wing"
  wing    = "east"
  lockers = 3
}

वेगळ्या accounts साठी, प्रत्येक environment चा provider वेगळा role assume करतो, आणि prod चा CI job हाच prod role assume करण्याची परवानगी असलेला एकमेव घटक असतो (धडा 12). Terragrunt सारखी tools मुख्यतः अनेक environment folders लहान ठेवण्यासाठी असतात.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे आहे: prod साठी लिहून ठेवा की ते बदलणारे credentials कोण आणि काय assume करू शकते. उत्तरात "dev चालवू शकणारे कोणीही" असेल, तर environments अजून वेगळे झालेले नाहीत.

⏭️ पुढे

प्रत्येक plan डोळ्यांनी वाचणे मोठ्या प्रमाणावर शक्य नाही. पुढे: तुमच्यासाठी आराखडा वाचणारे तपासनीस — validate, tests, policy आणि cost.

git checkout lesson-11-testing-policy

🏘️ Lesson 10 — Environments: dev and prod from the same plans

📍 You are here: Lesson 10 of 12 · Previous: lesson-09-drift-import · Next: lesson-11-testing-policy

📦 What's in this branch

Lessons 01–09, plus many sites. The same plans must build a small dev campus and a big prod campus, and a change to one must never touch the other. Three common ways: workspaces (one config, one backend, a separate state per workspace), separate directories (one folder per environment, each with its own backend key, sharing modules) and separate accounts (plus separate state and separate CI roles). environments() in iac/demo.py; Backend.path() in iac/engine.py.

🧒 Explain like I'm 5

The school has a practice campus (dev) where new ideas are tried, and the real campus (prod) where the children are. 🏫🏫 Same plans, different sizes: the practice lab has 10 seats and 1 locker; the real lab has 40 seats and 3 lockers. The sizes live on two small cards: dev.tfvars and prod.tfvars. 🃏

Way 1 — workspaces. One register book with two tabs: "dev" and "prod". Before you work, you open the right tab. Katrina opens the prod tab but picks up the dev card by mistake. The contractor reads the plan out loud: "Real lab: 40 seats → 10. Take away 2 lockers." Luckily Katrina reads plans before saying yes. 😅

Way 2 — separate folders. A folder for dev, a folder for prod, each with its own register. You can't be "in the wrong tab" — you are standing in a different room.

Way 3 — separate campuses. Dev and prod are different sites with different keys. The practice builders' keys don't even open the real campus gate. 🔑

🗺️ Diagram

flowchart LR
    plans["📜 one set of plans + modules"]
    plans -->|"workspace dev + dev.tfvars"| d["📒 env:/dev/campus.tfstate<br/>dev-lab · 10 seats · 1 locker"]
    plans -->|"workspace prod + prod.tfvars"| p["📒 env:/prod/campus.tfstate<br/>prod-lab · 40 seats · 3 lockers"]
    oops["⚠️ prod selected + dev.tfvars"] --> bad["~ seats 40 → 10<br/>- 2 lockers"]

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

❓ What

Environment — a full copy of the system for one purpose: dev, test, staging, prod. Same shape, different size, data and access.
CLI workspaces — terraform workspace new dev, select dev, show. One config, one backend, a separate state per workspace. terraform.workspace holds the name. With the S3 backend, non-default workspaces are stored under env:/<workspace>/<key> (the workspace_key_prefix, env: by default).
.tfvars per environment — terraform plan -var-file=prod.tfvars. The config stays the same; the values change.
Directory per environment — envs/dev/main.tf and envs/prod/main.tf, each a small root module that calls shared modules with its own values and its own backend block. Each directory is initialised and applied on its own.
Account per environment — dev and prod in different cloud accounts (or subscriptions, projects), with different credentials. The strongest isolation: a dev role cannot touch prod at all.
HCP Terraform workspaces — a different thing with the same name: in HCP Terraform a workspace is a full unit with its own state, variables, permissions and run history.

🤔 Why

Because "tested in staging" only means something if staging was built from the same plans. And because the most expensive mistakes in IaC are plans applied to the wrong environment. HashiCorp's own documentation says CLI workspaces are not a good fit when environments need separate credentials or access controls. The more the environments differ in who may change them, the more they need separate directories, backends and accounts.

🔧 How (in this repo)

Backend.path(workspace) in iac/engine.py returns campus.tfstate for default and env:/<workspace>/campus.tfstate for the others. plan(..., workspace=ws) makes ${terraform.workspace} resolve to the workspace name. ENV in iac/demo.py names the lab ${terraform.workspace}-lab and takes seats and lockers from TFVARS. The demo applies dev and prod, then plans prod with dev's values.

🧪 Try it

python3 iac/demo.py environments
python3 - <<'EOF'
import sys; sys.path.insert(0, "iac")
from cloud import FakeCloud
from engine import plan, apply, Backend
from demo import ENV
cloud, be = FakeCloud(), Backend()
vars = {"dev": {"seats": 10, "lockers": 1}, "staging": {"seats": 20, "lockers": 2}, "prod": {"seats": 40, "lockers": 3}}
for ws, v in vars.items():
    st, _, msg = apply(plan(ENV, be.read(be.path(ws)), cloud, vars=v, workspace=ws), cloud, backend=be, key=be.path(ws))
    names = [r["attrs"]["name"] for r in st["resources"].values() if r["type"] == "school_room"]
    print(f"{ws:<8} {be.path(ws):<27} {len(st['resources'])} resources · room {names}")
print("campus objects:", len(cloud.inventory()), "· default workspace empty:", be.read(be.path())["resources"] == {})
EOF

✅ Verify — what you should see

environments prints:

   the backend now holds ['env:/dev/campus.tfstate', 'env:/prod/campus.tfstate'] · the campus has 6 objects
── Katrina forgets `workspace select dev` and plans with dev.tfvars while prod is selected:
     ~ school_room.lab  seats: 40 → 10
     - school_locker.row[1] (destroy)
     - school_locker.row[2] (destroy)
   Plan: 0 to add, 1 to change, 2 to destroy.  ← prod shrinks to dev's size

Your snippet prints:

dev      env:/dev/campus.tfstate     2 resources · room ['dev-lab']
staging  env:/staging/campus.tfstate 3 resources · room ['staging-lab']
prod     env:/prod/campus.tfstate    4 resources · room ['prod-lab']
campus objects: 9 · default workspace empty: True

🏁 What you just proved

One set of plans built three separate environments, each with its own register key and its own size — and the default workspace stayed empty. But all three live in one campus and one backend, and nothing but the selected workspace separates them: the wrong .tfvars with the wrong workspace planned to shrink prod (1 to change, 2 to destroy). Only the plan review stood between that and an outage.

⚠️ Common mistakes

dev and prod as CLI workspaces with the same credentials — one wrong select away from prod
copy-pasted environment folders that slowly drift apart — share modules, keep the folders thin
count = terraform.workspace == "prod" ? 3 : 1 sprinkled everywhere — put sizes in .tfvars
one state for all environments — every dev change locks and risks prod
no visible marker of the environment in the plan output (put it in names and tags)

🏭 In production

On a real account — CLI workspaces, when the environments share access:

terraform workspace new staging
terraform workspace select staging
terraform workspace show                          # always check before apply
terraform plan -var-file=staging.tfvars -out=tfplan

A directory per environment, each with its own backend key, calling shared modules:

infra/
├── modules/wing/                 # the shared design
└── envs/
    ├── dev/   main.tf  backend.tf (key = "dev/campus.tfstate")   dev.tfvars
    └── prod/  main.tf  backend.tf (key = "prod/campus.tfstate")  prod.tfvars

# envs/prod/main.tf
module "east" {
  source  = "../../modules/wing"
  wing    = "east"
  lockers = 3
}

For separate accounts, each environment's provider assumes a different role, and the CI job for prod is the only thing allowed to assume the prod role (lesson 12). Tools like Terragrunt exist mainly to keep many environment folders short.

🏭 Why this matters in production: write down, for prod, who and what can assume credentials that change it. If the answer includes "anyone who can run dev", the environments are not separate yet.

⏭️ Next

Reading every plan by eye does not scale. Next: inspectors that read the plans for you — validate, tests, policy and cost.

git checkout lesson-11-testing-policy

← Previousdrift import Next →testing policy

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