Limitările configurării manuale
Când administrați un server prin conectare SSH directă și rulați comenzi una câte una, fiecare modificare rămâne doar în memoria dumneavoastră sau, în cel mai bun caz, într-un document separat care se învechește rapid. Dacă instalați nginx, editați un fișier de configurare și reporniți serviciul, nimic din acest proces nu este înregistrat automat undeva verificabil. Peste șase luni, când trebuie să reconstruiți același server după o defecțiune de disc, va trebui să vă amintiți exact ce ați făcut sau să căutați prin istoricul shell-ului, dacă mai există.
Această abordare produce ceea ce se numește „configuration drift”, adică diferența care apare treptat între serverele care ar trebui să fie identice. Un server de producție și unul de staging, configurate manual la interval de câteva luni, ajung să difere prin versiuni de pachete, fișiere de configurare uitate sau reguli de firewall aplicate doar pe unul dintre ele. Pe hosting-ul cPanel cu LiteSpeed, de exemplu, o regulă de rescriere adăugată manual într-un vhost și uitată la migrarea pe alt server produce erori 404 greu de depanat luni mai târziu.
Ce înseamnă infrastructura ca și cod
Infrastructura ca și cod (Infrastructure as Code, prescurtat IaC) înseamnă că descrieți starea dorită a serverelor și a resurselor de rețea în fișiere text, pe care le păstrați într-un depozit Git alături de codul aplicației. În loc să rulați comenzi ad-hoc, scrieți un playbook Ansible sau un fișier Terraform care descrie „acest server trebuie să aibă nginx instalat, versiunea 1.24, cu acest fișier de configurare”. Uneltele citesc fișierul, verifică starea curentă a serverului și aplică doar diferențele necesare.
Acest model aduce trei avantaje verificabile. Primul este repetabilitatea: același fișier aplicat pe zece servere produce zece servere identice, ceea ce elimină diferențele accidentale. Al doilea este istoricul: fiecare modificare a infrastructurii trece printr-un commit Git, cu autor, dată și mesaj, exact ca modificările de cod. Al treilea este posibilitatea de a testa modificările înainte de aplicare, prin comenzi precum terraform plan sau ansible-playbook --check, pe care le veți folosi începând cu capitolul al patrulea.
Terraform și Ansible: două etape complementare
De-a lungul acestui curs veți lucra cu două unelte care rezolvă probleme diferite, dar complementare. Terraform, dezvoltat de HashiCorp, provizionează resursele: creează mașini virtuale, discuri, interfețe de rețea sau reguli de firewall la un furnizor cloud sau pe un hypervisor precum Proxmox VE. Ansible, scris în Python, se conectează la mașinile deja create prin SSH și le configurează: instalează pachete, copiază fișiere, pornește servicii. Fluxul obișnuit este simplu, mai întâi Terraform creează serverul, apoi Ansible îl configurează.
Distincția este importantă pentru că multe echipe încearcă inițial să facă totul cu o singură unealtă. Terraform poate rula comenzi shell printr-un provizioner local-exec, dar acest mecanism are limitări serioase pe care le discutăm în capitolul despre integrarea celor două unelte. Ansible, la rândul lui, are module pentru câțiva furnizori cloud, dar nu gestionează starea infrastructurii la fel de riguros ca Terraform, care păstrează un fișier de stare dedicat, discutat pe larg în capitolul al zecelea.
Limitările pe care trebuie să le cunoașteți
Infrastructura ca și cod nu elimină toate problemele. O greșeală într-un playbook se poate propaga instant pe toate serverele la care aveți acces, motiv pentru care veți învăța să testați modificările cu --check --diff înainte de a le aplica în producție. Curba de învățare este reală: sintaxa YAML din Ansible este sensibilă la indentare, iar HCL din Terraform are propriile reguli de tipuri de date. Pentru un singur server administrat ocazional, configurarea manuală rămâne uneori mai rapidă. Beneficiile infrastructurii ca și cod apar clar de la câteva servere în sus.