Infrastructure as Code: Terraform i Ansible usluge

Infrastructure as code zamjenjuje klikanje kroz konzolu i jednokratne shell komande fajlovima koje tim može pregledati, verzionisati i primijeniti na isti način svaki put. Serveri, firewall pravila, DNS zapisi, baze podataka i cloud nalozi postaju opis u Gitu: novo staging okruženje je produkcijski opis sa drugim varijablama, obnova nakon kvara je komanda, a svaka izmjena dolazi kao plan koji tačno nabraja šta će biti kreirano, izmijenjeno ili obrisano.

U CodeWizu pišemo Terraform i OpenTofu module, CloudFormation šablone tamo gdje je Amazon Web Services jedini cloud, i Ansible playbookove koji konfigurišu servere koje ti alati kreiraju. Postavljamo udaljeni state, tajne, pregled koda i pipeline, tako da izmjena infrastrukture prolazi istu disciplinu kao izmjena koda aplikacije. Primopredaja je repozitorij koji vaš tim može pokrenuti, a ne dijagram koji zastari sedmicu nakon puštanja.

Usluga je namijenjena timovima čiji staging nikada nije baš isti kao produkcija, agencijama koje sličan stack grade iznova za svakog klijenta, i firmama koje su narasle do nekoliko servera koje niko ne želi dirati jer cijelo podešavanje živi u sjećanju jedne osobe. Ako vam novo okruženje danas oduzme dan ručnih koraka, opis u kodu je obično promjena nakon koje sljedeće okruženje traži sat pregleda.

Terraform: Serverski ormari sa uredno provučenim plavim i bijelim mrežnim kablovima

Infrastructure as Code uz Terraform i OpenTofu

Terraform konfiguracija opisuje cloud resurse u HashiCorp Configuration Languageu i razgovara sa providerima za AWS, Hetzner, DigitalOcean, Cloudflare i desetine drugih platformi. OpenTofu je open-source fork koji čita isti jezik i iste providere, i to je podrazumijevani izbor koji preporučujemo kada nema razloga ostati na komercijalnom izdanju Terraforma. Opišete šta treba da postoji; alat uporedi taj opis sa onim što stvarno postoji i primijeni samo razliku.

Kako slažemo repozitorij

Mali moduli sa jasnim ulazom i izlazom: server, upravljana baza, firewall, DNS zona. Okruženja slažu te module umjesto da ih kopiraju.
Jedan state fajl po okruženju i po većoj cjelini, tako da greška u DNS izmjeni ne može isplanirati brisanje baze.
Fiksirane verzije providera i modula, formatirane sa terraform fmt i provjerene sa tflint i skenerom konfiguracije kao što je Trivy, prije nego što iko pokrene apply.
Pipeline koji na svakom pull requestu pokreće terraform plan i ostavlja plan kao komentar. Apply ide iz pipelinea sa zaštićene grane, a ne sa laptopa.

Mali poziv modula dovoljan je da se vidi oblik. Ime okruženja, firewall i DNS zapis dolaze iz varijabli, pa staging i produkcija dijele modul i razlikuju se samo u vrijednostima:

variable "environment" {
  type = string
}

module "app" {
  source   = "./modules/server"
  name     = "app-${var.environment}"
  image    = "ubuntu-24.04"
  firewall = ["http", "https", "ssh-admin"]
  backups  = var.environment == "production"
}

resource "cloudflare_record" "app" {
  zone_id = var.zone_id
  name    = var.hostname
  type    = "A"
  content = module.app.ipv4
  proxied = true
}

Ovako radimo VPS flote na Hetzneru i DigitalOceanu, AWS naloge, te Cloudflare DNS, keš i firewall pravila koja bi inače odlutala poslije svake izmjene u dashboardu. HashiCorpova dokumentacija Terraform jezika je referenca za sintaksu. Gdje serveri zapravo rade zasebna je odluka, o kojoj pišemo u vodiču za deployment na DigitalOceanu, AWS-u, Hetzneru i bare metal serverima.

CloudFormation šabloni kada ste potpuno na AWS-u

CloudFormation je AWS-ov način da se stack resursa opiše u YAML-u ili JSON-u. AWS čuva state, otkriva drift i može vratiti neuspješan update. Šabloni su razuman izvor istine kada je firma u potpunosti na AWS-u i već razmišlja u nalozima, IAM-u i StackSetsima. Za sve ostale, alat koji pokriva više cloudova manje je dugoročno obavezivanje.

