Terraform Fundamentals

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Terraform, episodul 1 din 13. Provisioning-ul serverelor însemna înainte să deschizi un tichet la helpdesk și să aștepți două săptămâni ca cineva să dea niște click-uri într-o consolă cloud. Astăzi, exact același proces este un simplu pull request care primește deploy în siguranță, în câteva minute. Această schimbare este condusă în întregime de paradigma Infrastructure as Code, iar HashiCorp Terraform este motorul principal care o alimentează. Infrastructure as Code este exact ceea ce pare. Îți gestionezi bazele de date, rețelele virtuale și instanțele de compute folosind fișiere plain text în loc de click-uri manuale. Aceste fișiere pot fi ținute în version control, pot primi review de la colegi și pot fi testate automat. Ca să înțelegi de ce chestia asta e atât de puternică, gândește-te la un sysadmin care are nevoie de o nouă mașină virtuală în Azure. Folosind un workflow imperativ, ar putea scrie un script PowerShell complex. Acel script trebuie să definească explicit fiecare acțiune, în ordine. Îi spune sistemului să se logheze, să verifice dacă există o rețea, să o creeze dacă nu există, să aloce un IP public și, în final, să pornească serverul. Dacă scriptul dă fail la pasul patru, rămâi cu o infrastructură construită parțial. Dacă rulezi scriptul a doua oară, de multe ori vei primi erori, pentru că unele resurse există deja. Terraform folosește, în schimb, o abordare declarativă. Nu scrii tu secvența de pași. Pur și simplu definești starea finală dorită. Scrii un fișier de configurare în care declari că vrei o mașină virtuală în Azure, atașată la o anumită rețea. Terraform compară starea pe care ai cerut-o cu ceea ce există în prezent în cloud. Apoi calculează secvența exactă de API calls necesară pentru a acoperi această diferență. Dacă rețeaua există deja, Terraform o lasă în pace și construiește doar serverul. Aici e ideea de bază. Mulți ingineri confundă tool-urile de provisioning de infrastructură, cum e Terraform, cu tool-urile de configuration management, cum ar fi Chef, Puppet sau Ansible. Nu sunt același lucru. Terraform construiește casa. Tool-urile de configuration management așază mobila. Terraform face provisioning la resursele brute de cloud, cum ar fi load balancer-ele și mașinile virtuale. Ansible sau Chef se loghează apoi pe acele mașini pentru a instala pachete software și a porni background services. Tool-urile de configuration management au fost concepute fundamental pentru mutable infrastructure. Ele se așteaptă ca un server să trăiască mult timp și să treacă prin patching și tweaking constant. Terraform te împinge către immutable infrastructure. Dacă un environment are nevoie de o altă versiune a sistemului de operare, Terraform nu se loghează ca să ruleze un script de upgrade. El distruge serverul vechi și face provisioning la unul complet nou, cu imaginea corectă. Această abordare strictă garantează că mereu codul tău corespunde cu realitatea, eliminând complet configuration drift-ul. Acest workflow este deosebit de valoros pentru că este platform agnostic. O companie folosește rareori un singur vendor. Poți să-ți rulezi workload-urile principale pe Azure, să-ți gestionezi DNS-ul prin Cloudflare și să te ocupi de incident routing în PagerDuty. Terraform gestionează toate astea printr-un model de provideri. Un provider este pur și simplu un plugin care înțelege un API specific al unui vendor. Folosind mai mulți provideri, poți construi o singură configurație care face spin up la o bază de date în Azure, configurează record-urile DNS necesare și setează simultan alertele de monitorizare. Acele API calls din spate se schimbă, dar workflow-ul tău rămâne exact același. Dacă vrei să ajuți ca aceste episoade să continue, poți căuta DevStoriesEU pe Patreon pentru a susține emisiunea. Un tool care doar automatizează task-uri te face mai rapid, dar un tool care impune o stare declarativă îți face întregul sistem predictibil. Aș vrea să-ți mulțumesc pentru că asculți — ne ajută foarte mult. Să ai o zi faină!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Terraform, episodul 2 din 13. Apeși pe deploy, te uiți la consolă și ții pumnii, sperând că nu tocmai ai picat mediul de producție. Acest salt în gol este un risc masiv și este exact ceea ce elimină workflow-ul de bază Terraform. Workflow-ul constă în trei pași stricți: write, plan și apply. Fiecare pas funcționează independent pentru a traduce cerințele tale în resurse care rulează. Începi cu faza de write. Creezi fișiere de configurare care declară exact infrastructura pe care o vrei. Nu scrii un script procedural care spune cum să construiești un server pas cu pas. Descrii starea finală, dorită, a mediului tău. Salvezi aceste fișiere, iar codul tău devine single source of truth pentru ceea ce ar trebui să existe. Utilizatorii noi cred uneori că următorul pas este pur și simplu executarea secvențială a acelor fișiere, de sus în jos. Nu așa funcționează acest tool. Nu rulează comenzi orbește. În schimb, trece la faza de plan. Faza de plan este superputerea absolută a acestui workflow. Când rulezi comanda plan, tool-ul evaluează noua configurație în raport cu starea actuală, reală, a infrastructurii. Calculează un diff precis între realitate și codul dorit. Aici e cheia. Tool-ul citește acest diff și generează un dry run foarte detaliat al fiecărei acțiuni pe care intenționează să o facă. Gândește-te la un inginer care trebuie să adauge un Azure Load Balancer într-un mediu live. Își actualizează fișierele de configurare și rulează comanda plan. Sistemul se conectează la cloud provider, verifică starea activă și afișează un rezumat strict. Inginerul citește output-ul și vede o resursă de adăugat, zero de modificat și zero de distrus. Output-ul detaliază proprietățile exacte ale noului load balancer. Inginerul validează acest dry run. Știe că modificarea este sigură înainte ca un singur API call să modifice infrastructura reală. Nu mai e nevoie să ghicești. După validarea output-ului, treci la faza de apply. Acesta este momentul execuției. Tool-ul preia diff-ul exact calculat în timpul fazei de plan și construiește un execution graph strict. Mapează toate dependențele. Dacă noul tău load balancer necesită o adresă IP publică dedicată, execution graph-ul se asigură că IP-ul este provizionat mai întâi. Sistemul așteaptă ca IP-ul să devină disponibil, îi preia noua adresă și abia apoi creează load balancer-ul. Gestionează automat timing-ul și ordinea. Deoarece faza de apply respectă cu strictețe planul de execuție aprobat, nu vei avea niciodată resurse care să facă spin up în ordinea greșită sau care să șteargă accidental baze de date existente din cauza unui typo. Workflow-ul te obligă să separi intenția de execuție. Cel mai puternic aspect al acestui proces nu este provizionarea automată în sine. Este eliminarea completă a anxietății operaționale prin dry run-uri previzibile și revizuibile. Asta e tot pentru acest episod. Mulțumesc pentru audiție și spor la construit!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Terraform, episodul 3 din 13. Out of the box, aplicația Terraform core nu știe de fapt cum să construiască un Virtual Machine în Azure sau să creeze o bază de date. Este strict un engine care evaluează cod, determină dependențe și gestionează state-ul. Pentru a face o treabă reală, se bazează pe mii de plugin-uri de traducere care pot fi descărcate. Asta ne aduce la providers și la modul în care îți conectezi codul la Azure. O confuzie comună este să crezi că aplicația Terraform în sine conține logica pentru fiecare platformă de cloud. Nu e așa. Binarul pe care îl instalezi pe mașina ta este complet agnostic față de infrastructură. Înțelege limbajul de configurare și workflow-ul de deployment, dar are zero cunoștințe hardcoded despre vreun API de cloud specific. În schimb, Terraform folosește plugin-uri numite providers. Un provider este o bucată de software standalone care înțelege endpoint-urile, metodele de autentificare și comportamentul resurselor pentru o anumită platformă. Există un provider pentru Microsoft Azure, unul pentru Amazon Web Services și altele pentru platforme software as a service precum GitHub sau Datadog. Aceste plugin-uri sunt publicate și găzduite într-un director central numit Terraform Registry. Când începi un nou proiect de infrastructură, trebuie să declari explicit ce providers va folosi codul tău. De asemenea, specifici versiunea exactă a provider-ului pe care o vrei. Să fixezi o versiune este o practică critică. Asta te asigură că, dacă API-ul de cloud se modifică sau plugin-ul de provider primește un update major mâine, deployment-ul tău nu se va strica pe neașteptate. Tu controlezi exact când să faci upgrade. Simpla declarare a provider-ului în fișierul tău text nu îl instalează. Trebuie să rulezi o comandă de inițializare în terminalul tău. Acest pas de inițializare contactează activ Terraform Registry, descarcă plugin-urile de provider necesare și le pune în cache într-un director local ascuns. Până când nu rulezi acest pas, proiectul tău Terraform nu poate interacționa cu niciun sistem extern. Hai să ne uităm la cum setezi asta pentru un proiect nou care se conectează la o subscripție Azure enterprise. Vei folosi provider-ul oficial Azure Resource Manager, denumit azurerm. După ce declari versiunea de care ai nevoie, trebuie să configurezi comportamentul specific al provider-ului. Fiecare provider are propriile cerințe de configurare bazate pe API-ul din spate. Pentru Azure, plugin-ul îți cere să declari explicit cum ar trebui să gestioneze anumite comportamente ale resurselor. De exemplu, trebuie să îi spui provider-ului dacă ar trebui să șteargă definitiv disk-urile de storage atașate atunci când un Virtual Machine este distrus. Provider-ul cere această configurare de la bun început, astfel încât acțiunile distructive să fie mereu intenționate. Odată inițializat și configurat, provider-ul acționează ca un layer de traducere plug-and-play. Când îți execuți codul, engine-ul core Terraform calculează diferența dintre infrastructura ta actuală și state-ul dorit. Apoi transmite acele instrucțiuni generice către plugin-ul de provider Azure. Plugin-ul preia controlul, traducând intenția ta în request-uri HTTP autentificate, trimise direct către API-ul Azure Resource Manager. Plugin-ul așteaptă ca Azure să termine de creat sau modificat resursele, traduce răspunsul API-ului înapoi într-un format pe care Terraform îl înțelege și returnează datele finale către engine-ul core. Terraform în sine nu comunică niciodată direct cu mediul tău de cloud; deleagă fiecare API call către plugin-ul de provider, făcând din provider puntea reală dintre codul tău și infrastructura ta live. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Terraform, episodul 4 din 13. Te uiți pe cod și vezi o bază de date etichetată primary, dar când te loghezi în consola de cloud, exact aceeași bază de date are un nume complet diferit, cum ar fi db-cluster-node-one. Dacă vrei ca ceva să existe fizic în mediul tău de cloud, trebuie să ceri asta folosind cel mai important construct din Terraform, dar trebuie să și înțelegi cum denumește Terraform lucrurile. Astăzi vorbim despre declararea infrastructurii folosind resurse. Resursele sunt componentele fundamentale ale infrastructurii tale. De fiecare dată când vrei să creezi, să faci update sau să distrugi un obiect, scrii un resource block. Acest obiect poate fi o componentă fizică, cum ar fi o instanță de compute sau un storage drive, sau un construct logic, cum ar fi un DNS record sau un role assignment. Acest resource block este modul prin care traduci ideea unei componente de infrastructură într-un API request pe care cloud provider-ul tău chiar îl înțelege. Când declari un resource block, îi definești identitatea folosind două etichete distincte. În primul rând, declari acel resource type. Asta îi spune lui Terraform exact ce fel de obiect vrei să construiești și ce provider îl va construi. Tipul începe mereu cu namespace-ul provider-ului, cum ar fi Azure sau AWS, urmat de serviciul specific. Practic, îi spui lui Terraform că ai nevoie de un resource group în Azure sau de un storage bucket în AWS. Imediat după resource type, definești acel local identifier. Acesta este pur și simplu un nickname. Există doar în configurația ta Terraform. Folosești acest nickname ca să faci referință la obiect din alte părți ale codului tău. Nu are absolut niciun efect asupra a ceea ce vede cloud provider-ul tău. Asta ne aduce la configuration block în sine. Odată ce declari tipul și acel nickname local, definești argumentele pentru acea resursă. Argumentele sunt setările și valorile specifice care configurează obiectul. Aici pasezi parametrii efectivi ceruți de API-ul cloud provider-ului. Ca să punem lucrurile cap la cap, imaginează-ți că faci deploy la un resource group în Azure. Declari acel resource type pentru un resource group de Azure și îi dai un nickname local, cum ar fi main. În interiorul acelui configuration block, oferi argumentele efective. Definești un argument name pe care îl setezi la rg-enterprise-prod și definești un argument location pe care îl setezi la o anumită regiune. Când rulezi deployment-ul, Terraform folosește acel resource type ca să știe ce API de provider să apeleze. Folosește argumentele tale ca să-i spună API-ului exact cum să configureze resursa. În portalul Azure, resource group-ul tău va apărea ca rg-enterprise-prod. Azure nu știe absolut nimic despre acel nickname main. Dar înapoi în codul tău, de fiecare dată când ai nevoie să preiei ID-ul sau locația acelui resource group pentru a le pasa către o mașină virtuală sau o bază de date, pur și simplu îi ceri lui Terraform datele ținute de resursa locală numită main. Fiecare resource type are propriul său set unic de argumente. Unele sunt obligatorii, cum ar fi locația pentru un resource group sau un instance size pentru un server virtual. Altele sunt opționale, cum ar fi tagging-ul sau reguli specifice de routing. Documentația provider-ului dictează exact ce argumente poți folosi. Tu doar mapezi valorile de care ai nevoie în acel resource block, iar Terraform se ocupă de traducerea în API calls care îți fac efectiv provision la infrastructură. Acel local identifier aparține de Terraform pentru a-ți menține codul lizibil, dar argumentele tale aparțin de cloud pentru a defini realitatea. Mersi că ne-ai ascultat. Până data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Terraform, episodul 5 din 13. Dacă o bază de date trebuie să existe înainte ca un web server să se poată conecta la ea, cum știe un tool de infrastructură pe care să o construiască prima fără scripturi secvențiale? Dacă vii dintr-un mediu de scripting imperativ, cum ar fi Bash sau Python, s-ar putea să cauți modalități de a forța execuția linie cu linie. Dar în Terraform, ordinea liniilor din fișierul tău nu contează deloc. Singurul lucru care contează sunt relațiile dintre resurse și dependențele. Terraform este un execution engine extrem de inteligent. Înainte să creeze ceva, îți analizează configurația și construiește un directed acyclic graph. Acest graf mapează exact felul în care fiecare bucată de infrastructură se conectează cu celelalte. Folosește această hartă pentru a determina cea mai eficientă ordine de creare, construind resursele fără legătură în paralel și secvențiindu-le pe cele care depind unele de altele. Nu scrii niciodată manual scripturi de wait sau sleep. De cele mai multe ori, Terraform își dă seama automat de această secvențiere prin dependențe implicite. O dependență implicită apare atunci când o resursă face referință la un atribut al altei resurse. Gândește-te la un scenariu în care creezi un Azure Virtual Network și un Subnet. Un subnet nu poate exista fără un virtual network. În configurația ta, definești block-ul de virtual network, iar apoi definești block-ul de subnet. În interiorul block-ului de subnet, setezi argumentul virtual network name să indice direct către atributul name al resursei virtual network pe care tocmai ai definit-o. Când Terraform face parse la asta, vede conexiunea. Știe inerent că trebuie să termine de creat acel virtual network și să-i preia acel name generat înainte să poată măcar începe crearea subnet-ului. Nu trebuie să-i spui ce să facă. Pur și simplu îi pasezi datele, iar Terraform se ocupă de timing. Asta e partea care contează. Folosește mereu dependențe implicite, dacă poți. Prin referențierea directă a atributelor, îi oferi lui Terraform informațiile exacte de care are nevoie pentru a-ți optimiza acele deployments în siguranță. Uneori, relația dintre două resurse nu este vizibilă în cod. S-ar putea să ai o situație în care o resursă are nevoie ca o altă resursă să fie complet activă, dar nu are de fapt nevoie să tragă date din ea. Gândește-te că faci deploy la o mașină virtuală care rulează o aplicație, în timp ce faci și provisioning pentru un managed database. Aplicația are nevoie ca baza de date să termine procesul de boot înainte să poată porni. Totuși, configurația mașinii virtuale nu face referință la niciun atribut din resursa bazei de date. Pentru că nu există niciun data link, Terraform presupune că aceste două resurse sunt complet independente și va încerca să le construiască în același timp. Aplicația va face boot, va căuta o bază de date care nu există încă, și va da fail. Pentru a repara asta, folosești dependențe explicite. Terraform oferă un meta-argument numit depends on. Adaugi acest argument la block-ul mașinii virtuale și îi pasezi o listă care conține resursa bazei de date. Asta îi spune explicit lui Terraform să pună pe pauză crearea mașinii virtuale până când baza de date a terminat complet procesul de provisioning. Ar trebui să tratezi dependențele explicite ca pe o ultimă soluție. Ele forțează Terraform să fie mai conservator în execuția sa, ceea ce îți încetinește acele deployments. De asemenea, pot face configurația mai greu de menținut în timp, deoarece motivul real al dependenței nu este mereu evident pentru următorul inginer care citește fișierul. Să lași acel execution graph să facă greul este ceea ce separă infrastructura declarativă de scripturile procedurale, așa că nu mai încerca să faci micro-management pe ordinea de execuție și lasă acel data flow să dicteze secvența. Mersi că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Terraform, episodul 6 din 13. Scrii codul de infrastructură, rulezi apply și serverele tale pornesc perfect. Dar dacă rulezi din nou apply cinci minute mai târziu, nu se întâmplă nimic. Terraform știe că treaba este deja făcută. Spre deosebire de scripturile simple de automatizare care execută orbește comenzi, Terraform are o memorie. Fără ea, ar fi complet orb față de infrastructura pe care tocmai a terminat să o construiască. Această memorie se numește Terraform State. Când rulezi Terraform, acesta creează un fișier local numit terraform dot tfstate. Mulți ingineri privesc inițial acest fișier ca pe o bătaie de cap. Pare un artefact suplimentar de gestionat și securizat. Dar acest fișier este nucleul modului în care funcționează Terraform. Terraform are nevoie de un mecanism pentru a mapa resursele logice definite în fișierele tale de configurare la obiectele fizice remote care se află în mediul tău cloud. O concepție greșită des întâlnită este că Terraform se uită doar la tag-urile cloud provider-ului pentru a-și da seama ce gestionează. S-ar putea să crezi că pune un tag pe un server în timpul creării, iar apoi caută în cloud acel tag specific pentru a ști ce să actualizeze. Această abordare dă greș rapid. Nu toate resursele cloud suportă tag-uri. În plus, cineva ar putea edita sau șterge manual un tag, rupând conexiunea. În cele din urmă, căutarea într-un cont cloud enterprise masiv după tag-uri specifice de fiecare dată când rulezi un plan ar fi incredibil de lentă. Deoarece tag-urile nu sunt de încredere, Terraform folosește un state file dedicat, extrem de structurat. State file-ul acționează ca o bază de date privată de mapare. Când declari o resursă în codul tău, Terraform o creează prin intermediul API-ului provider-ului. Provider-ul returnează un identificator fizic unic pentru acel obiect nou creat. Terraform preia numele resursei logice din cod, îl asociază cu acel cloud ID unic și scrie perechea în state file. Ia un scenariu practic. Te decizi să modifici dimensiunea unei mașini virtuale Azure în codul tău. Când rulezi apply, Terraform nu ghicește ce mașină să modifice. Verifică state file-ul, caută numele resursei logice și preia instance ID-ul exact din Azure. Apoi trimite un update request care vizează acel ID specific. Fără state file, Terraform nu ar ști dacă ar trebui să actualizeze o mașină existentă sau pur și simplu să creeze una duplicată. Dincolo de mapare, state-ul se ocupă de urmărirea de metadata. Terraform trebuie să știe ordinea exactă în care au fost create resursele pentru a le putea actualiza sau distruge în siguranță. Dacă un web server are nevoie de o bază de date, acea dependență este scrisă în codul tău. Totuși, dacă ștergi întregul bloc de cod pentru a dezafecta mediul, Terraform nu mai poate citi codul pentru a găsi dependența. State file-ul păstrează o copie a acestor metadata istorice, asigurându-se că Terraform distruge web server-ul înaintea bazei de date. State-ul oferă, de asemenea, un caching crucial pentru performanță. Interogarea unui API de cloud provider pentru a colecta statusul actual a mii de reguli de rețea, storage buckets și compute nodes necesită o cantitate semnificativă de timp. Cloud providerii impun, de asemenea, API rate limits stricte. State file-ul acționează ca un cache al atributelor infrastructurii tale. Consultând acest cache, Terraform minimizează numărul de API calls lente și costisitoare necesare pentru a calcula un plan. Iată ideea de bază. Configurația ta descrie ceea ce îți dorești, cloud provider-ul deține ceea ce există de fapt, iar state file-ul este singura punte definitivă care leagă cele două. Asta e tot pentru acest episod. Ne auzim data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Terraform, episodul 7 din 13. Să faci hardcoding la valori e ok pentru un test rapid, dar ce se întâmplă când trebuie să dai deploy la exact același setup atât într-un mediu de development, cât și în producție? Nu poți să duplici și să rescrii codul pentru fiecare deploy nou. Mecanismul care rezolvă asta este parametrizarea cu input variables. Aceste input variables servesc drept parametri pentru un module Terraform. Ele îți permit să personalizezi aspecte ale infrastructurii tale fără să modifici codul sursă de la bază. Ăsta e exact pasul în care codul tău trece de la un proof of concept la un template production-ready. Folosind variabile, scrii configurația o singură dată și o refolosești peste tot. Înainte să intrăm în detalii, trebuie să clarificăm o confuzie comună. Există o diferență strictă între declararea unei variabile și atribuirea unei valori pentru ea. Declararea unei variabile îi spune pur și simplu lui Terraform că există un parametru și îi definește regulile. Atribuirea unei valori este actul de a-i oferi efectiv date în timpul unui deploy. Declari o variabilă folosind un block variable urmat de un nume unic. În interiorul acestui block, definești tipul de date așteptat. Terraform suportă mai multe tipuri. Un string este doar text obișnuit. Un list este o secvență ordonată de valori, cum ar fi mai multe availability zones. Un map este o colecție de perechi key-value, ceea ce e perfect pentru aplicarea de resource tags standard. În interiorul block-ului variable, poți seta și o valoare default. Dacă oferi o valoare default, variabila devine opțională. Dacă userul nu dă o valoare în timpul deploy-ului, Terraform folosește pur și simplu valoarea default. Dacă nu setezi o valoare default, Terraform va forța userul să ofere o valoare înainte să continue. Hai să ancorăm asta într-un scenariu practic. Să presupunem că ai un deploy în Azure. În acest moment, configurația ta cere explicit un virtual machine size mic numit Standard B2s și face hardcoding la un environment tag cu valoarea dev. Ca să faci asta reutilizabil, înlocuiești acel text hardcoded cu o referință. În Terraform, faci referire la o input variable tastând var dot urmat de numele variabilei. Deci, în loc să scrii Standard B2s, scrii var dot vm size. În loc de dev, scrii var dot environment. Acum codul tău e flexibil, dar Terraform tot trebuie să știe ce valori să folosească atunci când rulează efectiv. Aici intervin fișierele de definire a variabilelor. Astea sunt fișiere care se termină în dot tfvars. Un fișier tfvars este pur și simplu o listă de nume de variabile și valorile lor corespunzătoare. Pentru deploy-ul în producție, creezi un fișier numit prod dot tfvars. În el, setezi variabila environment la prod, iar variabila vm size la o instanță mai mare, cum ar fi Standard D4s. Când rulezi Terraform, îl direcționezi către acest fișier. Terraform citește fișierul tfvars, injectează acele valori în referințele tale var dot și face provision la mediul de producție. Mâine, poți direcționa exact același cod Terraform către un fișier dev dot tfvars ca să ridici un mediu de testare mic. Aici e ideea cheie. Să îți ții logica complet separată de datele specifice mediului este ceea ce face infrastructura cu adevărat repeatable. Dacă ți se par utile aceste episoade și vrei să susții emisiunea, poți căuta DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mulțumesc că ai ascultat și spor la construit!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Terraform, episodul 8 din 13. Infrastructura ta cloud termină procesul de deploy perfect, dar tot ai o problemă majoră: trebuie să îi știi adresa IP publică pentru a te conecta efectiv la ea. Să cauți manual prin dashboard-urile providerului de cloud anulează tot scopul automatizării. Ai nevoie de o modalitate să extragi acea informație specifică direct din Terraform. Aici intervine expunerea datelor folosind output values. Aceste output values sunt, în esență, valorile returnate de o configurație Terraform. Când definești și creezi o resursă, providerul de cloud generează anumite atribute în mod dinamic. Acestea sunt lucruri pe care nu le poți ști înainte de deploy, cum ar fi o adresă IP atribuită, o parolă generată pentru baza de date sau un anumit nume de domeniu. Folosești block-uri de output pentru a captura acele atribute generate dinamic și a le expune către exterior. Ca să definești unul, scrii un block de output urmat de un label. Acest label este pur și simplu numele pe care vrei să-l atribui acelui output. În interiorul block-ului, definești un singur argument obligatoriu numit value. Acest argument indică exact bucata de date pe care vrei să o extragi. De exemplu, dacă creezi o mașină virtuală, poți seta argumentul value să indice direct către atributul de IP public al acelei resurse specifice. Ia un scenariu concret. Ai un pipeline automatizat care face deploy la un nou cluster Azure Kubernetes Service. Când se termină procesul de deploy, developerii tăi au nevoie de acel endpoint de Kubernetes brut, generat automat, pentru a-și configura tool-urile locale de conectare. Fără un output, cineva ar trebui să se logheze în portalul de cloud, să găsească cluster-ul și să copieze manual adresa URL. În schimb, scrii un block de output numit cluster endpoint. Îi setezi argumentul value să facă referință la atributul fully qualified domain name al cluster-ului Kubernetes nou construit. Când Terraform termină de aplicat configurația ta, adună toate acele output values definite și le afișează direct în command line interface. Pipeline-ul tău de automatizare poate apoi să citească acel text și să transmită endpoint-ul direct developerilor. De asemenea, poți recupera aceste valori mai târziu fără să rulezi un nou deploy. Pur și simplu rulezi comanda Terraform output în terminalul tău. Pentru scripturile de automatizare, poți chiar să îi spui acelei comenzi să returneze datele ca raw text sau în format JSON, făcându-le ușor de parsat pentru alte tool-uri software. Uneori, datele pe care trebuie să le expui ca output sunt confidențiale, cum ar fi o parolă de bază de date sau un private key. Nu vrei ca acele string-uri să ruleze pe un ecran de terminal partajat sau să rămână permanent în build log-urile tale de continuous integration. Pentru a preveni asta, adaugi argumentul sensitive în interiorul block-ului de output și îl setezi pe true. Terraform va ascunde apoi valoarea reală în afișajul consolei, înlocuind-o cu un tag de tip placeholder care indică faptul că valoarea este sensitive. Iată detaliul cheie. Setarea unui output ca sensitive doar îl ascunde din afișajul terminalului. Nu criptează și nu ascunde datele din fișierul de state Terraform. Parola sau cheia este în continuare stocată în plain text în datele tale de state de pe disk sau în remote backend-ul tău. Flag-ul sensitive este pur și simplu un filtru de afișare pentru command line interface, nu un mecanism de securitate pentru stocarea ta. Aceste output values acționează în cele din urmă ca API-ul tău de configurare. Ele reprezintă modul structurat și predictibil prin care transmiți informații critice înapoi către oameni sau tool-uri de automatizare în momentul în care un run se finalizează. Asta e tot pentru acest episod. Îți mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Terraform, episodul 9 din 13. Nu orice element de infrastructură din mediul tău cloud a fost construit de codul Terraform pe care îl scrii în prezent. Cu toate acestea, codul tău are totuși nevoie de o modalitate de a se conecta la acele sisteme existente în siguranță, fără a le modifica accidental. Interogarea cu Data Sources este exact modul în care gestionezi acest lucru. Un punct major de confuzie atunci când înveți Terraform este diferența dintre un resource block și un data block. Hai să clarificăm asta chiar acum. Un resource block îi spune lui Terraform să creeze, să actualizeze și să dețină un obiect de infrastructură. Un data block face doar o căutare read-only. Acesta cere API-ului de provider să găsească un obiect existent și să returneze detaliile acestuia, astfel încât configurația ta să poată citi acele detalii. Această capacitate read-only este fundamentul unei arhitecturi de infrastructură decuplate. Ia în considerare un setup standard de enterprise. O echipă centralizată de networking construiește și gestionează acel Virtual Network corporate. Ca application developer, trebuie să dai deploy la un Azure Virtual Machine și să îl atașezi exact la acea rețea. Tu nu deții codul rețelei. De asemenea, nu ar trebui să dai hardcode la ID-ul unic al rețelei în fișierele tale Terraform, deoarece ID-urile hardcoded se strică ușor dacă mediile sunt vreodată recreate. În schimb, pur și simplu cauți rețeaua. Faci asta prin definirea unui data block. Sintaxa seamănă foarte mult cu un resource block. Începi cu cuvântul cheie data. Apoi, specifici tipul de data source, cum ar fi azurerm virtual network. Apoi îi dai un nume local, cum ar fi corporate, pe care îl vei folosi pentru a-l referenția mai târziu în codul tău. În interiorul blocului, definești argumentele de căutare. Acestea acționează ca niște filtre stricte. Poți pasa numele human-readable al acelui virtual network și resource group-ul din care face parte. Terraform folosește aceste argumente pentru a construi un query. Când rulezi un Terraform plan, Terraform contactează API-ul Azure și caută un virtual network care se potrivește cu filtrele tale. Dacă API-ul returnează exact un match, Terraform descarcă proprietățile acelei rețele în memorie. Dacă query-ul returnează zero match-uri, sau dacă filtrele sunt prea permisive și returnează mai multe match-uri, Terraform se oprește imediat și aruncă o eroare. Această strictețe este intenționată. Te împiedică să dai deploy accidental la aplicația ta în subnet-ul sau environment-ul greșit. După ce data source-ul preia cu succes informațiile, poți extrage orice atribut exportat din el. Sintaxa pentru referențierea unui data source este extrem de structurată. Începi cu cuvântul data, urmat de un punct, tipul de data source, un punct, numele tău local și, în final, atributul specific de care ai nevoie. În scenariul nostru, ai tasta data dot azurerm virtual network dot corporate dot id. Pasezi acel string specific direct în resource block-ul de virtual machine, ocolind complet nevoia de a da hardcode la o valoare statică. Iată partea care contează. Data sources îți permit să tratezi infrastructura din jur ca pe un serviciu dinamic. Nu trebuie să construiești environment-ul pentru a interacționa cu el și poți lega în siguranță workspace-uri independente pur și simplu făcând un query după identificatorii exacți de care ai nevoie la runtime. Mersi că ai stat cu mine. Sper că ai învățat ceva nou.

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Terraform, episodul 10 din 13. Dacă trebuie să dai deploy la cincizeci de servere web identice, ultimul lucru pe care vrei să-l faci este să dai copy și paste la același block de cod de cincizeci de ori. Poate cauți un while-loop tradițional sau un for-loop, dar Terraform nu funcționează așa. În schimb, gestionezi scalarea la nivel de block folosind count și for each. Implicit, un resource block configurează exact un obiect de infrastructură. Pentru a face provision la mai multe obiecte, adaugi meta-argumentul count în interiorul acelui block. Acesta acceptă un număr întreg. Dacă setezi count la trei, Terraform face provision la trei obiecte din acel singur block de configurare. Aceste obiecte, de obicei, nu pot fi strict identice în lumea reală. Au nevoie de nume sau adrese IP unice. Pentru a gestiona asta, Terraform îți oferă obiectul count dot index. Asta este o variabilă specială, disponibilă doar în block-urile care au un argument count. Să zicem că dai deploy la trei mașini virtuale Azure. Scrii un resource block pentru mașina virtuală și setezi count la trei. În interiorul block-ului, atribui numele mașinii combinând cuvântul web, o cratimă și valoarea count dot index. Pentru că indexul începe de la zero, Terraform evaluează acest block și generează ca output trei mașini separate numite web-zero, web-one și web-two. Adăugarea lui count schimbă modul în care Terraform urmărește resursa intern. O singură resursă este adresată simplu, prin tipul și numele ei. Odată ce adaugi count, acea adresă devine un array. Acum faci referință la instanțe specifice în altă parte a codului tău folosind numerele lor de index între paranteze pătrate. Count este foarte eficient, dar are un risc mecanic specific legat de ordinea din listă. Iată ideea cheie. Count identifică resursele în întregime prin poziția lor de tip integer. Dacă folosești o listă de valori pentru a configura un block cu count, poziția de index este singurul lucru de care îi pasă lui Terraform. Dacă ai trei elemente și schimbi count la doi, Terraform distruge ultimul element din array, indexul doi. Dacă injectezi un nou string în mijlocul listei tale sursă, toate pozițiile de index ulterioare se decalează în jos. Terraform va observa că s-a modificat configurarea pentru indexul unu, s-a modificat pentru indexul doi, și așa mai departe. Probabil va distruge și va recrea o infrastructură perfect sănătoasă doar pentru că ordinea din lista sursă s-a decalat. Pentru a rezolva această vulnerabilitate, folosești în schimb meta-argumentul for each. În timp ce count acceptă un număr întreg, for each acceptă un map sau un set de string-uri. În loc să creeze un array de obiecte indexate prin numere secvențiale, for each creează un map de obiecte urmărite prin chei explicite de tip string. Dacă îi pasezi un set care conține string-urile frontend și backend, Terraform creează resurse adresate prin acele nume exacte. Dacă adaugi un string nou mai târziu, sau elimini unul, Terraform adaugă sau distruge doar acea resursă specifică. Restul rămân neatinse pentru că identificatorii lor sunt chei fixe de tip string, nu poziții numerice fragile. Folosește count atunci când obiectele de infrastructură sunt cu adevărat interschimbabile, dar treci la for each în momentul în care acele obiecte necesită identități distincte, care trebuie să supraviețuiască modificărilor din lista ta de configurare. Mersi că ai ascultat. Până data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Terraform, episodul 11 din 13. Singurul tău fișier de configurare Terraform a fost ok pentru un web server simplu, dar pe măsură ce infrastructura ta crește, devine rapid un monolit dezordonat și greu de citit. Dai copy-paste la aceleași resource blocks la nesfârșit doar pentru a schimba un singur string de nume sau un environment tag. E timpul să nu te mai repeți și să construiești componente reutilizabile folosind module. Un modul este un container pentru mai multe resurse care sunt folosite împreună. Dacă ești familiarizat cu orice limbaj de programare, te poți gândi la un modul ca la o funcție. Scrii logica complexă o singură dată, o încapsulezi, și apoi o apelezi de mai multe ori din altă parte. În Terraform, fiecare configurație are deja cel puțin un modul. Fișierele din working directory-ul tău principal formează ceea ce se numește root module. Când root module-ul tău face referință la un alt set de fișiere de configurare, acel al doilea set este cunoscut sub numele de child module. Gândește-te la un scenariu specific. O echipă DevOps centralizată vrea să se asigure că fiecare storage account creat în companie este securizat by default, cu criptare, private endpoints și diagnostic logging aplicate strict. În loc să se bazeze pe fiecare developer de aplicații că va configura corect zece resurse complexe diferite, echipa DevOps creează un modul standard Secure Azure Storage. Când o echipă de aplicații are nevoie de storage, nu scrie un bloc masiv de definiții de resurse. Scrie doar un module block în configurația lor root. În interiorul acelui module block, primul lucru pe care îl definesc este un argument source. Source-ul îi spune lui Terraform exact unde să găsească fișierele din child module, fie că este vorba de un local directory path sau de un remote repository. Sub source, echipa de aplicații pasează argumente. La fel ca atunci când pasezi argumente unei funcții, ei furnizează datele specifice de care child module-ul are nevoie pentru a rula, cum ar fi un nume unic de aplicație sau un environment identifier. Aceste argumente se mapează direct pe input variables definite în interiorul child module-ului. Child module-ul preia aceste inputuri, execută configurațiile de resurse din spate și construiește infrastructura. Echipa de aplicații obține automat un storage compliant, complet izolată de complexitatea din spate. Aici este ideea cheie. Oamenii sunt adesea confuzi în legătură cu felul în care Terraform gestionează scope-ul dintre aceste module. Când apelezi un child module, resursele din interiorul lui sunt strict încapsulate. Root module-ul tău nu poate citi direct o adresă IP, un connection string sau un storage ID generat în interiorul acelui child module. Child module-ul este un black box. Dacă root module-ul tău are nevoie de o informație care a fost generată în interiorul child module-ului, child module-ul trebuie să o exporte explicit folosind un output block. Variabilele acționează ca input parameters, iar output-urile acționează ca return values. Acestea formează o interfață strictă. Odată ce child module-ul exportă acele date ca output, root module-ul le poate citi în sfârșit. Accesezi aceste date folosind cuvântul module, urmat de numele specific pe care l-ai atribuit acelui module block, și apoi de numele output-ului. Dacă child module-ul dă ca output un storage account ID generat, root module-ul tău îl poate prelua folosind acea sintaxă și îl poate pasa mai departe către o bază de date sau o mașină virtuală care trebuie să se conecteze la el. Adevărata putere a modulelor nu constă doar în a salva linii de cod. Este abilitatea de a defini un standard arhitectural o singură dată, de a ascunde complexitatea și de a oferi o interfață curată și predictibilă pentru restul organizației. Mersi pentru audiție. Aveți grijă de voi, tuturor.

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Terraform, episodul 12 din 13. Un state file local de pe hard disk funcționează perfect atunci când construiești singur. Dar în momentul în care doi ingineri încearcă să actualizeze aceeași infrastructură în exact aceeași secundă, ai rețeta perfectă pentru un mediu corupt. Acesta este pragul dintre experimentarea individuală și colaborarea în echipă și ne aduce la enterprise readiness: remote state și locking. By default, Terraform își scrie starea curentă a infrastructurii tale într-un fișier local numit terraform dot tfstate. Acest fișier este sursa critică de adevăr care mapează codul de configurare la resursele din lumea reală. Problema apare atunci când adaugi mai mulți oameni în proiectul tău. Dacă colegul tău face o modificare de pe mașina lui, laptopul tău habar nu are că mediul tocmai s-a schimbat. Lucrezi cu informații învechite. Uneori, echipele încearcă să rezolve asta dând commit la state file în sistemul lor de version control. Acesta este un risc sever de securitate. Fișierele state file stochează în mod obișnuit date sensibile, cum ar fi parole de baze de date sau chei private, în plain text. Abordarea corectă este configurarea unui remote backend. În loc să salveze acel state file pe o mașină locală, Terraform citește și scrie aceste date dintr-un data store securizat și centralizat. Acesta este de obicei un serviciu de object storage, cum ar fi un bucket Amazon S3, un container Azure Blob Storage sau un bucket Google Cloud Storage. Când folosești un remote backend, de fiecare dată când cineva rulează o comandă, Terraform interoghează acel storage central pentru a obține cea mai precisă și actualizată imagine a infrastructurii. Tranziția la acest setup necesită adăugarea unui bloc de configurare backend în codul tău, care să definească unde ar trebui să stea acel state. Fii atent la partea asta. O greșeală foarte comună este să scrii acea configurare, să salvezi fișierul și să presupui că acel state este acum remote. Nu este. După adăugarea blocului backend, trebuie să rulezi din nou terraform init. Rularea acestei comenzi de inițializare este trigger-ul care îi spune lui Terraform să copieze fizic acel state file local existent și să-l migreze în cloud backend. Mutarea acelui state file într-o locație shared rezolvă problema de vizibilitate, dar te expune la modificări concurente. Dacă două deployment pipelines declanșează simultan un update, ambele ar putea încerca să scrie în acel remote state file în același timp, corupându-l complet. De aceea, un remote backend suportă state locking. Ia în considerare un mediu care folosește Azure Blob Storage pentru remote state-ul său. Doi ingineri lucrează la update-uri diferite. Inginerul A rulează un apply. Înainte de a face orice modificare la resursele cloud reale, Terraform contactează containerul de storage Azure și pune un lock pe acel remote state file. O fracțiune de secundă mai târziu, Inginerul B încearcă să ruleze propriul apply. Terraform verifică acel remote backend, detectează lock-ul activ și interceptează imediat rularea Inginerului B. În loc să creeze o coliziune, Terraform se oprește în siguranță și returnează o eroare, explicând că un alt proces deține în prezent acel lock. Odată ce prima rulare se finalizează cu succes, Terraform eliberează automat lock-ul. Implementarea unui remote backend cu locking este pasul definitoriu pentru infrastructure as code la nivel enterprise. Îți securizează datele sensibile și elimină acele race conditions periculoase. Un remote state se asigură că, indiferent cine rulează codul sau de unde, întreaga ta echipă este ferm ancorată în exact aceeași realitate. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. Fundamentele Terraform, episodul 13 din 13. Ți-ai scris configurația, ai testat-o local și ai făcut deploy la resurse. Dar executarea modificărilor de infrastructură de pe laptopul unui developer este un bottleneck, nu o strategie. Un apply manual duce la state-uri conflictuale, modificări fără review și riscuri de securitate. Automatizarea adevărată rulează în siguranță într-un pipeline, declanșată automat de version control. Asta ne aduce la Enterprise Workflows și CI/CD. Când treci de la a lucra singur la o echipă, workflow-ul de bază Write, Plan și Apply se mută complet de pe mașina ta locală. Version control-ul devine source of truth-ul absolut. Nu mai rulezi comenzi direct și începi să lași pipeline-urile de continuous integration să orchestreze modificările de state. Iată ideea cheie. Pipeline-ul împarte faza tradițională de plan în două concepte distincte: planuri speculative și planuri concrete. Înțelegerea diferenței este crucială pentru designul pipeline-ului. Gândește-te la un developer care trebuie să mărească dimensiunea unei mașini virtuale Azure. El actualizează dimensiunea instanței în configurație, face commit la cod și deschide un Pull Request. În exact acest moment, pipeline-ul declanșează automat un plan speculativ. Un plan speculativ arată pur și simplu ce intenționează să facă Terraform. Verifică codul propus în raport cu remote state-ul pentru a calcula delta, dar este strict read-only. Nu i se poate da apply în nicio circumstanță. Pipeline-ul preia output-ul acestui plan speculativ și îl postează direct ca un comentariu text la Pull Request. Când un senior engineer face review la cod, nu vede doar schimbarea de sintaxă. Vede impactul exact asupra infrastructurii. Știe precis ce resurse Azure vor fi modificate, create sau distruse înainte de a da approve. Odată ce Pull Request-ul primește approve și merge în main branch, pipeline-ul declanșează a doua fază. Generează un plan concret pe acel main branch. Acesta este un fișier plan executabil. Deoarece main branch-ul este source of truth-ul de încredere, pipeline-ul preia acest plan concret și îi dă imediat apply. Infrastructura live este actualizată automat de către robot, nu de către om. Rularea Terraform în automatizare deschide ușa către controale enterprise avansate. Policy-as-code, folosind framework-uri precum Sentinel, se integrează direct în acest pipeline. Sentinel evaluează planul înainte ca apply-ul să aibă loc. Dacă un developer solicită accidental o instanță de bază de date care încalcă restricțiile de cost sau regulile de compliance, policy engine-ul o semnalează și oprește imediat pipeline-ul. Acest workflow automatizat este ceea ce permite un model de infrastructură self-service. Platform engineers construiesc și testează module reutilizabile, în timp ce developerii de aplicații deschid pur și simplu un Pull Request solicitând resursele de care au nevoie. Pipeline-ul generează planul pentru schimbare, policy-as-code verifică compliance-ul, iar un coleg face review la intenție. Echipa aplicației își obține rapid infrastructura, iar echipa de platformă impune securitatea fără a acționa ca un roadblock manual. Asta încheie seria noastră de fundamente. Acum știi cum scalează Terraform de la o singură comandă locală la un engine enterprise automatizat. Cea mai bună modalitate de a consolida aceste cunoștințe este să construiești ceva, să citești documentația oficială și să experimentezi chiar tu cu aceste pipeline-uri. Dacă ai idei pentru subiecte viitoare, vizitează devstories dot eu. Aș vrea să-mi iau un moment să-ți mulțumesc că ne-ai ascultat — ne ajută foarte mult. Să ai o zi super!