Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Tip | Opis | Status |
---|---|---|
Tip | Opis | Status |
---|---|---|
Nekoliko resursa, bez vanjskih zavisnosti. Jedan AWS racun. Jedna regija. Jedno okruzenje.
Zavrseno
Nekoliko AWS racuna i okruzenja, skolski primjer infrastrukturnih modula koristeci Terrafrom
Zavrseno
Vise AWS racuna, mnogo regiona, hitna potreba da se smanji kopiranje i ponavljanje koda, velika upotreba konpozicija. Koristi se Terrafrom
Rad u toku
vrlo velika
Nekoliko razlicitih cloud provajdera(AWS, GCP, Azure). Deplojment na vise cloud platformi. Koristi se Terrafrom.
Nije zapoceto
mala
Nekoliko AWS racuna i okruzenja, skolski primjer infrastrukturnih modula koristeci Terrafrom
Nije zapoceto
srednja
Vise AWS racuna, mnogo regiona, hitna potreba da se smanji kopiranje i ponavljanje koda, velika upotreba konpozicija. Koristi se Terrafrom
Nije zapoceto
velika
Nekoliko razlicitih cloud provajdera(AWS, GCP, Azure). Deplojment na vise cloud platformi. Koristi se Terragrunt.
Nije zapoceto
Zvanična Terrafrom dokumentacija detaljno opisuje sve detalje vezane za konfiguraciju. Pročitajte je pazljivo kako bi razumijeli ostatak ovog poglavlja.
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.
Resurs moduli (eng. resource module) predstavljaju kolekciju resursa, koji skupa mogu napraviti neku zajedničku akciju (npr. AWS VPC Terraform modul kreira VPC, podmreže, NAT, itd). Od konfiguracije cloud provajdera zavisi koji resursi mogu biti definisani unutar modula, ili unutar struktura na većem nivou (npr. unutar infrastrukturnog modula).
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)
Na primjer, modul terraform-aws-atlantis koristi resurs module kao što su terraform-aws-vpc i terraform-aws-security-group kako bi se kreirala infrastruktura potrebna za pokretanje Atlantisa unutar AWS Fargate servisa.
Još jedan primjer je modul terraform-aws-cloudquery gdje su zajedno korišteni drugi razlčiti moduli od strane terraform-aws-modules kao i od strane Docker resursa, kako bi se postiglo kreiranje i deplojment Docker slika, sve unutar jednog istog seta komandi.
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.
Izvor podataka external dozvoljava vanjskim programima da budu izvor podataka, omogućavajući im kasnije korištenje u drugim dijelovima Terrafrom konfiguracije. Ovdje je primjer terraform-aws-lambda module modula gdje je ime datoteke kreirano pozivajuci eksternu Paython skriptu.
Izvor podataka http pravi HTTP GET zahtjeve prema datom URL-u i eksportuje informacije dobijenog odgovora. Ovaj pristup se obično koristi da bi se dobile informacije izvora podataka od pristupne tačke (eng. endpoint) koja ne podržava Terrafrom.
Infrastrukturni moduli i kompozicije bi se trebali nalaziti unutar svog fajla Terrafrom stanja koji se pohranjuje na nekoj udaljenoj lokaciji sa koje moze biti dohvaćena od strane drugih programera na kontrolisan način (sa dnevnikom pristupa, specifičnom sigurnosnom politikom itd.)
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.
Dok su individualni resursi kao atomi unutar infrastrukture, resurs moduli su molekule koje su sastavljene od atoma. Modul je namanja verzionisana i dijeljena jedinica. Posjeduje tačnu listu argumenata, osnovnu implementacijsku logiku da bi se napravila željena funkcionalnost. Npr. modul terraform-aws-security-group kreira aws_security_group
i aws_security_group_rule
resurse na osnovu ulaznih podataka. Ovaj resurs modul se sam po sebi može koristiti skupa sa drugim modulima kako bi se kreirao infruastrukturni modul.
Pristup podacima kroz različite molekule (resurs module i infrastrukturne module) je napravljen koristći izlazne podatke dobijene od strane modula i izvora podataka.
Pristup između kompozicija je često napravljen koristeći udaljeni fajl stanja izvora podataka. Postoji više načina uz pomoć kojih se mogu dijeliti podaci između konfiguracija.
Ako koncepte opisane iznad postavimo u pseudo vezu onda bi to moglo izlgedati ovako:
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
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
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.
Sa tim na umu, u ovoj knjizi je napravljen osvrt na prve dvije vrste strukture projekta, samo Terrafrom i Terragrunt.
Ovaj dokument ima za cilj da se sistematski opišu najbolje prakse prilikom korištenja Terrafrom alata kao i da se daju preporuke za najčešće probleme sa kojima se susreću korisnici Terraforma.
Terrraform je moćan (ako ne i najmoćniji) i jedan od najkorištenijih alata koji vam dozvoljavaju upravljanje infrastrukturom kao kodom. Dozvoljava programerima da rade mnoge stvari i ne ograničava ih da te stvari rade na način koji bi bio težak za podršku ili integraciju.
Neke informacije opisane u ovoj knjizi možda ne izgledaju kao najbolje prakse. Ja to znam, i da bi pomogao čitaocima da razdvoje šta su ustaljene najbolje prakse, a šta je samo još jedno misljenje o tome kako treba raditi stvari, ponekad koristim pomoćne dijelove koda kako bi dao širi kontekst. Također ponekad koristim savjete kako bi dao dodatni kontekst i ikone da bi specificirao o kojem nivou zrelosti se radi za svaku podsekciju vezanu za najbolje prakse
Nekoliko godina kasnije je ažurirana sa aktuelnim najboljim praksama dostupnim sa Terrafrmom 1.0. U konačnici ova knjiga bi trebala sadržavati većinu neospornih najboljih praksi za korisnike Terrafroma.
Kontaktirajte me ukoliko želite prevesti ovu knjigu i na druge jezike.
Uvijek želim da dobijem povratnu informaciju kako bi mogao da ovu knjigu držim ažuriranom. Kako zajednica napreduje, i dolaze nove ideje i prijedlozi za ažuriranje, ažuriranja su impletirane i verifikovane sa vremena na vrijeme.
Rad na ovoj knjizi je licenciran pod Apache 2 licencom. Pogledajte LICENCU za vise informacija.
Autori i oni koji su doprinijeli pisanju sadržaja ove knjige ne mogu garantovati za ispravnost informacija koje ćete ovdje pronaći. Molim vas vodite računa da razumijete, da informacije koje su ponuđene u ovo knjizi su proizvod slobodne volje, i nikakva vrsta dogovora ili ugovora nije napravljena između vas i osoba koje su povezane sa sadržajem knjige ili samim projektom. Autori i oni koji su doprinijeli pisanju knjige nisu odgovorni za bilo kakve eventulne posljedice koje mogu proisteći iz korištenja sadržaja ove knjige.
Autorska prava © 2018-2023 Anton Babenko.
Logicki provajderi rade u potpusnosti unutar logike Terrafroma i vrlo cesto nemaju interakciju sa bilo kojim drugim servisima. Za njih mozemo smatrati da su binarni 0 ili 1. Najcesci logicki provajderi ukljucuju , , , , .
terraform.tfvars
ne bi trebao biti koristen nigdje osim unutar .
Pobrinite se da razumijete kljucne koncepte - , , i , kao sto su koristene u sljecem primjeru.
Vjezbajte konzistentnu strukturu i :
i druga rjesenja inspirisana Kubernetesom. Ponekad ima smisla da koristite Kubernetes eko sistem alata da bi postigli zeljeno stanje vase Terrafrom konfiguracije. Pogledati video za vise informacija.
Pogledajte primjere organizacije koda za ili u sljedecem poglavlju.
je relativno nov alat (kao i većina ostalih DevOps alata) koji je započet 2014. godine.
Ova knjiga je započeta u sunčanom Madridu, 2018. godine i dostupna je besplatno za preuzimanje preko sljedećeg linka .
Please if you want to become a sponsor.
Ako ste zainteresovani za neku posebnu temu koja već nije obrađena unutar ove knjige, molim vas da ga je predložite ili glasajte za neku od vec predloženih tema koje bi željeli da vidite u ovoj knjizi. Ako mislite da imate sadržaj koji bi se trebao naći u ovoj knjizi i želite da doprinesete, napišite prijedlog i napravite zahtijev za izmjenom (nemojte se opterećivati o stilu pisanja teksta u ovom trenutku!).
Ova knjiga je održavana od strane uz pomoć različitih kontributora i prevoditelja.
Izvor: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform
Ovaj primjer sadrzi kod koji je primjer organizacije Terrafrom konfiguracije za male infrastrukture bez vanjskih zavisnosti.
Idealan za pocetak i izmjene u hodu
Idealan za male resurs module
Dobar za male i linearne infrastrukturne module (npr: terraform-aws-atlantis)
Dobar za mali broj resursa (manje od 20-30)
Jedan fajl stanja za sve resurse moze uciniti proces rada sa Terrafromom sporim ukoliko broj resursa poraste (razmislite o upotrebi argumenta -target da bi ogranicili broj resursa)
Izvor: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform
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 razlicitu verziju infrastrukturnog modula (alb
) preuzetog sa Terraform Registry-a
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.
Source: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform
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 razlicitu verziju infrastrukturnog modula (alb
) preuzetog sa Terraform Registry-a
Svako okruzenje koristi istu verziju internog modula modules/network
posto je taj modul preuzet iz lokalnog direktorija.
U velikim projektima kao sto je opisano ovdje prednosti koristenja Terragrunta postaju ocigledne. Pogledajte Primjeri organizacije koda sa Terragruntom.
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.
— Cut your Kubernetes costs by 60%+ on average. First cluster optimization FREE!
— Terraform Providers, SDKs and docs for your API. Make your API enterprise-ready!
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
Dokumentacija moze ukljucivati dijagrame krierane sa mermaid i primjere kreirane uz pomoc cloudcraft.co.
Koristite Terraform pre-commit hooks kako bi osigurali da je kod validan, pravilno formatiran i automatski dokumentovan prije nego bude dostupan na gitu i pregledan od strane ljudi.
pre-commit je framework za menadzmen i odrzavanje visejezicnih okidaca prije nego se kod nadje na gitu. Napisan je u Python programskom jeziku i to je mocan alat koji vam omogucava da odradite nesto automatski na racunaru programera prije nego je kod postavljen na git repozitoriji. Koristi se za pokretanje automatskih formatera koda (pogledajte podrzane okidace).
Sa Terraform konfiguracijama pre-commit
se moze korisititi da formatira i validira kod kao i da azurira dokumentaciju.
Pogledajte pre-commit-terraform repository kako bi se poblize upoznali sa tim, takodjer pogledajte i postojeci repozitoriji terraform-aws-vpc gdje se to i koristi.
terraform-docs je alat koji vam omogucava generisanje dokumenatacije iz Terrafrom modula u razlicitim izlaznim formatima. Mozete ga pokrenuti rucno bez upotrebe pre-commit okidaca, ili koristeci pre-commit-terraform hooks da bi se dokumentacija azurirala automatski..
@todo: Document module versions, release, GH actions
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):
Ime resrusa treba biti imenovano sa this
ako nema neko vise opisujuce ili generalnije ime, ili ako resurs modul kreira jedan resurs tog tipa (npr, u AWS VPC modulu postoji jedan resurs tipa aws_nat_gateway
i vise resursa tipaaws_route_table
, tako bi aws_nat_gateway
trebao biti imenovan this
aaws_route_table
treba da ima bolje opisujuce ime - kao private
, public
, database
).
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
tags
count
Don't reinvent the wheel in resource modules: use name
, description
, and default
value for variables as defined in the "Argument Reference" section for the resource you are working with.
Support for validation in variables is rather limited (e.g. can't access other variables or do lookups). Plan accordingly because in many cases this feature is useless.
Use the plural form in a variable name when type is list(...)
or map(...)
.
Order keys in a variable block like this: description
, type
, default
, validation
.
Always include description
on all variables even if you think it is obvious (you will need it in the future).
Prefer using simple types (number
, string
, list(...)
, map(...)
, any
) over specific type like object()
unless you need to have strict constraints on each key.
Use specific types like map(map(string))
if all elements of the map have the same type (e.g. string
) or can be converted to it (e.g. number
type can be converted to string
).
Use type any
to disable type validation starting from a certain depth or when multiple types should be supported.
Value {}
is sometimes a map but sometimes an object. Use tomap(...)
to make a map because there is no way to make an object.
Make outputs consistent and understandable outside of its scope (when a user is using a module it should be obvious what type and attribute of the value it returns).
The name of output should describe the property it contains and be less free-form than you would normally want.
Good structure for the name of output looks like {name}_{type}_{attribute}
, where:
{name}
is a resource or data source name without a provider prefix. {name}
for aws_subnet
is subnet
, foraws_vpc
it is vpc
.
{type}
is a type of a resource sources
{attribute}
is an attribute returned by the output
If the output is returning a value with interpolation functions and multiple resources, {name}
and {type}
there should be as generic as possible (this
as prefix should be omitted). See example.
If the returned value is a list it should have a plural name. See example.
Always include description
for all outputs even if you think it is obvious.
Avoid setting sensitive
argument unless you fully control usage of this output in all places in all modules.
Prefer try()
(available since Terraform 0.13) over element(concat(...))
(legacy approach for the version before 0.13)
output
Return at most one ID of security group:
When having multiple resources of the same type, this
should be omitted in the name of output:
locals
Da bi specificirali ekspicitne zavisnosti izmedju resursaKoristan nacin da ukazete Terrafromu da bi neki resurs trebao biti izbrisan cak i kad nema direktne zavisnosti u Terrafrom konfiguraciji.
https://raw.githubusercontent.com/antonbabenko/terraform-best-practices/master/snippets/locals.tf
Zahtjevani argument index_document
mora biti postavljen, ako var.website
nije prazan.
Opcioni argumenti error_document
mogu biti izostavljeni.
Postoji mnogo ljudi koji kreiraju sjajan sadrzaj i odrzavaju projekte otvorenog koda relevantnim za Terrafrom zajednicu ali ja ne mogu smisliti bolji nacin organizacije ovih linkova osim da kopiram linkove koji su navedeni unutar awesome-terraform.
https://twitter.com/antonbabenko/lists/terraform-experts - Lista ljudi koji rade sa Terrafromom veoma aktivno i koji ce vam reci mnogo (ukoliko ih pitate).
https://github.com/shuaibiyy/awesome-terraform - Azurna list resursa HashiCorp Terraform.
http://bit.ly/terraform-youtube - "Your Weekly Dose of Terraform" YouTube kanal Antonona Babenka. Prenosi uzivo sa osvrtima, interviju, pitanja i odgovori, programiranje uzivo, i neki trikovi sa Terraformom.
https://weekly.tf - Terraform sedmicne vijesti. Razlicite vijesti iz Terraform svijeta (projekti, najave, diskusije). Urednik Anton Babenko.
FTP (Cesti Terraform Problemi)
Terragrunt - Orkestracijski alat
tflint - Alat za formatiranje koda
tfenv - Menadzer verzija
Atlantis - Automatizacija zahtijeva za izmjene
pre-commit-terraform - Kolekcija git okidaca za Terraform koji mogu biti koristeni sa pre-commit framework
Infracost - Procjena troskova infrastrukture za Terraform unutar zahtjeva za izmjenu. Radi sa Terragruntom, Atlantisom i pre-commit-terraform.
Verzionisanje resursa i infrastrukturnih modula treba biti specificirano. Provajderi trebaju biti konfigurisani izvan modula, ali samo unutar kompozicija. Verzinisanje provajdera i Terrafroma moze takodjer biti zakljucano.
Ne postoji najbolji alat za odrzavanje zavisnosti i njihov menadzment, ali postoje odredjene upute kako napraviti zavisnosti manje problematicnim. Na primjer, Dependabot moze biti koriste za automatizaciju azuriranja zavisnosti. Dependabot zahtjev za izmjenu da bi drzao vase zavisnosti sigurnim i azuiranim. Dependabot podrzava Terraform konfiguracije.
Ukoliko zelite vježbati neke od stvari opisanih u ovom upustvu pogledajte link ispod na kojem cete pronaci workshop za vježbu.
Workshop za vježbu je dostupna na sljedecem linku -