2. Predstavljanje
● Coming:
○ osnovani 1991, 100+ zaposlenih u BG, NI i NS
○ full-stack konsalting, razvoj i podrška
■ infrastruktura, platforma, aplikacije i sve između
● Moja malenkost:
○ 13+ godina u IT-u (uglavnom Ops, malo i Dev)
○ na čelu sektora za cloud i infrastrukturu (~25 inženjera)
nebojsailic
nilic
3. Problem
● Ciklus build-ovanja, testiranja i deployment-a softvera je
(uglavnom) u velikoj meri automatizovan
● Upravljanje infrastrukturom je često i dalje manuelan ili
polu-automatizovan proces ..
● .. koji se oslanja na komandnu liniju, skripte i ClickOps*
* "clicking around in the web console, then lying about it”
4. Infrastructure as Code - IaC
● Koncept upravljanja infrastrukturom kroz programski kod
● Zašto je ovo dobro:
○ Tera nas da automatizujemo manuelne operacije
■ ljudi nisu stvoreni za repetitivne taskove, mašine jesu
○ Kod možemo da parametrizujemo
■ isti kod + različiti inputi = različita okruženja
○ Infrastrukturu možemo da tretiramo kao bilo koji drugi kod
■ version control, odobravanje promena kroz PR proces, CI/CD …
5. GitOps
● Primena Dev/DevOps praksi i alata na infrastrukturu:
○ Version control
■ Git kao “single source of truth” za konfiguraciju infrastrukture
○ Code review
■ (automatizovane i ljudske) provere promena
○ CI/CD
■ primena promena isključivo kroz pipeline
8. GitOps u užem smislu (pull-based)
https://opengitops.dev/
9. ● Open source alat za kreiranje, upravljanje i uništavanje
infrastrukture* kroz programski kod
* AWS, Azure, GCP, VMware, Kubernetes, Cisco, Citrix, F5, Check Point, Palo Alto, Fortinet, Github,
GitLab, Azure DevOps, Artifactory, Cloudflare, Okta, Elastic, Digital Ocean, Hetzner, …
11. proceduralno vs deklarativno
“izvrši te i te komande ovim
redosledom da bih dobio
željeno krajnje stanje”
npr. bilo koji scripting jezik / CLI
“izvoli željeno stanje koje treba da
mi obezbediš”
npr. Terraform, Kubernetes YAML
kako šta
12. Primer Terraform koda
resource "vsphere_datacenter" "dc" {
name = "MyDatacenter"
}
resource "vsphere_folder" "folder" {
path = "MyFolder"
type = "vm"
datacenter_id = vsphere_datacenter.dc.id
}
13. Multi-cloud
● Sa Terraform-om koristi se isti jezik za različite cloud platforme..
● .. ali ne i isti kod - kod se mora prilagoditi pojedinačnoj platormi
16. Terraform 101 - state
● JSON fajl koji u clear textu:
○ mapira Terraform konfiguraciju sa stvarnim svetom (infrastrukturom)
■ npr. instancu “foo” iz koda sa instancom ID-a abcd1234 u infrastrukturi
○ čuva informaciju o zavisnosti između kreiranih objekata
● Svaki terraform plan je diff između koda i state fajla/infrastrukture
● Po defaultu, stanje se čuva lokalno u radnom direktorijumu, moguće
ga je čuvati i remote (S3, Azure Blob, Google Cloud Storage, ..)
17. Levels of operational maturity (by HashiCorp)
1. Sve manuelno
○ Infrastruktura se provisionuje kroz UI ili CLI, ne postoji kontrola ni istorija
promena
2. Polu-automatizovano
○ Koristi se kombinacija UI/CLI, IaC alata i skripti
○ Svako za sebe radi provisioning (npr kroz Terraform CLI sa svog računara)
3. (Collaborative) Infrastructure as Code
○ Sve se provisionuje kroz alate za automatizaciju
○ Kod je smešten na centralnoj lokaciji (Git serveru)
○ Provisioning proces je automatizovan i centralizovan
○ Postoji kontrola i istorija promena
18. 1. smestiti Terraform kod u centralni VCS
2. izmestiti state van lokalnog foldera (koristiti remote backend)
3. uspostaviti kontrolu nad promenama u infrastrukturi
○ ko sme da unosi promene, ko ih odobrava, kako se radi review ..
4. automatizovati proces primene promena nakon odobrenja
Preduslovi za Terraform kolaboraciju
20. ● Podrazumeva da sami kreiramo pipeline koji radi:
○ Validaciju koda (CI)
○ Validaciju promena (CI + čovek)
○ Primenu promena (CI)
1. Uradi Sam
21. Terraform CI pipeline (primer)
1. Otvaranje pull request-a (čovek)
2. Validacija koda i najboljih praksi (CI)
○ terraform fmt -check, terraform validate, 3rd-party alati (tflint, checkov, ..)
3. terraform init (CI)
4. terraform plan –out i output plana u PR (CI)
5. review koda i plana iz tačke 4 (čovek)
○ ako nešto nije kao što je očekivano: izmene u kodu, push, koraci 2-5 do uspeha
6. odobravanje promena i merge pull request-a (čovek)
7. terraform apply plana iz tačke 4 (CI)
22. Prilagodite Terraform pipeline-u
● -input=false
○ ako je potrebno da neku promenljivu unesemo interaktivno, negde smo zabrljali
● -out=tfplan i kasnije terraform apply tfplan
○ da bismo bili sigurni da kreiramo ono što smo review-ovali
● -auto-approve
○ da bismo izbegli interaktivnu potvrdu apply operacija
● -no-color
○ da ne boji output komandi
● TF_IN_AUTOMATION
○ env variabla koja ako je setovana na bilo koju vrednosti čini Terraform manje “pričljivim”
23. Niste potpuno sami
● Mnogi CI alati poseduju Terraform integracije:
○ Azure Pipelines: Azure Pipelines Terraform Tasks
○ Github: hashicorp/setup-terraform akcija
○ GitLab:
■ Terraform CI template
■ Terraform report artifact i widget
■ Bonus: GitLab se može koristiti i kao remote state backend
24. 2. Pozovi prijatelja
● Outsource-ujmo naš pipeline 3rd-party rešenju
● Specijalizovane Terraform CI platforme koje (obično):
○ poseduju integracije sa popularnim VCS rešenjima
○ izvršavaju init, plan i apply operacije
○ podržavaju definisanje procedura za odobrenje promena
○ služe kao remote backend za state
○ omogućavaju primenu bezbednosnih polisa
○ daju procenu troškova deploy-ovane infrastrukture
○ podržavaju detekciju drifta
26. Poređenje Terrafom CI platformi
https://medium.com/@elliotgraebert/four-great-alternatives-to-hashicorps-terraform-cloud-6e0a3a0a5482
27. Primer Terraform CI platforme - Atlantis
● Self-hosted rešenje koje implementira init, plan i apply
korake iz pipeline-a
● Podržava:
○ GitHub
○ GitLab
○ Bitbucket
○ Azure DevOps
28.
29.
30.
31. 3. TF-controller
● .. ili GitOps u užem smislu
● plug-in za popularni GitOps alat
● Flux tipično upravlja Kubernetes resursima
○ TF-controller mu donosi podršku i za Terraform kod
https://github.com/weaveworks/tf-controller
32. 3. TF-controller funkcionalnosti
● Glavni cilj: sync Terraform koda u Git repou na infrastrukturu
● plan i apply koraci pipeline-a se izvršavaju u okviru Flux-a na
Kubernetes klasteru
● Plan se output-uje kao Kubernetes objekat i može biti odobren
automatski ili manuelno (kroz commit u Git repozitorijumu)
● Fokus na provisioning, state enforcement i detekciju drifta
○ ne obezbeđuje kompletan Terraform CI workflow
34. Terraform GitOps opcije + -
1. Uradi Sam:
+ najfleksibilnija (“mašta je granica”) i pogodna za kompleksnije workflow-e
- (skoro) sve morate sami
2. Pozovi prijatelja:
+ najmanje vremena potrebno do zaokruženog workflow-a
- mogućnost prilagođavanja zavisi od izabranog rešenja
- platforma mora imati pristup vašim tajnama (kredencijalima, secret-ima ..)
3. TF-controller:
+ rešenje u GitOps maniru, drift detection
+ - Kubernetes kao preduslov
- osnovne funkcionalnosti, fokus na CD umesto zaokruženog workflow-a
35. Zašto GitOps?
● Standardizacija Ops procesa
○ korišćenjem proverenih workflow-a dev timova
● Automatizovana primena polisa na infrastrukturu
○ coding konvencije, security, najbolje prakse ..
● Kolaboracija pri unošenju promena
○ jasno definisan review/approval proces i za infrastrukturu
● Vidljivost i audit
○ kompletna istorija kada, kako i od strane koga su promene unesene i odobrene
● Poboljšana kontrola pristupa
○ ključeve infrastrukture može imati samo CI
