Infrastructura ca cod: medii de lucru pe care le putem reconstrui

Seria II: De la infrastructură la proiecte agentice în producție. Episodul 05 din 20.

În episodul precedent, am separat identitățile și credențialele portalului B2B fictiv pentru solicitări și documente. Următorul pas este să transformăm deciziile despre rețele, servicii și acces în configurații care pot fi citite, revizuite și refăcute. Decizia principală este ca schimbarea aprobată în cod și planul verificat să devină calea normală spre infrastructură, iar intervențiile manuale să fie excepții documentate și reconciliate.

Ce este infrastructura ca cod

Infrastructure as Code, prescurtat IaC, înseamnă descrierea resurselor de infrastructură în fișiere care pot fi versionate și procesate de un instrument. OpenTofu este un exemplu open source care poate administra resurse cloud și on-premises prin configurații lizibile. Îl folosim aici pentru a explica metoda, nu ca alegere obligatorie pentru orice firmă.

Codul poate descrie rețele, mașini virtuale, reguli, spații de stocare, DNS sau servicii gestionate, în limita furnizorilor disponibili. Nu include automat aplicația, datele clienților, copiile de siguranță ori procedurile de incident. Nici nu transformă o arhitectură slabă într-una sigură. IaC face intenția repetabilă și diferențele vizibile; calitatea rezultatului depinde în continuare de decizii, acces și verificări.

Structura minimă pentru portal

Scenariu ipotetic: portalul are medii de dezvoltare, test și producție. În repository-ul de infrastructură păstrăm module pentru rețea, calcul, stocare și identități tehnice. Fiecare mediu are propriile valori aprobate și propria stare. Refolosirea modulelor reduce diferențele accidentale, dar nu obligă mediile să fie identice. Producția poate avea redundanță și politici mai stricte, iar dezvoltarea poate folosi resurse mai mici și date sintetice.

O structură simplă poate conține:

• modules, pentru componente reutilizabile precum rețeaua și serviciul aplicației;
• environments/dev, test și prod, pentru compoziția și valorile fiecărui mediu;
• verificări automate pentru format, validare și politici;
• documentație despre proprietar, ordine de aplicare, recuperare și excepții.

Secretele nu intră în fișierele versionate. Configurația poate referi identitatea sau locația controlată din care un proces autorizat le obține. Agenții AI care dezvoltă portalul pot propune modificări în această structură. Agentul integrat în portal, care clasifică o solicitare, nu are nevoie să modifice infrastructura.

Fluxul: scriere, plan, revizuire, aplicare

Documentația OpenTofu descrie trei pași de bază: write, plan și apply. Într-o echipă, îi transformăm într-un control operațional.

1. Schimbarea este făcută pe o ramură și explicată într-un pull request.
2. Un mediu controlat validează configurația și generează planul, adică previzualizarea acțiunilor propuse.
3. Revizorul compară intenția cu planul: ce se adaugă, ce se modifică, ce se înlocuiește sau se șterge, dacă există întreruperi și cine este afectat.
4. După aprobare, se generează planul final pentru același commit, folosind starea curentă, apoi se aplică prin identitatea mediului țintă.
5. Echipa verifică serviciul și înregistrează rezultatul. Dacă aplicarea este parțială, nu presupune că revenirea codului anulează toate efectele.

Planul văzut în pull request poate diferi de cel final dacă între timp s-a schimbat infrastructura, ordinea integrărilor sau starea. De aceea, un plan vechi nu se aplică mecanic. Îl regenerăm și revedem când contextul s-a schimbat. Fișierele de plan pot conține valori sensibile, deci nu le publicăm ori atașăm fără control.

Pentru o firmă mică, aprobarea poate aparține unei singure persoane desemnate, dar autorul și aprobatorul ar trebui separați pentru schimbările cu risc ridicat. Nu este necesară o platformă complexă din prima zi. Sunt însă necesare o cale clară de aplicare, un istoric și o regulă pentru urgențe.

