Pulumi: Infrastructure as Code

Salut, sunt Alex de la DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodul 1 din 10. Ce-ar fi dacă ai putea scrie infrastructura de cloud folosind exact același limbaj de programare pe care îl folosești pentru aplicația ta? Gata cu context-switching-ul între logica aplicației și mii de linii de markup custom. Infrastructura developerului: De ce Pulumi? acoperă exact această schimbare. Istoric vorbind, Infrastructure as Code însemna să scrii domain-specific languages sau blocuri nesfârșite de YAML. Dacă voiai să dai deploy la o bază de date și un server, învățai o sintaxă exclusivă pentru acel tool specific de provisioning. Pierdeai ecosistemul bogat de software engineering standard. Nu puteai să scrii ușor un loop, să integrezi testing frameworks standard sau să dai share la logică folosind package registries standard. Pulumi schimbă această fundație. Este o platformă de Infrastructure as Code care îți permite să construiești, să dai deploy și să gestionezi resurse de cloud folosind limbaje de programare general-purpose. În loc să înveți un limbaj de configurare custom, folosești TypeScript, Python, Go, C# sau Java. Gândește-te la un developer care definește resurse de cloud folosind TypeScript. Cu tool-urile tradiționale, faci constant context-switching ca să cauți scheme YAML într-un web browser. Cu Pulumi, rămâi în editor. Instanțiezi o clasă de resurse, pui un punct, iar auto-completion-ul standard din IDE îți arată exact ce proprietăți sunt disponibile. Ai inline type-checking înainte să rulezi un deployment. Dacă ai nevoie de trei storage buckets identice, scrii un for-loop standard. Dacă firma ta impune reguli de securitate specifice pe fiecare server, abstractizezi acea logică într-o funcție standard, o publici într-un package registry standard și lași alte echipe să o importe, la fel ca pe orice library de cod obișnuit. Iată ideea cheie. Pentru că scrii această infrastructură în limbaje imperative, ai putea presupune că Pulumi este doar un automation script care apelează secvențial cloud APIs. Nu este un script de execuție imperativă. Pulumi folosește în continuare un declarative state model extrem de robust în culise. Când execuți programul tău Pulumi, acesta nu face imediat provisioning de resurse linie cu linie. În schimb, codul tău rulează pentru a construi acel end state dorit al infrastructurii tale. Engine-ul Pulumi capturează aceste definiții de resurse și construiește un dependency graph strict. Apoi compară acest state dorit cu state-ul actual al mediului tău de cloud. Pulumi calculează diferența exactă și efectuează doar operațiunile specifice de create, update sau delete necesare pentru ca realitatea să corespundă codului tău. Scrii cu flow-ul expresiv al unui limbaj imperativ, dar beneficiezi de siguranța și predictibilitatea unui deployment engine declarativ. Prin adoptarea limbajelor general-purpose, deblochezi accesul la linters, unit testing frameworks și continuous integration pipelines existente. Pulumi pur și simplu nu mai tratează infrastructura ca pe un domeniu de configurare separat și o transformă în software standard, guvernat de exact aceeași rigoare și tooling ca aplicația ta principală. Dacă vrei să susții podcastul, ne poți găsi căutând DevStoriesEU pe Patreon. Aș vrea să-ți mulțumesc pentru că ne asculți — ne ajută foarte mult. Să ai o zi super!

