• Infrastructure as Code
  • Terraform
  • CI/CD
  • DevOps
  • GCP
  • Automatizacija
  • AWS

Infrastructure as Code: Terraform Vodič za AWS i GCP — 2026

Infrastructure as Code: Terraform Vodič za AWS i GCP — 2026
DevOps & Cloud

Infrastructure as Code: Terraform Vodič za AWS i GCP

Terraform drži 76% IaC tržišta prema CNCF 2024 anketi — naučite kako deklarativno upravljati infrastrukturom, modulima i CI/CD pipelineima.

Manuelno konfigurisanje servera je prošlost. U 2026. godini, Infrastructure as Code (IaC) nije samo trend — to je industrijski standard. Svaki put kada ručno kliknete kroz AWS konzolu ili SSH-ujete na server da biste promijenili konfiguraciju, stvarate tzv. snowflake server: jedinstvenu, neponovljivu i tešku za upravljanje infrastrukturu. Terraform eliminiše ovaj problem deklarativnim pristupom — vi opisujete željeno stanje, a alat se pobrine za sve ostalo.

Zašto je IaC Neophodni Standard u 2026?

Globalno IaC tržište doživljava eksplozivan rast. Prema istraživanju Precedence Research, tržište je vrijedilo oko 1,06 milijardi USD u 2024. godini i projektovano je da dostigne 9,40 milijardi USD do 2034, uz godišnji rast (CAGR) od 24,39%. Ovaj rast nije slučajan — organizacije koje koriste IaC bilježe konkretne, mjerljive prednosti.

Prema istraživanju SNS Insider, više od 70% enterprise kompanija koje koriste DevOps prakse implementira IaC za automatizaciju infrastrukturnih životnih ciklusa. Pored toga, 74% IT lidera smatra da će IaC biti ključan element njihovih budućih cloud strategija.

76%
tržišni udio (CNCF 2024)

Terraform

De facto standard za multi-cloud IaC, sa ekosistemom od 4.800+ providera i ogromnom zajednicom.

90%
cloud korisnika (State of IaC 2023)

IaC Adopcija

Gotovo svi cloud korisnici već koriste IaC u nekom obliku — pitanje je samo kojim alatom i koliko efikasno.

80%+
enterprise kompanija

CI/CD Integracija

Prema HashiCorp State of Cloud Strategy Survey, više od 80% enterprise organizacija integrira IaC u CI/CD pipeline.

Terraform: Osnove Deklarativnog Pristupa

Terraform je open-source alat koji koristi HashiCorp Configuration Language (HCL) — dizajniran da bude čitljiv i za ljude i za mašine. Za razliku od imperativnih alata (kao što je Ansible, koji opisuje kako nešto uraditi), Terraform je deklarativan: vi opisujete šta želite, a Terraform planira i izvršava promjene da bi postigao to stanje.

Osnova svakog Terraform projekta je jednostavna konfiguracija. Evo primjera kreiranja AWS EC2 instance:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  backend "s3" {
    bucket         = "moja-kompanija-terraform-state"
    key            = "production/main.tfstate"
    region         = "eu-west-1"
    encrypt        = true
    use_lockfile   = true
  }
}

provider "aws" {
  region = var.aws_region
}

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = var.instance_type

  tags = {
    Name        = "web-server-${var.environment}"
    Environment = var.environment
    ManagedBy   = "Terraform"
  }
}

Tri ključne komande čine srž Terraform workflow-a: terraform init inicijalizuje projekat i preuzima providere, terraform plan prikazuje šta će se promijeniti (bez ikakvih izmjena na infrastrukturi), i terraform apply primjenjuje promjene. Ova sekvenca — plan pa apply — je temelj sigurnog IaC rada.

Terraform Moduli: DRY Princip za Infrastrukturu