Šta predajemo kada je CloudFormation pravi izbor

Ugniježđene stackove sa jasnom granicom: mreža, podaci, aplikacija, rub. Change set se pregleda prije pokretanja, što je AWS-ov ekvivalent čitanja Terraform plana.
Parametre za sve što se razlikuje među nalozima, a tajne se čitaju iz Systems Managera ili Secrets Managera umjesto da se upisuju u šablon.
DeletionPolicy: Retain i zaštitu od brisanja na bazama, bucketima i svemu što mora preživjeti brisanje stacka.
StackSets kada ista osnova (logovanje, zaštitne ograde, IAM) treba da stigne u više naloga.
AWS CDK kada tim radije generiše te šablone iz TypeScripta ili Pythona, uz sintetisani šablon i dalje commitovan kako bi pregled ostao moguć.

Ispravan Terraform ne prepisujemo u CloudFormation samo radi promjene alata. AWS CloudFormation vodič pokriva sam servis; naš posao je da odlučimo treba li vam i, ako treba, da ostavimo stackove koje može mijenjati i neko ko nije prvobitni autor.

Ansible automatizacija za konfiguraciju i objave

Terraform i CloudFormation dobro kreiraju infrastrukturu, a slabo opisuju ono što se dešava unutar servera: pakete, korisnike, SSH politiku, verzije PHP-a ili Node.js-a, Nginx, cron i korake objave. Tu sloj pokriva Ansible automatizacija. Playbookovi su YAML, sigurno ih je pokretati ponovo i rade preko SSH-a na mašinama koje Terraform nikada nije kreirao.

Playbook koji bismo vam zaista ostavili

Role ostaju male i verzionisane. Inventari i group_vars drže razlike među okruženjima. Tajne su u Ansible Vaultu ili, bolje, u eksternom skladištu koje playbook čita u trenutku pokretanja. Osnovna rola ojačava SSH, uključuje nenadgledana sigurnosna ažuriranja i podešava slanje logova; aplikacione role instaliraju runtime i objavljuju tačno određenu verziju.

- name: Baseline application server
  hosts: app
  become: true
  roles:
    - role: baseline
    - role: nginx
    - role: php
      vars:
        php_version: "8.3"
  tasks:
    - name: Enable unattended security upgrades
      ansible.builtin.apt:
        name: unattended-upgrades
        state: present

ansible-lint i check mode u CI-ju, tako da pull request pokaže šta bi se promijenilo prije nego što išta dotakne server.
Serijske grupe i handleri, tako da postupna izmjena Nginxa ne restartuje sve mašine odjednom.
Tagovi kojima se pokreće jedna rola, i dokumentovana komanda za puni prolaz.
Nema lozinki u repozitoriju. Vault lozinke i SSH ključevi čuvaju se sa istom pažnjom kao kredencijali produkcijske baze.

Zvanična Ansible dokumentacija je referenca za module i inventare. Između dva alata povlačimo čvrstu liniju: Terraform kreira mašinu i njen firewall, Ansible podešava ono što na njoj radi. Kada oba pokušaju da posjeduju isti resurs, drift je zagarantovan.

Mrežni patch panel sa mnogo isprepletenih kablova u numerisanim portovima

Upravljanje okruženjima: dev, staging i produkcija

Upravljanje okruženjima čini ostatak pouzdanim. Modul koji koristi samo produkcija, dok je staging složen ručno, slaže vam laž onog dana kada objava zavisi od te razlike. Držimo jedan opis, a razlikuju se varijable, veličina i pristup.

Okruženje	Gdje radi	Podaci	Smije primijeniti izmjene
Razvoj	Laptop ili mali dijeljeni server	Testni podaci ili mali sintetički skup	Bilo koji programer, često automatski
Staging	Isti oblik kao produkcija, manji	Anonimizovani ili sintetički	Pipeline, na spajanju u glavnu granu
Produkcija	Pravi kapacitet i pravi backupi	Podaci korisnika	Pipeline, sa zaštićene grane, nakon što čovjek pročita plan

Odvojen state i odvojeni kredencijali po okruženju. Apply na stagingu ne vidi produkciju.
Imena i tagovi koji sadrže okruženje, vlasnika i repozitorij, tako da zaboravljeni server odmah vidite na cloud računu.
Staging smije biti manji, ali ne i drugačije arhitekture. Ako su u produkciji dva aplikaciona servera iza load balancera, staging je isti, čak i kada je svaki jeftiniji.
Dokumentovan način da se staging podaci osvježe iz produkcije bez kopiranja tajni, ličnih podataka koje nemate osnov da kopirate, ili podataka o plaćanju.

