Terraform 101 – Začíname

Ak sa pohybujete vo svete systémových administrátorov už nejaký ten čas, určite si za posledných pár rokov počuli slovo Terraform. A možno ste sa zamýšlali nad tým, prečo ho admistrátori používajú, keď máme na svete (scriptovacie) jazyky ako napr. powershell alebo python. V tomto článku priblížim fungovanie Terraformu a sami si urobíte názor na to, prečo sa stal štandardom Infrastructure As Code (IaC).

Čo je to vlastne Terraform?

Terraform je nástroj, ktorý nám umožňuje definovať a spravovať našu IT infraštruktúru pomocou kódu. Namiesto toho, aby sme sa manuálne prihlasovali napr. do vCenter servera a “klikali” virtuálne stroje cez wizard, napíšeme konfiguračný súbor. Terraform tento súbor prečíta a automaticky vytvorí, upraví alebo zmaže zdroje tak, aby realita v našom DC zodpovedala našemu kódu.

V čom je teda rozdiel oproti ostatným?

Najväčší rozdiel spočíva v prístupe. Terraform používa deklaratívny jazyk.

  • Imperatívny prístup (napr. PowerCLI skript): Povieme počítaču kroky, ktoré má vykonať (“Vytvor VM, potom pridaj disk, potom pripoj sieť…”).

  • Deklaratívny prístup (Terraform): Povieme počítaču výsledný stav (“Chcem mať VM s 2 CPU a 4GB RAM”). Terraform sám zistí, čo musí spraviť, aby tento stav dosiahol.

No dobre, ale počul som aj o Ansible. V čom sa líšia Terraform a Ansible?

Oba nástroje sú automatizačné, ale každý rieši iný problém.

  1. Terraform (Orchestrácia/Provisioning): Je najlepší na vytváranie infraštruktúry. Použijeme ho na to, aby sme vo vCentri “vyrobili” prázdne VMky, nastavili im CPU, RAM, disky a sieťové karty.

  2. Ansible (Configuration Management): Je najlepší na konfiguráciu softvéru vo vnútri týchto VMiek. Použijeme ho na to, aby sme sa do vytvorenej VM prihlásili, nainštalovali aktualizácie a aplikáciu.

V skratke: V praxi sa často používajú spolu. Terraform vytvorí VM vo vCenter a následne zavolá Ansible, aby ju nakonfiguroval.

Výhody a nevýhody Terraform

Výhody:

  • Unifikovaný workflow: Jedným nástrojom (a rovnakým syntaxom) môžeme spravovať VMware vSphere, NSX, ale aj verejný cloud ako napr. AWS alebo Azure.

  • State Management (Správa stavu): Terraform si pamätá, aké VMky vytvoril. Ak zmeníme v kóde RAM zo 4GB na 8GB, Terraform vie, že nemusí mazať celú VMku, ale stačí ju len prekonfigurovať.

  • Dokumentácia infraštruktúry: Kód sa stáva dokumentáciou. Presne vidíme, ako sú naše servery nastavené, bez toho, aby sme museli otvárať vCenter.

Nevýhody:

  • Spravovanie State súboru: Súbor so stavom infraštruktúry je kritický. Ak sa poškodí, Terraform “stratí prehľad” o našej konfigurácii.

  • On-premises špecifiká: Pri on-premises infraštruktúre musíme riešiť veci, ktoré v cloude neriešime (ako napr. statické IP adresy, dostupnosť konkrétnych hostov, datastores), čo môže písanie kódu trochu zťažiť.

Základná štruktúra

Terraform používa jazyk HCL. Základnou stavebnou jednotkou je Resource (zdroj).

Tu je ukážka kódu, ktorý vytvorí VMku vo našom vCenter:

# 1. Konfiguracia providera (pripojenie na vCenter)
provider "vsphere" {
  user           = "administrator@vsphere.local"
  password       = "SuperTajneHeslo123!"
  vsphere_server = "vcenter.spolocnost.sk"
  
  # Vypnutie overovanie SSL certifikátu
  allow_unverified_ssl = true
}

# 2. Vytvorenie VMky
resource "vsphere_virtual_machine" "moj_server" {
  name             = "tf-test-vm"
  resource_pool_id = "resgroup-123"  # ID resource poolu v clustri
  datastore_id     = "datastore-123" # ID datastore

  num_cpus = 2
  memory   = 4096             # RAM v MB
  guest_id = "ubuntu64Guest"  # Typ Guest OS

  # Konfiguracia siete
  network_interface {
    network_id = "network-123" # ID portgroupy
  }

  # Konfiguracia disku
  disk {
    label = "disk0"
    size  = 40 # Velkost disku v GB
  }
}