Moduli su najvažniji koncept u skalabilnom Terraform razvoju. Terraform moduli čine vaš kod DRY (Don't Repeat Yourself) i ubrzavaju deploymente — umjesto da pišete istu konfiguraciju za svaki environment, jednom kreirate modul i reusujete ga svuda.

Preporučena struktura repozitorija za GCP i AWS projekte izgleda ovako:

terraform/
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── README.md
│   ├── eks-cluster/
│   └── rds-postgres/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   └── terraform.tfvars
│   ├── staging/
│   └── prod/
│       ├── main.tf
│       └── terraform.tfvars
└── .terraform.lock.hcl

Primjer pozivanja modula za GCP VPC mrežu koristeći zvanične Google module:

module "vpc" {
  source  = "terraform-google-modules/network/google"
  version = "~> 9.0"

  project_id   = var.project_id
  network_name = "moja-vpc-${var.environment}"

  subnets = [
    {
      subnet_name   = "subnet-app"
      subnet_ip     = "10.0.1.0/24"
      subnet_region = "europe-west1"
    },
    {
      subnet_name   = "subnet-db"
      subnet_ip     = "10.0.2.0/24"
      subnet_region = "europe-west1"
    }
  ]
}

# Pozivanje custom modula za Kubernetes klaster
module "gke_cluster" {
  source = "./modules/gke"

  project_id   = var.project_id
  network_id   = module.vpc.network_id
  environment  = var.environment
  node_count   = var.environment == "prod" ? 3 : 1
}

Ključne Prednosti Terraform Modula

  • Reusabilnost — isti modul za dev, staging i prod environment
  • Konzistentnost — standardizovane konfiguracije kroz cijelu organizaciju
  • Smanjen blast radius — manji moduli znače manji rizik od kaskadnih grešaka
  • Verzionisanje — semantic versioning za pouzdane deploymente
  • Testabilnost — moduli se mogu unit testirati sa Terratest frameworkom
  • Izbjegavajte mega-module — manji moduli smanjuju kompleksnost i blast radius

State Management: Srce Terraform Sigurnosti

Terraform state file je mapa između vaše konfiguracije i stvarnih cloud resursa. Lokalno čuvanje state fajla je prihvatljivo za solo eksperimentisanje, ali u timskom okruženju je neprihvatljivo. Remote state backend je obavezan za produkciju.

Terraform koristi state locking i remote backende kako bi spriječio istovremene modifikacije. Kada više članova tima pokuša istovremeno da mijenja infrastrukturu, state lock osigurava da samo jedna operacija može biti u toku.

Konfiguracija Remote State za AWS (S3 + DynamoDB locking):
terraform {
  backend "s3" {
    bucket         = "moja-kompanija-terraform-states"
    key            = "production/vpc/terraform.tfstate"
    region         = "eu-west-1"
    encrypt        = true
    use_lockfile   = true  # Native S3 locking (Terraform 1.10+)
  }
}

# Kreiranje S3 bucketa sa verzionisanjem
resource "aws_s3_bucket" "terraform_state" {
  bucket = "moja-kompanija-terraform-states"
}

resource "aws_s3_bucket_versioning" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
  versioning_configuration {
    status = "Enabled"
  }
}
Konfiguracija Remote State za GCP (Cloud Storage):
terraform {
  backend "gcs" {
    bucket  = "moja-kompanija-terraform-state"
    prefix  = "production/main"
  }
}

# GCS bucket sa versioning-om
resource "google_storage_bucket" "terraform_state" {
  name          = "moja-kompanija-terraform-state"
  location      = "EU"
  force_destroy = false

  versioning {
    enabled = true
  }

  uniform_bucket_level_access = true
}
!

Jeste li znali?

Prema istraživanju Firefly AI State of IaC 2025, manje od jedne trećine organizacija kontinuirano prati drift u infrastrukturi — ostatak je reaktivan i rješava probleme tek kada nastanu. Pored toga, samo 6% anketiranih timova postiglo je potpunu kodifikaciju cloud infrastrukture, što pokazuje koliko je prostora za napredak još uvijek dostupno.