Terraform, OpenTofu, CloudFormation ili Ansible

Timovi nas često pitaju da izaberemo jedan alat. Koristan odgovor je par sa jasnom granicom, izabran prema tome gdje infrastruktura zaista živi.

Pristup	Čime dobro upravlja	State	Najbolji za	Kompromis
Terraform ili OpenTofu	Serveri, mreže, DNS, baze, object storage, Cloudflare	Udaljeni state koji vi održavate	Više od jednog clouda, ili cloud uz Cloudflare	Zaključavanje statea, nadogradnje providera, disciplina oko applyja
CloudFormation	AWS resursi, osnove naloga, StackSets	Čuva i zaključava AWS	Okruženje koje jeste i ostaće na AWS-u	Nema pomoći onog dana kada dodate Hetzner, DigitalOcean ili drugi cloud
Ansible	Paketi, korisnici, web serveri, objave aplikacije	Uglavnom bez statea	Konfiguracija mašina koje već postoje	Nezgodan kao jedini alat za kreiranje cloud resursa
Terraform plus Ansible	Jedan kreira, drugi konfiguriše	Namjerno podijeljeno	Uobičajeno produkcijsko stanje koje ostavljamo	Dva alata za naučiti i napisano pravilo šta koji alat posjeduje

Cloudflare postavke pripadaju istom repozitoriju kao serveri na koje pokazuju. Proxy, pravilo keša ili izmjena firewalla urađena samo u dashboardu neće biti tu kada budete obnavljali, zato i tu konfiguraciju tretiramo kao kod. Odvojeno smo pisali o Cloudflare konfiguraciji za performanse.

State, drift, tajne i pregled

Fajlovi su lakši dio. Navike oko njih sprječavaju da samouvjeren plan sruši produkciju.

Udaljeni state sa zaključavanjem. State živi u šifrovanom backendu (S3 bucket sa lockom, GitLab HTTP backend ili ekvivalent), nikada u Gitu i nikada samo na laptopu. State često sadrži tajne i ID-jeve resursa; pristup njemu je pristup produkciji.
Planovi se pregledaju. Pull requestovi pokazuju plan. Destruktivne izmjene se izdvajaju. Produkcijski apply koristi ulogu koju ljudi ne koriste za svakodnevni rad u cloud konzoli.
Drift se otkriva po rasporedu. Dnevni plan koji javi „nešto se promijenilo van koda” način je da klik u konzoli nađete prije nego što postane incident. Ansible check mode radi isti posao unutar servera.
Postojeća infrastruktura se može preuzeti. terraform import i import blokovi uvode živi server pod upravljanje bez ponovnog kreiranja. Ovakav rad na postojećem okruženju radimo češće nego gradnju od nule.
Tajne ostaju van repozitorija. Fajlovi varijabli sa lozinkama se ne commitaju. Ansible Vault, SOPS ili cloud secret manager ih drži, a CI dobija samo pristup koji tom okruženju treba.

Uobičajene greške u Infrastructure as Code projektima

Jedan state fajl za cijelu firmu, pa je svaki plan spor, a svaki apply zastrašujuć.
Apply sa laptopa programera i ličnim cloud ključem, bez traga ko je mijenjao produkciju.
Nefiksirani provideri, pa rutinski init povuče major verziju i predloži zamjene.
Terraform i panel, ili Terraform i Ansible, istovremeno upravljaju istim firewall pravilom.
Staging složen ručno, koji se tiho razišao u verziji PHP-a, cronu ili varijablama okruženja.
Tajne u terraform.tfvars commitovane pored koda.
Nema zaključavanja backenda, pa dva applyja rade odjednom i pokvare state.

Ne treba ovo svakom sajtu. Jedna WordPress instalacija na uredno vođenom serveru, kroz open-source hosting panel, može biti jednostavnije i jeftinije. Ako je to vaša situacija, reći ćemo vam.

Od čega zavisi cijena Infrastructure as Code projekta

Procjenu dajemo nakon kratkog popisa naloga, servera i načina na koji danas radite deployment. Faktori koji pomjeraju cifru su ustaljeni:

Koliko cloudova, naloga i okruženja postoji, i koliko se zaista razlikuju.
Da li opisujemo nešto novo ili uvozimo godine resursa građenih klikanjem.
Koliko je podešavanje nedokumentovano, uključujući izuzetke na firewallu i cron poslove koje je neko dodao preko SSH-a.
Da li su u obimu Ansible konfiguracija, CI integracija i upravljanje tajnama, ili samo cloud resursi.
Zahtjevi politike i revizije: koji nalozi smiju raditi apply, koliko dugo se čuvaju planovi i da li je obavezno skeniranje konfiguracije.
Primopredaja sa dokumentacijom, ili stalni aranžman u kojem module i providere držimo ažurnim.

Kako radimo

Popis: nabrajemo naloge, servere, DNS, baze, firewall pravila i korake koje neko danas radi ručno.
Dizajn: biramo Terraform, OpenTofu, CloudFormation i Ansible, povlačimo granicu među njima i dogovaramo koja su okruženja u obimu.
Opis: pišemo module, šablone i playbookove, i uvozimo postojeće resurse tako da se produkcija ne gradi ponovo samo da bi došla pod upravljanje.
Pregled: planovi i check mode završavaju na pull requestovima. Destruktivna iznenađenja ispravljamo prije bilo kakvog applyja.
Primjena: prvo staging, zatim produkcija iz pipelinea, uz put za rollback aplikacije i dokumentovan način da se infrastrukturna izmjena vrati.
Primopredaja: dobijate repozitorij, runbook i prolazak kroz rad. Providere, role i provjere drifta možemo i dalje držati ažurnim.

Zašto CodeWiz

Pokrećemo ono što opisujemo: Laravel, Node.js, WordPress i serveri ispod njih već su posao koji radimo, pa moduli odgovaraju tome kako se aplikacije zaista ponašaju.
Open-source na prvom mjestu: OpenTofu, Ansible, tflint i Trivy čuvaju vas od licence koja vam ne treba.
Mjereno prema problemu: jedan server ne dobija platformu sa više naloga. Flota koja je prerasla ručno klikanje ne dobija README pun SSH komandi.
Fer cijene: vrhunski razvoj bez vrhunskih cijena, iz Banje Luke, uz rad na daljinu sa klijentima iz regiona i svijeta.
Jedan tim za cijeli stack: infrastruktura, deployment, performanse i sigurnost idu zajedno. Više o načinu rada je na stranici o CodeWizu.

Često postavljana pitanja

Koliko košta infrastructure as code?

Zavisi od broja naloga i servera, i od toga da li opisujemo novo okruženje ili uvozimo ono što je građeno ručno. Jedno okruženje sa nekoliko servera kratak je angažman. Više cloudova, godine nedokumentovanih izmjena i puna Ansible osnova traju duže. Pisanu procjenu dobijate nakon popisa, prije nego što počnemo.

Da li da koristimo Terraform ili Ansible?

Obično oba, za različite poslove. Terraform ili OpenTofu kreira cloud resurse. Ansible konfiguriše operativni sistem i objavljuje aplikaciju. CloudFormation zamjenjuje Terraform samo kada je okruženje na AWS-u i tu će i ostati.

Moramo li ponovo izgraditi produkciju da bismo ovo uveli?

Ne. Uvoz postojećeg servera, baze ili DNS zapisa uvodi ih pod upravljanje bez ponovnog kreiranja. Taj uvoz planiramo, plan pažljivo čitamo i primjenjujemo ga tek kada plan ne pokazuje zamjenu.

Koliko traje tipičan projekat?

Mali, dobro poznat stack često je opisan, uvezen i spojen na CI u roku od nekoliko sedmica. Postojeće okruženje sa više okruženja i malo dokumentacije traje duže, jer je i sam popis dio posla.

Ko pokreće alate nakon primopredaje?

Vaš tim može. Pipeline primjenjuje izmjene, a runbook pokriva plan, apply, rollback i dodavanje servera. Module možemo i dalje održavati ako to želite.

Da li nas ovo vezuje za jedan cloud?

Suprotno, kada koristimo OpenTofu ili Terraform. Providere za Hetzner, DigitalOcean, AWS i Cloudflare držimo jedne pored drugih. Ono na šta pristajete je disciplina da se infrastruktura mijenja kroz pregled, i ta disciplina ostaje i ako se provider promijeni.

Spremni da infrastrukturu opišete kodom?

Recite nam koje cloudove i servere imate, i gdje izmjena i dalje zavisi od toga da neko klikne ili uđe preko SSH-a. Kontaktirajte nas i predložićemo obim, ili pogledajte ostale naše infrastructure as code usluge.

Infrastructure as Code: Terraform i Ansible usluge

Sadržaj