Salut, sunt Alex de la DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodul 2 din 10. Instanțiezi o clasă Python standard în editorul tău, dai deploy și, câteva secunde mai târziu, există un storage bucket în cloud. Cum se traduce mai exact un obiect local din memorie într-o resursă fizică remote? Astăzi, răspundem la această întrebare analizând Under the Hood: Pulumi's Architecture. Există o concepție greșită des întâlnită despre cum funcționează acest tool. Când scrii un script de deployment, codul tău nu comunică cu API-urile de cloud. Mediul care rulează codul tău Python, Node sau Go nu are absolut nicio idee cum să comunice cu Amazon Web Services. În schimb, Pulumi împarte procesul de deployment în trei componente distincte: Language Host, Deployment Engine și Resource Providers. Totul începe cu Language Host. Această componentă îți evaluează programul și îți extrage intenția. Ia în considerare un script Python în care declari un bucket AWS S3 prin inițializarea unui obiect de tip bucket. Language Host-ul pentru Python îți rulează scriptul linie cu linie. Când ajunge la acea declarație de bucket, nu face un network request către AWS. Pur și simplu trimite un registration request către Deployment Engine. Îi spune engine-ului că vrei să existe un bucket cu anumite proprietăți specifice. Language Host-ul comunică acest desired state printr-o conexiune locală și apoi se oprește, așteptând un răspuns înainte de a evalua următoarea linie de cod. Deployment Engine-ul primește acest registration request. Această componentă este orchestratorul. Engine-ul nu știe nimic despre sintaxa Python și nu știe nimic despre API-ul AWS. Singura sa sarcină este de state management. Analizează acel desired state trimis de Language Host și îl compară cu ultimul actual state cunoscut al infrastructurii tale. Dacă engine-ul vede că exact acest bucket S3 nu există în state-ul curent, calculează un diff și determină că este necesară o operațiune de creare. Pentru a construi efectiv bucket-ul, engine-ul predă sarcina celei de-a treia componente, Resource Provider-ul. Providerii sunt pluginuri standalone descărcate pentru platforme specifice, cum ar fi AWS, Azure sau Kubernetes. Deployment Engine-ul trimite o instrucțiune către Resource Provider-ul AWS, spunându-i să creeze bucket-ul cu proprietățile solicitate. Aici este ideea cheie. Resource Provider-ul este singura componentă din întregul lanț care știe cum să comunice cu cloud-ul. Preia comanda generică de creare de la engine, o traduce în apelurile REST API specifice cerute de AWS și le execută prin rețea. Odată ce AWS face provision la bucket-ul S3, returnează un physical resource ID. Resource Provider-ul prinde acest physical ID și îl dă înapoi Deployment Engine-ului. Engine-ul își actualizează state-ul intern pentru a înregistra faptul că bucket-ul există acum în lumea reală. În cele din urmă, engine-ul semnalează înapoi către Language Host că resursa este gata, transmițând orice output properties, cum ar fi numele bucket-ului sau adresa URL. Language Host-ul își reia execuția, iar scriptul tău Python continuă cu următoarea instrucțiune. Această separare strictă între evaluarea limbajului, orchestrarea de state și execuția în cloud este ceea ce conferă arhitecturii flexibilitatea sa. Poți adăuga un nou limbaj de programare fără a atinge cloud providerii și poți adăuga un nou cloud provider fără a modifica Language Hosts. Asta e tot pentru acest episod. Pe data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodul 3 din 10. Configurarea unui proiect de infrastructură cloud însemna ore întregi de luptă cu fișiere de tip boilerplate și structuri de foldere înainte să poți scrie o singură linie de logică. Astăzi, poți să faci scaffold la un mediu complet în câteva secunde. Ne concentrăm pe Hello Azure: Creating Your First Project ca să vedem exact cum se întâmplă asta. O concepție greșită des întâlnită este că rularea comenzii de creare a proiectului construiește imediat infrastructura în cloud. Nu e așa. Comanda despre care discutăm generează doar fișiere locale și îți pregătește state tracking-ul. Nu se creează resurse Azure reale până când nu rulezi explicit o comandă de deploy mai târziu. Ca să dai bootstrap la un proiect nou, folosești command line interface-ul. Mai întâi, creezi un director gol și te muți în el. Apoi, rulezi comanda pulumi new urmată de numele unui template. Pentru Azure, acest template este de obicei azure dash și limbajul tău de programare preferat, cum ar fi azure dash typescript sau azure dash python. Când rulezi asta, interfața devine interactivă. Te ghidează printr-o serie de prompt-uri ca să îți configurezi mediul. Mai întâi, îți cere un nume de proiect, care implicit este numele directorului tău. Apoi, îți cere o descriere a proiectului. După aceea, îți cere un nume de stack. Un stack este o instanță izolată a proiectului tău, reprezentând de obicei un mediu precum development sau production. Stack-ul implicit se numește dev. În cele din urmă, template-urile Azure îți cer printr-un prompt o locație Azure, cum ar fi WestUS, care va fi salvată ca regiunea ta implicită de deploy. După ce răspunzi la prompt-uri, tool-ul descarcă template-ul, instalează dependențele de limbaj necesare și creează câteva fișiere în directorul tău. Aici e partea esențială. Cel mai important fișier generat este Pulumi dot yaml. Acesta este fișierul principal al proiectului tău. Definește numele proiectului, runtime-ul pe care îl folosește și descrierea. Practic, îi spune sistemului cum să îți execute codul. Vei vedea de asemenea un fișier numit Pulumi dot dev dot yaml dacă ai acceptat numele implicit al stack-ului. Acest fișier secundar stochează valorile de configurare specifice acelui stack, inclusiv regiunea Azure pe care tocmai ai selectat-o. Pe lângă acestea, primești fișierele standard de dependențe, care variază în funcție de limbajul ales, și fișierul tău de entrypoint. În interiorul fișierului de entrypoint, template-ul Azure implicit oferă un exemplu funcțional de Azure Storage Account. Logica codului se desfășoară în trei pași clari. În primul rând, importă pachetul Azure Native. În al doilea rând, declară un nou Azure Resource Group, dându-i un nume logic pe care fișierul de state să îl urmărească. În al treilea rând, declară un Azure Storage Account. Aici devine interesant. În loc să facă hardcode la numele resource group-ului, storage account-ul preia proprietatea name direct din obiectul resource group creat în pasul anterior. Asta creează o dependență implicită. Sistemul știe acum că trebuie să termine crearea resource group-ului înainte să încerce să creeze storage account-ul. Template-ul completează automat și argumentele necesare pentru storage account, cum ar fi account replication type și account tier. Chiar la finalul fișierului, codul exportă o valoare. În acest exemplu generat prin scaffold, exportă primary storage key-ul storage account-ului nou definit. Când vei da deploy în cele din urmă, această valoare exportată va fi printată direct în consola ta, făcând ușoară recuperarea de connection strings sau endpoint-uri fără să te loghezi în portalul Azure. Treci de la un folder gol la un program de infrastructură complet configurat pur și simplu răspunzând la câteva prompt-uri, oferindu-ți o bază solidă, corectă sintactic, ca să începi să îți construiești propria arhitectură. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodul 4 din 10. Scriptul tău de deploy rulează perfect pe laptop. Faci push la cod, pipeline-ul automat se declanșează, iar build-ul eșuează imediat, pentru că nu găsește un fișier sursă. Nimic din cod nu s-a schimbat, dar directorul în care a fost executată comanda s-a schimbat puțin. Aceasta este o capcană clasică de pathing, iar evitarea ei necesită să înțelegi Proiecte și Path-uri: Structurarea Codului Tău. În esență, un proiect Pulumi este pur și simplu un folder care conține un fișier numit Pulumi.yaml. Acest fișier este ancora. El îi spune command line interface-ului că acest director specific conține logica infrastructurii tale. În interiorul fișierului Pulumi.yaml, declari metadate precum numele proiectului, o descriere și limbajul de runtime. Proprietatea runtime este cea care decide modul în care se execută efectiv codul tău. Dacă specifici Python, runtime-ul caută un fișier Python principal în acel director. Dacă specifici Node, caută entrypoint-ul definit în fișierul tău package, care este de obicei un fișier index. Dacă preferi să îți păstrezi codul sursă într-un subfolder, în loc de directorul principal al proiectului, poți face override în mod explicit la acest comportament setând proprietatea main din fișierul Pulumi.yaml să pointeze către acel subfolder specific. Acum, să analizăm confuzia frecventă legată de path-urile fișierelor. Să presupunem că faci build la o imagine de container Docker ca parte a infrastructurii tale, iar Dockerfile-ul tău se află într-un subdirector numit app, situat chiar lângă codul tău Pulumi. Inginerii pasează adesea un path absolut de pe mașina lor locală pentru a-i spune lui Pulumi unde se află Dockerfile-ul. Dar un path absolut include directorul tău personal de user. Când un coleg de echipă face pull la cod și rulează un update, engine-ul vede un path absolut diferit pe mașina sa. Înregistrează acest lucru ca o modificare structurală a resursei, creând un drift inutil în state-ul infrastructurii tale. Pentru a remedia asta, poți trece la un path relativ standard, cum ar fi dot slash app. Path-urile relative standard se bazează în întregime pe current working directory-ul terminalului care execută codul. Dacă sistemul tău de continuous integration rulează comanda dintr-un director mai sus în repository, path-ul relativ se rezolvă incorect, iar deploy-ul crapă. Iată ideea cheie. Ai nevoie de path-uri care sunt complet independente de mașina pe care rulează și independente de locul în care userul a tastat comanda de execuție. Ai nevoie de path-uri relative la proiect. Pulumi oferă o funcție built-in pentru a obține locația exactă a fișierului Pulumi.yaml în timpul execuției. În funcție de limbajul tău de programare, această funcție se numește de obicei get root directory sau ceva similar. Când apelezi această funcție, runtime-ul returnează path-ul absolut către folderul care conține fișierul tău Pulumi.yaml. În loc să hardcodezi un path către Dockerfile-ul tău, construiești path-ul dinamic. Iei rezultatul funcției root directory și îi adaugi subdirectorul tău app. Deoarece această funcție se evaluează dinamic la fiecare execuție, path-ul rezultat este întotdeauna perfect adaptat la environment-ul care rulează codul. Mașina ta locală, laptopul colegului tău de echipă și serverul de build remote vor genera toate path-ul absolut corect pentru sistemele lor specifice de fișiere. Path-ul fișierului se rezolvă consistent de fiecare dată, iar engine-ul detectează zero modificări la definiția resursei. Codului tău de infrastructură nu ar trebui să îi pese niciodată unde trăiește pe un hard disk. Ancorează-ți întotdeauna asset-urile de tip fișier la funcția Pulumi root directory, asigurându-te că proiectul tău rămâne complet portabil în orice environment. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodul 5 din 10. Să dai copy-paste la codul tău de infrastructură pentru a crea un mediu de staging este o rețetă pentru drift și dezastru. Ajungi să menții mai multe foldere cu fișiere aproape identice și, în cele din urmă, cineva uită să facă update în producție. Soluția este să tratezi mediile tale ca instanțe izolate ale unui singur codebase, folosind Stacks. Înainte să mergem mai departe, hai să clarificăm o confuzie frecventă. Un Project în Pulumi este pur și simplu un director care conține codul tău sursă. Reprezintă doar instrucțiunile. Un Stack este o instanță activă de deploy a acelui cod. Scrii acel Project o singură dată și îi faci deploy de mai multe ori sub formă de Stacks diferite. Aceste Stacks îți permit să gestionezi diferite medii, cum ar fi development, staging și producție, fără să duplici deloc cod. Când rulezi un update în Pulumi, acesta aplică codul din acel Project pe orice Stack este activ în acel moment. Fiecare Stack își menține propriul state file izolat, urmărind doar resursele create pentru acel mediu specific. Gestionarea acestor medii se face direct în terminalul tău. Creezi un mediu nou rulând comanda stack initialize, dându-i un nume precum dev sau prod. Pulumi înregistrează această nouă instanță și creează un state nou pentru ea. Pentru a schimba contextul, folosești comanda stack select. Pulumi CLI ține minte care Stack este activ. Dacă selectezi acel Stack de dev și rulezi un update, Pulumi se uită doar la acel state de development. Face provision sau modifică infrastructura de development, lăsând mediile de staging și producție complet neatinse. Asta acoperă partea de deploy pentru medii izolate. Dar ce se întâmplă când aceste medii trebuie să comunice? Uneori, un Stack se bazează pe informații generate de altul. S-ar putea să ai un Project care gestionează infrastructura de bază și un Project complet separat care se ocupă de codul aplicației. Să zicem că ai un Project de infrastructură care face provision la un cluster Kubernetes. Îi faci deploy sub forma unui Stack numit base-infra-prod. În timpul procesului de deploy, clusterul generează un connection string dinamic. Acum, ai un al doilea Project pentru un microservice care trebuie să facă deploy exact în acel cluster. Nu vrei să dai hardcode la acel connection string și nu vrei să îmbini ambele Projects într-un singur state file masiv și greoi. Aici devine interesant. Poți conecta în siguranță aceste deployment-uri folosind un Stack Reference. Un Stack Reference permite unui Stack să citească acele outputs exportate de un alt Stack. Pentru a seta asta, programul tău de cluster Kubernetes trebuie să exporte explicit acel connection string la finalul execuției sale. Un export este doar o variabilă pe care Pulumi o salvează în acel stack state special pentru a putea fi citită din exterior. Apoi, în programul tău de microservice, creezi un obiect Stack Reference. Îi pasezi numele acelui Stack de infrastructură din care vrei să citești. Mai departe, apelezi o metodă get output pe acea referință, cerând acel connection string după numele său exportat. Acel microservice al tău poate folosi acum acea valoare pentru a-și configura procesul de deploy. Acel Stack de microservice nu poate modifica acel Stack de cluster. Poate citi doar valorile specifice pe care acel Stack de cluster a ales să le exporte. Asta impune o graniță clară. Poți să faci update și să scalezi infrastructura de rețea de bază complet independent de acele workloads ale aplicației, pasând în același timp în siguranță detaliile necesare de conexiune. Prin decuplarea codului tău de instanța de mediu, garantezi că fiecare nivel al sistemului tău trece prin exact aceeași logică, eliminând riscurile ascunse ale duplicării manuale. 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. Pulumi: Infrastructure as Code, episodul 6 din 10. Faci deploy la codul de infrastructură, sintaxa este impecabilă, și pică imediat pentru că un nume de storage bucket este deja luat. Sau, mai rău, actualizezi o instanță de bază de date, iar tool-ul tău o șterge pe cea veche înainte să o creeze pe cea nouă, provocând un outage major. Poți rezolva ambele probleme înțelegând cum gestionează identitatea tool-ul tău de infrastructură. Exact asta acoperim astăzi: Elementele de bază: Resursele Pulumi. În Pulumi, o resursă este un obiect care reprezintă o bucată de infrastructură. Există două tipuri principale cu care vei lucra. Primul este un Custom Resource. Acesta se mapează direct pe un obiect fizic gestionat de un cloud provider. Când declari un Custom Resource, Pulumi face un API call către Amazon, Azure sau Google Cloud pentru a crea exact acel obiect, cum ar fi un virtual machine sau un load balancer. Al doilea tip este un Component Resource. Un Component Resource nu se mapează pe o singură bucată de infrastructură cloud. În schimb, este un container logic pentru alte resurse. Folosești Component Resources pentru a construi abstracții de nivel mai înalt. De exemplu, ai putea crea un singur Component Resource numit Secure Web Server, care provisionează intern un virtual machine, un security group și o adresă IP. Component Resource-ul în sine doar le grupează în state file-ul tău, făcând codul mai curat și mai ușor de gestionat. Indiferent dacă definești un Custom Resource sau un Component Resource, absolut fiecare necesită un nume. Asta aduce în discuție o sursă comună de frustrare. Oamenii scriu un nume în codul lor, îi fac deploy, și apoi își verifică cloud console-ul doar ca să descopere că resursa lor are un string random de caractere atașat la finalul numelui. Asta nu este un bug. Este un feature de bază al modului în care funcționează Pulumi, și trebuie să înțelegi diferența dintre un nume logic și un nume fizic. Numele logic este numele pe care îl scrii în cod ca argument. Pulumi folosește acest nume logic pentru a urmări resursa în state file-ul său. Așa știe Pulumi că baza de date din codul tău de azi este exact aceeași bază de date căreia i-ai făcut deploy ieri. Numele fizic este cum numește de fapt cloud provider-ul resursa în propriul său sistem. By default, Pulumi ia numele tău logic, adaugă un sufix random, și folosește acel string combinat ca nume fizic. Asta se numește auto-naming. Iată ideea cheie. Auto-naming-ul previne naming collisions la nivel global și permite zero-downtime replacements. Gândește-te la provisionarea mai multor storage buckets identice într-un loop folosind Azure. Azure cere ca numele de storage account să fie unice la nivel global printre toți clienții. Dacă încerci să forțezi un nume fizic strict, al doilea bucket din loop-ul tău va da fail pentru că numele este luat, sau mai rău, altcineva din lume ar putea deja să îl dețină. Cu auto-naming, poți folosi pur și simplu un nume logic precum archive-bucket în interiorul loop-ului tău. Pulumi va urmări fiecare iterație logic, asigurându-se în același timp că fiecare bucket primește un nume fizic unic din punct de vedere matematic în Azure. Auto-naming-ul îți protejează de asemenea uptime-ul sistemului. Dacă faci o modificare care forțează înlocuirea unei resurse, Pulumi creează mai întâi noua resursă, verifică dacă funcționează, și abia apoi o șterge pe cea veche. Dacă faci override la auto-naming și forțezi un nume fizic strict, cloud provider-ul nu va lăsa două resurse să împartă același nume în același timp. Pulumi ar fi forțat să șteargă mai întâi resursa veche, cauzând downtime în timp ce cea nouă se provisionează. Dacă vrei să ajuți la continuarea emisiunii, poți căuta DevStoriesEU pe Patreon. Păstrează-ți numele fizice flexibile. Lasă tool-ul să gestioneze sufixele random, pentru că, în timp ce state file-ul tău necesită un nume logic pentru a menține ordinea, mediul de producție se bazează pe flexibilitatea fizică pentru a rămâne online. Mulțumesc pentru audiție. Aveți grijă de voi, tuturor.