Usporedba Glavnih IaC Alata u 2026.

Alat Pristup Jezik Multi-cloud Tržišni udio Idealno za
Terraform / OpenTofu Deklarativni HCL ✓ 4.800+ providera 76% (CNCF 2024) Multi-cloud provisioning, enterprise timovi
Pulumi Deklarativni Python, TS, Go, C# ✓ 1.800+ providera Raste 45% godišnje Developer-first timovi, složena logika
Ansible Imperativni YAML ~ Djelimično Visok Konfiguracija servera, agentless deplojment
AWS CloudFormation Deklarativni JSON / YAML ✗ Samo AWS AWS-specifičan AWS-only timovi, native integracija
OpenTofu Deklarativni HCL (Terraform-kompatibilan) ✓ Isti kao Terraform ~20% novih projekata 2025. Open-source alternativa, bez vendor lock-in

CI/CD Integracija: Automatizacija Terraform Workflow-a

Manuelno pokretanje Terraform komandi je sporo i stvara uska grla. Prema HashiCorp istraživanju, organizacije koje koriste automatizovane Terraform workflow-e deployuju infrastrukturne promjene 89% brže od onih koje se oslanjaju na manuelne procese. CI/CD integracija je stoga ključna za svaki ozbiljan tim.

Postoje dvije dominantne platforme za Terraform CI/CD: GitHub Actions i GitLab CI/CD. GitHub Actions zahtijeva external state storage, dok GitLab CI/CD ima ugrađen HTTP Terraform state backend koji čuva state fajlove direktno unutar GitLab projekta.

GitHub Actions Terraform Pipeline (AWS sa OIDC autentifikacijom):
# .github/workflows/terraform.yml
name: 'Terraform CI/CD'

on:
  pull_request:
    branches: [ main ]
  push:
    branches: [ main ]

jobs:
  terraform:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      id-token: write  # Potrebno za OIDC

    steps:
      - uses: actions/checkout@v4

      # OIDC autentifikacija — bez dugovječnih kredencijala!
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: eu-west-1

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      - name: Terraform Init
        run: terraform init

      - name: Terraform Format Check
        run: terraform fmt -check -recursive

      - name: Terraform Validate
        run: terraform validate

      - name: Terraform Plan
        run: terraform plan -out=tfplan

      # Apply samo na main branchu, manuelno odobrenje
      - name: Terraform Apply
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
        run: terraform apply -auto-approve tfplan
GitLab CI/CD Pipeline sa ugrađenim state managementom:
# .gitlab-ci.yml
image: hashicorp/terraform:1.10

variables:
  TF_ROOT: ${CI_PROJECT_DIR}/terraform
  TF_STATE_NAME: production
  # GitLab ugrađeni HTTP backend za state
  TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/${TF_STATE_NAME}

stages:
  - validate
  - plan
  - apply

before_script:
  - cd ${TF_ROOT}
  - terraform init

validate:
  stage: validate
  script:
    - terraform fmt -check
    - terraform validate

plan:
  stage: plan
  script:
    - terraform plan -out=plan.tfplan
  artifacts:
    paths:
      - ${TF_ROOT}/plan.tfplan
    expire_in: 1 week

apply:
  stage: apply
  script:
    - terraform apply -auto-approve plan.tfplan
  dependencies:
    - plan
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual  # Manuelno odobrenje za produkciju

Ključni Principi Terraform CI/CD Pipeline-a

  • Razdvajanje plan i apply faza — uvijek pregledajte plan prije primjene
  • OIDC autentifikacija — eliminišite dugovječne AWS/GCP kredencijale iz pipeline-a
  • State locking — spriječite istovremene modifikacije infrastrukture
  • Statički skeneri — integrirajte tfsec, checkov ili KICS za sigurnosne provjere
  • Manuelno odobrenje za produkciju — nikad ne auto-applyjte na prod bez pregleda
  • Nikad ne hardkodujte tajne — koristite AWS Secrets Manager, GCP Secret Manager ili HashiCorp Vault