Čo tento kód robí?

  1. Prihlási sa do nášho vCenter servera.

  2. Skontroluje, či už existuje VM s názvom “tf-test-vm”.

  3. Ak nie, vytvorí ju so špecifikovanými parametrami (2 vCPU, 4GB RAM, 40GB Disk).

Poznámka: V reálnom svete by sme IDčka (pre datastore alebo sieť) nepísali “natvrdo” ako v ukážke, ale použili by sme tzv. Data Sources, ktorými si Terraform sám vyhľadá napríklad “Datastore_SSD_01”. To si ale ukážeme v ďalších článkoch priamo na príkladoch.

Organizácia súborov

Organizácia súborov je v Terraforme kľúčová, aby sa v kóde vyznal nielen Terraform, ale aj my a naši kolegovia. Hoci Terraform načíta všetky súbory s koncovkou .tf v adresári naraz (a nie je dôležité, ako sa volajú), existuje zlatý štandard, ktorý dodržiava väčšina Infra/DevOps inžinierov.

Keď začíname s prvým pokusom, možno budeme mať všetok kód v jednom súbore (zvyčajne main.tf). No pri reálnych projektoch sa kód delí do logických celkov. Terraformu na tom nezáleží (spojí si ich dokopy), ale pre nás je to nevyhnutnosť pre udržanie prehľadu.

Tu sú najčastejšie súbory, s ktorými sa v praxi stretneme:

  1. providers.tf – Tento súbor hovorí Terraformu, s kým má komunikovať. Definujeme tu tzv. providerov (napr. VMware vSphere, AWS, Azure) a ich verzie. Je to aj miesto, kde sa nastavuje autentifikácia (prihlasovacie meno, server, certifikáty). “Pripájam sa na vCenter server vcenter.organizacia.sk s užívateľom administrator@vsphere.local”
  2. main.tf – Toto je “srdce” našeho projektu. Tu sa nachádza definícia samotných zdrojov (Resources), ktoré chceme vytvoriť. “Vytvor virtuálny stroj, sieťovú kartu a disk.”
  3. variables.tf – Slúži na definovanie vstupných premenných. Aby bol náš kód znovupoužiteľný, nechceme písať hodnoty “natvrdo” do main.tf. Namiesto toho, aby sme v kóde napísali num_cpus = 2 napíšeme num_cpus = var.cpu_count. V tomto súbore teda definujeme, že premenná cpu_count existuje a aký má dátový typ.
  4. terraform.tfvars – Kým variables.tf hovorí, aké premenné existujú, súbor terraform.tfvars im priraďuje konkrétne hodnoty. 
    • Rozdiel: variables.tf hovorí “Potrebujem vedieť počet CPU”. terraform.tfvars odpovedá “Počet CPU je 4”.
    • Pozor: Tento súbor často obsahuje citlivé údaje, preto sa nezvykne nahrávať do Gitu!
  5. datastources.tf (alebo data.tf) – Veľmi dôležitý súbor pre prácu v existujúcom prostredí. Slúži na “čítanie” informácií o infraštruktúre, ktorú Terraform nevytvoril, ale potrebuje ju použiť.
    • Príklad: Chceme umiestniť VM do siete “VLAN_10”. Túto sieť Terraform nevytvára (už v vCenter je). V datastoruces.tf povieme: “Nájdi mi v dátovom centre sieť s názvom VLAN_10 a zisti jej interné ID”. Toto ID potom použijeme v main.tf.
  6. outputs.tf – Slúži na výpis dôležitých informácií po tom, čo Terraform dobehne.
    • Príklad: Terraform vytvoril 10 serverov. V outputs.tf mu povieme: “Na konci mi vypíš do konzoly IP adresy všetkých nových serverov, aby som ich nemusel hľadať.”

Tento prístup k organizácii súborov, robí náš kód modulárnym, čistým, čitateľným a profesionálnym.

Terraform init, plan a apply