Salut, sunt Alex de la DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodul 7 din 10. Să faci hardcoding la parola bazei de date în codul de infrastructură este un eșec de securitate garantat. Dar injectarea manuală a environment variables în fiecare deployment pipeline este fragilă și greu de urmărit. Ai nevoie de o modalitate prin care să legi automat valori specifice, criptate, de medii specifice. Acesta este Keeping Secrets: Configuration Management. Ideea de bază aici este separarea codului tău de configurație. Vrei să scrii logica de infrastructură exact o singură dată. Apoi, când faci deploy pe stack-ul de development, codul face provision la instanțe mici. Când faci deploy în producție, face provision la instanțe mari și folosește acele credentials ale bazei de date de producție. Pulumi gestionează asta printr-un sistem de configurare built-in. Un punct comun de confuzie este modul în care aceste valori sunt stocate de fapt. Setarea unei valori de configurare Pulumi nu setează environment variables pe sistemul de operare local. În schimb, stochează valorile direct într-un fișier numit Pulumi punct stack-name punct yaml. Pentru că fiecare stack primește propriul fișier de configurare distinct, configurația ta de dev și configurația de prod stau una lângă alta în repository-ul tău, separate clar prin numele fișierului. Adaugi date în acest fișier folosind command line interface-ul Pulumi. Dacă rulezi comanda pulumi config set frontendPort 8080, Pulumi scrie acel key-value pair direct în fișierul yaml pentru stack-ul tău activ în prezent. Ca să folosești acea valoare în codul tău de infrastructură, instanțiezi un obiect Config. Apoi, apelezi o metodă precum get sau require pe acel obiect, pasând numele cheii. Diferența este simplă. Apelarea metodei get returnează valoarea dacă există, sau nimic dacă nu există. Apelarea metodei require va arunca o eroare și va opri deployment-ul dacă lipsește cheia de configurare. Asta e o modalitate excelentă să te asiguri că un deployment nu continuă niciodată fără o setare obligatorie. Nu ești limitat la simple string-uri. Poți stoca și recupera date structurate, cum ar fi un bloc JSON care definește parametrii de scalare, și să îi faci parse direct într-un obiect din codul tău. Acum, ce se întâmplă când acea valoare de configurare este foarte sensibilă? Să presupunem că aplicația ta trebuie să se conecteze la o bază de date externă și trebuie să pasezi parola bazei de date către infrastructura ta. Sub nicio formă nu poți stoca asta în plaintext în fișierul tău yaml, pentru că acel fișier primește commit în version control. Aici intervin secretele Pulumi. Folosești exact același command line interface, dar adaugi un flag de secret. Rulezi pulumi config set dbPassword your-password dash dash secret. Pulumi criptează valoarea înainte să o salveze în fișierul yaml. Dacă cineva se uită la fișierul din repository-ul tău, va vedea doar un string ciphertext criptat în siguranță de encryption provider-ul stack-ului tău. În codul tău, recuperezi asta în siguranță apelând o metodă secretă specifică pe obiectul tău Config, cum ar fi requireSecret. Iată ideea principală. Când recuperezi un secret în acest fel, Pulumi îi face wrap într-un tip special de secret. Pe măsură ce această valoare circulă prin codul tău de infrastructură și este pasată către resurse, engine-ul Pulumi o urmărește. Se asigură că valoarea plaintext este mascată în output-ul consolei tale în timpul unui deployment și garantează că valoarea rămâne criptată în state file-ul tău Pulumi. Configurarea îți permite să scrii cod de infrastructură o singură dată și să îi faci promote în siguranță în diferite medii. Criptarea nativă a secretelor se asigură că acele credentials sensibile conduc acele deployment-uri fără să ajungă vreodată în version control sau în state files. Îți mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodul 8 din 10. Dai copy și paste la un bloc de cod de storage și networking pentru a cincea oară săptămâna asta. Codul tău de infrastructură crește, dar nu devine mai inteligent. În loc să repeți configurații cloud identice de fiecare dată când ai nevoie de un setup standard, le poți genera cu o singură unitate logică. Acesta este focusul acestui episod: Scaling Up: Component Resources pe Azure. Când începi să folosești Pulumi, declari resurse raw. Un resource group aici, un storage account acolo. Dar pe măsură ce sistemul tău crește, să faci deploy la o bucată standard de arhitectură necesită provizionarea aceluiași set exact de primitive iar și iar. Acest lucru încalcă regula de a nu te repeta. Component Resources rezolvă asta permițându-ți să încapsulezi mai multe resurse cloud fizice într-o singură abstracție reutilizabilă. Gândește-te la un component resource ca la o clasă custom pe care o definești în limbajul tău de programare ales. Odată definită, o instanțiezi exact ca pe o resursă Pulumi built-in. Ia în considerare un scenariu în care faci deploy frecvent la static websites pe Azure. Un setup minim necesită un Azure Resource Group, un Storage Account configurat pentru static website hosting și un obiect Blob care servește drept document de index. În loc să scrii aceste trei definiții în programul tău main de fiecare dată, creezi un component Azure pentru static websites. Pentru a construi asta, definești o nouă clasă care moștenește de la base class-ul Pulumi ComponentResource. Constructorul clasei tale primește un nume, un set de argumente pentru customizare și resource options standard. Primul lucru pe care îl face constructorul tău este să apeleze constructorul base class-ului. Îi oferi un type token unic, cum ar fi custom două puncte infrastructure două puncte static website, împreună cu numele. Acest type token îi spune engine-ului cum să urmărească noua ta abstracție în state file. Apoi, definești primitivele Azure reale în interiorul constructorului tău. Declari resource group-ul. Declari storage account-ul în interiorul acelui grup. Faci upload la index blob în acel account. Iată ideea cheie. Când creezi aceste resurse interne, trebuie să îi spui explicit engine-ului că ele aparțin noului tău component. Faci asta pasând instanța componentului în resource options, sub proprietatea parent. Mulți ingineri uită acest pas. Dacă omiți opțiunea parent, child resources vor fi provizionate cu succes, dar vor fi tratate ca top-level resources. Output-ul tău din command line va fi o listă plată și confuză. Setând proprietatea parent la instanța componentului tău, engine-ul organizează state tree-ul. Când rulezi un update, interfața va face nest vizual la resource group, storage account și blob direct sub componentul tău custom de website. Asta îți menține state-ul ușor de gestionat și output-ul lizibil. În cele din urmă, programul tău main trebuie probabil să cunoască adresa web a site-ului nou creat. În interiorul componentului tău, după definirea storage account-ului, mapezi primary web endpoint-ul său la o proprietate publică din clasa ta. Apoi, apelezi o metodă numită register outputs. Asta finalizează inițializarea și se asigură că adresa finală este expusă restului programului tău și printată în consolă atunci când deploy-ul se termină. În fișierul tău main, nu mai vezi boilerplate-ul. Pur și simplu instanțiezi componentul de website, îi pasezi un fișier de index și faci deploy. Resursele din spate sunt gestionate în siguranță în spatele abstracției. Adevărata putere din Infrastructure as Code este tratarea arhitecturii cloud ca pe un software, iar Component Resources reprezintă modul prin care construiești o librărie standard și de încredere pentru echipa ta. Asta e tot pentru acest episod. Mersi că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodul 9 din 10. Nu trebuie să arunci ani de cod existent pentru a începe să folosești un nou tool de infrastructură astăzi. Rescrierea masivă a sistemului, de care se teme toată lumea, este un risc uriaș și, din fericire, este complet opțională. Strategia care face acest lucru posibil se numește Coexistență Pașnică: Citirea Terraform State-ului. O concepție greșită des întâlnită este că trecerea la Pulumi înseamnă că trebuie să migrezi toată infrastructura existentă dintr-o dată. Asta este incorect. Pulumi poate citi nativ și poate depinde de resursele care sunt gestionate activ de Terraform. Poți adopta tool-uri noi incremental, în paralel cu pipeline-urile de deployment existente. Ia în considerare un mediu enterprise tipic. Compania ta are un AWS Virtual Private Cloud de bază, gestionat de o echipă centrală de rețea folosind Terraform. Ești un developer care construiește o aplicație nouă și vrei să folosești Pulumi pentru a face deploy la task-uri Elastic Container Service. Containerele tale trebuie să ruleze exact în acel VPC. Nu vrei să rescrii codul VPC-ului în Pulumi și cu siguranță nu vrei să preiei gestionarea rețelei subiacente. Pentru a gestiona asta, folosești provider-ul Pulumi Terraform. Acest provider include o componentă specifică, concepută pentru a citi state file-urile, numită remote state reference. Procesul se bazează pe modul în care Terraform își stochează datele de execuție. În primul rând, codul Terraform care gestionează rețeaua trebuie să expună explicit datele de care are nevoie noua ta aplicație. Face asta folosind blocuri standard de output Terraform. Echipa de rețea își configurează codul pentru a da ca output ID-ul VPC-ului și o listă de ID-uri de subnet-uri private. Când Terraform își aplică configurația, acele output-uri sunt scrise în Terraform state file, care este de obicei stocat remote într-un backend, cum ar fi un AWS S3 bucket sau Terraform Cloud. Apoi, treci la programul tău Pulumi. Scrii cod pentru a instanția acel remote state reference. Oferi acestui obiect exact aceleași detalii de configurare a backend-ului pe care Terraform le folosește pentru a-și găsi state file-ul. Asta include tipul de backend, locația de stocare, regiunea și cheia specifică a state file-ului. Când execuți deployment-ul Pulumi, engine-ul accesează acel remote backend, deschide Terraform state file-ul și parsează output-urile disponibile. Iată ideea cheie. Pulumi tratează Terraform state-ul ca fiind strict read-only. Nu modifică niciodată Terraform state file-ul și nu își asumă ownership-ul asupra resurselor de rețea. Pur și simplu interoghează valorile curente, cunoscute, ale infrastructurii. Odată ce Pulumi preia ID-urile de VPC și subnet din state, tratezi aceste valori ca pe orice altă variabilă din codul tău. Le pasezi direct în logica de deployment pentru noul tău cluster de containere. Pulumi provizionează noile tale containere fără probleme în rețeaua existentă. Această arhitectură păstrează responsabilitățile complet separate. Echipa centrală continuă să gestioneze lifecycle-ul rețelei folosind Terraform. Dacă actualizează un route table sau adaugă un tag, folosesc workflow-ul lor standard. Dacă modifică un output, cum ar fi crearea unui nou subnet, Pulumi va citi automat state file-ul actualizat în timpul următorului update și va ajusta deployment-ul containerului în consecință. Folosirea de remote state references creează o graniță de dependență curată, unidirecțională, permițându-ți să construiești cu încredere sisteme noi cu capabilități moderne, bazându-te în același timp pe o fundație stabilă gestionată de legacy code. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Pulumi: Infrastructure as Code, episodul 10 din 10. Testarea logicii complexe de infrastructură este recunoscută ca fiind dificilă. Scrii mii de linii de configurare, dar să verifici dacă o combinație specifică de reguli de firewall se comportă exact cum ai intenționat înainte de deploy, pare adesea un joc de ghicit. Marea Migrare: Conversia HCL la Pulumi este modul prin care poți rezolva asta. Trecerea de la Terraform la Pulumi nu este un simplu find-and-replace sintactic. Nu este vorba doar de schimbarea acoladelor în paranteze. Este vorba despre a lua o configurare statică și a o transforma într-un program executabil, oferindu-ți acces imediat la loops native, funcții și framework-uri de testare standard. Gândește-te la o configurare de security group în Terraform extrem de complexă și repetitivă. Probabil ai zeci de port ranges care se suprapun, allowlists de IP-uri specifice și definiții greoaie de block-uri. În HCL, gestionarea acestor lucruri necesită structuri rigide, iar validarea logicii necesită rularea unui plan pe un cloud state live. Tranziția începe cu comanda pulumi convert. Navighezi într-un director care conține fișierele tale Terraform existente și rulezi această comandă, specificând limbajul target, cum ar fi TypeScript sau Python. Tool-ul parsează source code-ul tău HCL, citește variables, resources principale și outputs, și generează un program Pulumi echivalent. Acesta traduce intenția declarativă din HCL în structura imperativă a limbajului de programare pe care l-ai ales. Odată ce acel cod este generat, beneficiile strategice ale migrării devin clare. Acum poți face refactor acelei liste masive de reguli de security group într-un array curat de data objects, sau le poți trage dintr-un fișier de configurare extern. Poți itera prin acel array pentru a genera reguli de firewall în mod dinamic, folosind loops standard din TypeScript sau Python. Iată ideea cheie. Pentru că infrastructura ta este acum scrisă într-un limbaj de uz general, o poți testa exact ca pe codul aplicației. Poți scrie un unit test folosind framework-uri standard precum Jest sau PyTest. Creezi un test case care face mock la runtime-ul Pulumi și dă assert că funcția ta de builder pentru security group nu expune niciodată accidental portul douăzeci și doi către tot internetul. Rulezi aceste teste în milisecunde, complet offline, prinzând erorile logice înainte ca faza de plan a infrastructurii să înceapă măcar. Această schimbare deblochează o integrare profundă a limbajului. Codul tău de infrastructură poate partaja libraries standard, logică de validare și typing definitions direct cu codul aplicației tale. Primești acces la ecosistemele mature ale package managers precum NPM sau pip, permițându-ți să împachetezi și să distribui infrastructure patterns la fel de ușor ca orice altă software library. Comanda de conversie face greul în a-ți traduce state-ul curent, dar adevărata migrare are loc atunci când îți schimbi mentalitatea de la a scrie fișiere statice, la a face engineering pe sisteme testabile. Cel mai mare avantaj al conversiei codului tău este trecerea de la simpla configurare a infrastructurii, la programarea ei pe bune. Te încurajez cu tărie să citești documentația oficială Pulumi, să iei un Terraform module mic și să încerci să rulezi conversia tu însuți pentru a vedea output-ul. Dacă ai idei despre ce subiecte tehnice ar trebui să abordăm în următoarea noastră serie, vizitează devstories dot eu și dă-ne de veste. Asta e tot pentru acest episod. Îți mulțumesc că ai ascultat și continuă să construiești!