Sigurnost i IaC: DevSecOps Pristup

Sigurnost u IaC nije opcija — to je obaveza. Istraživanje koje je analiziralo 340 Terraform modula i 1.200 definicija resursa na AWS i Azure okruženjima otkrilo je 290 sigurnosnih miskonfiguracija, od kojih je 94% moglo biti automatski remedijovano statičkim skeniranjem. Ovo pokazuje koliko je važno integrirati sigurnosne alate direktno u pipeline.

Statički Skeneri za Terraform

  • Checkov (Bridgecrew/Palo Alto) — sveobuhvatni statički analizator za IaC konfiguracije
  • tfsec (Aqua Security) — brzi sigurnosni skener specijalizovan za Terraform
  • KICS (Checkmarx) — Keeping Infrastructure as Code Secure, podržava više IaC formata
  • OPA / Sentinel — Policy as Code framework za napredne compliance provjere

Upravljanje Tajnama

  • AWS Secrets Manager — centralizovano upravljanje tajnama za AWS okruženja
  • GCP Secret Manager — nativna GCP solucija za sigurno čuvanje kredencijala
  • HashiCorp Vault — enterprise rješenje za upravljanje tajnama i dinamičkim kredencijalima
  • Ephemeral Resources — nova Terraform funkcionalnost koja ne upisuje privremene kredencijale u state

Terraform u 2026: Ekosistem i Budućnost

U 2025. godini, IBM je preuzeo HashiCorp, kompaniju koja stoji iza Terraform-a. Ova akvizicija, zajedno s promjenom licence na Business Source License (BSL) iz 2023, pokrenula je značajne promjene u ekosistemu. Zajednica je odgovorila kreiranjem OpenTofu — open-source forka Terraform-a pod Linux Foundation okriljem.

Prema dostupnim podacima, OpenTofu je dostigao verziju 1.9.x sa više od 20.000 GitHub zvjezdica i solidnom enterprise adopcijom. Otprilike 20% novih projekata u 2025. godini startovalo je direktno na OpenTofu. Oba alata su production-ready u 2026. — svaki .tf fajl je validan u oba alata, a state format je kompatibilan.

Terraform (HashiCorp/IBM)

  • Najveći ekosistem (4.800+ providera)
  • Enterprise podrška kroz HCP Terraform
  • Ephemeral resources (nova funkcionalnost)
  • Custom provider funkcije u HCL-u
  • BSL licenca — ograničenja za komercijalne konkurente
  • Ukidanje legacy free plana (mart 2026.)

OpenTofu (Linux Foundation)

  • Potpuno open-source (MPL 2.0)
  • 100% kompatibilan sa Terraform .tf fajlovima
  • Podržan od Spacelift, env0, Gruntwork
  • Aktivan razvoj, 20.000+ GitHub zvjezdica
  • Manji enterprise support ekosistem
  • Mlađi projekt — manje community resursa

AI i IaC: Sljedeći Korak Automatizacije

Prema Gartner predviđanjima, do 2026. više od 40% organizacija koristit će AI-augmented IaC alate za dio svog infrastrukturnog workflow-a — što je skok sa manje od 10% u 2023. godini. AI alati poput GitHub Copilot i Cursor već preoblikuju način na koji timovi pišu Terraform kod, ubrzavajući razvoj kroz LLM-powered generaciju koda.

Međutim, AI donosi i rizike: bot za automatsku remedijaciju koji otvori portove da bi riješio health check grešku, ili generisani modul koji zaboravi enkripciju, može tiho proširiti nesigurne defaulte kroz cijeli stack. Automatizacija treba ići ruku pod ruku s policy-as-code guardrailsima.

"