Tieto tri príkazy tvoria základný pracovný cyklus (workflow) v Terraforme. Predstavujú postupnosť krokov, ktoré musíme vykonať, aby si bezpečne vytvorili alebo zmenili infraštruktúru.

  1. terraform initToto je prvý príkaz, ktorý musíme spustiť v novom projekte (adresári). Pripravuje náš pracovný adresár na použitie Terraformu.

    Čo sa udeje?

    • Sťahovanie providerov: Terraform prečíta kód, zistí, ktoré služby chceme používať (napr. AWS, Azure, Google Cloud, VMware vSphere, Cloud Provider, …), a stiahne potrebné plugins pre komunikáciu s týmito službami.
    • Nastavenie backendu: Nakonfiguruje miesto, kde sa bude ukladať “stav” (state file) – či už lokálne na disku alebo vzdialene (napr. v S3 buckete).
    • Inštalácia modulov: Ak náš kód odkazuje na iné moduly (znovupoužiteľné kusy kódu), stiahnu sa.
  2. terraform planTento príkaz slúži na kontrolu a náhľad zmien. Je to kľúčový krok pre bezpečnosť, pretože nám ukáže, čo presne sa stane, skôr než sa čokoľvek reálne zmení.

    Čo sa udeje?

    • Porovnanie: Terraform porovná náš lokálny kód (požadovaný stav) s aktuálnym reálnym stavom v prostredí (uloženým v state file).
    • Identifikácia rozdielu (Diff): Identifikuje, aké kroky sú potrebné na to, aby realita zodpovedala našemu kódu.
    • Výstup: Vypíše zoznam zmien s farebným označením:
      • (zelená): Niečo sa vytvorí.
      • (červená): Niečo sa vymaže (!).
      • (žltá): Niečo sa zmení (napr. zmena veľkosti RAM pri VMke).
  3. terraform applyTento príkaz vykonáva zmeny. Až v tomto momente Terraform reálne komunikuje s API providera a vytvára, mení alebo maže zdroje.

    Čo sa udeje?

    • Potvrdenie: Zvyčajne sa znova ukáže plán a vyzve nás, aby sme napísal yes na potvrdenie
    • Exekúcia: Vykoná kroky z plánu v správnom poradí (rieši závislosti – napr. najprv vytvorí sieť, až potom server v nej). Áno, je možné aj manuálne špecifikovať postupnosť krokov.
    • Aktualizácia stavu: Po úspešnom vykonaní zapíše nový stav infraštruktúry do súboru terraform.tfstate.

Príbeh OpenTofu

Pri čítaní o Terraforme môžete naraziť na názov OpenTofu. O čo ide?

V auguste 2023 spoločnosť HashiCorp (tvorca Terraformu), podobne ako pri Vault, zmenila licenčné podmienky. Prešli z čisto open-source licencie (MPL) na viac obmedzujúcu BUSL (Business Source License). Hoci pre bežného používateľa sa veľa nezmenilo, pre firmy, ktoré na Terraforme stavali svoje komerčné produkty, to bol problém.

Ako reakcia vznikol OpenTofu – (Pri Vaulte – OpenBao)

  • Čo to je? Je to tzv. “fork” Terraformu. Komunita vzala poslednú skutočne open-source verziu Terraformu a začala ju vyvíjať pod krídlami Linux Foundation.

  • Prečo vznikol? Aby zaručil, že nástroj na správu infraštruktúry ostane navždy slobodný, komunitou riadený a skutočne open-source.

  • Rozdiel: V súčasnosti funguje OpenTofu ako “drop-in” náhrada. Väčšina kódu pre Terraform funguje v OpenTofu bez zmeny, len namiesto príkazu terraform apply píšeme tofu apply.

Je len na Vás, či použijete Terraform alebo OpenTofu. Ideálne je, prečítať si licenčné podmienky a uistiť sa, že váš “use case” je licenčne v poriadku.

Záver

Terraform nie je len nástroj pre “veľké cloudy”. Je to silný spojenec aj pre administrátorov VMware, ktorým pomáha automatizovať rutinné vytváranie a konfiguráciu virtuálnych strojov, sietí, datastores, … znižovať chybovosť a v neposlednom rade – šetriť čas.

Author: Martin

Infrastructure engineer | virtualization & cloud enthusiast | vSphere specialist | blogger | Veeam Vanguard 2021,2022,2023 | VMware vExpert 2017 - 2025 | VMCE | VCP-VCF Architect, VCP-DCV, NV, TKO, VCAP-DCV, CompTIA Security+ | Slovak VMUG Leader | Slovak VUG Leader | husband&father