Starea nu este un fișier oarecare

State, sau starea infrastructurii, leagă resursele reale de obiectele declarate în configurație. OpenTofu o folosește pentru a decide ce trebuie creat, schimbat sau eliminat. Starea poate conține identificatori și atribute sensibile, inclusiv parole inițiale pentru unele resurse. Marcarea unei valori ca „sensitive” poate ascunde afișarea ei, dar nu garantează eliminarea din state.

Într-o echipă, păstrăm starea într-un backend controlat, cu acces minim, criptare, istoric și copii de siguranță potrivite. Verificăm explicit dacă backend-ul suportă locking, adică blocarea scrierilor concurente. OpenTofu folosește blocarea automat când backend-ul o oferă, dar nu toate o implementează. Forțarea deblocării fără a confirma cine deține operația poate permite două scrieri și poate corupe starea.

OpenTofu poate cripta fișierele de state și plan, însă cheia de criptare devine o dependență critică. Pierderea ei poate face starea nerecuperabilă. Criptarea nu protejează împotriva pierderii fișierului, folosirii unui plan vechi sau unei persoane care rulează instrumentul cu acces legitim. Procedura de recuperare trebuie testată, nu doar scrisă.

Starea IaC nu este backup pentru baza de date și documentele portalului. Ea poate ajuta la reconstruirea resurselor, dar conținutul persistent are nevoie de copii, retenție și restaurare testată separat.

Drift: diferența dintre cod și realitate

Drift este abaterea dintre configurația aprobată și infrastructura existentă, de exemplu după o modificare manuală în consolă. Un plan actualizat poate scoate diferența la vedere, însă remedierea nu trebuie automatizată orbește. Schimbarea poate fi accidentală, o intervenție de urgență încă necesară sau un indiciu că modelul din cod este incomplet.

Regula pentru portal este simplă: identificăm proprietarul, motivul și impactul, apoi alegem explicit dacă revenim la cod sau adoptăm schimbarea în configurație. După o urgență, refacem planul și reconciliem codul înaintea următoarei livrări. Astfel, consola nu devine o a doua sursă de adevăr cunoscută doar de o persoană.

Ce le permitem agenților de dezvoltare

Un agent AI poate pregăti un pull request, explica planul și semnala resurse neobișnuite. Nu primește implicit credențiale de producție și nu aprobă propria schimbare. Rulăm din nou validarea și controalele de securitate după fiecare corecție, nu doar la final. Un studiu publicat la ESEM 2026 a observat regresii de securitate în unele bucle iterative de reparare IaC cu modele lingvistice; rezultatele variază după metoda de detecție, deci nu trebuie generalizate la orice instrument. Concluzia practică este că o reparație funcțională poate modifica și alte proprietăți.

Piesa adăugată proiectului este repository-ul minimal pentru medii și regula: nicio aplicare în producție fără plan final legat de commit, revizuire și identitate autorizată. Rezultatul nu promite infrastructură perfect identică, deoarece imaginile, API-urile furnizorilor și serviciile externe se pot schimba. Pentru o reconstrucție realistă, fixăm versiunile importante, păstrăm artefactele necesare și testăm periodic un mediu nou. În episodul următor vom transforma obiectivele proiectului în sarcini verificabile pentru oameni și agenți AI.

Surse

• OpenTofu, Documentation și Working with OpenTofu, pentru aria instrumentului și fluxul write, plan, apply, documentație consultată la 7 octombrie 2026.
• OpenTofu, Sensitive Data in State și State Locking, pentru protejarea stării și scrierile concurente.
• OpenTofu, State and Plan Encryption, pentru capacități, limite și recuperarea cheilor.
• Agyekum și Santos, Does Fixing Break Security?, ESEM 2026, studiu academic despre regresiile de securitate în repararea iterativă IaC cu modele lingvistice.

Următorul pas

Vrei medii reproductibile și schimbări de infrastructură verificabile? Discută cu i8 despre un flux Infrastructure as Code potrivit echipei tale.