Najskuplji IaC incidenti dijele zajednički obrazac: neko je primijenio promjene bez čitanja plana. Alati u 2026. — Atlantis, Spacelift, ephemeral values, AI-generisani moduli — ne mijenjaju taj constraint. Oni samo čine plan lakšim za generisanje i težim za preskakanje.

— Clanker Cloud Blog, Terraform Latest Trends 2026

Best Practices: Terraform u Produkciji

Na osnovu aktuelnih industrijskih istraživanja i iskustava iz prakse, evo ključnih preporuka za uspješno upravljanje Terraform infrastrukturom:

1. Semantic Versioning Modula

Prema istraživanju iz juna 2025, oko 60% organizacija koje primjenjuju semantic versioning na module bilježi smanjenje deployment grešaka. Uvijek tagujte module (v1.0.0, v1.1.0) i koristite version constraints.

2. Code Review za IaC

Isti izvor bilježi da timovi koji koriste peer review za Terraform kod bilježe 30% poboljšanje kvaliteta koda. Tretirajte infrastrukturni kod jednako kao aplikacijski.

3. Jedan Environment, Jedan State

Koristite jedan GCP projekat po environmentu (my-app-dev, my-app-prod) i odgovarajući state fajl. Ovo izoluje promjene i smanjuje rizik od kaskadnih grešaka.

4. Drift Detection

Redovno pokretajte terraform plan u CI/CD-u da biste rano detektovali drift. Alati poput Spacelift, Atlantis i ControlMonkey nude kontinuiranu drift detekciju.

5. Terraform Lock File

Uvijek commitujte .terraform.lock.hcl u verzionsku kontrolu. Ovo osigurava konzistentne verzije providera na svim developer mašinama i u CI/CD okruženjima.

6. Pre-commit Hookovi

Dodajte pre-commit hookove za terraform fmt i terraform validate koji se pokreću automatski prije svakog commita. Ovo sprječava formatiranje i sintaksne greške da dostignu pipeline.

Praktični Primjer: Kompletan AWS VPC sa Terraform Modulima

Evo realnog primjera kako izgleda modularna Terraform konfiguracija za AWS produkcijsko okruženje:

# environments/prod/main.tf

locals {
  environment = "prod"
  region      = "eu-west-1"
  common_tags = {
    Environment = local.environment
    ManagedBy   = "Terraform"
    Team        = "Platform"
  }
}

# VPC modul
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = "vpc-${local.environment}"
  cidr = "10.0.0.0/16"

  azs             = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = false  # HA u produkciji

  tags = local.common_tags
}

# EKS Kubernetes klaster
module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "eks-${local.environment}"
  cluster_version = "1.30"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  eks_managed_node_groups = {
    general = {
      min_size     = 2
      max_size     = 10
      desired_size = 3
      instance_types = ["m5.large"]
    }
  }

  tags = local.common_tags
}

# RDS PostgreSQL baza podataka
module "rds" {
  source  = "./../../modules/rds-postgres"

  identifier     = "db-${local.environment}"
  vpc_id         = module.vpc.vpc_id
  subnet_ids     = module.vpc.private_subnets
  environment    = local.environment
  instance_class = "db.t3.medium"

  tags = local.common_tags
}

Infrastructure as Code sa Terraform nije samo tehnički alat — to je fundamentalna promjena u načinu razmišljanja o infrastrukturi. Umjesto manualne konfiguracije koja se ne može reproducirati, dobijate verzionisanu, testabilnu i auditabilnu infrastrukturu koja živi zajedno s vašim kodom. Kombinacija Terraform modula za reusabilnost, remote state managementa za timsku saradnju i CI/CD integracije za automatizaciju čini osnovu modernog DevOps pristupa. Bez obzira da li odaberete Terraform, OpenTofu ili Pulumi, principi ostaju isti: deklarišite željeno stanje, verzionišite sve, automatizujte što je više moguće i nikad ne preskačite pregled plana prije primjene promjena na produkciju.