Sesiunea 6
Infrastructure as Code cu Bicep & Terraform
Zero to hero — de la deploy manual la platformă repetabilă și auditabilă
Introducere
Infrastructure as Code cu Bicep & Terraform
Ce vei învăța în acest curs
Scopul acestui material este să treacă studentul de la deploy manual în Azure Portal la gândire de platformă, modularitate, control al schimbărilor, review, versionare și automatizare repetabilă cu Bicep și Terraform.
Traseul de învățare
Resurse Azure & deploy manual
Înțelegi ce construiești înainte de a automatiza.
Bicep — IaC nativ Azure
Înveți IaC cu fricțiune mică, sintaxă modernă și module.
Terraform — state, backend, multi-cloud
Înțelegi state, backend, module enterprise și multi-cloud thinking.
Pipelines, policy & day-2 operations
CI/CD, monitoring, observabilitate și producție sigură.
Slide 3–4
Infrastructure as Code în Azure — ce alegi și când?
Cele trei opțiuni principale
ARM Templates
JSON nativ pentru Azure. Control total, compatibilitate maximă. Verbose, greu de citit. Bun când moștenești template-uri vechi sau ai nevoie de JSON pur.
Bicep
DSL modernă peste ARM. Sintaxă curată, modules și reuse, excelent pentru Azure. Alegerea recomandată pentru proiecte noi Azure-first.
Terraform
Tool multi-cloud bazat pe state. Standard de industrie: Azure + AWS + GCP + ecosistem bogat. Foarte bun pentru platforme mari și echipe mixte.
Vrei doar Azure și vrei experiența cea mai simplă? → Bicep. Ai deja Terraform în companie sau lucrezi multi-cloud? → Terraform. Ai template-uri JSON vechi sau exportate din Azure? → ARM Templates. Vrei modularitate cu module verificate? → Bicep sau Terraform cu AVM.
Slide 5–7
De ce IaC este o abilitate fundamentală
Dacă Azure Portal este volanul cu care înveți să conduci, Infrastructure as Code este pilotul automat, cartea tehnică a mașinii și jurnalul de service în același timp. Cu IaC descrii infrastructura în fișiere text, o versionezi în Git, o revizuiești prin pull requests, o validezi în pipeline și o refaci identic de câte ori ai nevoie.
Beneficiile cheie ale IaC
Replicabilitate
Același mediu poate fi recreat în dev, test și prod fără click-uri manuale diferite.
Audit și guvernanță
Orice schimbare este vizibilă în cod, nu doar în memoria celui care a făcut-o.
Viteză
Infrastructură complexă poate fi lansată în minute, nu în ore sau zile.
Standardizare
Naming, tags, securitate și politici pot fi aplicate consecvent.
Disaster recovery
Un nou coleg sau un nou proiect pornește mult mai repede.
Portalul te ajută să înveți. IaC te ajută să scalezi, să repeți, să auditezi și să livrezi fără surprize.
Slide 8
ARM Templates vs Bicep vs Terraform — comparație
Comparație detaliată
| Criteriu | ARM Templates | Bicep | Terraform |
|---|---|---|---|
| Sintaxă | JSON, verbos, greu de menținut | DSL compactă, lizibilă, transpilează în ARM JSON | HCL, lizibil, orientat pe modules și providers |
| Scop principal | Azure nativ, model vechi dar valid | Azure nativ modern, recomandat pentru proiecte noi | Multi-cloud și enterprise IaC standard |
| State | Fără state separat; ARM calculează desired state | La fel ca ARM, fără state separat | State explicit; local sau remote backend |
| Modularitate | Posibilă dar greoaie prin nested templates | Foarte bună prin modules, registries și AVM | Foarte bună prin modules, registry și compositions |
| Când o alegi | Moștenești JSON existent sau ai output exportat | Vrei cea mai bună experiență Azure și sintaxă modernă | Ai standard corporativ Terraform sau mediu multi-cloud |
Dacă organizația este Azure-first și nu are un standard impus pe Terraform, Bicep este în general cea mai simplă alegere. Microsoft recomandă Bicep peste ARM JSON pentru authoring nou.
Slide 9
Fluxul complet IaC: de la idee la producție
6 etape de la idee la producție
1. Design
Arhitectură, Naming, CIDR, Securitate, Tagging.
2. Author
Bicep modules sau Terraform modules, variables, outputs.
3. Validate
lint, what-if / plan, policy checks, security checks.
4. Deploy
Dev → Test → Prod, pipeline, approvals, service connection.
5. Operate
Monitoring, changes, imports, state / drift, rollback.
6. Improve
Refactor, reuse AVM, versioning, platform standards.
Slide 10
Concepte-cheie pe care studentul trebuie să le stăpânească
Concepte fundamentale IaC
Declarativ vs Imperativ
Bicep, ARM și Terraform descriu starea dorită. Nu spui pas cu pas ce să execute, ci ce resurse vrei să existe și cu ce configurație.
Idempotență
Rulezi același cod de mai multe ori și ajungi la aceeași stare. Asta reduce surprizele.
Drift
Dacă cineva modifică manual o resursă în portal și codul nu reflectă schimbarea, apare drift. Terraform detectează drift prin state + refresh/plan; Bicep se bazează pe what-if și guvernanță.
Modules
O bucată reutilizabilă de infrastructură: un VNet standard, un storage account sau un set complet App Service + plan + insights.
Parameters / Variables
Separați ce se schimbă între medii de codul comun. De exemplu: nume, locație, SKU, CIDR, număr de noduri.
Outputs & Dependencies
Outputs: expui valori pentru consum ulterior (resource IDs, endpoint-uri). Dependencies: limbajele declarative rezolvă ordinea automat prin referințe.
Slide 12–17
Bicep în profunzime
Bicep este limbajul IaC recomandat pentru Azure-first. El păstrează modelul declarativ ARM, dar reduce enorm complexitatea sintaxei. În loc să scrii JSON cu proprietăți repetitive, lucrezi într-o sintaxă mai apropiată de un limbaj modern: clară, compactă și ușor de modulizat.
Structura recomandată de foldere
main.bicep
Fișierul orchestrator care leagă toate modulele.
main.dev.bicepparam
Fișierul de parametri pentru mediul Dev.
modules/loganalytics.bicep
Modul pentru Log Analytics Workspace.
modules/network.bicep
Modul pentru VNet, subnet-uri și NSG.
modules/nsg.bicep
Modul pentru Network Security Group.
Bicep best practices
Folosește .bicepparam pentru medii diferite
Nu dublica codul pentru dev, test și prod. Folosește fișiere .bicepparam separate.
Păstrează module mici și coerente
Un modul pentru rețea, unul pentru monitoring, unul pentru compute. Coerența facilitează reutilizarea.
Nu hardcode secrete
Leagă-te de Key Vault sau injectează valori în pipeline. Niciodată parole în fișierele IaC.
Rulează validation, linter și what-if
Validarea preventivă reduce riscul de surprize în mediile critice.
Slide 18–22
Terraform în profunzime
Terraform este foarte popular pentru că nu este limitat la Azure. Cu același model mental poți descrie Azure, AWS, GitHub, Datadog, Cloudflare și multe altele. Pentru companii mari, acesta este un avantaj major: un singur limbaj de automatizare pentru întregul ecosistem.
Componentele Terraform
Provider
Plugin-ul care știe să vorbească cu o platformă, de exemplu azurerm.
State
Fișierul care ține evidența resurselor administrate.
Backend
Locul unde state-ul este stocat (local sau remote).
Module
Componentă reutilizabilă, similară conceptual cu modulele Bicep.
Plan
Previzualizarea schimbărilor înainte de apply.
State management — partea cea mai importantă
Dacă studentul reține un singur lucru despre Terraform, acesta trebuie să fie state-ul. Terraform nu doar trimite comenzi spre Azure; el menține o hartă a resurselor pe care le administrează. Fără el, Terraform nu știe corect ce există deja, ce trebuie schimbat și ce trebuie șters.
Local state vs Remote state
| Model | Avantaje | Riscuri |
|---|---|---|
| Local state | Simplu pentru laborator sau PoC individual | Nu este bun pentru echipe; risc de pierdere, conflicte și lipsă de locking centralizat |
| Remote state (Azure Storage) | Potrivit pentru echipe; acces centralizat, locking, backup și control mai bun | Necesită bootstrap corect: storage account, container, RBAC, securizare acces |
Storage account-ul pentru state trebuie tratat ca infrastructură critică: acces minim necesar, versioning, soft delete, RBAC clar și separare pe medii.
Când două persoane rulează terraform apply în același timp, state locking previne coruperea state-ului. Backend-ul azurerm folosește Azure Blob Storage pentru locking. Dacă locking-ul eșuează, Terraform nu ar trebui forțat decât după investigație.
Slide 23–24
Azure Verified Modules (AVM)
Azure Verified Modules sunt module validate și susținute într-un model consistent pentru deploy și management de resurse Azure. Există variante atât pentru Bicep, cât și pentru Terraform. Pentru studenți, AVM sunt o punte excelentă între teoria IaC și standardizarea enterprise.
Când să folosești AVM
Folosește AVM când...
Vrei viteză și consistență pe resurse standard, echipa are mai multe proiecte similare, vrei să reduci boilerplate-ul.
Evită să te bazezi orbește pe AVM când...
Nu înțelegi încă ce face modulul sub capotă, ai nevoie de comportamente foarte custom, sau studentul nu a învățat mai întâi bazele resursei.
Regulă bună: Învață mai întâi resursa, apoi accelerează cu module verified.
Slide 25–27
Deploying multi-resource architectures
Un student știe că a înțeles IaC abia când poate codifica o arhitectură mai mare, nu doar o resursă izolată.
Pattern de arhitectură recomandat — layere
Foundation
Resource groups, locks, tags, role assignments de bază.
Network
VNet, subnets, NSG, UDR, private DNS.
Shared Services
Monitoring, Key Vault, registries, bastion, firewall.
Workload
AKS, App Service, Function, SQL, Storage etc.
Gândește în module și responsabilități, nu într-un fișier uriaș. Unele layere se schimbă rar, altele mai des.
Ce se întâmplă în lumea reală
Mediu nou lansat rapid
IaC permite clonarea controlată a arhitecturii. Un mediu complet poate fi recreat în minute, nu în zile.
Audit cere dovadă
Cu IaC vezi imediat standardul și poți aplica remedieri la scară.
Un coleg a modificat manual
Prin code review și deploy-uri controlate reduci șansele de drift nedocumentat.
Slide 28
Cum aleg între Bicep și Terraform într-o organizație reală
Criterii de decizie Bicep vs Terraform
| Întrebare | Indicator Bicep | Indicator Terraform |
|---|---|---|
| Platforma este exclusiv Azure? | Da, Bicep este foarte natural | Avantajul Terraform scade dacă nu folosești alte providere |
| Echipă cu standard Terraform matur? | Poate fi folosit doar în proiecte punctuale | Da, continuitatea operațională contează mult |
| Authoring apropiat de Azure ARM? | Da | Nu este prioritatea principală |
| Același limbaj pentru Azure + GitHub + Datadog + alte SaaS? | Mai puțin potrivit | Foarte potrivit |
| Juniorii trebuie să învețe repede Azure IaC? | Bicep este adesea mai simplu | Terraform merită imediat după bazele IaC |
Slide 29–31
CI/CD pentru IaC
IaC fără pipeline este mai bun decât click-ops, dar adevărata valoare apare când codul trece printr-un flux controlat: lint, validate, what-if sau plan, approvals, deploy și verificare post-deploy.
CI/CD — Bicep vs Terraform
Bicep pipeline
bicep build/lint → az deployment what-if → deployment create
Terraform pipeline
terraform fmt → validate → plan → aprobare plan → apply
Pipeline logic — 4 stage-uri
Stage 1 — Validate
lint / fmt, security checks, dependency checks.
Stage 2 — Preview
Bicep what-if sau Terraform plan. Publish plan artefact.
Stage 3 — Deploy Dev
Deploy automat, smoke tests.
Stage 4 — Deploy Prod
Approval manual, deploy controlat, post-deploy validation.
Slide 32–35
Laborator complet — zero to hero
Obiectivul laboratorului
Studentul va construi aceeași arhitectură mică în două moduri: o dată cu Bicep, o dată cu Terraform. La final va înțelege diferența dintre transpile-to-ARM și state-based IaC.
Pașii Bicep
Creează resource group-ul
az group create -n rg-iac-lab -l swedencentral
Construiește modulele
Module pentru workspace, NSG și network conform structurii de foldere.
Leagă output-urile între module
nsgId din modulul NSG → transmis corect modulului network.
Rulează what-if
az deployment group what-if -g rg-iac-lab -f main.bicep -p prefix=lab01
Rulează deployment create
az deployment group create -g rg-iac-lab -f main.bicep -p prefix=lab01
Verifică în portal
Confirmă că toate resursele există și sunt configurate corect.
Pașii Terraform
Creează storage account pentru remote state
Tratează-l ca infrastructură critică: RBAC, versioning, soft delete.
Configurează backend azurerm
Definește resource_group_name, storage_account_name, container_name și key.
Scrie resursele sau modulele echivalente
Aceeași arhitectură ca la Bicep: Log Analytics, VNet, subnet, NSG.
Rulează init, fmt, validate, plan și apply
terraform init → fmt -recursive → validate → plan -out=tfplan → apply tfplan
Compară experiența
Observă diferențele: plan-ul, state-ul și drift awareness față de experiența Bicep.
Ambele pot produce aceeași infrastructură, dar experiența operațională este diferită. Înțelegerea acestei diferențe este esența laboratorului.
Slide 36–37
Troubleshooting și greșeli frecvente
6 greșeli clasice IaC de evitat
Naming invalid
Unele resurse Azure au reguli stricte. Folosește funcții de normalizare și convention-over-configuration.
Order / dependency issues
Nu folosi dependsOn inutil. Referințele directe rezolvă ordinea. În Terraform, folosește referințe între resurse.
State blocat în Terraform
Investighează de ce există lock. Nu sări direct la force-unlock fără să înțelegi contextul.
Drift din portal
Evită modificările manuale pe resurse administrate prin cod; dacă sunt necesare, readuce-le apoi în cod.
Secrete în repo
Nu pune parole, chei sau connection strings sensibile direct în fișierele IaC sau tfvars neprotejate.
Module prea mari
Când un modul face prea multe lucruri, devine greu de reutilizat și testat. Păstrează coerența.
Slide 38
Bune practici de platform engineer aplicate în IaC
Principii esențiale
Planifică CIDR și subnetting
Înainte de primul deploy, nu după. Schimbările de adresare ulterior sunt costisitoare.
Tagging standard
Owner, environment, cost center, criticality — aplicate consecvent prin cod.
Separare foundation / workload
Layere cu cicluri de viață diferite nu ar trebui în același modul sau pipeline.
Aprobări pentru producție
Ferestre de schimbare pentru medii critice și approvals manuale înainte de apply.
Versionează modulele
Documentează breaking changes. Tratează modulele ca pe API-uri cu versiuni.
Observabilitate ca parte din cod
Diagnostics, logs, alerts, workspace links — incluse în modulele de resurse, nu adăugate după.
Cheat Sheet
Referință rapidă
Cheat sheet rapid pentru studenți
Concluzie
De la operator la cloud engineer
Studentul care înțelege Bicep și Terraform nu mai este doar un operator de portal. Devine un inginer capabil să descrie infrastructura ca produs: repetabil, revizuibil, auditabil și pregătit pentru scală.
Exact această tranziție face diferența între un administrator care apasă butoane și un cloud engineer care construiește platforme.
Infrastructura și aplicația nu sunt complete fără un traseu de livrare repetabil. Cloud-ul fără IaC este doar jumătate din poveste.
Verificare rapidă — întrebări de recapitulare
1 Care este diferența fundamentală dintre Bicep și Terraform?
Bicep transpilează în ARM JSON, fără state separat. Terraform menține un state file explicit și suportă multi-cloud.
2 Ce este state-ul în Terraform și de ce contează?
State-ul este harta resurselor administrate. Fără el, Terraform nu știe ce există, ce trebuie schimbat sau șters.
3 Când alegi Bicep și când Terraform?
Bicep pentru Azure-only, experiență simplă. Terraform pentru multi-cloud, standard enterprise existent, sau ecosistem de module deja matur.
4 Ce este drift-ul și cum îl detectezi?
Drift apare când cineva modifică manual o resursă. Terraform detectează prin state + refresh/plan. Bicep se bazează pe what-if și guvernanță.
5 De ce este important să nu pui secrete în fișierele IaC?
Secretele în repo sunt un risc major de securitate. Folosește Key Vault, Variable Groups sau Secure Files.
Exerciții practice
Lab 1: Primul deployment Bicep
Creează un resource group, un storage account cu TLS 1.2 și public access dezactivat folosind un fișier Bicep simplu.
Lab 2: Module Bicep
Sparge arhitectura în 3 module (NSG, network, Log Analytics) și orchestrează-le din main.bicep.
Lab 3: Primul proiect Terraform
Aceeași arhitectură ca în Lab 2, dar cu Terraform. Configurează remote state în Azure Storage.
Lab 4: Compară what-if vs plan
Modifică o proprietate (de exemplu SKU) și compară output-ul lui az deployment what-if cu terraform plan.
Resurse suplimentare
Bicep și Terraform evoluează constant. Rămâi la curent cu noile funcționalități și module disponibile.
Ce să faci acum (A06)
- Reascultă rezumatul audio sau recitește secțiunile cheie — salt la audio.
- Verifică notele cu quiz-ul acestei sesiuni.
- Sesiunea următoare — Microsoft Entra ID & Zero Trust.
Opțional: repetă termenii în Studiu sau joacă un modul din Game Hub.
Crează-ți profil
Dacă nu te loghezi, parcursul prin sesiuni rămâne doar în acest browser: nu îl vezi pe alt dispozitiv sau în alt browser și îl pierzi dacă ștergi datele site-ului ori folosești incognito.
PIN-ul nu este un cont securizat și nu trebuie să fie aceeași combinație ca parole importante (Microsoft, email bancă). Este doar o etichetă locală + sincronizare pentru progresul din Learn Cloud.
Cu prenume, nume și PIN (4 cifre) îți poți continua cursul oriunde — același cont ca în Game Hub și Realizări(vizite, audio, quiz, lectură).
Ai uitat PIN-ul?
Nu există recuperare automată a PIN-ului. Încearcă combinația salvată sau creează un profil nou cu alt nume/prenume (generând alt ID). Pentru date pe server vezi Ajutor · PIN.
Backup & date locale
Exportul este un fișier JSON pentru arhivă personală; nu îl încărca în locuri publice (poate conține pseudo-identificatori).