Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Pitanja vezana za strukturu Terrafrom koda su daelko najecsca pitanja unutar zajednice. Takodjer svi se u odredjenom trenutku nadju u sitauaciji da razmisljaju koji je najbolji nacin da najbolje struktruiraju kod za svoj projekat.
Ovo je jedno od pitanja za koje postoje razlicita rjesenja i tesko je dati univerzalni savjet, pocnimo prvo sa razumijevanje na sta se sve ovo pitanje odnosi.
Kakava je kompleksnost projekta?
Broj povezanih resursa
Broj Terraform provajdera (pogledati biljesku ispod o "logickim provajderima")
Koliko cesto se vasa infrastruktura mijenja
Od jedanput mjesecno/sedmicno/godisnje
Do kontinuirano (svaki put kada napravite novu izmjenu)
Inicijatori izmjene koda? Da li dozvoljavate da vas CI server radi azuiranje repozitorija kada se napravi novi artifakt?
Samo programeri mogu praviti izmjene unutar repozitorija u kojem cuvamo infrastruktruni kod
Svi mogu predloziti izmjenu praveci zahtijev za izmjenom (eng. Pull Request) ukljucuji i automatske zatatke pokrenute od strane CI servera
Koju deplojmet platformu odnosno servis koristite?
AWS CodeDeploy, Kubernetes, ili OpenShift zahtijevaju malo drugaciji pristup
Kako ste grupisali vasa okruzenja?
Po okruzenju (produkcijsko, testno), regionu ili projektu
Stavljanjem cjelokupnog koda unutar main.tf
je dobra ideja kada ste na pocetku ili pravite neki jednostavni primjer. U svim drugim slucajevima puno bolja opcija je radvojiti fajlove u nekoliko logickih cjelina kao sto su:
main.tf
- poziva module, sadrzi lokalne varijable i izvore podataka da bi se kreirali svi resursi.
variables.tf
- sadrzi deklaraciju varijabli koristenih unutar main.tf
outputs.tf
- sadrzi izlazne podatke za resurse kreirane unutar main.tf
versions.tf
- sadrzi detalje o verziji Terrafroma i projevajdera
terraform.tfvars
ne bi trebao biti koristen nigdje osim unutar kompozija.
Pobrinite se da razumijete kljucne koncepte - resurs module, infrastrukturne module, i ckompozicije, kao sto su koristene u sljecem primjeru.
Lakse je i brze raditi sa manjim brojem resursa
terraform plan
i terraform apply
prave API pozive da bi projeverili status resursa
Ako imate citavu infrastrukturu unutar jedne kompozicije to moze uzeto dosta vremena
Ranjivos (u slucaju sigurnosnog incidenta) je manja sa manjim brojem resursa
Izolacija ne relevantnih resursa jednih od drugih stavljajuci ih unutar razlicitih kompozicija smanjuje rizik ukoliko nesto krene po zlu
Zapocnite svoj projekat koristeci udaljeno stanje zato sto:
Vas laptop nije mjesto na kojem cete cuvati jedinu ispravnu verziju vaze infrastrukture
Menadzment tfstate
fajla unutar git-a je nocna mora
Kasnije kada slojevi infrastrukture krenu da rastu u vise smjerova (broj njihovih zavisnosti ili resursa) bit ce lakse drzati stvari pod kontrolom
Vjezbajte konzistentnu strukturu i konvenciju o imenovanjima:
Kao i proceduralni kod, Terrafrom kod treba biti pisan kako bi ga u prvom redu bio citljiv rudima, konzistentnost ce pomoci kada krenete da mijenjate vas kod u buducnosti
Moguce je pomjerati resurse unutar Terrafrom fajla stanja ali je to dosta teze raditi ukoliko imate ne konzistentnu sturkturu koda i nacin imenovanja.
Drzite resurs module sto je moguce jednostavnijim
Nemojte pisati vrijednosti direktno u kodu ukoliko te vrijednosti mogu biti prosljedjene kao varijabile ili mogu biti procitane direktno iz izvora podataka.
Koristite izvor podataka i terraform_remote_state
kao poveznicu izmedju infrastrukturnih modula i kompozicija.
U ovoj knjizi primjeri su grupisani po kompleksnosti - od manjih prema vecim infrastrukturama. Ovakvo razdvajanje nije striktrno pa svakako provjerite i druge struktrue koda.
Imati malu infrastrukturu znaci imati mali broj zavisnosti i nekoliko resursa. Kako projekat raste, raste i potreba za lancem izvrsavanja Terrafrom konfigracija, spajajci razlicite infrastukturne module i prosljedjujuci vrijednosti unutar kompozicija koje su postale ocigledne.
Postoji najmanje 5 razlicitih grupa orkestracijskih rjesenja koje bi programeri trebalo da koriste:
Samo Terraform. Vrlo jednostavno, programer treba da zna samo Terrafrom kako bi zavrsio posao.
Terragrunt. Cisti orkestracijski alat koji moze biti koristen za orkestraciju citave infrastrukture kao i za brigu o zavisnostima. Terragrunt po prirodi radi sa infrastukturnim modulima i kompozicijama sto smanjuje ponavljanje koda.
Vlastite skripte. Cesto se dogadja na pocetku i prije otkrivanja Terragrunt-a
Ansibl ili slicni alati automatizacijski alati. Obicno se koristi kada se sa upotrebom Terrafroma krenulo nakon Ansibl-a ili kada se Ansibl UI aktivno kroisti.
Crossplane i druga rjesenja inspirisana Kubernetesom. Ponekad ima smisla da koristite Kubernetes eko sistem alata da bi postigli zeljeno stanje vase Terrafrom konfiguracije. Pogledati video Crossplane vs Terraform za vise informacija.
Sa tim na umu, u ovoj knjizi je napravljen osvrt na prve dvije vrste strukture projekta, samo Terrafrom i Terragrunt.
Pogledajte primjere organizacije koda za Terraform ili Terragrunt u sljedecem poglavlju.
Ovo poglavlje opisuje ključne koncepte koji su korišteni unutar ove knjige.
Resursi (eng. resource) su aws_vpc
, aws_db_instance
, itd. Resurs pripada pružatelju usluga u oblaku odnosno cloudu (eng. cloud provider), prihvata argumente, kao izlaznu informaciju pruža atribute i ima svoj životni ciklus. Resursi mogu biti kreirani, možete dohvatiti ranije kreirane resurse, raditi njihovo ažuriranje i brisanje.
Infrastrukturni moduli predstavljaju kolekciju resurs modula, oni logički ne moraju biti povezani ali u odredjenoj situaciji ili konfiguraciji projekta služe istoj svrsi. Definišu kofiguraciju za cloud provajdera koja je prosljeđena resurs modulima a dalje prema samim resursima. Limitirani su na jedan entitet unutar logičke cjeline. (npr. AWS region, Google projekat)
Kompozicija (eng. composition) je kolekcija infrastrukturnih modula, koji mogu biti rašireni preko nekoliko logički razdvojenih područja (npr. AWS regioni, različiti AWS računi). Kompozicija se koristi kako bi se opisala kompletna infrastruktura potrebna za čitavu organizaciju ili projekat.
Kompozicija se sastoji od infrastrukturnih modula, koji se dalje sastoje od modula resursa koji dalje implementiraju same resurse.
Izvor podataka (eng. data source) je zadužen samo za operaciju čitanja, i zavisi od pružatelja cloud usluga, koristi se kao resurs modul i kao infrastrukturni modul.
Izvor podataka terraform_remote_state
se ponaša kao vezivno tkivo za module višeg nivoa i kompozicije.
Provajderi dostupni unutar terrafroma, zatim provisioners, kao i nekoliko drugih pojmova su vrlo dobro opisani i objašnjeni unutar zvanične dokumentacije tako da ih nećemo ovdje dodatno opisivati. Po mom mišljenju, oni imaju malo ili nimalo veze sa pisanjem dobrih Terrafrom modula.
Pristup podacima kroz različite molekule (resurs module i infrastrukturne module) je napravljen koristći izlazne podatke dobijene od strane modula i izvora podataka.
Ako koncepte opisane iznad postavimo u pseudo vezu onda bi to moglo izlgedati ovako:
Primjeri Terrafrom modula trebaju sadrzavati dokumentovana objasnjenja mogucnosti i kako ih koristiti.
Svi linkovi README.md trebaju biti apsulutni da bi ih Terrafrom Registry web stranica prikazivala ispravno
Sa Terraform konfiguracijama pre-commit
se moze korisititi da formatira i validira kod kao i da azurira dokumentaciju.
@todo: Document module versions, release, GH actions
Ovaj primjer sadrzi kod koji je primjer organizacije Terrafrom konfiguracije za vece infrastrukture, u primjeru se koriste:
2 AWS racuna
2 regiona
2 odvojena okruzenja (produkcijsko
and testno
). Svako okruzenje je smjesteno unutar posebnog AWS racuna i resursi se prostiru izmedju 2 regije.
Svako okruzenje koristi istu verziju internog modula modules/network
posto je taj modul preuzet iz lokalnog direktorija.
Idealan za projekte gdje je infrastruktura logicki razdvojena (radvojeni AWS racuni)
Dobar kada nema potrebe da mijenjate resurse koji su dijeljeni izmedju AWS racuna (jedno okruzenje = jedan AWS racun = jedan Terraform fajl stanja)
Dobar kada nema potrebe za orkestracijom izmjena izmedju okruzenja
Dobar kada su resursi infrastrukture u razilicitim okruzenjima sa svrhom i kada se ne mogu generalizovati (npr: neki resursi se ne koriste u jednom od okruzenja ili u nekom od regiona)
Kako projekat raste, bit ce teze odrzati ova okruzenja u azuriranom stanju. Razmislite o upotrebi infrastruktrurnih modula za zadatke koji se ponavljaju.
Ovaj primjer sadrzi kod koji je primjer organizacije Terrafrom konfiguracije za infrastrukture srednje velicine, u ovom primjeru se koriste:
2 AWS racuna
2 odvojena okruzenja (produkcijsko
and testno
). Svako okruzenje je smjesteno unutar posebnog AWS racuna i nemaju dodairnih tacaka.
Svako okruzenje koristi istu verziju internog modula modules/network
posto je taj modul preuzet iz lokalnog direktorija.
Idealan za projekte gdje je infrastruktura logicki razdvojena (radvojeni AWS racuni)
Dobar kada nema potrebe da mijenjate resurse koji su dijeljeni izmedju AWS racuna (jedno okruzenje = jedan AWS racun = jedan Terraform fajl stanja)
Dobar kada nema potrebe za orkestracijom izmjena izmedju okruzenja
Dobar kada su resursi infrastrukture u razilicitim okruzenjima sa svrhom i kada se ne mogu generalizovati (npr: neki resursi se ne koriste u jednom od okruzenja ili u nekom od regiona)
Kako projekat raste, bit ce teze odrzati ova okruzenja u azuriranom stanju. Razmislite o upotrebi infrastruktrurnih modula za zadatke koji se ponavljaju.
Ne bi trebao postojati razlog da pratite samo jednu konvenciju :)
Budite svjesni cinjenice da cloud resursi cesto imaju ogranicenja u dozvoljenim imenima. Neki resursi, npr: ne mogu sadrzavati srednju crtu u imenu. Konvencija u ovoj knizi se odnonosi samo na imenovanje unutar Terrafroma
Koristite _
(donja crta) umjesto -
(srednje crte) na svim mjestima (za imena resursa, imena izvora podataka, imena varijabli, izlaznih vrijednosti itd).
Preferirajte upotrebu malih slova i brojeva (iako je UTF-8 podrzan).
Ne ponavaljajte tip resursa u imenima resursa (u dijelovima ili kompletno):
Uvijek koristite imenice u jednini za imena.
Koristite -
unutar vrijednosti argumenata i na mjestima gdje ce vrijednosti biti izlozene ljudima (npr, unutar DNS imena RDS instance).
Ukljucite argument count
/ for_each
unutar resursa ili blokova izvora podataka kao prvi argument na vrhu i razdvojite novim redom nakon toga.
Ukljucite argument tags,
ako je podrzano od strane resursa, kao zadnji pravi argument pracen sa depends_on
i lifecycle
, ako je neophodno. Sve ovo bi trebalo biti razdvojeno sa jednim praznim redom.
Kada koristite uslove unutar argumentacount
/ for_each
praktikujte booelan vrijednosti (true/false) umjesto koristenjalength
ili drugih izraza.
resource
count
/ for_each