# Introduction **NOTE: U toku je migracija sadrzaja sa** [**GitHub repozitorija**](https://github.com/awsbosnia/devops-aws-mentorship-program) **koji se koristi za DevOps Mentorship Program, sadrzaj ce biti kompletno migriran do 1.10.2023.** Kada je kompanija Amazon 2002. godine programerima ponudila beta verziju SOAP i XML interfejsa prekog kojeg mogu da pristupaju Amazon katalogu i zarade kroz njihov Amazon Associates program pocela je jedna nova era u IT-u nama danas poznata kao racunarstvo u oblaku odnosno *Cloud Computing* ili skraceno samo *Cloud*. Sa pojavom *Cloud-a* poceo je da se mijenja i nacin na koji IT profesionalci obavljaju svoje svakodnevne zadatke pa je tako 2009. godine na konferenciji DevOpsDays u Belgiji prvi put upotrebljen termin **DevOps**. To mozemo smatrati pocetkom novog pristupa IT timova razvoju i isporuci softvera. Od 2009. do danas na trazistu se pojavilo nebrojeno mnogo alata i tehnologija koji bi trebalo da proces razvoja i isporuke softvera ucine sto je moguce brzim, sa sto je moguce manjim brojem gresaka koje se isporucuju kao finalni prozivod krajnjem korisniku, gdje u razvoju i isporuci softvera zajednicki ucestuju i blisko saradjuju razliciti timovi IT profesionalaca (developeri, sistem administratori, mrezni administratori, projekt menadzeri itd.) Pojava novih alata i tehnologija dovela je do povecanja zahtijeva trzista rada za IT strucnjacima koji bi bili u mogucnosti da sa tim alatima i tehnologijama rade na sto je moguce kvalitetniji i efektivniij nacin. Upravo iz tog razloga su i nastale stranice ovog prirucnika, kako bi se svima onima koji imaju zelju da se edukuju u polju racunarstva u oblaku sa naglaskom na **Amazon Web Servise (AWS)** te **DevOps** principe, alate i tehnologije ponudilo jedinstveno mjesto gdje mogu zapoceti svoj proces ucenja na jezicima koji se govore na prostoru balkana. \ \ Sadrzaj ovog prirucnika podijeljen je u tri glavne cjeline: * [DevOps Mentorship Program](/devops-mentorship-program) * [Amazon Web Services (AWS)](/amazon-web-services-aws) * [DevOps Learning Path](/devops-learning-path) ### Kako koristiti ovaj prirucnik? Prirucnik je namjenjen kako onima koji se nalaze na pocetku svog ucenja tako i onima koji imaju napredno znanje i dugi niz godina iskustva te vjerujemo da ce svi oni koje interesujuju podrucja kojima se ovaj prirucnik bavi dobiti priliku nauciti nesto novo ili osvjeziti postojece znanje. Ukoliko ste apsultuni pocetnik odnosno nemate radnog iskustva u radu sa DevOps alatim i tehnologijama preporuka je da krenete ucenje od [DevOps Mentorship Programa](/devops-mentorship-program). Ukoliko pak imate radno iskustvo i zanimaju vas specificni DevOps alati i tehnologije preporuka je da krenete od [DevOps Learning Path-a](/devops-learning-path). Dio prirucnika koji se odnosi na [Amazon Web Services(AWS)](/amazon-web-services-aws) vam moze pomoci da steknete i prosirite znanje o specifinicnim AWS servisima. Trenutno AWS broji preko 200 razlicitih servisa, i taj broj se povecava, autori ovog prirucnika su obradili servise koji se prema njihovom iskustvu najvise koriste i upotrebljavaju. Kako se prirucnik konstantno unaprijedjuje i mijenja tako se i broj servisa koji su obradjeni unutar prirucnika stalno povecava. Kako budete prolazili kroz materijale kreirane za DevOps Mentorship Program i DevOps Learning Path cesto cete se susresti sa referencama koje vode do povezanih AWS servisa. ### Povratne informacije Povratne informacije bilo pozitivne ili negativne su nam jako bitne jer uz pomoc njih mozemo da radimo na unaprijedjenju sadrzaja ovog prirucnika. Budite slobodni da sve povratne informacije i posaljete na email . ### Jezik Za pisanje projekta koristimo Bosanski, Hrvatski, Srpski, Crnogorski jezik sa ijekavski dijalektom i latinicnim pismom. Izbjegavali smo upotrebu dijalektickih znakova i specijalnih karaktera (`č, ć, đ, š, ž`). Naslovi odredjenih poglavalja, rijeci i/ili izraza, zbog lakse pretrage i razumijevanja mogu biti napisani i na engleskom jeziku. ### Kontributori Svima koji su na bilo koji nacin doprinijeli pisanju i izradi ovog prirucnika dugujemo neizmjernu zahvalnost. Listu ljudi koji su ucestovali u izradi prirucnika mozete vidjeti u dijelu [Contributors](/contributors). ### Dodatna pitanja i informacije Za sva dodatne pitanja i informacije o ovom prirucniku molimo vas pogledajte dio [Frequently Asked Questions (FAQ)](broken://pages/MvgXBcVlv7R9NDJgvMYj) ili se sa vasim pitanjem javite na email [dzenan.dzevlan@gmail.com](mailto:undefined). # DevOps Mentorship Program **AWS / Cloud / DevOps / Site Reliability Engineering / Platform Engineering / Production Engineering Mentorship program** ili skraceno **DevOps Mentorship Program** je **BESPLATNI** mentorski program odrzan od Februara 2023. do Septembra 2023. godine namjenjan svima onima koji zele da steknu i/ili prosire svoje znanje iz polja Cloud-a i DevOps tehnologija i alata. Program je pokrenut od strane grupe entuzijasta, AWS zajednice u Bosni i Hercegovini te uz pomoc kolega iz AWS zajednice Crne Gore, Srbije i Slovenije sa ciljem sirenja znanja i pomoci svima onima koji zele da svoju IT karijeru grade i razvijaju u navedenom podrucju.\ \ Za vise infromacija o tome kako je sam program organizovan preporuka je da pogledate snimak KickOff Meetinga. {% embed url="" %} DevOps Mentorship Program - KickOff Meeting {% endembed %} Program je trajao 28 sedmica i u nastavku mozete pronaci biljeske sa predavanja i snimke video lekcija za svaku od sedmica. # Week-1: Git - Sistem za verzionisanje koda **Git** je alat koji je razvio [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) kako bi olaksao vodjenje jednog velikog i kompleksnog projekta – **Linux kernela**. Git je de-facto postao standardni alat za verzionisanje koda. ### Git - Osnovni pojmovi * **Init** – Inicijalizacija Git repozitorijuma. Inicijalizacija se obavlja komandom `git init` u direktorijumu u kojem se nalazi projekat. * **Repozitoriji** – Git repozitorijum je mesto gde se nalaze sve verzije projekta. * **Remote** – Remote je udaljeni/remote repozitorijum (npr. onaj koji ste kreirali na git serveru, GitHub-u etc.). * **Local** – Local je lokalni repozitorijum (incijaliziran na vasem lokalnom racunaru). * **Add** – Add je proces dodavanja fajlova u staging area. Fajlovi se dodaju komandom `git add` ili `git add .` (dodaje sve fajlove u trenutnom direktorijumu). * **Staging Area** – Staging area je mesto gde se nalaze fajlovi koji ce biti dodati u commit. * **Commit** – Commit je verzija projekta. Commit se sastoji od snapshot-a projekta i metapodataka koji opisuju commit. * **Push** – Push je proces slanja izmjena koda iz lokalnog repozitorijuma na udaljeni/remote repozitorijum (npr. na GitHub). * **Branch** – Branch je nezavisna linija/grana razvoja projekta. Branch se koristi da bi se razvijale nove funkcionalnosti neovisno od glavne `main` grane, Branch/Grana se moze spojiti sa drugom granom/branch-om. * **Pull** – Pull je proces preuzimanja izmjena koda iz udaljenog/remote repozitorijuma na lokalni repozitoriji (onaj na vasem racunaru). * **Merge** – Merge je proces spajanja dve grane/branch-a u jednu granu/branch. * **Pull Request** – Pull request je zahtjev za spajanje izmjena iz jedne grane/branch-a u drugu granu/branch. * **Fork** – Fork je kopija projekta. Fork se koristi da bi se napravila kopija postojeceg projekta i nastavio rad na njemu bez uticaja na originalni projekat. Fork se moze spojiti sa originalnim projektom koristeci Pull Request.
### **Osnovne Git Naredbe** ```bash $ git init #inicijalizacija git repozitorijuma $ git status #prikaz statusa repozitorijuma $ git add file-name #dodavanje fajla u staging area $ git add . #dodavanje svih fajlova iz radnog direktorija ova u staging area $ git commit -m"commit message" #kreiranje commit-a $ git push #slanje izmjena na udaljeni/remote repozitorijum $ git pull #preuzimanje izmjena sa udaljenog/remote repozitorijuma $ git log #prikaz loga commit-ova $ git log --oneline #prikaz loga commit-ova u jednoj liniji $ git log --oneline --graph #prikaz loga commit-ova u jednoj liniji sa #grafickim prikazom $ git clone repo-url #kloniranje projekta sa udaljenog/remote repozitorijuma $ git remote -v #prikaz povezanih udaljenih/remote repozitorijuma $ git branch #prikaz trenutne grane/branch-a unutar kojeg se nalazite $ git branch branch-name #kreiranje nove grane/branch-a od trenutne #grane/branch-a na kojem se nalazite, #necete biti automatski prebaceni na novu granu/branch $ git merge branch-name #spajanje grane/branch-a sa trenutnom granom/branch-om $ git checkout branch-name #prebacivanje na drugu granu/branch $ git remote add origin repo-url #povezivanje lokalnog repozitorijuma sa #udaljenim/remote repozitorijumom $ git config --global user.name "username" #podesavanje korisnickog imena --global #znaci da ce ove postavke biti #primjenjene na svaki repozitorijum na #vasem racunaru ``` ### Git Cheat Sheet

Git Cheat Sheet by Jan Kruger

### Snimci predavanja #### DevOps Mentorship Program - Week 1 - Git & GitHub ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} DevOps Mentorship Program - Week 1 - Git & GitHub ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% endembed %} #### DevOps Mentorship Program - Week 1 - Git & GitHub (#tier-1-group-2) {% embed url="" %} DevOps Mentorship Program - Week 1 - Git & GitHub (#tier-1-group-2) {% endembed %} ### Materijali za ucenje * [Uvod u Git - Tomo Krajina](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/books/github_knjiga_tomo_krajina.pdf) * [Git Notes for Professionals](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/books/git-notes-for-professionals.pdf) * [Git for Professionals Tutorial - Tools & Concepts for Mastering Version Control with Git](https://www.youtube.com/watch?v=Uszj_k0DGsg) * [git Documentation](https://git-scm.com/docs/git) ### Korisni alati * [VS Code Git History Extension](https://marketplace.visualstudio.com/items?itemName=donjayamanne.githistory) * [VS Code Git Graph Extension](https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph) * [VS Code GitLens — Git supercharged Extension](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens) ### Zadatak Kreirajte javni GitHub repozitoriji unutar svog GitHub racuna i nazovite ga: `ime-prezime-devops-mentorship`. Kreirajte `.gitignore` i `README.md` fajlove. Nakon sto ste kreirali fajlove na vasem lokalnom racunaru postavite ih na GitHub repozitoriji koji ste ranije kreirali. Vas repozitoriji bi trebao da ima dvije grane main i development gdje cete sve izmjene na `main` granu dodavati praveci Pull Request sa `development` grane odnosno branch-a. ### Dodatni materijali #### Knjige * [Git Pro - Scott Chacon & Ben Straub](https://git-scm.com/book/en/v2) #### Video materijali * [The gitflow workflow - in less than 5 mins.](https://www.youtube.com/watch?v=1SXpE08hvGs\&ab_channel=Devchild) * [Professional Guides: Workflow Strategies](https://www.youtube.com/watch?v=aJnFGMclhU8\&ab_channel=GitHubTraining%26Guides) * [Git Flow vs GitHub Flow: What You Need to Know](https://www.youtube.com/watch?v=hG_P6IRAjNQ\&ab_channel=AlexHyett) * [Git Tutorial - Git Crash Course using BitBucket](https://www.youtube.com/watch?v=1tC6Z57AOkY\&t=984s\&ab_channel=AHTCloud) #### Blog Postovi * [15 Git Commands You May Not Know](https://dev.to/zaiste/15-git-commands-you-may-not-know-4a8j) * [Introduction to git flow](https://blog.knoldus.com/introduction-to-git-flow/) * [Mastering git merge and rebase](https://towardsdatascience.com/mastering-git-merge-and-rebase-f2a7c5c348a9) * [Git Flow vs Github Flow\*\*](https://www.geeksforgeeks.org/git-flow-vs-github-flow/) # Week-2: Linux / UNIX Operativni sistemi **UNIX** je stabilan, mocan i fleksibilan operativni sistem visokih performansi pogodan za izvrsavanje kriticnih aplikacija od visoke vaznosti. **UNIX** je cvrsto povezan sa mreznim servisima TCP/IP protokola, cime je u potpunosti promijenjena slika **UNIX** servera i radnog okruženja iz prošlosti. Umjesto servera sa klasicnim serijskim terminalima UNIX server se nalazi u mreži, pri cemu sa radnim stanicama ostvaruje vezu preko LAN/WAN mreže i TCP/IP skupa protokola. Vecina velikih svjetskih proizvodjaca racunara razvija specificnu varijantu UNIX operativnog sistema, što ukazuje na njegov kvalitet, popularnost i rasprostranjenost. Vecina UNIX sistema, poput Red Hat Enteprise, je komercijalna - korisnik mora da plati licencu za korištenje, a izvorni kod nije raspoloziv. To su razlozi narastajuce popularnosti Linux sistema koji zadržava vecinu dobrih osobina UNIX sistema, a dodatno se odlikuje raspolozivim izvornim kodom i prakticno besplatnim korišenjem. Zbog toga danas vecina proizvodjaca racunara osim sopstvene komercijalne verzije UNIX sistema nudi i podršku za Linux. Linux se najcesce koristi kao operativni sistem na radnim stanicama ili serverima u manjoj ili srednjoj klasi servera, a jedna od oblasti dominantne primjene, u kojoj veliki broj korisnika podržava i promoviše Linux kao bazicni server, su Internet servisi. **(dio iz knjige** [**Linux i UNIX - B. Djordjevic, D.Pleskonjic, N.Macek - Beograd 2004**](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/books/os-unix-i-linux-beograd-el-skola.pdf)**)** ### **Osnovne Linux/UNIX komande** ```bash $ man ssh #Manual for ssh command $ man $ ssh [ip or hostname] #Secure shell, an encrypted network protocol #allowing for remote login and command execution $ ssh -vvv #verbose for troubleshooting access $ pwd #displays the current directory $ sudo su - #Switch to root user $ whoami #Displays your logged in user id $ id #Displays your user id and group id $ hostnamectl #Displays your hostname $ cd / #Change directory to the root of the filesystem $ cd target #Change directory to “target” directory $ cd ~ #Change directory to your user home directory $ cp file1 file2 #Copy file1 to file2 $ cp -r dir1 dir2 #Copy directory dir1 to dir2 $ mv file1 file2 #Move file1 to file2, file1 is deleted $ rm file1 #Remove file1 $ rm -r dir1 #Remove directory dir1 and all its contentsbash ``` U **UNIX** sistemima, postoje dva tipa poveznica (eng. links) koje se koriste za stvaranje referenci na datoteke i direktorije - simbolicke (engl. symbolic links) i tvrde (engl. hard links). **Simbolička poveznica**, također poznata i kao `soft link`, je datoteka koja predstavlja simbolicku referencu na neku drugu datoteku ili direktorij. Simbolicka poveznica sadrži putanju do izvorne datoteke ili direktorija, a kada se na nju pristupa, sistem ce slijediti putanju koju simbolicka poveznica pokazuje i doci do izvorne datoteke. Simbolicke poveznice se stvaraju uz pomoc naredbe `ln -s`, **a brisanje simboličke poveznice neće utjecati na izvornu datoteku ili direktorij**. S druge strane, tvrda poveznica, također poznata i kao `hard link`, je druga kopija iste datoteke ili direktorija. Tvrde poveznice se stvaraju uz pomoc naredbe ln, a nakon stvaranja tvrde poveznice, izvorna datoteka **i njezina tvrda poveznica se tretiraju kao jedna te ista datoteka**. To znaci da ako se promijeni sadrzaj izvorne datoteke, promjena ce se vidjeti i u tvrdoj poveznici, jer su to ista datoteka. Brisanje izvorne datoteke nece utjecati na tvrdu poveznicu, jer tvrda poveznica nije samo referenca na izvornu datoteku, vec je to druga kopija te datoteke. Kljucna razlika između simbolickih i tvrdih poveznica u **UNIX** sistemima je u tome što simbolicke poveznice predstavljaju samo referencu na izvornu datoteku ili direktorij, dok su tvrde poveznice kopije izvorne datoteke ili direktorija. ```bash $ ln -s /path/to/file /path/to/symlink #Create a symbolic link to file $ ln file1 file2 #Create a hard link to file1 ``` ### **Struktura Linux/Unix file sistema** ``` [centos@ip-172-31-34-106 /]$ tree -L 1 . |-- bin -> usr/bin |-- boot |-- dev |-- etc |-- home |-- lib -> usr/lib |-- lib64 -> usr/lib64 |-- media |-- mnt |-- opt |-- proc |-- root |-- run |-- sbin -> usr/sbin |-- srv |-- sys |-- tmp |-- usr `-- var ``` Za vise informacija o fajl sistemu i strukturi direktorijuma pogledati [File System Hierachy Standard](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/books/filesystem-hierarchy-standard.pdf) ### Snimci predavanja #### DevOps Mentorship Program - Week 2 - Linux / UNIX commands ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} #### DevOps Mentorship Program - Week 2 - Linux / UNIX commands ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} ### Materijali za ucenje * [DevOps Learning Path - Linux/UNIX OS](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/devops-learning-path/linux-unix.md) * [Linux i UNIX - B. Djordjevic, D.Pleskonjic, N.Macek - Beograd 2004](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/books/os-unix-i-linux-beograd-el-skola.pdf) * [Osnove Administracije Operacijskog Sustava Linux - Obrazovni Sustav Srce Hr](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/papers/osnove-administracije-operacijskog-susteva-1-linux-srca.pdf) | [Biljeske iz Knjige](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/devops-mentorship-program/02-february/week-2-210223/files/osnove-administracije-linuxa-biljeske.md) * [UNIX and Linux System Administration Handbook, 5th Edition](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/books/unix-linux-sys-admin-handbook.pdf) * [UNIX Operativni Sistemi](http://os.etf.rs/POS/tutorials/srdjan/kurs/html/sadrzaj.html) * [yum cheat sheet](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/chaet-sheets/yum-cheatsheet.pdf) * [Linux Performance Analysis in 60,000 Milliseconds](https://netflixtechblog.com/linux-performance-analysis-in-60-000-milliseconds-accc10403c55) ### Dodatni materijali # Week-3: Bash / Shell Scripting **Shell** je program koji obezbjedjuje korisniku direktnu interakciju sa operativnim sistemom. Na pocetku je Unix OS koristio shell program pod nazivom **Bourne shell**. Danas se koristi **Bash** shell program koji je kompatibilan sa Bourne shell-om. **Bash** shell je standardni shell program na vecini Linux distribucija.\ Postoji vise razlicitih shell programa koji su razvijani za razlicite verzije UNIX-a. Ovo su neki od njih: * `sh` - Bourne shell * `csh` - C shell * `ksh` - Korn shell * `tcsh` - Tenex C shell / poboljsani C shell * `zsh` - Z shell / extenzija za `bash`, `ksh` i `tchsh` * `bash` - GNU Bourne again shell * `fish` - Friendly interactive shell Detaljnije o razlikama izmedju razlicith shellova mozete pogledati na linku: [Hyperpolyglot - Unix Shells: Bash, Fish, Ksh, Tcsh, Zsh](https://hyperpolyglot.org/unix-shells) Kad god ukucamo neku komandu u Terminal shella, shell (`bin/bash`) je odgovoran da pravilno izvrsi komandu. Aktivnosti koje shell izvrsava su: * parsiranje komande * procjenjivanje meta karaktera kao sto su zamjenski znakovi, specijalni karakter itd. * obrada signala * pokretanje programa za izvrsenje komande Da bi provjerili koji shell koristimo, mozemo ukucati komandu `echo $SHELL`. Ova komanda ce nam vratiti putanju do shell programa koji se trenutno koristi. ```bash $ echo $SHELL /bin/bash ``` Prethodna komanda nam govori da koristimo `/bin/bash` odnosno Bash shell. Sljedecom komandom mozemo provjeriti verziju Bash shell-a. ```bash $ bash --version GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. ``` ### Bash shell konfiguracijski fajlovi Shell konfiguracijski fajl je tekstualni fajl koji se koristi za konfigurisanje okruzenja shell-a. Konfiguracijski fajlovi se koriste za postavljanje okruzenja, definisanje shell promjenljivih, kreiranje aliasa, postavljanje putanja (PATH) i drugih varijabli, kao i za dodavanje funkcionalnosti shell-u koristenjem skripti i drugih dodataka. Kada se shell pokrene, prvo se cita konfiguracijski fajl kako bi se postavilo okruzenje, prije nego sto se shell prikaze na ekranu i korisnik moze poceti kucati komande. Konfiguracijski fajl se izvrsava za svaki novi shell koji se pokrene, bilo da se shell pokrene na pocetku sesije, ili putem skripte ili terminala. Ovi fajlovi se nalaze u korisnickom direktoriju (home folder-u) i mogu biti uredjeni koristenjem bilo kojeg tekst editora. ``` $ pwd /home/centos $ ls -la .* -rw-------. 1 centos centos 6744 Feb 28 22:19 .bash_history -rw-r--r--. 1 centos centos 18 Nov 24 2021 .bash_logout -rw-r--r--. 1 centos centos 193 Nov 24 2021 .bash_profile -rw-r--r--. 1 centos centos 259 Feb 28 19:07 .bashrc ``` * `.bashrc` - Ovaj fajl se izvrsava svaki put kada se pokrene Bash shell. Ovaj fajl se nalazi u korisnikovom home direktoriju. Ovaj fajl se koristi za postavljanje promenljivih okruzenja, aliasa, funkcija itd. * `.bash_profile` - Ovaj fajl se izvrsava samo kada se pokrene Bash shell u interaktivnom modu. Ovaj fajl se nalazi u korisnikovom home direktoriju. Ovaj fajl se koristi za postavljanje promenljivih okruzenja, aliasa, funkcija itd. * `.bash_history` - Ovaj fajl se nalazi u korisnikovom home direktoriju. Ovaj fajl sadrzi istoriju komandi koje je korisnik izvrsio u Bash shell-u. * `.bash_logout` - Ovaj fajl se izvrsava kada se korisnik izloguje iz Bash shell-a. Ovaj fajl se nalazi u korisnikovom home direktoriju. * `.profile` - Ako postoji, ovaj konfiguracijski fajl interno poziva `.bashrc` Razliciti shellovi imaju razlicite nazive i putanje do konfiguracijskih fajlova. Ovo su neki od njih: * `sh` - `.profile` * `csh` - `.cshrc` * `ksh` - `.kshrc` * `tcsh` - `.tcshrc` * `zsh` - `.zshrc` * `bash` - `.bashrc` * `fish` - `.config/fish/config.fish` ```bash # Hello World Shell Script # Kreirajte novi fajl sa nazivom `hello.sh` i dodajte sljedeci sadrzaj: #!/bin/bash # Ovo je komentar unutar skripte echo "Danas je: " date ``` Kada pokrenemo ovu skriptu, dobijamo sljedeci rezultat odnosno output u terminalu: ```bash $ ./hello.sh Danas je: Wed Mar 1 10:43:12 UTC 2023 ``` Linija `#!/bin/bash` se naziva **shebang** i govori shell-u da koristi Bash shell za izvrsavanje skripte. Shebang je obavezna linija u svakoj shell skripti. Shell koristi ovu liniju da odredi koji shell program treba koristiti za izvrsavanje skripte. Trebalo bi da to uvijek bude prva linija u skripti. Skriptu mozemo izvrsiti na nekoliko nacin: 1. `$ bash hello.sh` - Na ovaj nacin izvrsavamo skriptu koristeci Bash shell program tako sto smo proslijedili naziv skripte kao argument komandi `bash`. 2. `$ ./hello.sh` - Na ovaj nacin izvrsavamo skriptu koristeci Bash shell program tako sto smo proslijedili naziv skripte kao argument komandi `./`. Ova komanda ce pokrenuti skriptu ako je fajl izvrsiv. Ako fajl nije izvrsiv, dobijamo gresku `Permission denied`. Da bi fajl bio izvrsiv, potrebno je da mu dodamo prava za izvrsavanje. To mozemo uraditi sa komandom `chmod +x hello.sh`. Nakon toga mozemo izvrsiti skriptu sa komandom `./hello.sh`. `./` - U UNIX sistemima, "./" predstavlja relativnu putanju do trenutnog direktorija u kojem se nalazimo u shell-u. "." predstavlja trenutni direktorij, a "/" predstavlja putanju. Kada se koristi `./` zajedno sa nazivom izvrsnog fajla (npr. "./hello.sh"), to znaci da se taj fajl pokrece iz trenutnog direktorija. Ovo je korisno kada se nalazimo u direktoriju u kojem se nalazi izvrsni fajl, jer nam omogucava da pokrenemo fajl bez potrebe za kucanjem pune putanje do fajla. ### Kompajler vs Interpreter * **Kompajler** - Kompajler je program koji prevede izvorni kod u izvrsni fajl. Programski jezici koji koriste kompajler (C, C++, Java ...) za izradu izvrsnog fajla. * **Interpreter** - Interpreter je program koji u toku izvrsavanja prevodi jednu po jednu naredbu. Shell je zasnovan na interpreteru, svaka linija programa odnosno skripte je usnos u shell. Linije shell skripte se izvrsavaju jedna po jedna sekvencijalno. Cak i ako druga linija skripte ima gresku, shell interpreter ce izvrsiti prvu liniju. ### Environment Variables **Environment variables** su varijable (promijenjive vrijednosti) koje su definisane u operativnom sistemu i dostupne su svim procesima koji se pokrecu u tom okruzenju. One sadrze informacije koje se koriste za postavljanje okruzenja za procese koji se pokrecu u operativnom sistemu, kao sto su putanje do direktorija, sistemski parametri, konfiguracijske postavke i druge informacije koje su potrebne da bi se programi izvrsavali ispravno. Environment variables su u osnovi nazivi koji su povezani sa odredjenim vrijednostima. Na primjer, `PATH` je environment variable koja sadrzi putanje do direktorija u kojima se nalaze izvrsni fajlovi, a `HOME` je environment variable koja sadrzi putanju do korisnickog direktorija (home folder-a). Environment variables se mogu definisati i mijenjati na razlicite nacine, ovisno o operativnom sistemu. U Unix sistemima se najcesce koristi `export` komanda kako bi se kreirale ili modifikovale environment variables. Programi koji se izvrsavaju u **UNIX** okruzenju mogu koristiti environment variables da bi pristupili informacijama o okruzenju u kojem se pokrecu. Na primjer, programi koji se koriste u skriptama mogu koristiti environment variables kako bi pristupili informacijama o putanjama do direktorija ili drugim informacijama koje su neophodne da bi se programi izvrsili ispravno. #### **PATH environment variable** **PATH** je jedna od najvaznijih environment varijabli na UNIX sistemima. Ona definise putanje direktorija u kojima se operativni sistem trazi izvrsne (executable) fajlove kad izvrsavate komande u shell-u. Kada korisnik unese neku komandu u shell, operativni sistem trazi tu komandu u nizu direktorija definisanim u `PATH` varijabli, pocevsi od prvog direktorija u nizu, sve dok ne pronadje trazeni fajl. Ako se fajl ne pronadje u nijednom direktoriju u PATH-u, operativni sistem ce prijaviti gresku i prikazati poruku o gresci. Standardne putanje koje su definisane unutar environment varijable `PATH` obicno ukljucuju direktorije poput `/usr/bin`, `/bin` i `/usr/local/bin`. Kada korisnik unese neku komandu, npr. `ls`, OS ce pretraziti direktorije navedene u `PATH` putanji unutar kojih ce traziti izvrsni (executable) fajl komande `ls`. Ako se izvrsni fajl za komandu `ls` nalazi u jednom od tih direktorija komanda `ls` ce biti uspjesno izvrsena. ```bash $ which ls # which je komanda koja nam pokazuje putanju do izvrsnog fajla alias ls='ls --color=auto' /usr/bin/ls #putanja na kojoj se nalazi ls executable fajl $ echo $PATH /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/centos/.local/bin:/home/centos/bin # Vidimo da je putanja /usr/bin/ fajla u PATH-u i da ce se ls komanda moze uspjesno izvrsiti ``` Putanje u PATH-u na UNIX sistemima su odvojene dvotackom `:`. Korisnici mogu mijenjati `PATH` varijablu kako bi dodali nove direktorije u nju, omogucavajuci im da pokrenu programe koji se nalaze u drugim direktorijima osim standardnih direktorija. To se moze uraditi dodavanjem novih direktorija u `PATH` putem komandne linije odnosno terminala ili putem konfiguracijskih fajlova za `shell`, kao sto je `.bashrc` ### Snimci predavanja #### DevOps Mentorship Program - Week 3 - Bash/Shell Scripting ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} #### DevOps Mentorship Program - Week 3 - Bash/Shell Scripting ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} ### Materijali za ucenje * [Linux Command Line and Shell Scripting Bible, 3nd Edition](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/books/linux_command_line_and_shell_scripting_bible_3rd_edition.pdf) ### Korisni alati ### Zadatak ### Materijali za dodatno citanje # Week-4: Racunarske mreze i Web aplikacije **Racunarske mreze** su skup povezanih racunara i drugih uredjaja koji su medjusobno povezani radi razmjene informacija i resursa. Ove mreze omogucuju racunarima da komuniciraju i razmjenjuju podatke jedni s drugima putem zicanih ili bezicnih veza. Postoji nekoliko razlicitih vrsta racunarskih mreza, ukljucujuci lokalne mreze (LAN), mreze sireg podrucja (WAN), virtualne privatne mreze (VPN) itd. Internet je racunarska mreza koja povezuje milione racunarskih uredjaja sirom svijeta.

Racimarske mreze - Interent

### OSI Model Medjunarodna organizacija za standardizaciju je krajem 70tih godina predlozila organizaciju racunarskih mreza u sedam slojeva. Takva arhitektura mreza dobila je naziv model otvorenog sistem za medjusobno povezivanje (Eng. Open System Interconnection - OSI).

OSI Model

* Aplikativni sloj * Prezentacijski sloj * Sloj sesije * Transportni sloj * Mrezni sloj * Sloj veze * Fizicki sloj

OSI Model

\*Tabela i Slika su preuzeti sa stranice [Layers of OSI Model](https://www.geeksforgeeks.org/layers-of-osi-model/) #### Aplikativni sloj Na aplikativnom sloju nalaze se mrezne aplikacije i njihovi protokoli aplikativnog sloja. Aplikativnom sloju pripadaju protokoli kao sto su `HTTP`, `SMTP`, `FTP`. Odredjene mrezne funkcionalnosti kao sto je npr: `DNS translacija` takodjer se obavljaju na aplikativnom sloju. #### Prezentacijski sloj Uloga prezentacijskog sloja je da aplikacijama koje medjusobno komuniciraju, razmijenjuju podatke, obezbjedi usluge koje omogucavaju tumacenje znacenja ramzmijenjenih podataka. #### Sloj sesije Sloj sesije obezbjedjuje razgranicavanje i sinhronizovanje razmjene podatka ukljucujuci i nacin za stvaranje tacke za oporavak u slucaju greske. Takodjer omogucava i seme za oporavak podataka. #### Transportni sloj Transportni sloj prenosi poruke aplikativnog sloja izmedju krajnjih tacaka aplikacije. Protokoli transportnog sloja su `TCP` i `UDP`. `TCP` protokol aplikacijama koje ga koriste nudi uslugu za uspostavljanjem veze. Ova usluga podrazumjeva garantovanu isporuku poruka aplikativnog sloja do odredista i kontrolu toka. Za razliku od `TCP` protokola, `UDP` protokol aplikacijama koje ga koriste nudi uslugu bez uspostavljanja veze sto ga cini manje pouzdanim jer nema kontrolu toka i kontrolu zagusenja. #### Mrezni sloj Mrezni sloj odgovoran je za prenosenje paketa mreznog sloja poznatih kao `datagrami` od jednog racunara do drugog. **Datagrami** su osnovna jedinica za prenos podataka u mrezama koje koriste paketno prenosenje podataka. Datagrami su obicno sastavljeni od zaglavlja (header) i korisnih podataka (payload). Zaglavlje sadrzi informacije o adresama odredista i izvora, kao i druge kontrole informacija koje su potrebne za uspjesan prijenos podataka. Payload sadrzi stvarne podatke koji se prenose preko mreze. Protokol transportnog sloja u izvornom racunaru prosljedjuje paket (odnosno segment) transportnog sloja i odredisnu mreznu adresu. **Mrezni sloj je taj koji obezbjedjuje isporuku paketa do transportnog sloja na odredisnom racunaru.** **IP protokol** pripada mreznom sloju. Mrezni sloj takodjer obuhvata protokole za rutiranje. #### Sloj veze Mrezni sloj usmjerava datagrame kroz niz rutera izmedju izvora i odredista. Za prenosenje paketa od jednog covera (racunara ili rutera) do sljedeceg, mrezni sloj se oslanja na usluge sloja veze. Primjeri protokola sloja veze su `ethernet`, `wifi` kao i protokoli koji se koriste za kablovske pristupne mreze. #### Fizicki sloj Zadatak fizickog sloja jeste prenosenje pojedinacnih bitova iz istog paketa prosljedjenog od strane sloja veze izmedju susjednih cvorova. Protokoli na ovom sloju zavise od vrste linka ali i medija uz pomoc kojeg je taj link ostvaren (opticka vlakna, bakrene parice i sl.) ### Protokoli Mrezni protokol slican je pravilu ponasanja medju ljudima. **Svime sto se desava na internetu a obuhvata komunikaciju dva udaljena samostalna dijela ili vise njih upravlja neki protokol.** Protokol definise format poruke i redoslijed po kojem se ta poruka razmijenjuje izmedju najmenje dvije zasebne cjeline koje medjusobno komuniciraju, kao i postupke koji se preduzimaju poslije slanja i/ili prijema odredjenih poruka ili nekog drugog dogadjaja. Internet kao i sve druge racunarske mreze koriste protokole, prilikom komunikacije za ispunjavanje razlicitih zadataka koriste se razliciti protokoli. Svaki od protokola pripada jednom od slojeva **OSI modela**. Protokol na nekom sloju moze da se sprovodi kako u softveru tako i u hardveru, ali i uporedo. Protokoli aplikativnog sloja (`HTTP`, `SMTP`) skoro uvijek se sprovode u softveru krajnjih sistema. Isti je slucaj i sa protokolima transportnog sloja. Posto su fizicki sloj i sloj veze podataka odgovorni za komunikaciju preko odredjenog linka, protokoli na njima obicno se sporovode u mreznoj kartici koja je povezana sa datim linkom. Protokoli na mreznom sloju obicno se istovremeno sprovode i u softveru i u hardveru. Svi protokoli zajedno nazivaju se skup protokola. ### IPv4 Adresiranje Racunar obicno ima samo jedan link prema mrezi: **kada IP adresa u tom racunaru zeli da posalje datagram (paket mreznog sloja) ona to radi preko tog linka.** Granica izmedju racunara i fizickog linka naziva se `interfejs`. Posto je zadatak rutera da primi datagram sa jednog linka i proslijedi ga na drugi link, ruter obavezno mora da bude povezan sa najmanje dva linka. Granica izmedju rutera i bilo kojeg od njegovih linkova takodjer se naziva `interfejs`. **U skladu s tim ruter ima vise interfejsa, po jedan za svaki link**. Posto svi racunari i ruteri mogu da primaju i salju `IP datagrame`, `IP` protokola zahtijeva da svi interfejsi racunara i rutera imaju vlastitu `IP adresu`. `IP adresa` je tehnicki pridruzena interfejsu a ne racunaru ili ruteru na kome se nalazi taj intefejs. **Svaka IP adresa dugacka je 32 bita.** IP adrese se obicno pisu u decimalnoj notaciji sa tackama u kojoj se svaki bajt adrese zapisuje u decimalnom obliku a od ostalih bajtova u adresi razdvaja se tackom. Uzmimo za primjer IP adresu `193.32.216.9` Broj `193` je vrijednost prvih `osam bitova` u adresi. Prevedeno u binarni oblik, IP adresa `193.32.216.9` bi izgledalo ovako: ```bash 193 . 32 . 216 . 9 11000001 00100000 11011000 00001001 ``` Svaki interfejs na svim racunarima i na ruterima mora da ima `IP adresu` koja je globalno jedinstvena osim interfejsa ispred kojih se koristi `NAT - Network Address Translator` odnosno prevodjenje adresa. Adrese **ne mogu** da se biraju nasumicno. **Dio IP adrese interfejsa odredjuje podmreza sa kojom je povezan.** U IP zargonu, mreza koja povezuje tri racunara i interfejse rutera predstavlja **podmrezu (subnet).** Podmreza se u literaturi naziva IP mreza ili samo mreza. **Subnet Mask - MASKA PODMREZE** (npr: `/24`) znaci da 24 krajnja lijeva bita 32-bitne vrijednosti IP adrese predstavljaju adresu podmreze. Strategija dodjeljivanja adresa na interentu poznata je kao besklasno rutiranje izmedju domena **Classless Internetdomain Routing - CIDR**( cider blok). `a.b.c.d / X` `(a.b.c.d/24)` `X` oznacava broj bitova u prvom dijelu adrese koji oznacavaju **MREZNI DIO IP ADRESE**, preostali biti su namjenjeni hostovim odnosno uredjajima unutar te podmreze. **Ruteri** izvan ove organizacije sa kojim komunicira ova mreza u obzir uzimaju samo adresu podmreze odnosno mrezni prefix adrese. Ovo doprinosi smanjenu velicine ruting tabela, gdje ostale mreze sa kojima ova mreza komunicira ne moraju da znaju za ostale adrese unutar mreze, cesto i vise manjih podmreza unutar nje. Mogucnost da se korisiti jedan prefiks za predstavljanje vise mreza cesto se naziva agregacija adresa. Preostali `biti` unutar `IP adrese` odnose se na `hostove` i na osnovu njih se pravi razlika izmedju uredjaja unutar iste podmreze gdje svi ti hostovi imaju isti `mrezni prefix` odnosno istu `adresu podmreze`. `255.255.255.255` - IP Adresa za difuzno emitovanje. Kada racunar posalje `datagram` sa adresom odredista `255.255.255.255` ta se poruka isporucuje svim racunarima unutar iste podmreze. **Prije nego je usvojena CIDR sema, mrezni dio IP adrese morao je da bude duzine 8 bitova, 16 bitova ili 24 bita u semi poznatoj kao puno klasno adresiranje (classful addresing) jer su podmreze sa adresama od 8 bitova, 16 bitova i 24 bita bila poznate kao mreze klase A, B i C.** * **Class A:** `10.0.0.0` to `10.255.255.255` * **Class B:** `172.16.0.0` to `172.31.255.255` * **Class C:** `192.168.0.0` to `192.168.255.255` **Sve adrese koje pripadaju ovim klasama su privatne adrese i smatraju se non routable adresama.** Sve adrese koje **ne pripadaju** nijednoj od ovih klasa su **javne adrese** / `PUBLIC IP` address. Podmreza kalse C - `/24` je na osnovu toga mogla da obuhvati samo `2^8 - 2 = 254` racunara sto je premalo. Podklasa mreze B - `/16` koja obuhvata `65634` adrese bila je prevelika za vecinu organizacija, sto je vodilo do lose iskoristenosti adresnog prostora klase B. IP v4 adrese su ogranicene na 4.294.967.296 adrese. #### Specijalne IP adrese Postoji nekoliko IPv4 adresa koje se koriste za posebne svrhe. Ove adrese se ne mogu koristiti za komunikaciju izmedju uredjaja na internetu.

IPv4 Specijalne IP adrese

#### IPv6 **IPv6 (Internet Protocol version 6)** adresiranje je nasljednik IPv4 protokola. IPv6 koristi 128-bitne adrese, sto je znatno vise od IPv4 protokola koji koristi 32-bitne adrese. To znaci da IPv6 moze podrzati znatno veci broj mreznih uredjaja i povezanih uredjaja u poredjenju s IPv4. IPv6 adrese se sastoje od 8 blokova koji se odvajaju sa dvije tacke. Svaki blok je zapisan sa 4 heksadecimalne znamenke, sto znaci da svaki blok ima vrijednost izmedju `0` i `FFFF`. Na primjer, IPv6 adresa moze izgledati ovako: `2001:0db8:85a3:0000:0000:8a2e:0370:7334`. Jedna od glavnih prednosti IPv6 protokola je veca sigurnost, jer IPv6 ukljucuje ugradjenu enkripciju i autentifikaciju koja stiti od napada na mreznu sigurnost. Takodjer, IPv6 adresiranje omogucuje jednostavnije upravljanje mrezom i vecu ucinkovitost u usporedbi s IPv4, jer se ne moraju koristiti razni trikovi poput NAT-a (Network Address Translation) kako bi se omogucilo povezivanje velikog broja uredjaja na internet. IPv6 adrese su velicine 128 bita i mogu da obuhvate `340.282.366.920.938.463.463.374.607.431.768.211.456` adresa. ### Web aplikacije Web aplikacija ima dva nezavisna udaljena programa odnosno procesa koji komuniciraju jedan sa drugim preko mreze. * browser (klijent / klijentski program / client) * web server (server / serverski program / server) **U Klijent-Server arhitekturi** postoji uvijek dostupan racunar odnosno server, cije usluge trazi vise drugih racunara koji se nazivaju klijenti. Kada od racunara klijenta stigne zahtjev za uslugom, web server na racunaru servera obradjuje zahtjev i vraca klijentu odgovor. Klijenti ne komuniciraju neposredno jedan sa drugim. Takodjer bitno je napomenuti da server ima stalnu IP adresu (ili domensko ime preko kojeg je dostupan). U okviru komunikacione sesije izmedju dva procesa, proces koji inicira komunikaciju, tj. prvi kontaktira proces na pocetku sesije oznacava se kao **klijent**. Proces koji ceka na poziv da bi uspostavio komunikaciju oznacava se kao **server**. Sve poruke poslate od jednog procesa do drugog moraju da prodju kroz mrezu izmedju njih. Procesi salju poruke u mrezu i primaju poruke iz mreze preko softverskog interfejsa koji se zove `socket`.
Na internetu se racunar identifikuje svojom IP adresom, pored toga sto zna adresu racunara kome je poruka namjenjena, predajni proces mora takodjer da identifikuje prijemni proces (tacnije prijemni soket) koji se izvrsava na tom racunaru za sta se koristi odredisni broj **porta**. ### TCP Protokol **TCP (Transmission Control Protocol)** je jedan od osnovnih protokola na Internetu koji se koristi za uspostavljanje pouzdane veze izmedju uredjaja (npr. racunala, mobilnih uredjaja) putem mreze. TCP je odgovoran za sigurnu i pouzdanu isporuku podataka izmedju racunala preko mreze, a glavne znacajke TCP-a ukljucuju: 1. Pouzdana isporuka: TCP je dizajniran tako da osigura da se svi podaci isporucuju u pravom redoslijedu i da se svi podaci isporucuju bez gubitka ili dupliranja. Ovo je postignuto koristenjem razlicitih mehanizama poput potvrdjivanja (acknowledgments), ponovnog slanja (retransmission) i prozora (window) za kontrolu protoka. 2. Trosak: TCP odrzava razumnu kontrolu protoka kako bi se izbjegao zagusenje mreze i smanjio broj ponovnog slanja podataka. 3. Uspostava i prekidanje veze: TCP koristi trostepeni proces za uspostavu veze izmedju dvije strane, nakon cega se podaci mogu prenositi u oba smjera. Takodjer ima mehanizme za prekidanje veze kada je prijenos podataka zavrsen. 4. Pouzdanost: TCP provjerava integritet podataka kako bi se osiguralo da se preneseni podaci nisu promijenili ili ostetili tijekom prijenosa. 5. Poredak: TCP osigurava da se podaci isporucuju u pravom redoslijedu. **TCP 3-Way Handshake Process** - Trostepeni proces za uspostavu veze izmedju dva racunala preko TCP-a sastoji se od: * SYN * SYN/ACK
* ACK
**Korak 1:** Sinhronizacija (SYN) - U ovom koraku klijent salje SYN paket posluzitelju kako bi inicirao uspostavu veze. SYN paket sadrzi vrijednost pocetnog broja (Initial Sequence Number - ISN), koja se koristi za identifikaciju pocetne pozicije podataka u sekvencijskom broju, i zatvaracki broj (window size), koji se koristi za kontrolu protoka podataka. Nakon sto posluzitelj primi SYN paket, on salje odgovor u koraku 2. **Korak 2:** Potvrda (ACK i SYN) - U ovom koraku posluzitelj prima SYN paket od klijenta i salje ACK paket klijentu, potvrdjujuci da je primio SYN paket. ACK paket takodjer sadrzi vrijednost sekvencijskog broja koja je jednaka vrijednosti pocetnog broja klijenta povecana za jedan, sto oznacava sljedeci ocekivani broj koji ce klijent slati posluzitelju. Uz ACK paket, posluzitelj takodjer salje SYN paket klijentu kako bi inicirao uspostavu veze sa svoje strane. SYN paket od posluzitelja sadrzi vrijednosti pocetnog broja i zatvarackog broja koji su potrebni za uspostavu veze. **Korak 3:** Potvrda (ACK) - U ovom koraku klijent prima SYN paket od posluzitelja i salje ACK paket posluzitelju kako bi potvrdio da je primio SYN paket. ACK paket od klijenta sadrzi vrijednost sekvencijskog broja koja je jednaka vrijednosti pocetnog broja posluzitelja povecana za jedan, sto oznacava sljedeci ocekivani broj koji ce posluzitelj slati klijentu. Nakon sto su ti koraci izvrseni, veza izmedju klijenta i posluzitelja je uspostavljena i oba racunala su spremna za razmjenu podataka. Vazno je napomenuti da se isti trostepeni proces koristi za uspostavu veze u oba smjera, tako da je proces izvrsen u oba smjera prije nego sto zapocne razmjena podataka ### **HTTP Protokol** **HTTP (Hypertext Transfer Protocol)** je protokol kojim se komunicira izmedju klijenta i posluzitelja na webu. HTTP je protokol na aplikacijskom sloju, sto znaci da radi iznad protokola na nizim slojevima, poput TCP-a ili UDP-a, kako bi se omogucila komunikacija izmedju aplikacija. HTTP koristi TXP kao svoj osnovni transportni protokol. HTTP prvo uspostavlja TCP vezu izmedju klijenta i posluzitelja, a zatim se podaci prenose putem TCP veze. HTTP koristi model zahtjev-odgovor (request-response model), gdje klijent salje zahtjev za odredjenim resursom na posluzitelju, a posluzitelj salje odgovor koji sadrzi trazene informacije. Zahtjev i odgovor sastoje se od headera i tijela. Header sadrzi metodu zahtjeva, URL zahtjevanog resursa, verziju protokola, moguce opcije, kao i druge metapodatke. Tijelo sadrzi podatke koji se prenose putem HTTP-a, poput HTML koda, slike ili drugih vrsta datoteka. HTTP metode zahtjeva ukljucuju GET, POST, PUT, DELETE, HEAD, OPTIONS i TRACE, a svaka metoda ima svoju specificnu svrhu. Primjerice, GET metoda se koristi za preuzimanje resursa sa servera, POST metoda se koristi za slanje podataka na server, PUT metoda se koristi za azuriranje postojeceg resursa, a DELETE metoda se koristi za brisanje resursa sa servera. HTTP koristi cookie-je (kolacice) kako bi omogucio pohranjivanje informacija izmedju vise zahtjeva. Cookie-ji se koriste za pohranu korisnickih postavki, poput autentifikacijskih tokena, sto korisnicima omogucuje da se prijavljuju bez potrebe za svakim unosom podataka za prijavu. Uz to, HTTP takodjer podrzava SSL (Secure Sockets Layer) i TLS (Transport Layer Security) protokole kako bi osigurao sigurnu komunikaciju putem interneta. Sigurna komunikacija se postize koristenjem kriptografije, sto stiti od prisluskivanja i manipulacije podacima. Ukratko, HTTP je protokol kojim se omogucava komunikacija izmedju klijenta i posluzitelja na webu. HTTP koristi model zahtjev-odgovor, podrzava razlicite metode zahtjeva, koristi cookie-je za pohranu informacija izmedju zahtjeva i osigurava sigurnu komunikaciju putem interneta. ### **Cookies** Kada korisnik zapocne sesiju na eBay web stranici, server ce mu poslati kolacic koji ce sadrzavati jedinstveni identifikator sesije. Taj identifikator ce biti koristen za identifikaciju korisnika u buducim zahtjevima koje korisnik salje na server. Takodjer, kolacici se koriste za pohranjivanje postavki i preferencija korisnika, kao sto su preferirani jezik ili valuta. Kada korisnik zatrazi neku stranicu na eBay web stranici, kolacici ce se poslati na server zajedno sa zahtjevom. Na taj nacin, server ce biti u mogucnosti prepoznati korisnika i pruziti mu personalizirano iskustvo na web stranici. Takodjer, kolacici se koriste za pracenje aktivnosti korisnika na web stranici. Na primjer, eBay moze koristiti kolacice za pracenje koje su proizvode korisnici pregledali ili stavili u kosaricu za kupnju. Ove informacije se mogu koristiti za personaliziranje ponuda ili marketinskih poruka koje ce korisnik vidjeti na web stranici.
### **HTTP metode** **GET** - Ova metoda se koristi za preuzimanje resursa sa servera. Primjerice, ako zelite preuzeti odredjenu web stranicu, mozete koristiti GET metodu kako biste zatrazili stranicu s posluzitelja. Primjer zahtjeva koji koristi GET metodu: ```bash GET /index.html HTTP/1.1 Host: devops-mentorship-program.com ``` **POST** - Ova metoda se koristi za slanje podataka na server. Primjerice, ako zelite poslati podatke s obrasca na server, mozete koristiti POST metodu kako biste poslali podatke na server. Primjer zahtjeva koji koristi POST metodu: ``` POST /login HTTP/1.1 Host: www.example.com Content-Type: application/x-www-form-urlencoded username=john&password=secret ``` Ovaj primjer salje podatke za prijavu (korisnicko ime i lozinku) na server putem URL-kodiranih parametara. **PUT** - Ova metoda se koristi za azuriranje postojeceg resursa na serveru. Primjerice, ako zelite azurirati odredjeni dokument na serveru, mozete koristiti PUT metodu kako biste azurirali taj dokument. Primjer zahtjeva koji koristi PUT metodu: ``` PUT /document.doc HTTP/1.1 Host: www.example.com Content-Type: application/msword ... sadrzaj dokumenta ... ``` Ovaj primjer azurira postojeci dokument.doc s novim sadrzajem. **DELETE** - Ova metoda se koristi za brisanje resursa sa servera. Primjerice, ako zelite izbrisati odredjeni dokument sa servera, mozete koristiti DELETE metodu kako biste izbrisali taj dokument. Primjer zahtjeva koji koristi DELETE metodu: ``` DELETE /file.txt HTTP/1.1 Host: www.example.com ``` Ovaj primjer brise datoteku.txt s posluzitelja. ### **HTTP Poruke** HTTP poruka se sastoji od tri dijela: pocetne linije (engl. start line), zaglavlja (engl. headers) i tijela (engl. body). Format HTTP poruke je strogo definiran i slijedi odredjena pravila. Pocetna linija (start line) se sastoji od tri dijela: HTTP metode, URI i verzije HTTP protokola. Primjer pocetne linije za GET zahtjev za web stranicu `https://example.com/page.html` u verziji HTTP/1.1 bi bio: ```bash GET /page.html HTTP/1.1 ``` Zaglavlje (headers) dolazi nakon pocetne linije i sadrzi razne informacije o zahtjevu ili odgovoru. Zaglavlje se sastoji od polja (engl. fields) koja su organizirana u obliku kljuc-vrijednost parova. Svako polje se navodi u zasebnom redu i sastoji se od naziva polja i vrijednosti, odvojenih dvotackom. Primjer zaglavlja bi bio: ```bash Host: example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 ``` Tijelo (body) dolazi nakon zaglavlja i sadrzi podatke koji se salju u zahtjevu ili odgovoru. Tijelo je opcionalno i moze biti prazno. Primjer tijela bi bio: ```bash username=john&password=secret ``` Ukoliko se radi o HTTP odgovoru, pocetna linija ce sadrzavati statusni kod koji govori o uspjesnosti obrade zahtjeva. Primjer pocetne linije za HTTP odgovor sa statusnim kodom 200 (OK) bi bio: ``` HTTP/1.1 200 OK ``` ### **HTTP Odgovori na poruke / Response Status Codes** HTTP kodovi su 3-znamenkasti kodovi koje server salje u odgovoru na zahtjev klijenta kako bi oznacio status odgovora. Ovdje su neki osnovni HTTP kodovi i njihovo znacenje: * `200 OK`: Server je uspjesno obradio zahtjev i vratio ocekivani sadrzaj. * `201 Created`: Server je uspjesno stvorio novi resurs u skladu s zahtjevom klijenta. * `204 No Content`: Server je uspjesno obradio zahtjev, ali nema sadrzaja koji bi se vratio kao odgovor. * `301 Moved Permanently`: Resurs koji je trazen je trajno premjesten na drugu lokaciju. Klijent treba koristiti novu adresu za daljnje zahtjeve prema tom resursu. * `400 Bad Request`: Server nije uspio razumjeti zahtjev klijenta zbog pogresne sintakse ili nepotpunih podataka. * `401 Unauthorized`: Klijent nije uspio autentificirati se prema serveru, odnosno nije poslao ispravne informacije za prijavu (npr. korisnicko ime i lozinka). * `403 Forbidden`: Server je razumio zahtjev, ali ne dopusta pristup resursu zahtjevanom klijentu. * `404 Not Found`: Server nije uspio pronaci trazeni resurs. * `500 Internal Server Error`: Server je dozivio interno neplanirano ponasanje, sto je dovelo do pogreske u obradi zahtjeva. * `503 Service Unavailable`: Server trenutno nije dostupan i ne moze obraditi zahtjev klijenta. Postoji mnogo drugih HTTP kodova koji se koriste za razlicite scenarije. Razumijevanje ovih kodova moze pomoci klijentu da shvati sto se dogodilo s njihovim zahtjevom i serveru kako bi mogao reagirati na odredjene zahtjeve i situacije. ### HTTP Zaglavlja / Headers HTTP zaglavlje (engl. headers) je dio HTTP poruke koji se sastoji od polja koja prenose dodatne informacije o zahtjevu ili odgovoru. Zaglavlje je formatirano kao niz linija, pri cemu svaka linija predstavlja jedno polje. Svaki redak zaglavlja sadrzi naziv polja, dvotocku i vrijednost polja, odvojene razmakom. Primjer zaglavlja za zahtjev moze biti sljedeci: ``` GET /index.html HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0 Accept-Language: en-US,en;q=0.5 ``` Ovaj primjer zaglavlja za zahtjev sadrzi sljedece polja: * Metoda (GET) i URI (/index.html) su dio pocetne linije HTTP poruke. * Host: specifikacija servera s kojim korisnik komunicira. * User-Agent: informacija o pregledniku ili softveru koji korisnik koristi za pristup resursu. * Accept-Language: informacija o prihvatljivim jezicima koje korisnik preferira. Primjer zaglavlja za odgovor moze biti sljedeci: ``` HTTP/1.1 200 OK Date: Mon, 10 Jun 2019 13:57:30 GMT Server: Apache/2.2.22 (Debian) Last-Modified: Tue, 23 Apr 2019 09:23:22 GMT ETag: "abcde-7890-5a8b7c6d" Content-Length: 16384 Content-Type: text/html; charset=UTF-8 ``` Ovaj primjer zaglavlja za odgovor sadrzi sljedeca polja: * Statusni kod (200 OK) je dio pocetne linije HTTP poruke. * Date: datum i vrijeme kada je odgovor poslan. * Server: naziv servera koji je odgovorio na zahtjev. * Last-Modified: datum kada je resurs posljednji puta modificiran. * ETag: identifikator entiteta (engl. entity tag) koji predstavlja verziju resursa. * Content-Length: velicina tijela HTTP odgovora u bajtovima. * Content-Type: vrsta medija (engl. media type) koja se prenosi kao tijelo HTTP odgovora, ovdje je to tekstualni HTML dokument s kodnom stranicom UTF-8. Uz ova polja, u zaglavlju HTTP poruke se mogu nalaziti i druga polja koja se koriste za razlicite svrhe, kao sto su autentifikacija, kolacici (engl. cookies), cache kontrola i druge. ### SSL/TLS **SSL (Secure Sockets Layer)** je kriptografski protokol koji se koristi za sigurnu komunikaciju izmedju racunara preko interneta. SSL se sastoji od dva sloja: * protokola za upravljanje sigurnoscu i * protokola za prijenos podataka. SSL omogucuje kripotovanje podataka koji se prenose preko interneta, sto znaci da su podaci zasticeni od neovlastenog pristupa i manipulacije. Osim toga, SSL omogucuje provjeru identiteta web servera s kojim se korisnik povezuje, kako bi se sprijecilo da se podaci salju na lazni ili zlonamjerni server. SSL certifikati su digitalni certifikati koji se koriste za autentifikaciju web servera i kriptiranje podataka koji se prenose izmedju korisnika i servera. Certifikati se izdaju od strane pouzdanih tijela za izdavanje certifikata (engl. Certificate Authorities) koja provjeravaju identitet vlasnika certifikata i izdaju digitalni potpis koji se koristi za autentifikaciju. Kada korisnik pristupi web stranici koja koristi SSL, preglednik i web server uspostavljaju sigurnu vezu koja se naziva SSL sesija. Tijekom ove sesije, podaci se kriptiraju i dekriptiraju kako bi se osigurala sigurnost podataka. Preglednik prikazuje simbol zakljucanog lokota u traci adrese kako bi korisnik znao da se koristi SSL i da su podaci sigurni. SSL je prethodnik protokola TLS (Transport Layer Security), koji je danas siroko koristen protokol za sigurnu komunikaciju izmedju racunala preko interneta. **TLS (Transport Layer Security)** je kriptografski protokol koji se koristi za sigurnu komunikaciju izmedju racunala preko interneta. TLS se koristi za zastitu razlicitih protokola koji se koriste za prijenos podataka, kao sto su HTTP, SMTP, FTP itd. TLS radi u tri glavna koraka: 1. Dogovor o parametrima kriptiranja: Klijent i server se dogovaraju o parametrima kriptiranja, ukljucujuci vrstu kriptografskog algoritma i duljinu kljuca. 2. Razmjena kljuceva: Klijent i server razmjenjuju javne kljuceve kako bi se osigurala sigurna komunikacija. Klijent generira jedinstveni kljuc za tu sesiju i salje ga serveru koji ga zatim koristi za kriptiranje podataka. 3. Autentifikacija: TLS koristi certifikate kako bi se osigurala autenticnost servera s kojim se klijent povezuje. Server salje svoj certifikat klijentu kako bi se klijent uvjerio da se povezuje s pravim serverom. TLS takodjer podrzava razne sigurnosne mehanizme kao sto su provjera integriteta podataka, provjera autenticnosti klijenta i zastita od ponovnog reproduciranja (engl. replay attack).
TLS handshake process je proces kojim se klijent i server dogovaraju o parametrima sigurne veze prije nego sto zapocnu prijenos podataka. U ovom procesu, klijent i server razmjenjuju informacije o algoritmima kriptiranja i autentifikaciji, te se dogovaraju oko kljuceva koji ce se koristiti za kriptiranje podataka. TLS handshake proces se sastoji od sljedecih koraka: 1. `Client Hello:` Klijent zapocinje TLS handshake slanjem Client Hello poruke serveru. Ova poruka sadrzi informacije o verziji TLS protokola koja se koristi, popis kriptografskih algoritama koje klijent podrzava i nasumicno generirani broj koji se koristi za stvaranje kasnije dogovorenog kljuca. 2. `Server Hello:` Nakon sto server primi Client Hello, server salje Server Hello poruku klijentu. Ova poruka sadrzi informacije o TLS verziji koju ce koristiti, izboru kriptografskih algoritama i nasumicno generirani broj koji ce se koristiti za dogovor o kljucu. 3. `Certificate:` Server salje svoj certifikat klijentu, koji sadrzi javni kljuc koji ce klijent kasnije koristiti za enkripciju podataka koje salje serveru. 4. `Server Key Exchange:` Ako je odabran Diffie-Hellman (DH) kriptografski algoritam, server salje svoj DH javni kljuc klijentu. Klijent tada generira svoj DH javni kljuc i salje ga serveru. 5. `Client Key Exchange:` Klijent salje serveru javni kljuc koji se koristi za stvaranje zajednickog tajnog kljuca. 6. `Certificate Verify:` Klijent potvrdjuje valjanost certifikata servera, koristeci javni kljuc iz certifikata. 7. `Change Cipher Spec:` Klijent i server se dogovaraju o tome koji ce kriptografski algoritam koristiti i prelaze na taj algoritam. 8. `Finished:` Nakon sto su klijent i server dogovorili parametre sigurne veze, oba uredjaja salju Finished poruke jedan drugome. Ove poruke sluze za potvrdu da je TLS handshake proces uspjesno zavrsen i da su klijent i server sada spremni za sigurnu komunikaciju. Nakon uspjesno zavrsenog TLS handshake procesa, klijent i server koriste zajednicki tajni kljuc za kriptiranje i dekriptiranje podataka koji se prenose izmedju njih. TLS handshake proces se ponavlja za svaku novu sesiju komunikacije izmedju klijenta i servera kako bi se osigurala sigurna i privatna komunikacija. #### HTTPS **HTTPS (Hypertext Transfer Protocol Secure)** je sigurna verzija HTTP protokola koja se koristi za enkripciju podataka koji se razmjenjuju izmedju web preglednika i web servera. HTTPS koristi SSL/TLS protokol za zastitu privatnosti podataka korisnika, osiguravajuci da se informacije ne mogu neovlasteno citati, mijenjati ili krivotvoriti. Kada korisnik pokusa pristupiti HTTPS stranici, web server salje SSL/TLS certifikat pregledniku. Preglednik tada provjerava valjanost certifikata, provjeravajuci identitet web stranice. Nakon sto preglednik potvrdi valjanost certifikata, on koristi javni kljuc koji se nalazi u certifikatu za stvaranje tajnog kljuca koji ce se koristiti za enkripciju podataka. Sve informacije koje se razmjenjuju izmedju preglednika i servera se sifriraju prije slanja, tako da samo preglednik i web server mogu razumjeti sadrzaj podataka. Ovo ukljucuje informacije kao sto su korisnicka imena i lozinke, podaci o kreditnoj kartici i drugi osjetljivi podaci. #### Ostali TCP Protokoli Postoje mnogi popularni TCP protokoli osim HTTP-a i HTTPS-a, neki od njih su: * **FTP (File Transfer Protocol)** - Protokol za prijenos datoteka izmedju racunala. FTP koristi TCP/IP za prijenos podataka izmedju klijenta i servera. * **SSH (Secure Shell)** - Kriptografski siguran protokol za daljinsku administraciju i prijenos datoteka izmedju racunala. SSH koristi TCP/IP za sigurnu komunikaciju izmedju klijenta i servera. * **Telnet** - Protokol za udaljeni pristup racunalu putem mreze. Telnet koristi TCP/IP za prijenos podataka izmedju klijenta i servera. * **POP3** (Post Office Protocol version 3) - Protokol za primanje e-poste preko interneta. POP3 koristi TCP/IP za prijenos poruka izmedju klijenta i servera. * **IMAP** (Internet Message Access Protocol) - Protokol za primanje i upravljanje e-postom na udaljenom serveru. IMAP koristi TCP/IP za prijenos poruka izmedju klijenta i servera. * **LDAP (Lightweight Directory Access Protocol)** - Protokol za pristup i upravljanje direktorijima na mrezi. LDAP koristi TCP/IP za prijenos upita i odgovora izmedju klijenta i servera. ### UDP (User Datagram Protocol) Protokoli UDP (User Datagram Protocol) je protokol na nizem sloju transportnog protokola u OSI (Open Systems Interconnection) modelu. Za razliku od TCP-a, koji pruza pouzdani prijenos podataka, UDP ne pruza garancije o isporuci paketa. UDP paketi se salju putem mreze bez ikakve garancije o tome da li ce paket stici na odrediste, hoce li se zagubiti ili duplicirati. UDP protokol je cesto koristen za aplikacije koje zahtijevaju brz prijenos podataka, ali ne zahtijevaju pouzdanost prijenosa, kao sto su video streaming, online igre i druge interaktivne aplikacije. Buduci da UDP ne ukljucuje mehanizme kao sto su potvrda primitka i ponovno slanje paketa, to ga cini manje pouzdanim, ali brzim i laksim za uporabu. * **DNS (Domain Name System)** - UDP se cesto koristi za DNS jer DNS paketi obicno nisu veliki, a brzina odgovora je kljucna. DNS je odgovoran za mapiranje IP adresa na ljudski citljive imena domena. * **DHCP (Dynamic Host Configuration Protocol)** - DHCP se koristi za automatsku konfiguraciju mreznih postavki, kao sto su IP adrese, podmrezne mreze i zadane mrezne brzine. UDP se koristi za prenosenje DHCP poruka izmedju klijenata i DHCP posluzitelja. * **TFTP (Trivial File Transfer Protocol)** - UDP se cesto koristi za TFTP, protokol koji se koristi za jednostavan prijenos datoteka izmedju racunala u mrezi. TFTP je jednostavan i ogranicen protokol, ali se cesto koristi za firmware i konfiguracijske datoteke. * **SNMP (Simple Network Management Protocol)** - SNMP se koristi za upravljanje mrezama i prikupljanje informacija o mrezama. UDP se cesto koristi za prenosenje SNMP poruka izmedju mreznih uredjaja. * **RIP (Routing Information Protocol)** - UDP se koristi za RIP, protokol za razmjenu informacija o rutiranju izmedju mreznih uredjaja. RIP je jedan od najjednostavnijih protokola za razmjenu informacija o rutiranju, ali nije najucinkovitiji i nije najbolji izbor za velike mreze. * **Syslog** - UDP se cesto koristi za syslog, protokol za prikupljanje i slanje log datoteka sa razlicitih uredjaja u mrezi, kao sto su posluzitelji, mrezni uredjaji i sigurnosni uredjaji. Syslog omogucuje centralizirano upravljanje logovima i olaksava dijagnostiku problema u mrezi. * **NTP (Network Time Protocol)** - UDP se koristi za NTP, protokol za sinkronizaciju vremena izmedju racunala u mrezi. NTP omogucuje racunalima u mrezi da se sinkroniziraju sa zajednickim referentnim vremenom, sto je kljucno za razlicite aplikacije koje se oslanjaju na tocno vrijeme, kao sto su bankarske transakcije ili mjerenje vremena u proizvodnoj liniji. #### Najcesce koristeni TCP i UDP Portovi
### DNS (Domain Name System) DNS (Domain Name System) je strogo hijerarhijski distribuiran sistem koji povezuje ljudski citljiva domenska imene s njihovim pripadajucim IP adresama. DNS je kljucan za funkcioniranje Interneta jer omogucuje korisnicima da pristupe web stranicama, e-posti i drugim uslugama na Internetu pomocu lako pamtljivih imena umjesto slozenih IP adresa. DNS se sastoji od nekoliko komponenti: * **DNS posluzitelji:** Ovo su racunala koja cuvaju bazu podataka DNS-a i odgovaraju na upite koje im salju drugi racunala na Internetu. DNS posluzitelji se mogu podijeliti u tri kategorije: korijenski, autoritativni i posrednicki. * **DNS rekordi:** Ovo su zapisi u bazi podataka DNS-a koji povezuju domenska imena s njihovim IP adresama. Postoje razliciti vrste DNS zapisa, ukljucujuci A zapis, CNAME zapis, MX zapis i PTR zapis, koji se koriste za razlicite svrhe. * **DNS klijenti:** Ovo su racunala ili uredjaji koji salju upite DNS posluziteljima kako bi saznali IP adresu za odredjeno domensko ime. DNS klijenti mogu biti ugradjeni u web preglednike, operativne sustave ili druge aplikacije koje se koriste za pristup Internetu. * **DNS protokoli:** Ovo su standardi za komunikaciju izmedju DNS posluzitelja i DNS klijenata. Postoje razliciti protokoli, ukljucujuci DNS protokol i DNSSEC protokol koji se koriste za osiguravanje integriteta i autenticnosti podataka u bazi podataka DNS-a.\\ * **DNS caching:** DNS posluzitelji i klijenti obicno pohranjuju informacije o DNS upitima kako bi se smanjio broj upita koji se salju DNS posluziteljima i ubrzalo vrijeme odgovora. To se naziva DNS caching. DNS zapisi imaju svoje vrijeme zivota (TTL - Time to Live) koje se koristi za upravljanje caching-om, sto znaci da se informacije u cache-u automatski brisu nakon isteka TTL-a. * **DNS hijacking:** Ovo je tehnika u kojoj napadac preusmjerava DNS upite s legitimne DNS adrese na laznu adresu. To omogucava napadacu da preuzme kontrolu nad komunikacijom izmedju DNS klijenta i posluzitelja te moze preusmjeravati korisnike na zlonamjerne web stranice ili kradju identiteta. ### Fully Qualified Domain Name (FQDN) Fully Qualified Domain Name (FQDN) je naziv koji se koristi za potpuno identificiranje jedinstvene lokacije na internetu, a sastoji se od nekoliko dijelova u hijerarhijskom poretku. FQDN ukljucuje sve dijelove naziva domene, ukljucujuci naziv subdomene, naziv drugog nivoa i naziv domene vrha (top-level domain, TLD). Primjer FQDN-a za web stranicu moze biti: `www.example.com`. **Domena** se odnosi na ime koje se koristi za identifikaciju odredjene web stranice ili servisa na internetu. Domena je sastavljena od `jedinstvenog naziva` i `top-level domene` (npr. `.com`, `.org`, `.net` itd.), a koristi se kako bi se olaksalo pronalazenje web stranice ili servisa na internetu. **Domensko ime** je dio domene i odnosi se na ime koje se koristi za identifikaciju pojedinog web mjesta. Domensko ime se nalazi prije top-level domene i sastoji se od naziva web stranice i naziva domene koja se nalazi nakon toga. Na primjer, u domeni `google.com`, `google` je naziv web stranice, a `.com` je top-level domena. Komponente domene ukljucuju:
* **Top-level domena (TLD):** TLD je najvisa razina domene u hijerarhiji domena. To su najcesce tri slova (npr. .com, .org, .net, .gov itd.) koja se nalaze nakon naziva web stranice. **Postoje dvije vrste TLD (Top Level Domain) domena:** * genericke * geografski bazirane **Genericke domene** su one koje se mogu koristiti za bilo koju web stranicu, dok su geografski bazirane domene rezervirane za web stranice koje se odnose na pojedine zemlje. Na primjer, `.com` je genericka domena, dok je `.ba` geografska domena. * **Druga razina domene (SLD):** SLD je dio domene koji se nalazi ispred top-level domene i koji obicno predstavlja naziv web mjesta. Na primjer, u domeni `google.com`, `google` je SLD. * **Subdomena:** Subdomena je dio domene koji se nalazi ispred drugog nivoa domene i obicno se koristi za organiziranje web stranica na istom web mjestu. Na primjer, u domeni `docs.google.com`, `docs` je subdomena koja pokazuje na Googleov servis za obradu teksta. Domena i domensko ime koriste se kako bi se olaksalo pronalazenje i pristupanje web stranicama i servisima na internetu. Svaka domena mora biti jedinstvena i registrirana kod registrara domena, koji upravlja domenom i odgovoran je za dodjelu domena korisnicima. #### Domenski registri Slicno kao i za IP adrese, postoje domenski registri, baze podataka o domenama i odgovarajucim IP adresama, po jedan za svaku TLD. Oni kao uslugu daju domenska imena za vlastitu TLD te omogucavaju ostatku svijeta pregled informacija o registracijama pojedinih domena. Domenski registri se inace nazivaju NIC (Network Information Centre). #### DNS rezolucija Svaki se funkcionalni DNS sistem sastoji se od tri dijela: 1. **DNS klijent (engl. resolver)**, program koji se izvrsava na klijentskom racunaru i koji formira odredjeni DNS zahtjev. Takav program ne mora biti poseban servis, on je na vecini UNIX operativnih sistema najcesce ugradjen u standardnoj biblioteci u formi sistemskih poziva koje pozivaju razliciti korisnicki programi, 2. **Rekurzivni (engl. recursive) DNS posluzitelj**, koji nakon dobivenih upita za klijenta obavlja pretrazivanje kroz DNS stablo i vraca nazad odgovore klijentima 3. **Autoritativni (engl. authoritative) DNS posluzitelj**, koji odgovara na upite rekurzivnih posluzitelja te vraca ili zavrsni odgovor ili zbog delegiranja vraca referencu na neki drugi autoritativni DNS posluzitelj. Sam proces primanja zahtjeva i njihove obrade te vracanja odgovora se naziva **DNS rezolucija (engl. name resolution)**. Pojednostavljeno, osnovna rezolucija je proces pretvaranja domenskog imena u IP adresu: prvo trazimo autoritativni DNS posluzitelj, a zatim mu saljemo upit za adresom, na koji on odgovara sa trazenom adresom. Buduci da je **DNS strogo distribuirana baza**, ona je raspodijeljena po mnogo razlicitih posluzitelja. No, ocigledno je da zbog raspodijeljenosti rezolucija obicno ne moze biti obavljena kroz samo jedan upit i odgovor, vec najcesce zahtijeva duzu komunikaciju i niz upita i odgovora. Najcesca je situacija da klijent salje zahtjeve lokalnom DNS posluzitelju (nadlezan za klijentsko racunalo, obicno dodijeljen od ISP-a ili ustanove u kojoj se nalazi klijentsko racunalo), koji predstavlja rekurzivni posluzitelj i obavlja upite te zatim vraca odgovor klijentu. Dakle, najveci i najkompliciraniji dio procedure predstavlja trazenje autoritativnog posluzitelja u slozenoj DNS hijerarhiji. Sto se samih tipova DNS rezolucije tice, postoje dva osnovna tipa prolaska kroz DNS hijerarhiju da bi se otkrio tocan zapis. Oni se razlikuju po tome tko obavlja vecinu posla oko saznavanja podataka i njihove obrade, a prvenstveno se pojavljuju kad obrada odredjenog DNS upita zahtijeva nekoliko koraka (dakle, lokalni DNS posluzitelj nema sve informacije): * **Iterativni** - kada klijent salje doticne upite, posluzitelj mora odgovoriti jednim od dva moguca odgovora: a) odgovorom na zahtjev ili b) imenom drugog DNS posluzitelja (vrsi se delegiranje) koji ima vise podataka o trazenom upitu. U ovakvom tipu upita najveci dio posla obavlja klijent iterirajuci akcije upit-odgovor i prolazeci kroz DNS hijerarhiju. * **Rekurzivni** - kada klijent salje rekurzivni upit, posluzitelj preuzima posao pronalazenja informacija o trazenom upitu. Dakle, ono sto je u iterativnom obavljao klijent, kod rekurzivnih upita obavlja posluzitelj - obradjuje informacije i salje nove upite drugim posluziteljima sve dok ne pronadje trazeno. Dakle, klijent salje svega jedan zahtjev te dobiva ili tocnu informaciju koju je trazio ili poruku o gresci. Ocigledno je rekurzivan nacin pretrazivanja vrlo povoljan za klijente, ali moze znatno opteretiti DNS posluzitelje (na stranu i potencijalni problem trovanja DNS posluzitelja o kojem ce kasnije biti rijeci), pa se takve forme upita obicno eksplicitno dozvoljavaju samo racunalima iz lokalne mreze, dakle racunalima kojima je doticni DNS posluzitelj nadlezan. I iskljucivo njima. #### DNS Hijerarhija **DNS (Domain Name System) hijerarhija** je organizacija domena na internetu koja omogucuje rjesavanje domenskih imena u IP adrese. DNS hijerarhija ima nekoliko razina domena, pri cemu svaka razina odgovara jednoj komponenti u domenskom imenu. Najvisa razina u DNS hijerarhiji su `root serveri`, koji se nalaze na vrhu hijerarhijske strukture i upucuju na druge DNS posluzitelje koji su zaduzeni za rjesavanje domenskih imena u nizim razinama. **Root serveri** su razmjesteni sirom svijeta i upucuju na posluzitelje za `Top-Level Domain (TLD)` - **najvisu razinu domena**. Nakon `root servera` dolaze `TLD` posluzitelji, koji upucuju na posluzitelje za drugu razinu domena (SLD), poput `.com`, `.org`, `.net` itd. `TLD` posluzitelji upucuju na posluzitelje za `SLD` domene, koji se nalaze na nizoj razini u hijerarhiji. Posluzitelji za `SLD` domene upucuju na posluzitelje za subdomene, ukoliko su definirane. Npr, posluzitelj za domenu `example.com` bi uputio na posluzitelje za subdomene, kao sto su `mail.example.com` ili `support.example.com`. Kada korisnik upise domensko ime u pregledniku, preglednik prvo upucuje DNS upit lokalnom DNS posluzitelju. Ako lokalni DNS posluzitelj nema trazeno rjesenje, on salje upit TLD posluzitelju, a zatim se upit salje posluzitelju za SLD domenu i tako dalje, sve dok se ne pronadje IP adresa povezana s trazenim domenskim imenom. DNS hijerarhija omogucuje brzo i ucinkovito rjesavanje domenskih imena u IP adrese, sto je kljucno za rad interneta.
Postoje cetiri glavna tipa DNS posluzitelja: * **Root posluzitelji:** Ovo su najvisi DNS posluzitelji u hijerarhiji i oni upucuju na posluzitelje TLD domena. * **TLD posluzitelji:** Ovi posluzitelji upucuju na posluzitelje za drugu razinu domena (SLD), poput .com, .org, .net itd. * **Posluzitelji za SLD domene:** Ovi posluzitelji upucuju na posluzitelje za subdomene, ukoliko su definirane. * **Autoritativni posluzitelji:** Ovi posluzitelji su izvorni izvori informacija o DNS zapisima za odredjenu domenu i oni vracaju IP adrese za trazena domenska imena. Kada se pronadje IP adresa povezana s trazenim domenskim imenom, DNS posluzitelj vraca tu adresu lokalnom DNS posluzitelju, koji je sprema u cache. U buducnosti, kada se ponovno zatrazi isto domensko ime, lokalni DNS posluzitelj vraca spremljenu IP adresu iz cache-a, umjesto da ponovo trazi adresu od DNS posluzitelja.
### VPN (Virtual Private Network) **VPN (Virtual Private Network)** je sigurna mrezna veza koja povezuje udaljene korisnike i uredjaje preko interneta kao da su direktno povezani u istoj lokalnoj mrezi. VPN se koristi za sigurno spajanje na udaljene mreze, pristup internetskim stranicama i servisima koji su inace nedostupni izvan odredjene lokacije, za zastitu privatnosti i anonimnosti, te za zastitu protoka podataka od neovlastenog pristupa. Kada korisnik uspostavi VPN vezu, svi podaci koji se prenose izmedju korisnika i VPN posluzitelja su sifrirani, sto znaci da se informacije koje se prenose izmedju korisnika i VPN posluzitelja ne mogu citati ili pristupiti bilo kome drugom. VPN takodjer moze pruziti dodatnu sigurnost koristenjem protokola za autentifikaciju i enkripciju, kao sto su IPsec (Internet Protocol Security), SSL/TLS (Secure Sockets Layer/Transport Layer Security) i drugi. VPN se moze koristiti na razlicite nacine, ukljucujuci: * Za pristup udaljenim mrezama: VPN se koristi za povezivanje korisnika s udaljenim mrezama, kao sto su poslovne mreze, koje inace ne bi bile dostupne izvan mreze. * Za zastitu privatnosti: VPN se moze koristiti za zastitu privatnosti i anonimnosti na internetu, tako da se korisnikovo mjesto i aktivnosti ne mogu pratiti. * Za zastitu od neovlastenog pristupa: VPN se moze koristiti za zastitu protoka podataka od neovlastenog pristupa, kao sto su hakiranje ili prisluskivanje. * Za pristup geografski ogranicenim uslugama: VPN se moze koristiti za pristup internetskim stranicama i servisima koji su inace dostupni samo u odredjenim geografskim podrucjima, kao sto su streaming servisi ili online trgovine. ### Snimci predavanja #### DevOps Mentorship Program - Week 4 - Computer Networks ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} #### DevOps Mentorship Program - Boris Bradic - Week 4 - Computer Networks ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} ### Materijali za ucenje * [Networking Fundamentals - Adrian Cantrill](https://www.youtube.com/playlist?list=PLTk5ZYSbd9Mi_ya5tVFD8NFfU1YZOyml1) * [IPv4 Addressing](https://www.tutorialspoint.com/ipv4/ipv4_addressing.htm) * [Subnetting - Classful Netmasks - part 1](https://youtu.be/jFN9TNSPVj4) * [Subnetting - ANDing - part2](https://youtu.be/KS3oz_D9FF8) * [Learning Subnetting Part 2 - The Subnet Mask, the Network Address and ANDing](https://youtu.be/uE5gdwr1mE0) * [Subnetting Cisco CCNA -Part 2 The Magic Number](https://youtu.be/84-zNmomYzk) * [Everything You Need to Know About DNS (Domain Name System)](https://youtu.be/27r4Bzuj5NQ) * [DNS 101 Miniseries - #1 - What does DNS do ?](https://youtu.be/zEmUuNFBgN8) * [DNS 101 Miniseries - #2 - Why DNS needs a complex architecture!](https://youtu.be/QTu7yDnR_58) * [DNS 101 Miniseries #3 - How DNS actually works ... walking the tree](https://youtu.be/xf01fJQsagQ) * [DNS 101 Miniseries - #4 - What happens when a domain is registered?](https://youtu.be/-WWQzOwbth4) * [DNS 101 Miniseries - #5 - Why do we need DNSSEC](https://youtu.be/thAUzOnUvP4) * [DNS 101 Miniseries - #6 - How DNSSEC Works within a Zone](https://youtu.be/4qlIim15xwM) * [DNS 101 Miniseries - #7 - DNSSEC Chain of Trust](https://youtu.be/YCk2WI-Fbtk) * [DNS 101 Miniseries - #8 - The DNSSEC Root Signing Ceremony - the most important meeting ever](https://youtu.be/1VqscYMG_Rs) * [A Beginner's Guide to WebSockets](https://youtu.be/8ARodQ4Wlf4) * [DNS Prirucnik](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/devops-mentorship-program/03-march/week-4-070323/files/DNS-prirucnik-1_5.pdf) * [What happens when you type a URL into your browser?](https://aws.amazon.com/blogs/mobile/what-happens-when-you-type-a-url-into-your-browser/) ### Materijali za dodatno citanje #### Knjige * [Computer Networking: A top-down approach - 7th edition](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/books/computer-networking-top-down-aproach.pdf) * [Computer Networking: A top-down approach 8th edition, Online Presentations](http://gaia.cs.umass.edu/kurose_ross/online_lectures.htm) * [TCP IP Illustrated, Volume 1: The Protocols - 2nd edition](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/books/Richard_Stevens-TCP-IP_Illustrated-EN.pdf) * [TCP IP Illustrated, Volume 2: The Implementation - 2nd edition](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/books/TCP-IP-Illustrated-Volume-2-The-Implementation.pdf) * [TCP IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols - 2nd edition](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/books/TCP-IP-Illustrated-Vol-3.pdf) #### Video materijali * [Wireshark Masterclass](https://youtube.com/playlist?list=PLW8bTPfXNGdC5Co0VnBK1yVzAwSSphzpJ) #### Blog Postovi * [iana - The global coordination of the DNS Root, IP addressing, and other Internet protocol resources is performed as the Internet Assigned Numbers](https://www.iana.org/) # Week-5: Server, tipovi servera Server je racunarski sistem ili program koji pruza usluge drugim racunarima ili programima u mrezi. Server moze biti svaki fizicki racunar ili virtuelna masina. Serverima se nazivaju i fizicki racunari koji se nalaze u on-premise data centrima a na kojima je pokrenut serverski program. Neke od osnovnih karakteristika servera su: * Pouzdanost * Perfromanse * Sigurnost * Skalabilnost * Visoka dostupnost * Upravljivost * Mrezna povezanost Za razliku od racunara za licnu upotrebu, hardwer racunara koji se koriste kao serveri su obicno dizajnirani da budu pouzdani i da imaju visoku dostupnost. Serveri su obicno opremljeni sa dodatnim hardwerom za povecanje performansi i sigurnosti. ![](/files/xOrkQrOmJ4VozvQOEe8A)![](/files/vhLtp5mnXi3p0rl4p6A3) ### Data centar Data centar je fizicki objekat koji sadrzi servere, mreznu opremu, klimatizaciju, UPS-e, generatora, kablovsku mrezu, itd. Data centri obicno imaju fizicke i digitalne sigurnosne mjere kako bi se zastitili podaci i oprema. Ovo moze ukljucivati kamere za nadzor, sisteme za pristup i identifikaciju, kao i razne fizicke barijere. [AWS Data Centers](https://aws.amazon.com/compliance/data-center/data-centers/) ### Server Operativni Sistem Server OS ima nekoliko karakteristika koje ga razlikuju od Operatinih Sistema na racunarima za licnu upotrebu. * Pouzdanost * Skalabilnost (podrska za multi-core procesore, multi-threading, itd.) * Perfromanse * Upravljanje resursima * Sigurnost * Udaljeno upravljanje ### Web Serveri **Web serveri** su racunarski programi / servisi koji su dizajnirani za obradjivanje HTTP zahtjeva i slanje HTTP odgovora korisnicima koji pregledavaju web stranice ili pristupaju web aplikacijama. Web serveri obicno se koriste za posluzivanje statickih web stranica, dinamickih web stranica i drugih vrsta web sadrzaja. Web serveri moze biti bilo koji racunar dostupan na Internetu, ali se obicno koriste posebni racunari odnosno serveri koje su optimizovani za brz i siguran rad. Trenutno najpopularniji web serveri su **Apache, Nginx i Microsoft IIS**.
### NGINX **NGINX** (izgovara se "Engine X") je open-source web server i reverse proxy server. Zahvaljujuci svojoj jednostavnosti koristenja, brzini, skalabilnosti i sigurnosti postao je jedan od najpopularnijih web servera. NGINX ima i svoju placenu verziju koja se naziva **NGINX Plus**. Iako NGINX Plus ima odredjene funkcionalnosti koje nisu dostupne u open-source verziji, vecina korisnika i dalje nalazi dovoljnim open-source verziju NGINX-a. ### **Instalacija NGINX-a na CentOS 7** Koraci za instalaciju Nginx-a na CentOS 7: ``` $ sudo yum install epel-release -y # instalacija EPEL repozitorija $ sudo yum install nginx -y # instalacija Nginx-a $ sudo systemctl start nginx # pokretanje Nginx-a ``` Defaultni root direktoriji nalazi se na lokaciji: `/usr/share/nginx/html`. Ova putanja definisana je unutar `server` bloka defaultnog nginx konfiguracijskog fajla koji se nalazi na lokaciji `/etc/nginx/nginx.conf`. **nginx.conf** predstavlja globalni konfiguracijski fajl. U njemu se definisu globalne promenljive, globalni `http` blok, globalni `server` blok, itd. Koraci za automatsko pokretanje Nginx-a nakon restarta servera: ``` $ sudo systemctl enable nginx # da se Nginx automatski pokrece nakon restarta servera $ systemctl is-enabled nginx # provjera da li je nginx podesen za automatsko startanje ``` ### **NGINX Konfiguracijski fajlovi** Za svaki pojedinacni web sajt / web servis koji hostujete na serveru potrebno je kreirati zaseban `server` blok unutar konfiguracijskog fajla. Preporuka je da se ti konfiguracijski fajlovi nalaze u direktorijumu `/etc/nginx/conf.d/` i da imaju ekstenziju `.conf`. Za svaki sajt kreirate poseban konfiguracijski fajl. U NGINX-u, direktive (eng. directives) su komande koje definisu kako Nginx obradjuje HTTP zahtjeve. Svaka direktiva se sastoji od naziva i vrijednosti koja se dodeljuje tom nazivu. Direktive se koriste u konfiguracijskim fajlovima da bi se definisala podesavanja za Nginx web server, kao sto su server blokovi, lokacije i ostale opcije. Primjer jedne direktive bi mogao biti: ``` listen 80; ``` U ovom primjeru, "listen" je naziv direktive, a "80" je vrijednost koja se dodeljuje toj direktivi. Ova direktiva definise da Nginx slusa na portu 80 za dolazne HTTP zahtjeve. **Konteksti (eng. contexts)** su oblasti u kojima se koriste direktive. Svaka direktiva se nalazi u nekom kontekstu, a kontekst definise koja se podesavanja primjenjuju na koji dio Nginx konfiguracije. Postoje tri vrste konteksta u Nginx-u: * `Main Context` - Ovo je glavni kontekst koji obuhvata podesavanja koja se primjenjuju globalno na Nginx server. * `Server Context` - Ovaj kontekst obuhvata podesavanja koja se primjenjuju na pojedinacne server blokove u konfiguraciji. * `Location Context` - Ovaj kontekst obuhvata podesavanja koja se primjenjuju na pojedinacne URL-ove na serveru. Primjer server konteksta bi mogao biti: ``` server { listen 80; server_name example.com; root /var/www/example.com; index index.html; location / { try_files $uri $uri/ /index.html; } } ``` U ovom primjeru, sve direktive koje se nalaze u bloku `server` primjenjuju se na taj pojedinacni server blok. Direktive koje se nalaze u bloku `location` primjenjuju se samo na URL-ove koji odgovaraju putanji /. U ovom slucaju, direktiva `try_files` definise da Nginx treba da pokusa da pronadje datoteku koja odgovara URL-u koji je klijent poslao. Ako datoteka ne postoji, Nginx ce pokusati da pronadje datoteku koja odgovara URL-u koji je klijent poslao, ali sa dodatnim znakom /. Ako ni ta datoteka ne postoji, Nginx ce pokusati da pronadje datoteku koja se zove index.html. **Razumijevanje konteksta i direktiva u Nginx-u je kljucno za kreiranje ispravne konfiguracije i definisanje podesavanja za vas web server.** Da bi izmjene koje ste napravili u konfiguraciji Nginx-a bile vidljive, potrebno je ponovo pokrenuti Nginx. Ovo se moze uraditi sa sledecom komandom: ``` $ sudo systemctl restart nginx ``` Pored nginx.conf fajla, postoje i drugi konfiguracijski fajlovi koji se nalaze u direktorijumu `/etc/nginx/`. Ovi fajlovi se koriste za dodatna podesavanja i konfiguracije. To su sljedeci fajlovi: * `mime.types` - Ovaj fajl sadrzi listu MIME tipova koji se koriste za odredjivanje tipa sadrzaja koji se vraca klijentu sto omogucava klijentima da pravilno prikazu sadrzaj web stranica. Npr. MIME tip za HTML fajl je `text/html`, a za JPEG sliku `image/jpeg`. Ako server salje HTML fajl sa MIME tipom `text/html`, browser ce ga pravilno interpretirati i prikazati HTML stranicu. Slicno tome, ako server salje sliku sa MIME tipom `image/jpeg`, browser ce prikazati sliku na odgovarajuci nacin. * `fastcgi.conf` - Ovaj fajl sadrzi podesavanja za `FastCGI` procese. `FastCGI` procesi se koriste za obradu dinamickog sadrzaja na web sajtu. `FastCGI` je protokol koji omogucava web serveru da uspostavi vezu sa FastCGI procesom koji izvrsava aplikaciju. FastCGI procesi se koriste za generisanje dinamickog sadrzaja na web sajtu, kao sto su skripte za generisanje HTML stranica, **PHP skripte** i drugi programski jezici. * `scgi_params` - **SCGI (Simple Common Gateway Interface)** je jednostavan protokol za komunikaciju izmedju web servera i aplikacijskog servera koji se koristi za generisanje dinamickog sadrzaja na web sajtovima. SCGI je slican FastCGI protokolu, ali je jednostavniji i manje fleksibilan. `SCGI` procesi se koriste za generisanje dinamickog sadrzaja na web sajtu, kao sto su skripte za generisanje HTML stranica, **Python skripte** i drugi programski jezici. * `uwsgi_params` - Ovaj fajl sadrzi podesavanja za `uWSGI` procese. `uWSGI` je jedan od najpopularnijh **WSGI (Web Server Gateway Interface)** servera. `uWSGI` procesi se koriste za obradu dinamickog sadrzaja na web sajtu. `uWSGI` je protokol koji omogucava web serveru da uspostavi vezu sa `uWSGI` procesom koji izvrsava aplikaciju. `uWSGI` procesi se koriste za generisanje dinamickog sadrzaja na web sajtu, kao sto su skripte za generisanje HTML stranica, **Python skripte** i drugi programski jezici. Preporuka je da pogledate sljedecu stranicu [Why is WSGI necessary?](https://www.fullstackpython.com/wsgi-servers.html) kako bi razumjeli zasto je potreban WSGI protokol. * `*-utf` - UTF metode omogucavaju enkodiranje znakova razlicitih jezika sto omogucava njihovo prikazivanje. **NAPOMENA:** Instalacija Nginx-a na ostalim Linux/Unix distribucijama moze da kreira dodatne direktorije poput `sites-available` i `sites-enabled`. Ovi direktoriji mogu da sadrze dodatne `.conf` fajlove koji se koriste za dodatna podesavanja i konfiguracije. Kod CentOS 7 OS-a konfiguracije za razlicite sajtove se nalaze unutar direktorijuma `/etc/nginx/conf.d/`. ### Aplikacijski server Da bi smo u potpunosti razumijeli rad web servera neophodno je da razumijemo aplikacijski server. Osnovni zadatak aplikacijskog servera je da omoguci klijentima pristup onome sto cesto nazivamo **biznis logikom aplikacije** koja generise dinamicki sadrzaj. **Web Server** isporucuje staticki sadrzaj ukljucujuci HTML stranice, slike, video fajlove i druge tipove podataka ukljucene u web sajt. Aplikacijski server sa druge strane generise dinamicki sadrzaj koji se isporucuje klijentima. Aplikacijski server nikada ne moze biti zamjena za web servere, umjesto toga aplikacijski server i web server moraju da rade zajedno kako bi klijent imao potpuno iskustvo prilikom koristenja web sajta. Bez aplikacijskog web servera, web aplikacije bi bile ogranicene na staticki sadrzaj i ne bi bile u mogucnosti da se prilagode promjenama u zahtjevima korisnika. ### Reverse Proxy Uzmimo za primjer da imamo Node.js aplikaciju koju zelimo da pokrenemo na nasem serveru (hostu). Da bi je pokrenuli potreban nam je `Node.js` server koji omogucava pokretanje `Node.js` aplikacije. `Node.js` server omogucava obradu `HTTP` zahtjeva koji stizu od klijenata i generisanje odgovora na osnovu Node.js koda. `Node.js` server pruza podrsku za razlicite `HTTP` metode, ukljucujuci `GET`, `POST`, `PUT`, `DELETE`, i druge. Kako bi omogucili posluzivanje statickih fajlova, bolju skalabilnost, sigurnost, jednostavniju konfiguraciju neophodno je da ispred naseg Node.js servera postavimo web server (u ovom primjeru Nginx) koji ce da obradi `HTTP` zahtjeve i proslijedi ih `Node.js` serveru. Ovaj tip arhitekture se naziva **Reverse Proxy** arhitektura. U ovom slucaju, **NGINX** server je **Reverse Proxy** server koji obradjuje `HTTP` zahtjeve i proslijedjuje ih `Node.js` serveru. `Node.js` server je u ovom slucaju **Backend** server koji obradjuje `HTTP` zahtjeve i generise odgovore na osnovu Node.js koda koje proslijedjuje **NGINX** serveru koji ih isporucuje klijentima.

Reverse proxy

**Kako da konfigurisemo Nginx da bude Reverse Proxy server?** Da bi konfigurisali **NGINX** da bude **Reverse Proxy** server neophodno je da podesimo jednostavnu Node.js aplikaciju koja ce da vrati `Hello World` poruku kada se pozove. Ova aplikacija ce biti nas **Backend** server. Nakon toga potrebno je da podesimo NGINX da bude **Reverse Proxy** server koji ce da obradjuje `HTTP` zahtjeve i proslijedjuje ih nasem **Backend** serveru. Postoji vise razloga zasto bi koristili reverse proxy, a neki od njih su: * **Skalabilnost** - Reverse proxy serveri mogu da podrze veliki broj klijenata i da se lako skaliraju. * **Sigurnost** - Reverse proxy moze da sprijeci napade na backend servere. * **Jednostavnost** - Reverse proxy serveri mogu da se konfigurisu jednostavnije nego backend odnosno aplikacijski serveri. * **Brzina** - Reverse proxy serveri mogu da se konfigurisu da podrze cache-ovanje i da omoguce brze isporuke sadrzaja klijentima. * **Load Balancing** - Reverse proxy serveri mogu da podrze load balancing i da rasporede zahteve klijenata na razlicite backend odnosno aplikacijske servere. * **SSL Termination** - Reverse proxy serveri mogu da podrze SSL terminaciju i da omoguce klijentima da komuniciraju sa backend serverima preko HTTPS protokola. U tu svrhu cemo ispratiti tutorijal sa Digital Ocean stranice [How To Set Up a Node.js Application for Production on CentOS 7](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-node-js-application-for-production-on-centos-7) ``` $ curl -L -o nodesource_setup.sh https://rpm.nodesource.com/setup_14.x # Download Node.js 14 setup script $ sudo bash nodesource_setup.sh # Run Node.js setup script $ sudo yum clean all # Clean yum cache $ sudo yum makecache fast # Make yum cache $ sudo yum install -y gcc-c++ make # Install build tools $ sudo yum install nodejs # Install Node.js $ node -v # Check Node.js version ``` Ukoliko dobijete sljedecu gresku: ``` ## You don't appear to be running a supported version of Enterprise Linux. Please contact NodeSource at https://github.com/nodesource/distributions/issues if you think this is incorrect or would like your architecture to be considered for support. Include your 'distribution package' name: no package provides redhat-release no package provides centos-release no package provides cloudlinux-release no package provides sl-release ``` Node JS mozete instalirati koristeci node version manager (nvm) alat na sljedeci nacin: ``` # Install node version manager (nvm) by typing the following at the command line. $ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash # Activate nvm by typing the following at the command line. $ . ~/.nvm/nvm.sh # Use nvm to install the version 14 of Node.js by typing the following at the command line. $ nvm install 14 # Test that Node.js is installed and running correctly by typing the following at the command line. $ node -e "console.log('Running Node.js ' + process.version)" ``` Svakako je preporuka da pogledate [node github repozitoriji](https://github.com/nodesource/distributions) za instrukcije za instalaciju na razlicitim operativnim sistemima. **Application setup** ``` # dodajte vas server public key na github kako bi mogli da klonirate application repo $ yum install git # Install git $ git clone git@github.com:allops-solutions/nodejs-simple-app.git # Klonirajte aplikaciju na vas server $ cd nodejs-simple-app # Pozicionirajte se u folder sa aplikacijom $ npm install # Instalirajte sve potrebne pakete iz package.json fajla $ npm install -g pm2 # Install pm2 process manager $ pm2 start server.js # Start Node.js application ``` Koraci za automatsko pokretanje pm2 nakon restarta servera: ``` $ pm2 list # provjeriti da li je aplikacija pokrenuta ako nije pokrenuti je sa komandom pm2 start server.js $ pm2 startup # Da se generise startup skripta. $ pm2 save # Da se sacuva trenutna lista procesa kojima upravlja pm2 i koji ce se automatski startati prilikom svakog restarta servera. ``` Nakon izvrsenja komande `pm2 startup` prikazuje se komanda koju trebamo pokrenuti kao root user ili sa sudo privilegijama. A ukoliko smo komandu `pm2 startup` izvrsili kao root korisnik onda se ta komanda izvrsava automatski i ne trebamo je ponovo izvrsavati. Primjer takve komande koja se generise je: ``` sudo env PATH=$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2 startup systemd -u your_user --hp /home/your_user ``` * Komanda kreira `systemd` servis koji ce pokrenuti `pm2` pri sistemskom boot-u i izvrsiti je kao navedeni korisnik `your_user` username koji koristimo za pokretanje Node.js aplikacije `-u your_user` opcija `-u` specificira korisnika s cijim će se username-om izvrsiti navedena komanda `env PATH=$PATH:/usr/bin` postavljamo enviromental varijablu `PATH` da ukljucuje `/usr/bin` direktorij gdje se nalazi `node` binary executable file * `node` komanda se koristi za izvršavanje fajla. Na primjer `$ node app.js` `/usr/lib/node_modules/pm2/bin/pm2` je putanja do executable PM2 fajla `--hp /home/your_user` specificira gdje se nalazi `home` direktorij korisnika, kako bi pm2 znao gdje se nalaze korisnikovi konfiguracijski fajlovi i log fajlovi Defaultno se **pm2** servis pokrece kao root korisnik, ali je preporuka iz sigurnosnih razloga da koristimo non-root korisnike sa ogranicenim permisijama i zato se navodi putanja do `home` direktorija. Kao poruku da je komanda izvrsena uspjesno dobijemo nesto slicno "**Systemd process manager installed**" , sto znaci da je skripta instalirana i `pm2` ce se pokretati automatski pri sistemskom boot-u. Za provjeru koristimo komande: ``` $ systemctl status pm2-root # Provjera da li je proces aktivan. $ pm2 unstartup # Ako zelimo onemoguciti startup system. ``` **NGINX setup** ``` $ cd /etc/nginx/conf.d $ vi node-app.conf ``` gdje je `node-app.conf`: ``` server { listen 80; server_name 3.68.91.255; location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } } ``` `node-app.conf` - predstavlja konfiguracijski fajl gdje smo unutar `server` bloka definisali jedan virtuealni server koji ce da obradjuje `HTTP` zahtjeve koji stizu na port `80` i proslijedjuje ih na `Node.js` server koji slusa na portu `3000` * `server` - pocetak definicije bloka konfiguracije za virtualni server. * `listen 80` - Nginx ce slusati dolazne zahtjeve na portu 80. * `server_name 3.68.91.255` - ovaj virtualni server ce odgovoriti na zahtjeve sa hostom 3.68.91.255 * `location /` - sva podudaranja putanja ce biti preusmjerena na proxy server. * `proxy_pass http://127.0.0.1:3000` - svi dolazni zahtjevi ce biti proslijedjeni na adresu `127.0.0.1:3000` gdje se pokrece vasa aplikacija, to je ustvari `localhost` adresa pa ste mogli da koristite i `proxy_pass http://localhost:3000` * `proxy_http_version 1.1` - verzija HTTP protokola koja ce se koristiti za komunikaciju izmedju Nginx i aplikacije. * `proxy_set_header Upgrade $http_upgrade;` - podesava zaglavlje Upgrade koje omogucava koristenje WebSocket komunikacije. * `proxy_set_header Connection 'upgrade';` - podesava zaglavlje Connection koje omogucava koristenje WebSocket komunikacije. * `proxy_set_header Host $host;` - podesava zaglavlje Host na vrijednost primljenog zahtjeva. * `proxy_cache_bypass $http_upgrade;` - onemogucuje koristenje kesa za WebSocket komunikaciju. **Troubleshooting** Pogledajte NGINX logove i greske: ``` $ cat /var/log/nginx/error.log ``` ``` [crit] 19207#19207: *23 connect() to 127.0.0.1:3000 failed (13: Permission denied) while connecting to upstream, client: 185.58.94.229, server: 3.68.91.255, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "3.68.91.255" ``` **Korisne komande za troubleshooting:** ``` $ curl -l http://localhost:3000 # Check if Node.js application is running $ pm2 list # Check if Node.js application is running $ ps aux | grep node # Check if Node.js application is running $ sudo netstat -tulpn | grep :3000 # Check if Node.js application is running on port 3000 $ systemctl status nginx # Check if NGINX is running $ sudo systemctl reload nginx # Reload NGINX configuration without stopping/restarting the NGINX service and without losing any active connections. $ sudo systemctl stop/start/restart nginx # Stop NGINX service / Start NGINX service / Restart NGINX service $ sudo nginx -t # Test NGINX configuration $ sudo nginx -s reload # Reload NGINX configuration, this command is used to reload NGINX configuration after making changes to the configuration file without restarting the NGINX service. $ sudo journalctl -u nginx # Shop NGINX logs and errors. journalctl is a command line tool for viewing and querying the systemd journal. $ sudo systemctl reload nginx # Reload NGINX configuration without stopping/restarting the NGINX service. $ semanage port --list # SELinux port list $ semanage port --list | grep http_port_t # Check if port 80 is allowed ``` ### Forward Proxy Za razliku od reverse proxy-a koji sluzi za zastitu servera, **forward proxy** sluzi za zastitu klijenta. Forward proxy je server koji se nalazi izmedju klijenta ili grupe klijenta i interneta. Kada klijenti naprave zahtijev odnosno request prema internetu, oni se prvo salju na forward proxy server, koji ih proslijedi na internet. Forward proxy ce presresti zahtijev i "razgovarati" ce sa web serverom u ime klijenta.

Forward proxy

Nekoliko je razloga zasto bi klijent zelio da koristi forward proxy server: * **Zastita privatnosti** - klijent moze da sakrije svoju IP adresu i da koristi IP adresu forward proxy servera. * **Zaobilazak zabrana** - klijent moze da koristi forward proxy server da bi zaobilazio zabrane koje su postavljene na strani servera. * **Blokira pristup** - forward proxy server moze da zabrani klijentima pristup odredjenim web stranicama. ### Apache **Apache HTTP Server** ili **Apache** ili **Apache HTTPD** je besplatni, open-source web server koji se koristi za hostovanje web stranica i web aplikacija. Instalacija Apache-a i osnovni konfiguracijski fajlovi Instalacija na CentOS 7: ``` $ sudo yum install httpd ``` Lokacija na kojoj je instaliran je `/etc/httpd/`. **Konfiguracijski direktoriji i fajlovi** Folderi koje vidimo na ovoj putanji su: * `conf` - folder koji sadrzi konfiguracijske fajlove za Apache server `httpd.conf` i `magic` fajlove. * `httpd.conf` - glavni konfiguracijski fajl za Apache server * `magic` - fajl koji sadrzi informacije o tipovima fajlova odnosno datoteka koje se prenose preko web-a. Apache koristi magic datoteku kako bi utvrdio vrstu datoteke koja se prenosi, a zatim pravilno poslao odgovarajući MIME tip u HTTP zaglavlje. MIME tip omogućuje klijentima da znaju kako da obrade datoteke koje primaju, što je posebno važno kada se radi o binarnim datotekama, poput izvršnih datoteka ili arhiva. * `conf.d` - folder koji sadrzi konfiguracijske fajlove za Apache server kreirane od strane korisnika * `modules` - Ovaj direktorij se koristi za pohranu modula koje Apache koristi. Ovdje se nalaze datoteke koje definiraju funkcionalnost Apache modula. To su prekompilirane datoteke s ekstenzijom `.so` za Unix sisteme ili `.dll` za Windows. * `conf.modules.d` - direktorij se koristi za pohranu konfiguracijskih datoteka za Apache module. Ove datoteke opisuju kako se moduli učitavaju i konfigurisu. Sadrži datoteke s nazivom u obliku `XX-naziv_modula.conf`, gdje `XX` oznacava redoslijed u kojem se moduli učitavaju. Datoteke u ovom direktoriju obično sadrže `LoadModule` direktive koje specificiraju putanju do modula i naziv modula. **Virtual Hosts / Virtuelni hostovi** Zahvaljujuci virtuelnim hostovi, Apache server moze da hostuje vise web stranica na jednom serveru. Svaka web stranica ima svoj virtuelni host. Virtuelni hostovi se konfigurisu u `httpd.conf` fajlu. Ukoliko je potrebno da se konfigurise vise virtuelnih hostova, onda se konfiguracija virtuelnih hostova izdvoji u posebane fajlove koji se nalaze u `conf.d` direktoriju. ``` ServerName www.prva-stranica.com DocumentRoot /var/www/prva-stranica.com ServerName www.druga-stranica.com DocumentRoot /var/www/druga-stranica.com ``` **Reverse Proxy** ``` ServerName example.com ServerAlias www.example.com # Proxy settings for Node.js app ProxyPreserveHost On ProxyPass / http://localhost:3000/ ProxyPassReverse / http://localhost:3000/ ProxyRequests Off ``` * `ProxyPreserveHost On` - ova opcija omogucava da se host header proslijedi na Node.js aplikaciju * `ProxyPass / http://localhost:3000/` - ova opcija proslijedjuje sve zahtjeve koji dolaze na Apache server na Node.js aplikaciju * `ProxyPassReverse / http://localhost:3000/` - ova opcija proslijedjuje sve odgovore koji dolaze od Node.js aplikacije na Apache server * `ProxyRequests Off` - zabranjuje koristenje apache web servera kao forward proxy servera #### Apache Tomcat **Apache Tomcat** ili samo **Tomcat** je open-source web server koji se koristi za posluzivanje web aplikacija koje su napisane u **Javi**. Tomcat se obicno koristi za posluzivanje dinamickih web stranica koje koriste **JSP (JavaServer Pages)** i servlet tehnologije. **Tomcat** je razvijen na bazi **Apache web servera** i sadrzi mnoge od njegovih funkcionalnosti, ali se razlikuje po tome sto je specijaliziran za posluzivanje Java aplikacija. Tomcat takodjer ima svoje vlastite funkcionalnosti, ukljucujuci ugradjenu podrsku za **Java Servlet API**, **JavaServer Pages (JSP)**, **WebSockets** i **Java Server Faces (JSF)**. ### Ostale vrste servera * **Serveri za baze podataka** - Koriste se za pohranu i upravljanje podacima u bazi podataka, neki od popularnih servera baza podataka (eng. database server) su: * MySQL * PostgreSQL * MariaDB * Microsoft SQL Server * Oracle Database Vise o serverima baza podataka je receno tokom predavavanja u [**WEEK-9**](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/devops-mentorship-program/04-april/week-9-110423/00-class-notes.md) snimak tog predavanja mozete pogledati na [**WEEK-9-tier-1-group-2 video session recording**](https://youtu.be/wsxwo_stIC0). * **E-mail serveri** - Koriste se za slanje i primanje e-poste. * **File serveri** - Koriste se za pohranu i dijeljenje fajlova. * **FTP serveri** - Koriste se za slanje i primanje fajlova preko `FTP (File Transfer Protocol)` protokola. * **DNS serveri** - Koriste se za razrjesavanje domenskih imena u IP adrese. ### Snimci predavanja #### DevOps Mentorship Program - Week 5 - Web Servers / NGINX ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} #### DevOps Mentorship Program - Week 5 - Web Servers / APACHE ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} ### Materijali za ucenje * [SSL - Secure Sockets Layer](/devops-learning-path/ssl-secure-sockets-layer) * [Proxy vs Reverse Proxy (Real-world Examples)](https://youtu.be/4NB0NDtOwIQ) * [nginx documentation](http://nginx.org/en/docs/) * [How nginx processes a request](http://nginx.org/en/docs/http/request_processing.html) * [nginx server names](http://nginx.org/en/docs/http/server_names.html) * [Avoiding the Top 10 NGINX Configuration Mistakes](https://www.nginx.com/blog/avoiding-top-10-nginx-configuration-mistakes/) * [Apache HTTP Server Project](https://httpd.apache.org/) # Week 6: Uvod u Cloud, Amazon Web Servisi (AWS) **Racunarstvo u oblaku** ili **cloud computing** odnosno **cloud**, je najjednostavnije receno mogucnost da **preko interneta koristite racunarske, mrezne i druge resurse bez mogucnosti fizickog pristupa hardverskim uredjajima koji vam pruzaju trazene resurse.** Kako se resursima pristupa preko javne mreze, odnosno interneta, za cloud koristimo i precizniji izraz **public-javni cloud**. ### Amazon Web Services (AWS) **Amazon Web Servisi (AWS)** predstavljaju web servise, koji vam omogucavaju da koristite mrezne, racunarske i resurse za pohranu podataka preko interneta. Historija AWS-a vuce korijenje od 2002. godine, kada je kompanija Amazon.com programerima ponudila beta verziju SOAP i XML interfejsa, preko kojeg bi mogli da pristupe Amazon katalogu i zarade kroz [Amazon Associates](https://affiliate-program.amazon.com/) program. Krajem 2004. godine, učinili su javno dostupnim Simple Queue Service (SQS), a zatim početkom i na ljeto 2006. godine objavili još dva servisa, Amazon S3 i Amazon EC2. Mozemo reci da je tako sve pocelo. Vise o historiji Amazon Web Servisa možete pročitati u blog postu Jeffa Barra, AWS Chief Evangeliste, [My First 12 Years at Amazon.com](http://jeff-barr.com/2014/08/19/my-first-12-years-at-amazon-dot-com/). #### AWS Infrastruktura AWS posjeduje data centre rasirene po cijelom svijetu. Data centri su grupisani po regijama - `regions` (Europe London, Europe Paris, Europe Frankfurt, US Northern Virginia itd), gdje svaka od regija mora da sadrzi minimalno dva fizički odvojena i nezavisna data centra koja se nazivaju Availibliy Zone (AZ). Availibility Zone i AWS regije su međusobno povezane redudantnim brzim linkovima, koji omogućavaju brzu privatnu mrezu sa minimalnim kasnjenjima u prenosu podataka, kao i komunikaciju servisa koji se nalaze u razlicitim regijama. **Regije** se oznacavaju koristeci **AWS Region Name** - npr. `Europe (Frankfurt)` i **AWS Region Code** - npr. `eu-central-1`. **Availablity Zone** se označavaju na način da se na ime regije doda slovo (`a`, `b`, `c`, `d`, `e`, itd.) kao sufix (npr. `eu-central-1a`). ### Snimci predavanja #### DevOps Mentorship Program - Week 6 - Uvod u Cloud/AWS ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} #### DevOps Mentorship Program - Week 6 - Uvod u Cloud/AWS ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} ### Materijali za ucenje * [Racunarstvo u oblaku - Cloud](https://sqlheisenberg.com/racunarstvo-u-oblaku-cloud/index.html) * [Uvod u Amazon Web Servise (AWS)](https://sqlheisenberg.com/uvod-u-amazon-web-servise-aws/index.html) * [My First 12 Years at Amazon.com](http://jeff-barr.com/2014/08/19/my-first-12-years-at-amazon-dot-com/) # Week 7: Uvod u AWS, Amzon EC2, IAM ### Elastic Compute Cloud (EC2) - Osnove **Elastic Compute Cloud (EC2)** je spada u kategoriju **IaaS** (Infrastructure as a Service) servisa. EC2 je AWS servis koji vam omogucava kreiranje i koristenje racunarskih resursa (CPU, RAM, GPU, Networking). EC2 instacu cesto nazivamo i virtuelnom masinom u cloudu. **Amazon Machine Image (AMI)** konfiguracija / template / sablon, koji koristimo da bi na osnovu njega brzo i jednostavno kreirali EC2 instancu. **AMI** sadrzi informacije o operativnom sistemu, arhitekturi (32/64-bit), ranije predinstaliranim aplikacijama itd. AMI moze biti Javni, Privatni ili Dijeljeni. **Instance Types / Tipovi EC2 instanci** predstavlja velicinu resursa vase EC2 sa stanovista resursa. Postoji vise razlicitih tipova EC2 instnaci koje su podjeljene u nekoliko porodica/kategorija. Tipovi instanci se oznacavaju, imenuju, kodovima npr: `t2.micro`, `m5.large`, `c5.2xlarge` itd.
\*Slika preuzeta iz AWS dokumentacije [Instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html). Sjajan blog post na temu imenovanja EC2 instanci pogledajte na sljedecem linku [Amazon EC2 names explained](https://justingarrison.com/blog/2023-02-23-ec2-names-explained/). {% embed url="" %} ## Identity Access Management (IAM) - Osnove **Identinty Access Management (IAM)** je AWS servis koji vam omogucava **autentifikaciju** i **autorizaciju** za rad sa AWS servisima unutar vaseg AWS racuna. Kada posaljete zahtjev prema AWS API-iju, bilo da radite sa servisima koristeci AWS konzolu,SDKs (Software Development Kit) ili AWS Command Line Interface (AWS CLI), IAM servis je taj koji verifikuje vas identitet i provjerava da li vam je dozvoljeno izvrsavanje zeljene akcije. IAM dakle kontrolise **KO (autentifikacija)** moze pristupiti vasem AWS racunu i **KOJE AKCIJE (autorizacija)** moze napraviti unutar AWS racuna. Postoje dva nacina da se verifikuje IAM korisnik unutar AWS racuna: * Korisnicko ime i lozinka * Kljucevi za pristup (Access Keys) **AWS Principals** predstavlja **osobu** ili **aplikaciju** koja koristi AWS `root korisnika`, `IAM korisnika` ili `IAM rolu` da se prijavi unutar AWS racuna i napravi API poziv prema nekom od servisa. Kada AWS racunu pristupate koristeci email adresu i password koji ste upisali prilikom kreiranja racuna, koristite `root korisnika / root user`. Root korisnik se kreira automatski sa vasim AWS racunom. Taj korisnik ima pune administratorske privilegije nad AWS racunom i moze da pristupi svim servisima ukljucujuci i dio namjenjen za placanje. Sve nove korisnike koje kreirate, kreirate koristeci IAM servis, medjutim oni nemaju privilegije za pristup resursima osim da se prijave na AWS racun sve dok im ih vi ne dodjelite koristeci `IAM Policy`. Najbolja praksa i preporuka je da root korisnika nikada ne koristite za dnevni menadzment i rad sa AWS racunom. Bitno je da zapamtite da unutar AWS racuna postoje odredjene akcije koje mozete napraviti samo koristeci root korisnika. Vise o tome pogledajte na sljedecem linku unutar AWS dokumentacije [Tasks that require root user credentials](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html) Opcija pristupa IAM korisnika dijelu za placanje unutar AWS racuna mora bit omogucena na nivou AWS racuna od strane root korisnika. Dok se to ne dogodi, IAM korisnik bez obzira na privilegije koje ima ne moze da pristupi dijelu za placanje i troskove unutar AWS racuna. Vise o tome kako da to uradite mozete pronaci u AWS dokumentaciji [IAM tutorial: Delegate access to the billing console](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_billing.html) **IAM Policy** je objekat unutar AWS-a koji kada se pridruzi identitetu (`IAM User`, `IAM Group`, `IAM Rola`) ili resursu (`EC2 instance`, `S3 bucket`) **definise njihova prava pristupa**. Kada identitet ili resurs pravi upit prema AWS API-ju, AWS na osnovu IAM polisija ocjenjuje, prvo da li uopste ima prava da napravi taj poziv a zatim i koja su mu prava odnosno akcije dozvoljene da napravi. Korisnici i role unutar IAM servisa posjeduju vlastiti `arn` **(amazon resource name)** i zato se zovu pravim identitetima dok je uloga **grupa organizatorske prirode** i one sluze administratorima da grupisu korisnike i na taj nacin lakse odrzavaju njihova prava pristupa dodjeljujuci rolu na nivou grupe a ne na nivou pojedinacnog korisnika. IAM servis, pored navedenih mogucnosti, ima i ulogu da kooridinira sa **AWS Security Token Service (STS)** servisom i na taj nacin omoguci da vanjski entiteti mogu da pristupe AWS resursima unutar AWS racuna. {% embed url="" %} Za vise informacija o IAM servisu pogledajte stranicu [Identity Access Management (IAM)](/amazon-web-services-aws/aws-service-notes/identity-access-management-iam) ### Snimci predavanja #### DevOps Mentorship Program - Week 7 - AWS: IAM Policy, AWS CLI, EC2 ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} #### DevOps Mentorship Program - Week 7 - AWS: IAM Policy, AWS CLI, EC2 ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} ### Materijali za ucenje * [Amazon EC2 FAQ](https://aws.amazon.com/ec2/faqs/) * [AWS Identity and Access Management (IAM) FAQs](https://aws.amazon.com/iam/faqs/) ### Materijali za dodatno citanje # Week 8: Amazon Elastic Load Balancer, Amazon EC2 Auto Scaling **Elastic Load Balancer (ELB)** ili samo **Load Balancer** preusmjerava saobraćaj/upućene zahtjeve ka **healthy targets** tj. EC2 instancama registrovanim unutar **target groups** po portu i protokolu koji smo definisali pri kreiranju target group . Vršeći **health checks** LB provjerava status svake instance. Ukoliko se poveća broj zahtjeva ka našoj aplikaciji, možemo **rucno** registrovati nove instance kako bismo uspjeli odgovoriti na sve zahtjeve. LB će, čim nova instanca bude u statusu *healthy* krenuti da šalje saobraćaj instanci. Ako se zahtjevi ka aplikaciji smanje, možemo smanjiti broj instanci unutar target grupe, tako što radimo **deregister** čime se instanca uklanja iz target grupe i pri tome ne mijenjamo instancu. Kako bismo automatizovali proces dodavanja instanci i terminiranja istih kada nam više nisu potrebne, koristimo **Amazon EC2 Auto Scaling** gdje kreiramo Auto Scaling grupu i za nju zakačimo željeni LB. O Auto Scaling grupama ce vise rijeci biti u nastavku. **Bitno je napomenuti da LB, sam ne moze vrsiti terminiranje niti podizanje novih instanci, vec taj proces radimo manuelno dodajuci sami nove instance ili automatizovano koristeci Auto Scaling Groups.** LB će saobraćaj preusmjeravati target grupama na osnovu pravila podešenih u **Listener rule** i time spriječiti neželjene upade, povećati bezbjednost aplikacije **Load Balancer iz stvarnog zivota** Kada bismo Load Balancer uporedili sa nekim situacijama iz stvarnog zivota, onda mozemo objasniti rad Load Balancera na primjeru portira koji radi u banci. * Load Balancer ce biti nas portir, koji stoji na ulazu u banku i regulise "saobracaj" klijenata sa zahtjevima. * Banka ima vise otvorenih saltera sa sluzbenikom u svakom, koji prihvataju zahtjeve klijenata. U ovom slucaju salteri sa sluzbenikom predstavljaju nase **EC2 instance**. * Salteri su podijeljeni u grupe - placanje racuna, isplata novca, krediti i sl. Svaka od ovih grupa saltera ima pravilo da se mogu raditi samo namjenske akcije, dakle na salteru placanje racuna, nije moguce podici kredit cime su uspostavljena odrednjena pravila. Ovako podijeljeni salteri cine zasebne **target grupe** * Portir je upoznat sa prethodnim pravilom i zapisao je sebi gdje salje koje klijente. Ovo je ekvivalent **Listener rules** koji se postavljaju u **Listener** naseg Load Balancera. * Kada klijent stigne do portira, pokaze mu svoje isprave i zahtjeve, koje portir provjeri u svojoj svesci i na osnovu zahtjeva i ispravnih dokumenata, proslijedi klijenta na odgovarajuci salter. U slucaju da klijent ne ispunjava neki od uslova, bice udaljen. Na ovaj nacin funkcionisu i pravi **requests** upuceni ka Load Balanceru, s tim da se provjerava port i protokol. * Portir periodicno provjerava koji su sve salteri dostupni, vrseci tako **healt check**. Onog momenta kada se ustanovi da je jedan salter ostao bez sluzbenika, portir ce smatrati da je taj salter **unhealthy** i prestace da salje klijente na taj salter. Portir nema mogucnost da zatrazi da se otvori novi salter sa sluzbenikom, jer nije u njegovoj nadleznosti. Vec na samom pocetku smo vise puta ponovili termin **health check**, pa cemo u nastavku saznati nesto vise o tome. #### Health check **Health check** su periodicni zahtjevi upuceni ka EC2 instancama. Onog trenutka kada jedna od instanci prestane sa radom, LB je oznacava kao `unhealthy` i prestaje sa prosljedjivanjem sadrzaja ka toj instanci. Postavljanjem LB-a ispred naših EC2 instanci, pravimo dodatni vid zaštite podataka, spriječavamo nedozvoljene pristupe i eventualne gubitke podataka. **Health check strategije** Po default-u ASG koriste EC2 instance status check kako bi odredile "zdravlje" instance. Ovi status-check mogu identifikovati failure conditions - loss of connectivity, loss of system power, exhausted memory ili incompatible kernel. Dakle, ne prati se stanje unutar instance - status softvera, operativnog sistema ili file sistema koji smo instalirali na instanci. Ukoliko ASG pridruzimo LB, omogucavamo time da ASG koristi LB health checks kako bi provjerila stanje EC2 instanci te podigla ili terminirala instance. Postoje tri strategije za mjerenje zdravlja instance: 1. **liveness checks** 2. **local health checks** 3. **dependency health checks** Kako zelimo znati vise informacija o *health check* nase instance, preporuka je da se koriste **local health checks** tzv. **shallow health checks** ili **dependency health checks** tzv. **deep health checks**. #### Shallow health checks * daju nam samo "on-box" checks kao sto je provjera kriticnih procesa i da li su agents u stanju running, da li je ponasanje softvera ispravno i zdravlje file sistema. Instanca vraca uspjesan HTTP odgovor na health check ako je sve u redu. #### Deep health checks * ukljucuju shallow health checks i test-interaction sa "off-box" dependencijes kao sto je razrjesavanje DNS record-a, querying database, slanje podataka ka downstream servisima ili external APIs. Vise o ovoj temi mozete procitati na blog postu [Choosing the right health check with Elastic Load Balancing and EC2 Auto Scaling](https://aws.amazon.com/blogs/networking-and-content-delivery/choosing-the-right-health-check-with-elastic-load-balancing-and-ec2-auto-scaling/). ### Tipovi Load Balancer-a U zavisnosti od potreba aplikacije možemo koristiti jednu od 3 vrste Load Balancer-a. #### Application Load Balancer **Application Load Balancer (ALB)** koristimo u slučaju kada radimo sa protokolima Aplikacijskog sloja OSI modela npr. kada trebamo prosljedjivati HTTP/HTTPS zahtjeve upucene nasoj aplikaciji.
\**Slika preuzeta sa posta* [*What is an Application Load Balancer?*](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) Upoznajmo se sa pojomovima: * `listener` komponenta ALB koja slusa dolazeci saobracaj na definisanom `port`-u, kao sto je `port 80` za HTTP i `port 443` za HTTPS saobracaj. Moze biti konfigurisan na nacin da sadrzi vise `listener rules` za rutiranje saobracaja ka `target grupama` * `Listener Rule` set pravila/uslova koja je potrebno ispuniti kako bi se saobracaj proslijedio odredjenoj `target grupi` * `target group` ciljna grupa ili logicka cjelina EC2 instanci kojima ce ALB prosljedjivati svoje zahtjeve * `target` EC2 instanca koja je registrovana unutar `target grupe` Kada klijent posalje zahtjev ka ALB, `listener` osluskuje na unaprijed definisanom portu za protokol. Zahtjev koji stigne na navedeni port, obradjuje se u skladu sa uslovima u `listener rules` i ako ispunjava uslove, ALB ce proslijediti saobracaj odgovarajucoj `target grupi` koja sadrzi registrovane `targets` tj. EC2 instance koje prihvataju saobracaj. Sam pojam **load balancing** govori nam da se radi o balansiranju dolazećeg saobraćaja, za šta svi load balancer-i koriste odgovarajuće algoritme. Izbor pravog balancing algoritma direktno utice na performanse nase aplikacije. Najcesce koristeni su **Round-Robin** i **Least Outstanding Request**. **Round-Robin** * najjednostavniji *sheduling* algoritam koji jednako distribuira dolazeće zahtjeve ka svim registrovanim EC2 instancama unutar `target group` vrseci ciklicne prolaze kroz EC2 instance Na dijagramu ispod, prikazano je kako round-robin algoritam prosljedjuje zahtjeve. U pocetku vidimo 5 EC2 instanci gdje svaka dobija po jedan zahtjev, a nakon što se doda nova, 6 EC2 instanca ona će dobiti zahtjev i krug se nastavlja dalje.
\**Animacija preuzeta sa blog posta* [*AWS Application Load Balancer algorithms*](https://medium.com/dazn-tech/aws-application-load-balancer-algorithms-765be2eca158) **Round-Robin pros | cons** ✅ Jednostavan i lak za razumijevanje ✅ Sve `targets` dobijaju jednak broj zahtjeva ❌ `targets` moraju biti iste velične i sličnih performansi ❌ Zahtjevi moraju imati isti `load` i `latency` što često nije moguće jer API dozvoljavaju više request metoda. Na primjer, `POST` metodi treba više vremena za procesuiranje podataka nego `GET` metodi. **Least Outstanding Request (LOR)** * *sheduling* algoritam koji provjerava trenutni `workload` svake EC2 instance unutar `target group` i bira onu instancu koja ima trenutno najmanji workload tj. najmanj broj neodgovorenih zahtjeva (*eng. outstanding request*) te moze obraditi dolazeci zahtjev najprije. Dijagram pokazuje kako LOR algoritam prosljedjuje zahtjeve. Prolazenjem kroz sve EC2 instance, provjerava se koja ima najmanji workload. U ovom slucaju je to EC2 instanca `TASK 2`. U slucaju kada se doda nova instanca, ista ce da primi sve dolazece zahtjeve dok ne bude jednaka po workload-u sa ostalim instancama tj. dok se ne postigne balans.
*\*Animacija preuzeta sa blog posta* [*AWS Application Load Balancer algorithms*](https://medium.com/dazn-tech/aws-application-load-balancer-algorithms-765be2eca158) **LOR pros | cons** ✅ Redukuje kasnjenje tj. `latency` ❌ problem kod dodavanja novih instanci, jer moze doci do `flood`- previse zahtjeva za obradu po instanci ❌ Health check moraju da se rade dovoljno brzo kako bi sprijecili da instanca koja ce uskoro biti terminirana, uspije dobiti zahtjev jer ima najmanji workload i brze odgovara **Promjena Routing algoritma** Deafultni routing algoritam pri kreiranju je Round Robin. Naravno, moguce je promijeniti algoritam u postavkama na sljedeci nacin: 1. Otvorimo Amazon EC2 konzolu 2. U navigacionom panelu izaberemo **LOAD BALANCING** i izaberemo **Target Groups** 3. Izaberemo ime target grupe i otvorimo *details page* 4. Pod **Group details**, u sekciji **Attributes** izaberemo **Edit** 5. Na stranici **Edit attributes**, za *Load balancing algorithm* izaberemo RR ili LOR. 6. Save changes Za vise informacija mozete procitati clanak [Routing algorithm](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#modify-routing-algorithm) Vise o routing algoritmima mozete procitati na blog postu [Load Balancing - SAM WHO](https://samwho.dev/load-balancing/) #### Network Load Balancer **Network Load Balancer (NLB)** funkcionise na transportnom nivou OSI modela i prosljedjuje TCP/UDP saobracaj registrovanim `targets` kao sto su EC2 instance, *containers* i IP adrese, uspostavljanjem TCP/UDP konekcije izmedju klijenta i `targets` * koristi se u slucaju kada imamo dio resursa na on-permises data-centru sto zahtjeva upravljanje TCP i UDP saobracajem * NLB je u mogucnosti da podrzi milione zahtjeva po sekundi, s jako malim kasnjenjem #### Gateway Load Balancer **Gateway Load Balancer (GWLB)** radi na mreznom nivou OSI modela i omogucava izvrsavanje i skaliranje **3rd party appliances** - firewalls, intrusion detection systems, prevention systems GLB ima dvije glavne komponente: * **Gateway Load Balancer endpoints (GWLBE)** smjestenom u VPC-u u kojem zelimo pratiti saobracaj i moze se dodati u `route table` kao `next hop`. Uloga GWLBE jeste da preusmjeri paket ka GWLB koji ce daljim koracima proslijediti paket na provjeru. Takodje, ako je paket siguran za prosljedjivanje serveru tj. nasoj aplikaciji, GWLB ce paket vratiti ka GWLBE koji paket proslijedi dalje ka ALB-u a on dalje ka `target group`. * **Gateway Load Balancer (GWLB)** enkapsulira sav saobracaj koji ide od GWLBE ka `targets` koristeci [**GENEVE**](https://datatracker.ietf.org/doc/html/rfc8926) protokol. **GENEVE** protokol omogucava da paketi ostanu nepromjenjeni, sa istim source IP, destination IP kao kada su i kreirane i poslate. To omogucava da security appliances urade pravu provjeru paketa podataka, izvrse analize i prilagode pakete po potrebi. ### Amazon EC2 Auto Scaling **Amazon EC2 Auto Scaling** pomaze nam da u svakom trenutku imamo dostupan odgovarajuci broj EC2 instanci kako bismo omogucili normalno funkcionisanje i visoku dostupnost aplikacije. * **Auto Scaling group (ASG)** je kolekcija EC2 instanci, čiji broj odredjuje velicinu ASG-a na nacin da podesimo parametre: `minimum number` kao najmanji broj instanci koje ASG moze imati, a to je po preporuci **2 EC2 instance**. `desired number` je broj EC2 instanci koje zelimo imati kreirane odmah na pocetku i cilj je odrzavati ovaj broj konzistentnim sto je vise moguce. Ovaj broj mora biti u rasponu **\[ minimum number - maximum number )** `maximum number` najveci broj instanci koje mozemo imati i ujedno maksimalna velicina ASG
\**Slika preuzeta iz AWS documentation na* [*linku*](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) #### Launch Template Prije kreiranja Auto Scaling group potrebno je da kreiramo **Launch Template** sto predstavlja jedan vid sablona koji sadrzi informacije poput - ID AMI image, instance type u nasem slucaju `t2.micro`, key pair za login, security groups, EBS volume za podizanje EC2 instanci. Za razliku od `Launch Configuration`, `Launch Template` omogucava kreiranje vise verzija template-a. #### Auto Scaling Policies **Auto Scaling Policies** predstavljaju unaprijed definisane korake koji se izvrsavaju ako je neki od naznacenih uslova ispunjen, sto se odnosi na automatsko podizanje ili terminiranje EC2 instanci tzv. skaliranje kapaciteta Auto Scaling grupe. U primjeru zadatka za TASK 7 upoznali smo se sa **Dynamic scaling policies** koji daje instrukcije EC2 Auto Scaling da prati naznacenu Cloud Watch metriku i definise koje akcije je potrebno preduzeti u slucaju kada CloudWatch Alarm bude u stanju `Alarm`. EC2 Auto Scaling se brine o tome da kapacitet ASG nikada ne bude manji od `minimum size limit` i veci od `maximum size limit`. Kapacitet se mjeri na dva nacina: 1. **Capacity in terms of instances** gdje se radi sa brojem instanci koje se dodaju ili terminiraju 2. **Capacity units ( instance weighting is applied)** kada se radi o tezini tj. unaprijed definisanim vrijednostima kapaciteta `vCPU` i `Memory`. Vise o *instance weighting* procitati [ovdje](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups-instance-weighting.html) **Tipovi Dynamic scaling policies** 1. **Target tracking scaling** - povecava i smanjuje trenutni kapacitet ASG na osnovu Cloud Watch metrike i `target value`. Na primjer, kao `target metric` mozemo postaviti `CPUUtilization` i staviti `50%` sto znaci da kada CPU bude preko 50% potrebno je da scaling policy poveca broj instanci unutar ASG kako bi se CPU smanjio i odrzavao na vrijednosti sto blizoj 50%. Suprotno, ako CPU padne ispod 50%, potrebno je terminirati instance do broja oznacenog kao `minimum number`. 2. **Step scaling** - povecava i smanjuje trenutni kapacitet ASG na osnovu `step adjustments`. Definisemo speficicni prag tj. `treshold` za metriku, gdje je svaki `treshold` povezan sa specificnim scaling podesavanjem, kao sto je podizanje ili terminiranje instanci. Na primjer, ako bismo `treshold` postavili `70% CPU utilization` desice se `trigger` tj. okidac koji ce da poveca broj instanci. Ako postavimo jos jedan `treshold` na `80% CPU utilization` ako CPU nastavi da raste, kada dostigne `80%` podici ce se jos jedna instanca. 3. **Simple scaling** - definisemo fiksnu kriticnu vrijednost `single scaling adjustment`koja ce dovesti do povecanja ili terminiranja instanci sa mogucnoscu definisanja `cooldown perioda` izmedju svake scaling aktivnosti. Kako bismo pokrili vise scenarija, moguce je da ASG ima vise scaling policy-a. U slucaju kada dva scaling policy-a dodju u konflikt tj. situaciji kada jedan scaling policy radi **scale in** i povecava broj instanci, a drugi radi **scale out** i smanjuje broj instanci - EC2 Auto Scaling bira policy koji ce zadovoljiti oba uslova ili ostaviti najveci broj instanci unutar ASG. ### Load Balancer vs Auto Scaling Vazno je da razumijemo glavnu razliku izmedju Load Balancer-a i Auto scaling grupe. **Load Balancer** nam omogucava da postignemo visoku dostupnost, jer je zahvaljujuci *healt checks* u stanju da utvrdi koje instance nisu u statusu *healthy* te zna da takvim instancama prestaje slati saobracaj tj. requests. Takodje, zahvaljujuci algoritmima koje smo prethodno spomenuli, balansira dolazeci saobracaj ka instancama u target grupi kako ne bi doslo do opterecenja, naravno u zavisnosti koji algoritam koristimo. Kao manu **Load Balancera**, navescemo to da **nema mogucnost da zamijeni *****unhealthy***** instancu**, vec to moramo uraditi rucno ili automatizovanim procesom uz pomoc Auto Scaling grupa. **Auto Scaling grupe** ako govorimo o EC2 autoscaling-u, pomazu nam da kreiramo instance u vise razlicitih Availability Zona, ciji ce broj da se poveca ili smanji u zavisnosti od uslova koje smo postavili u Policy-u o cemu je takodje bilo rijeci u ovom tekstu. Auto Scaling Grupe koriste *health checks* od strane Load Balancera kako bi utvrdile koje instance trebaju biti zamijenjene tj. nisu u statusu *healthy*. Vise o ovome mozete procitati na [What is the main differences between an load balancer and a autoscaling group](https://repost.aws/questions/QUBf2Pm87iSsWkcpA3tF0EyQ/what-is-the-main-differences-between-an-load-balancer-and-a-autoscaling-group). ### Snimci predavanja #### DevOps Mentorship Program - Week 8 - AWS: ALB, High Availability, Security Groups ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} #### DevOps Mentorship Program - Week 8 - AWS: EBS, Auto Scaling Groups ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} ### Materijali za ucenje * [Elastic Load Balancing FAQs](https://aws.amazon.com/elasticloadbalancing/faqs/) * [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) * [Gateway Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) * [Dynamic scaling policy](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html) * [Cantril Gateway Load Balancer](https://www.youtube.com/watch?v=GZzt0iJPC9Q) # Week 9: Amazon S3, Amazon RDS **Amazon S3** je object-level storage. Object-level storage znaci da se podaci pohranjuju u "objektima" a ne hijerarhijskog strukturi direktorija. Svaki objekt ukljucuje podatke i metapodatke koji opisuju objekt. Svaki objekt u S3-u ima svoj jedinstveni kljuc (key) koji se koristi za identifikaciju objekta. Amazon S3 mozemo koristiti za: * Backup i arhiviranje podataka - Amazon S3 je dizajniran na nacin da omogucava 99.999999999% (11 9') durability i 99.99% availability. * Media storage i streaming * Static website hosting * Data lake * S3 Standard - Za generalnu upotrebu i za podatke kojima cesto pristupamo * S3 Standard-Infrequent Access (S3 Standard-IA) - Za podatke ciji durability nam je bitan ali im ne pristupamo toliko cesto * S3 One Zone-Infrequent Access (S3 One Zone-IA) - Za podatke ciji durability nam je bitan ali im ne pristupamo toliko cesto. Razlika izmedju S3 Standard-IA i S3 One Zone-IA je sto S3 One Zone-IA ima samo jednu Availability Zone dok S3 Standard-IA ima 3 Availability Zone-a. * S3 Glacier Instant Retrieval - za podatke koji su nam jako bitni ali im ne pristupamo toliko cesto. Podaci se mogu vratiti u roku od 1 minuta. * S3 Glacier Flexible Retrieval - za podatke koji su nam jako bitni ali im ne pristupamo toliko cesto. Podacima mozete pristupiti koristeci expedited, standard ili bulk retrieval opcije. Expedited retrieval je najbrzi ali najskuplji, standard retrieval je srednje brz ali jeftiniji, bulk retrieval je najjeftiniji ali najsporiji. * S3 Glacier Deep Archive - za podatke koji su nam jako bitni ali im ne pristupamo toliko cesto, odnosno mozemo ih arhivirati na duze vrijeme. Podaci se mogu vratiti u roku od 12 sati. * S3 intelligent tiering - za podatke za koje nismo sigurni na koji nacin im pristupamo, S3 intelligent tiering automatski prebacuje podatke iz S3 Standard u S3 Standard-IA ili S3 One Zone-IA u zavisnosti od frekvencije pristupa podacima #### Tipovi S3 Storage-a * S3 Standard - Za generalnu upotrebu i za podatke kojima cesto pristupamo * S3 Standard-Infrequent Access (S3 Standard-IA) - Za podatke ciji durability nam je bitan ali im ne pristupamo toliko cesto * S3 One Zone-Infrequent Access (S3 One Zone-IA) - Za podatke ciji durability nam je bitan ali im ne pristupamo toliko cesto. Razlika izmedju S3 Standard-IA i S3 One Zone-IA je sto S3 One Zone-IA ima samo jednu Availability Zone dok S3 Standard-IA ima 3 Availability Zone-a. * S3 Glacier Instant Retrieval - za podatke koji su nam jako bitni ali im ne pristupamo toliko cesto. Podaci se mogu vratiti u roku od 1 minuta. * S3 Glacier Flexible Retrieval - za podatke koji su nam jako bitni ali im ne pristupamo toliko cesto. Podacima mozete pristupiti koristeci expedited, standard ili bulk retrieval opcije. Expedited retrieval je najbrzi ali najskuplji, standard retrieval je srednje brz ali jeftiniji, bulk retrieval je najjeftiniji ali najsporiji. * S3 Glacier Deep Archive - za podatke koji su nam jako bitni ali im ne pristupamo toliko cesto, odnosno mozemo ih arhivirati na duze vrijeme. Podaci se mogu vratiti u roku od 12 sati. * S3 intelligent tiering - za podatke za koje nismo sigurni na koji nacin im pristupamo, S3 intelligent tiering automatski prebacuje podatke iz S3 Standard u S3 Standard-IA ili S3 One Zone-IA u zavisnosti od frekvencije pristupa podacima. ### Snimci predavanja #### DevOps Mentorship Program - Week 9 - AWS: Amazon S3, IAM Roles, S3 Bucket Policy ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} #### DevOps Mentorship Program - Week 9 - AWS: MySQL on EC2 vs Amazon RDS MySQL ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} ### Materijali za ucenje ### Korisni alati ### Zadatak ### Materijali za dodatno citanje # Week 10: Amazon RDS, Deploying Java App on AWS ### Snimci predavanja #### DevOps Mentorship Program - Week 10 - AWS: Amazon RDS Part 2 ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} #### DevOps Mentorship Program - Week 10 - Java App Development on AWS, S3, RDS ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} ### Materijali za ucenje ### Korisni alati ### Zadatak ### Materijali za dodatno citanje # Week 11: Amazon Virtual Private Cloud (VPC) **Amazon Virtual Private Cloud** ili skraceno **Amazon VPC** je AWS servis koji vam omogucava da kreirate i definisete virtuelnu mrezu unutar AWS cloud-a te da unutar te mreze smjestite vase resurse. Vi imate potpunu kontrolu nad tom mrezom u smislu odabira IP adresnog opsega koji ce VPC da koristi te definisanja pravila pristupa resursima unutar VPC-a. Amazon VPC je regionalni servis, sto znaci da kada kreirate VPC morate da odaberete AWS regiju unutar koje se on nalazi. VPC moze da obuhvate sve dostupne Availibility Zone (AZ) unutar te regije. Mozete kreirati vise VPC-eva unutar jedne regije i svaki je logicki izolovan od onog drugog. Prilikom kreiranja VPC-a morate definisati IPv4 opseg adresa (CIDR - Classless Inter-Domain Routing block) koje ce VPC da koristi. Kada kreirate VPC sa zeljenim opsegom adresa, taj opseg vise ne mozete da mijenjate. Kada kreirate Vas AWS racun, defaultni VPC je kreiran za vas. Preporuka od strane AWS-a je da ne brisete defaultni VPC jer se neki pojedini resursi unutar AWS racuna kreiraju unutar tog defaultnog VPC-a osim ukoliko prilikom njihovog kreiranja vi drugacije eksplicitno ne odredite. **Amazon VPC se sastoji od sljedecih komponenati:** * Subnets * Route Tables * IP Addressing * Security Groups * Network Access Control Lists ACLs * Internet Gateway * Network Address Translation (NAT) Instances and NAT Gateways * Egress Only Internet Gateways (EIGWs) * Virtual Private Gateways, Customer Gateways, Virtual Private Networks (VPNs) * VPC Endpoints * VPC Peering * Placement Groups * Elastic Network Interfaces * Dynamic Host Configuration Protocol (DHCP) Option Sets * Amazon Domain Name Service (DNS) Server * VPC Flow Logs **Subnets** Subnet ili podmreza predstavlja dio VPC-a koji se nalazi unutar jedne Availibity Zone. Dakle za razliku od VPC-a koji obuhvata citavu regiju i sve AZ unutar nje, subnet moze da obuhvata samo jednu AZ unutar te regije. Prilikom kreiranja subneta morate da odaberete AZ kojoj taj subnet pripada te da alocirate zeljene IP adrese iz opsega dodjeljenog VPC-u prilikom kreiranja VPC-a. Pa ukoliko smo za VPC odabrali CIDR blok 10.0.0.0/16 za subnet unutar tog VPC-a cemo odabrati manji adresni opseg npr: 10.0.0.0/24 **NOTE: AWS ce rezervisati prve cetiri i zadnju IP adresu unutar svakog subneta kojeg kreirate za internu upotrebu.** * **Javni / Public Subnet** - Pridruzena ruting tablela sadrzi rutu do internet gateway-a (igw) * **Privatni / Private Subnet** - Pridruzena ruting tabela nema rutu do internet gateway-a (igw) a moze sadrzavati rutu do NAT instance odnosno NAT gatway-a **Route Tables / Ruting tabele** Svaki subnet unutar vaseg VPC-a sadrzi logicki konstruktor koji se naziva **implicit ruter**. Implicit ruter je mjesto na kojem se donose odluke o rutiranju na nivou subneta. **Upravljanje rutiranjem se vrsi uz pomoc ruting tabela.** Vama je omoguceno da kreirate ruting tabele i tako definisete zeljene rute. Korisnicki kreirane ruting table mogu biti pridruzene jednom ili vise subneta. Svaki VPC sadrzi glavnu (main) ruting tabelu koju mozete mijenjati. Glavna ruting tabela se koristi za sve subnete unutar VPC-a kojima nije eksplicitno dodjeljena korisnicki kreirana route tabela. Korisnicki kreirana ruting tablea moze biti oznacena kao glavna sto omogucava da svi novi subneti koji kreirate automatski koriste tu ruting tableu bez da im je eksplicitno dodjelite. **IP Addressing / IP Adresiranje** Amazon VPC podrzava IPv4 i IPv6 protokol adresiranja. Prilikom kreiranja nove EC2 instance njoj se pridruzuje IPv4 privatna adresa iz opsega definisanog subnetom u kojem se ta EC2 instanca nalazi. Imate mogucnost definisanja privatne IP adrese ukoliko je ta adresa dostupna i naravno ukoliko se nalazi unutar definisanog opsega. Amazon EC2 instance takodjer mogu imati i javnu IPv4 adresu. Te adrese se dodjeljuju automatski prilikom kreiranja. Na nivou subneta imate mogucnost da definisete da li ce prilikom kreiranja resursa unutar subneta automatski biti dodjeljena javna ipv4 adresa. Vodite racuna da automatski dodjeljene javne IPv4 adrese nisu fixne, te se mogu promijeniti bez prethodne najave ili prilikom izmjena stanja EC2 instance. Ukoliko vam je potrebna fixna javna IP adresa imate mogucnost da alocirate IPv4 javnu adresu koja je rezervisane od strane AWS-a, nakon sto alocirali javnu adresu imate mogucnost da je pridruzite EC2 instanci. Tako alocirane javne ip adrese postaju pridruzene vasem racunu i one se ne mijenjaju bez obzira sta vi uradite sa instancom kojoj je ta adresa pridruzena. Takve adrese se nazivaju Elastic IP Addresses. **Security Groups / Sigurnosne grupe** Security Groups odnosno sigurnosne grupe predstavljaju virtuelni firewall koji kontrolise ulazni i izlazni saobracaj prema AWS resursima i EC2 instancama. Security grupe su na nivou instance, dakle uz pomoc security grupa ne mozete definisati pristup citavom subnetu nego samo resursima kojima je ta security grupa pridruzena. Uz pomoc security grupa imate mogucnost definisanja saobracaja kojeg zelite prihvatiti ali nemate mogucnost da definisete koji saobracaj zelite odbiti. (za to se koriste access control liste). Takodjer vazno je napomenuti da su sigurnosne grupe stateful sto znaci da ukoliko posaljete neki request prema vasoj EC2 instanci, saobracaj koji dolazi od strane EC2 instance kao odgovor na taj request je dozvoljen bez obzira na izlazna pravila vase sigurnosne grupe. **Network Access Control Lists (NACLs)** Network Access Control Lists ili NACL je dodatni nivou sigurnosti koji se za razliku od security grupa nalazi na na nivou subnet-a. ACL predstavlja numericki poredanu listu pravila kroz koju AWS prolazi, pocevsi od najmanjeg numerinsanog pravila, prilikom donosenja odluke da li je saobracaj dozvoljen prema i izvan subneta koji je pridruzen toj ACL. Svaka ACL ima finalno DENY odnosno pravilo za odbijanje koje ne mozete promijeniti. Svaki vpc ima autmatski kreiranju standardnu ACL koja je pridruzena svakom subnetu unutar tog VPC-a i ona dozvoljava sav dolazni i odlazni saobracaj. Kada kreirate novu ACL ona ce odbijati sav dolazni i odlazni saobracaj dok vi ne kreirate pravila koja kazu drugacije. Razlike izmedju Security Grupe i Network Access Control Lista | Security Gruoup | Network Access Control List (NACLs) | | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Rade na nivou mreznog interfejsa | Nalaze se na nivou subnet-a | | Podrzavaju samo pravila za dozvoljavanje saobracaja | Podrzavaju pravila za dozvoljavanje i za odbijanje saobracaja | | Stateful: Povratni saobracaj je automatski dozvoljen bez obzira na izlazna pravila | Stateless: Povratni saobracaj mora biti eksplicitno dozvoljen sa izlaznim pravilom | | AWS prolazi kroz sva pravila prije nego donese odluku da li je upuceni saobracaj dozvoljen ili nije | AWS prolazi kroz numericki poredana pravila pocevsi od najmanje vrijednosti da bi odlucio da li je saobracaj dozvoljen. Onog trenutka kad naidje na pravilo koje dozvoljava ili odbija saobracaj koji je upucen prestaje sa daljnjom provjerom. Poredak pravila je jako bitan! | **Internet Gateway (IGW)** Internet Gateway predstavlja horizontalno skalabilnu, redudantnu i visko dostupnu komponentu VPC-a koja dozvoljava komunikaciju izmedju instanci unutar VPC-a i interenta. Kada je saobracaj poslan sa EC2 instance prema internetu, igw prevodi privatnu ip4 adresu u pridruzenu javnu ip4. IGW radi to jedan na jedan mapiranje izmedju javnih i privatnih adresa. Kada instanca prima saobracaj sa interenta internet gateway prevodi destinacijsku javnu IPv4 adresu u odgovarajucu privatnu adresu EC2 instance i prosljedjuje saobracaj unutar VPC-a. Da bi unutar vaseg VPC-a kreirali javni subnet (podmerezu) gdje ce resursi koji se nalaze unutar istog biti dostupni sa interneta i imati izlaz na internet VPC mora imati pridruzen igw. Pored toga potrebno je definisati pravilo rutiranja unutar ruting tabele gdje se sav ne-lokalni saobracaj (0.0.0.0/0) salje na igw. Pored navedenog neophodno je i da pravila definisana unutar ACL i SG dozvoljavaju zeljeni saobracaj. Jos jedan od preduslova da bi instanca bila u mogucnosti da salje i prima saobracaj sa interneta koji mora biti ispunjen je da ona ima pridruzenu javnu IP adresu. **NAT Instances and NAT Gateways** Prema definiciji niti jedna instanca koja se nalazi u privatnom subnetu ne moze da komunicira direktno sa interentom koristeci internet gateway. Sto je jos vaznije konekcije koje dolaze van vaseg VPC-a ne mogu da komuniciraju sa instancama koje se nalaze unutar privatnog subnet-a. Postoje slucajevi kao sto su preuzimanja sigurnosnih azuriranja, instalacije aplikacija sa interneta, kada je neopohodno omoguciti instancama koje se nalaze unutar privatnog subneta izlaz na interent. Da bi to postigli neophodno je da koristimo NAT instance ili NAT gateway. **NAT gateway** NAT gateway je AWS servis koji je dizajniran da bude visoko dostupan unutar AZ i ima zadatak da omoguci izlaz na interent resursima koji se nalaze unutar privatnog subneta. NAT gateway radi nesto sto se zove *IP masquerading* ili maskiranje IP adresa i to na nacin da se cijeli jedan CIDR blok privatnih IP adresa "krije" iza jedne javne IP adrese koja je dodijeljena NAT gateway-u. Dakle, kada instanca sa privatnom IP adresom iz privatnog subneta zeli izaci van svog VPC-a, bez da joj se dodijeli posebna javna IP adresa, tu nastupa NAT gateway koji ce ustupiti svoju javnu IP adresu. Sa ovom javnom IP adresom NAT gateway nastavlja rutiranje ka Internet gateway-u i omogucava se izlaz na mrezu. NAT gateway postavlja se u public subnet unutar AZ i predstavlja samo *next hop* izmedju privatnog subneta i internet gateway-a. Privatni subnet u default routing table upisuje NAT gateway, dok NAT gateway u routing table upisuje Internet gateway cime je obezbjedjeno povezivanje. Vazno je zapamtiti da sa koristenjem NAT gateway-a nemamo mogucnost dvosmjerne komunikacije putem mreze. Razlog tome je sto instance u slucaju koristenja NAT gateway-a mogu postaviti samo outbound pravila, ali ne i inbound pravila jer servis koji bi htio poslati nesto nasoj instanci, zna samo javnu IP adresu NAT gateway-a ali ne i adresu nase instance te ne moze specificirati kojoj tacno adresi tj. instanci je namijenjen paket ili request koji se salje. **NAT instance** Prije pojave NAT serivsa, da bi instancama unutar privatnog subneta omogucili izlaz na interent bilo je neophodno da manuelno kreirate NAT instancu i da je samostalno odrzavate. NAT instance su EC2 instance koje su obavljale posao koji sada radi NAT gateway. Svaka EC2 instanca ima ENI (Elastic Network Interface) koji simulira rad mrezne kartice kod stvarnih racunara. EC2 po defaultu radi filtriranje podataka te odbacuje sve one podatke cija source ili destination adresa nije adresa ENI-a tj. adresa EC2 instance. Ovaj proces obavlja Source/Destination check. Kada se radi NAT proces, onda kao source adress ili destinatin adress imamo adrese drugih servisa ili instanci, a kako ovaj saobracaj ne bi bio *dropped* moramo onemoguciti Source/destination check na EC2 instanci. Ovime nasa EC2 instanca postaje NAT instance i obavlja NAT proces. ### Snimci predavanja #### DevOps Mentorship Program - Week 11 - AWS: Amazon CloudFront, Amazon VPC ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} #### DevOps Mentorship Program - Week 11 - AWS: Amazon VPC Peering ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} ### Materijali za ucenje ### Korisni alati ### Zadatak ### Materijali za dodatno citanje # Weel 12: AWS Lambda, EventBridge, SQS, SNS ### AWS Lambda ***Lambda*** je AWS *event-driven servis* ciji je osnovni zadatak izvrsavanje **Lambda funkcije** onda kada se desi okidac tj. **trigger** a koji je izazvan dogadjajem koji se desio - **event**. Lambda servis ce izvristi Lambda funkciju specijalnizovanu za handle-ovanje tog event-a. Dakle, u ovom slucaju **ne znamo gdje se nasa funkcija u pozadini izvrsava**, ali to za nas nije od kljucne vaznosti. **Lambda funkcija** je dio koda koji Lambda servis izvrsava. Kada kreiramo Lambda funkciju, potrebno je da izaberemo jezik u kojem pisemo kod funkcije odnosno **runtime** koji ce funkcija koristiti. Tada se kreira i **runtime enviroment**, okruzenje podeseno na osnovu jezika koji smo izabrali za nasu Lambda funkciju. #### Runtime enviroment **Runtime enviroment** ima svoju memoriju **direct memory** koju alociramo unaprijed pri kreiranju Lambda funkcije, a jedan dio memorije ce biti odvojen za **virtual CPU**. * ***Alokacija memorije od 128MB do 1024MB sa 1MB koracima*** * ***1769 MB memorije dodjeljuje 1 vCPU*** Ne mozemo sami izabrati velicinu CPU koju zelimo, vec ce se taj dio odvojiti zavisno od memorije koju smo alocirali. Ovaj nacin dodjele CPU-a je **indirektan**. * ***Runtime enviroment ima alociranu dodatnu memoriju za fajlove u folderu /tmp - 512 MB, koja moze da se poveca do 10240 MB - dozvoljeno je koristenje ali /tmp folder je prazan pri svakom novom pozivu funkcije jer se tu cuvaju temporary files*** Izborom jezika koji ce biti koristen za izvrsenje koda, odredjuje se i koje komponente ce nam biti dostupne. ***Svaki put kada se Lambda funkcija pozove na izvrsenje, kreira se novi runtime enviroment sa svim potrebnim komponentama koje Lambda funkcija zahtjeva za adekvatno izvrsenje. Kod se ucita, izvrsi i terminira.*** ***Lambda funkcije su stateless*** Sto znaci *no data left from pevious invocation*. Nakon svakog novog poziva, pokrece se "cisto" radno okruzenje, bez zaostalih fajlova iz prethodnih poziva. Lambda funkciju osim kao *samo dio koda* mozemo posmatrati i kao paket koji sadrzi sve potrebne postavke za izvrsenje - **deployment package**. Kada se desi event i Lambda funkcija je pozvana na izvrsenje, deployment paket se preuzme i izvrsi unutar podesenog runtime enviroment-a. ### CloudWatch Events **CloudWatch Events** dostavljaju *stream* ili veci broj eventa koji su se desili nekim od AWS servisa, sto se desava skoro pa real-time uz mali delay. Na primjer, CW Events mozemo koristiti da obavjesti Lambda funkciju da se desilo terminiranje EC2 instance i treba nesto poduzeti. * Postoji **samo jedan** Event Bus koji nije prikazan unutar User Interface-a, iako smo u interakciji s njim kada trazimo evente i saljemo te evente ka target servisima kada zelimo da se nesto desi ### Amazon EventBridge **EventBridge** ima iste funkcionalnosti kao i CloudWatch Events uz dodatnu mogucnost hendlovanja eventima od strane third-parties application ili custom application. Iz ovih razloga, preporuka je da se polako krene u migraciju sa CW Events na EventBridge. * Pored defaultnog Event Bus-a, mozemo kreirati dodatne bus-ove bilo da su namijenjeni nasoj aplikaciji ili third-parties aplikacijama #### Kljucni koncepti **Ako se desi X, Y puta... uradi Z** * **X** predstavlja servis koji kreira event **producer of an event** * **Y** broj puta koliko se nesto desilo ili period vremena, za specifikaciju koristimmo UNIX cron format koji omogucava da specificiramo jedan ili vise puta kada se nesto treba desiti * **Z** je target servis kojem se dostavlja event da se dogadjaj X desio * Oba servisa imaju istu baznu arhitekturu, koriste default entity - ***Event Bus***, te imaju default event bus za AWS account ***Event Bus*** mozemo zamisliti kao pokretnu traku sa koferima na aerodromu. Gdje bi koferi predstavljali evente, aerodrom je nas AWS account, putnici su AWS servisi koji preuzimaju evente, a stuff aerodroma su AWS servisi koji dostavljaju evente. Na traku, stuff postavlja kofere na kojima pisu podaci o putniku, traka nosi kofere, a putnik kada prepozna svoj kofer i podatke uzima svoj kofer sa trake i odlazi. Na slican nacin EventBridge prihvata evente od servisa unutar AWS accounta, nosi te evente, a servisi koji budu obavjesteni da im stize event, rade polling tog eventa sa trake i vrse dalju obradu. * Kod oba servisa kreiramo *rules* koji odgovaraju sablonima eventa koji dolaze u bus, kada se prepozna unutar bus-a event, odgovarajuci rule salje event dalje ka target servisu * Mozemo uraditi i schedule rules, kako bismo podesili sablone eventa koji se desavaju u neko specificno vrijeme i za to ponovo koristimo UNIX CRON system ### Amazon Simple Queue Service (SQS) SQS - Simple Queue Service nam pruza upravljanje redovima (queues) poruka. To je public service, znaci da je dostupan bilo gdje sa AWS public space endpoints pristupom. To ukljucuje privatni VPC ako ima konektivnost ka servisima. U potpunosti je upravljiv, npr. **kreiramo queue i onda servis dostavlja taj queue kao servis**. Queues su HA (highly available), tako da ne moramo da brinemo o replikaciji i izdrljivosti. Postoje dva tipa queues-a: * Standard queues - najvise se koristi, ali postoji mogucnost da ne dobijemo poruke organizirano. * FIFO queues - pruza i garantira nam da poruke dolaze organizirano, i kada dobijemo poruke, vidimo ih organizirano, **npr. poruka 1, poruka 2, poruka 3...**. Posmatrajmo Standard queues kao autoput sa vise traka, dok je FIFO queues kao put sa jednom trakom bez prilike da bilo koga preteknemo. Standard queues nam garantira barem jednu isporuku ali ne garantira order te isporuke. Sa standardnim queues mozemo dobiti istu poruku dostavljenu 2x i order moze biti drugaciji. FIFO nam garantira order i isporuku tacno jednom. ### Amazon Simple Notification Service (SNS) SNS je **kljucna** komponenta mnogih arhitektura u AWS-u. SNS je **visoko dostupan, trajan, siguran, pub-sub messaging servis**. Vise o pub-sub servisu mozete pogledati [ovdje](https://aws.amazon.com/what-is/pub-sub-messaging/) * Potreban nam je network connectivity sa javnim AWS endpointom kako bi pristupili SNS-u. * Koordinacija slanja i primanja poruka. * Poruke su sadrzaji velicine do **256 KB**. * **SNS Topics su glavni entitet SNS-a** - Tu se permisije kontroliraju kao i vecina konfiguracija koja se definira. * Publisher salje poruke u TOPIC. * TOPICS imaju Subscribere i oni po defaultu primaju sve poruke koje se salju u TOPIC. * Subscriberi mogu da dodju u vise formi: HTTP(s), e-mail (JSON), SQS, Mobile Push, SMS poruke i Lambda . **HTTP(s)**: omogucuje slanje notifikacija putem HTTP(s) protokola. To je URL endpoint koji će primiti HTTP zahtijev sa sadrzajem notifikacije. Ova forma je veoma korisna kada bismo zeljeli da notifikacije stignu do web aplikacije. **E-mail (JSON)**: salju se notifikacije putem e-maila. Npr. navodi se adresa subscribera i onda notifikacija bude isporucena u JSON formatu putem e-mail poruke. **SQS (Simple Queue Service)**: SNS omogucuje integraciju sa SQS. Moze se subscribe-ati SQS queue na SNS topic, tako da svaka notifikacija bude dostavljena u queue kao poruka. **Mobile Push**: salju se notifikacije putem mobilnih push servisa. Uradi se subscribe mobilne aplikacije na SNS topic, a notifikacije će biti dostavljene putem push servisa na uredjajima korisnika. **SMS poruke**: moze se pretplatiti telefonski broj kao subscriber, a notifikacija će biti isporucena kao SMS poruka. **Lambda**: SNS moze pozvati cak Lambda funkciju kao subscribera. Kada se notifikacija posalje na SNS topic, Lambda funkcija će biti automatski pokrenuta i moci ce obraditi notifikaciju na zeljeni način. ### Amazon API Gateway * API Gateway omogucava kreiranje i upravljanje APIs (engl. *Application Programming Interface*). * API predstavlja softverski mehanizam koji pojednostavljuje *development* na nacin da radi apstrakciju detalja implementacije, prikazuje samo one detalje i objekte koji su potrebni developeru, te uspostavlja nacin komunikacije izmedju pruzatelja usluge i korisnika. * API Gateway je *highly available* i *scalable* servis. **API Gateway Endpoint types** 1. *Regional* - klijenti se nalaze u istoj regiji 2. *Edge-optimized* - koristi CloudFront 3. *Private* - moze se koristiti samo unutar VPC **RESTful API Gateway** 1. *REST API* * developer ima punu kontrolu nad zahtjevima i odgovorima 2. *HTTP API* * jednostavniji i jeftiniji za koristenje * manje kasnjenje * ne pruzaju mogunosti potpune kontrole nad zahtjevima i odgovorima **Autorizacija i autetifikacija API Gateway** 1. *None* - otvoreni pristup 2. *IAM* - koristenje *IAM* servisa i *IAM Credentials* za pristup 3. *JWT* - JSON Web Tokens se koriste u pozadini za provjeru autenticnosti zahtjeva kada se koristi OpenID Connect ili OAuth 2.0. REST APIs mogu koristiti Amazon Cognito kao JWT *authorizer*. 4. *Lambda authorizers* - koristi se lambda funkcija za provjeru tokena ili se zahtijevaju parametri za odobravanje pristupa **Monitoring tools** 1. *CloudWatch* - po *default*-u API Gateway svaku minutu salje odredjene metrike prema *CloudWatch* servisu 2. *AWS X-Ray* - prati i analizira zahtjeve *end-to-end* 3. *AWS Config* - procjena i pregled azuriranja konfiguracije 4. *AWS CloudTrail* - upravlja pozivima koji su upuceni prema API Gateway-u od strane korisnika, role ili nekog drugog AWS servisa. ### Snimci predavanja #### DevOps Mentorship Program - Week 12 - Serverless, AWS Lambda, EventBridge ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} #### DevOps Mentorship Program - Week 12 - Amazon SNS, Amazon SQS ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) PART I {% embed url="" %} #### DevOps Mentorship Program - Week 12 - Alma Kazija - Amazon API Gateway ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) PART II {% embed url="" %} ### Materijali za ucenje ### Korisni alati ### Zadatak ### Materijali za dodatno citanje * [Connecting SNS to SQS: Fanout SNS Topics to SQS Queues](https://blog.awsfundamentals.com/amazon-sns-to-sqs) # Week 13: Sta je DevOps, kako biti uspjesan kao DevOps praktikant U 13. sedmici DevOps mentorship programa sa gostima predavacima Viktrom Farcicem i Urbanom Jurcom smo razgovarali o tome sta je DevOps i kako biti uspjesan kao DevOps praktikant. Pored toga ragovarali smo o AWS servisu AWS Elastic Beanstalk. Predavanja o AWS Elastic Beanstalk servisu mozete pronaci u dijelu AWS Service Notes na stranici [AWS Elastic Beanstalk](/amazon-web-services-aws/aws-service-notes/aws-elastic-beanstalk) ### Snimci predavanja ## DevOps Mentorship Program - Week 13 - Viktor Farcic - What is DevOps? {% embed url="" %} #### DevOps Mentorship Program - Week 13 - Urban Jurca - How to be successful as a DevOps? \[On English] {% embed url="" %} ### Materijali za ucenje ### Korisni alati ### Zadatak ### Materijali za dodatno citanje * [The Phoenix Project](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/books/the-phoenix-project.pdf) # Week 14: Server management alati ### Machine Images / Slike Servera Svaki server kojeg pokrenete bilo unutar on-prem okruzenja ili u cloud okruzenju je baziran na nekoj slici servera (eng. Machine image - Zbog lakseg razumijevanja i ujednacenosti sa standardnom IT terminologijom u nastavku cemo koristiti termin ***Image***). Image predstavlja sablon odnosno template koji unutar sebe sadrzi prekonfigurisani operativni sistem i predinstlairane potrebne aplikacije. Image koristite da krairate nove ili klonirate postojece hostove. U zavisnosti od toga koju platformu koristite Image moze biti u razlicitim formatima. Npr. AWS koristi AMI (Amazon Machine Image) format, dok Azure koristi VHD (Virtual Hard Disk) format, vmWare koristi VMDK (Virtual Machine Disk) format itd.
### Golden Image Golden Image predstavlja predifisnisanu i pre-konfigurisani image koji cemo korisiti kao osnovu za sve hostove koje kreiramo. ### Packer Packer je besplatni open-source alat, razvijen od komapnije HashiCorp i napisan u programskom jeziku GO, koji se koriste za kreiranje Images. Packer vam dozvoljava da kreirate iste images za razlicite platforme. Npr. mozete kreirati isti image za AWS, Azure, vmWare, VirtualBox itd. Packer je takodje integriran sa razlicitim alatima za konfigurisanje servera kao sto su Ansible, Chef, Puppet, SaltStack itd. Packer koristi JSON konfiguracione fajlove za definisanje sta zelite da se nalazi unutar image-a. Packer je cross-platform alat i moze se koristiti na Windows, Linux i Mac OS operativnim sistemima. Packer mozete koristiti za razlicite scenarije i taskove medjutim dva najecsca razloga zasto da koristite Packer su konzistentnost images koje kreirate i mogucnost integracije u vas CI/CD pipeline. Korisne packer komande: ``` $ packer build -var-file=variables.json template.json $ packer fmt . $ packer validate template.json $ packer build -on-error=ask -debug your-template.json ``` ### Configuration Managment / Server Configuration Management / Upravljanje Konfiguracijama Servera Kako bi bili u mogucnosti da upravljavmo konfiguracijama (eng: configuration management) velikog broja servera na automatizovan, konzistentan, skalabilian i nacin koji mozemo jednostavno da reporoduciramo potreban su nam alati za upravljanje konfiguracijama servera odnosno server konfiguration menadzment alati. Upravljanje konfiguracijama servera je proces automatskog upravljanja konfiguracijama servera. Ovaj proces se sastoji od dva dijela: * **Provizioniranje** - Instalacija OS-a i aplikacija na servere * **Konfigurisanje** - Konfigurisanje aplikacija na serverima #### Imperative vs Declarative Imperativni i deklarativni pristupi su dvije različite paradigme koje se koriste u upravljanju serverima i automatizaciji. Osnovne razlike su: * **Imperative** - Imperativni pristup: U ovom pristupu, definirate kako postići željeno stanje. To znači da se fokusirate na korake ili operacije koje trebate izvršiti kako biste postigli željeno stanje. Na primjer, možete reći: "Instalirajte X softver, zatim konfigurirajte Y datoteku na ovaj način, a zatim pokrenite Z servis". Ovaj pristup je korak-po-korak i često uključuje ručnu intervenciju ili niz skripti koje izvršavaju specifične zadatke. Primjer imperativnog pristupa: ```bash $ export PDSH_SSH_ARGS_APPEND="-i /Users/ddzevlan/Downloads/week-8.pem" # SSH key za AWS instancu $ pdsh -w ^hosts.txt sudo yum -y install java # hostname komanda na svim serverima $ PDSH_SSH_ARGS_APPEND="-o StrictHostKeyChecking=no" pdsh -l ec2-user -w ^ip-addresses ./start-testing.sh ``` * **Declarative** Deklarativni pristup: U ovom pristupu, definisete sta zelite postici, ali ne i kako to postici. Na primjer, umjesto da definisete niz koraka za postavljanje servera, samo definisete zeljeno stanje (npr. "X softver treba biti instaliran, Y datoteka treba izgledati ovako, Z servis treba biti pokrenut"), a alat za upravljanje konfiguracijama (kao što su Ansible, Puppet, Chef ili SaltStack) odgovoran je za utvrđivanje kako postići to stanje. Ako stanje već postoji (npr. ako je softver već instaliran), alat neće ništa raditi; ako stanje ne postoji, alat će poduzeti potrebne korake za postizanje tog stanja. Deklarativni pristup je često poželjniji u upravljanju serverima i DevOps-u, jer omogućuje veću konzistentnost, pouzdanost i automatizaciju. Također olakšava upravljanje velikim brojem servera, jer samo trebate definirati željeno stanje, a ne brinuti se o pojedinačnim koracima potrebnim za postizanje tog stanja. #### Popularni alati za upravljanje konfiguracijama servera Postoji nekoliko popularnih alata za upravljanje infrastrukturom. Evo nekoliko najpoznatijih: * **Ansible**: Ansible je alat za upravljanje konfiguracijama koji koristi deklarativni pristup i ne zahtijeva instalaciju agenta na ciljanim serverima. Koristi se za automatizaciju postavljanja i konfiguracije servera, aplikacija i drugih IT potreba. Ansible koristi YAML za pisanje skripti, što ga čini lako čitljivim i razumljivim. * **Puppet**: Puppet je jedan od najstarijih alata za upravljanje konfiguracijama i koristi deklarativni pristup. Puppet koristi vlastiti opisni jezik i zahtijeva instalaciju agenta na svakom serveru koji upravlja. * **Chef**: Chef je još jedan popularan alat za upravljanje konfiguracijama. Chef koristi Ruby kao jezik za pisanje "receita" (skripti) koje definiraju konfiguraciju sistema. Kao Puppet, Chef također koristi model sa agentom. * **SaltStack (Salt)**: Salt je sličan Ansible u mnogim aspektima, uključujući upotrebu YAML-a za definiranje konfiguracija. Međutim, Salt može raditi u modu s agentom (kao Puppet i Chef) ili bez agenta (kao Ansible). #### Immutable vs Mutable Infrastructure Koncepti mutabilne i imutabilne infrastrukture odnose se na način na koji se upravlja promjenama u infrastrukturi. Evo osnovne razlike: * **Mutable Infrastructure** - Mutabilna infrastruktura: Tradicionalni pristup upravljanju infrastrukturom je mutabilan. To znači da se serveri i aplikacije mijenjaju tijekom vremena. Na primjer, kada se ažurira softver, dodaju se nove značajke ili popravljaju sigurnosni propusti, te promjene se primjenjuju direktno na postojeću infrastrukturu. Ova promjena može biti ručna ili automatizirana (koristeći alate za upravljanje konfiguracijama kao što su Ansible, Puppet, ili Chef), ali rezultat je isti: postojeći entiteti se mijenjaju tijekom vremena. * **Immutable Infrastructure** - Imutabilna infrastruktura: Sa druge strane, imutabilna infrastruktura tretira infrastrukturu kao nepromjenjivu: jednom kada se entitet (kao što je server ili kontejner) pokrene, on se ne mijenja. Umjesto ažuriranja postojeće infrastrukture, nova verzija infrastrukture se izgrađuje od nule, a zatim zamjenjuje staru verziju. To znači da nema "in-place" ažuriranja, konfiguracijskih promjena, ili popravaka na postojećim entitetima. Kada su potrebne promjene, novi entiteti se stvaraju sa novom konfiguracijom i zamjenjuju stari entiteti. Ovaj pristup često se koristi u kontekstu "infrastructure as code" i DevOps praksi. Imutabilna infrastruktura može poboljšati pouzdanost i predvidljivost infrastrukture, jer eliminira mogućnost konfiguracijske razlike odnosno "drift" (kada se stanje infrastrukture mijenja u nepredvidljive načine tijekom vremena) i smanjuje utjecaj ljudskih pogrešaka. Međutim, zahtijeva i sofisticiranije alate i procese, kao što su kontinuirana integracija i isporuka (CI/CD), te virtualizacija ili kontejnerizacija. #### Ansible Ansible je alat za upravljanje konfiguracijama servera koji koristi deklarativni pristup i ne zahtijeva instalaciju agenta na serverima. Ansible koristi YAML za pisanje skripti, što ga čini lako čitljivim i razumljivim. Ansible koristi DSL (Domain Specific Language) [**Ansible configuration file**](https://docs.ansible.com/ansible/latest/reference_appendices/config.html) Datoteka `ansible.cfg` je konfiguracijska datoteka koja se koristi za konfigurisanje različitih opcija i postavki za Ansible. Ova datoteka može biti prisutna u vasem radnom direktoriju ili u `/etc/ansible` direktoriju (globalna konfiguracija). Konfiguracijski fajl mozete generisati koristeci: ``` $ ansible-config init --disabled -t all > ansible.cfg ``` Unutar datoteke `ansible.cfg` mozete definisati različite opcije i postavke koje će utjecati na izvrsavanje Ansible-a. \[defaults] sekcija: Ova sekcija sadrži opće postavke za Ansible, kao što su putanje do inventory fajla, moduli koje koristi, izvršni direktorij i drugo. Primjeri opcija unutar \[defaults] sekcije: inventory: Putanja do inventara koji se koristi kao zadani. remote\_user: Zadani SSH korisnik za konekciju na remote hostove. module\_name: Zadani naziv modula koji se koristi za izvršavanje zadataka. roles\_path: Putanja do direktorija koji sadrži Ansible role. \[privilege\_escalation] sekcija: Ova sekcija se koristi za konfiguriranje privilegiranog izvršavanja (escalation) zadatka. Ovdje možete postaviti opcije kao što su become (omogući privilegirano izvršavanje) i become\_method (metoda koja se koristi za privilegirano izvršavanje, npr. sudo). \[ssh\_connection] sekcija: Ova sekcija se koristi za konfiguriranje SSH veze s ciljnim čvorovima. Ovdje možete postaviti opcije kao što su ssh\_args (dodatni argumenti za SSH) i pipelining (omogući ili onemogući pipelining). \[ansible\_become] sekcija: Ova sekcija se koristi za konfiguriranje opcija privilegiranog izvršavanja. Ovdje možete postaviti opcije kao što su become (omogući privilegirano izvršavanje), become\_method (metoda za privilegirano izvršavanje) i become\_user (korisnik koji će postati privilegirani korisnik). Ovo su samo neke od opcija koje se mogu nalaziti u datoteci ansible.cfg. Možete prilagoditi ove opcije prema svojim potrebama ili dodati druge opcije koje su relevantne za vaše okruženje i konfiguraciju. Napomena: Ako datoteka `ansible.cfg` ne postoji, Ansible će koristiti zadane vrijednosti i postavke. #### Ansible Playbooks Ansible Playbook je prvi fajl koji cete napisati kada krenete da radite sa Ansiblom. Playbook je izraz koji se koristi za fajl koji predstavlja skriptu sa izmjenama koje zelimo napraviti. Playbook pisemo u YAML formatu. YAML je fromat slican JSON-u s tim da je lakse za citanje i pisanje. **NOTE: Validan JSON fajl je validan YAML fajl, ali ne i obrnuto.** **Anatomija Ansible Playbook-a** Ansible Playbook se sastoji od nekoliko elemenata: * `name` - Komentar koji opisuje i govori sta playbook radi * `become` - Opcija koja omogucava privilegirano izvrsavanje. Po defaultu je vrijednost `false`. Mozete je promijeniti na `true` ili `yes` sto znaci da ce se komande izvrsavati kao root korisnik. To je losa praksa. * `hosts` - Lista hostova na kojima ce se izvrsavati Ansible taskovi. Hostovi se mogu navesti u obliku liste ili grupisani. * `vars` - Varijable koje se koriste u playbooku. Varijable se mogu definisati u samom playbooku ili u posebnom fajlu. * `tasks` - Lista taskova koji se izvrsavaju na hostovima. Taskovi se izvrsavaju po redoslijedu u kojem su navedeni. #### Ansible Modules Ansible Modules su skripte koje dolaze zapakovane skupa sa Ansiblom i omogucavaju izvrsavanje razlicitih operacija na ciljnim hostovima. Da bi vidjeli dokumentaciju modula izvrsite komandu: ``` $ ansible-doc ``` **Ansible Roles** Ansible Roles su najbolji nacin za organizovanje i ponovno koristenje Ansible koda. Ansible role je direktorij koji sadrzi sve sto je potrebno da bi se izvrsio odredjeni zadatak. **Ansible Inventory file** Ansible inventory je datoteka koja sadrži listu hostova na kojima će se izvrsavati Ansible taskovi. Ansible inventory može biti u razlicitim formatima, kao što su INI, YAML ili JSON. Ansible inventory moze sadrzavati i grupisane hostove, sto vam omogucava da grupisete hostove prema razlicitim kreterijima (npr. development, production itd). **Ansible Commands** ```bash $ ansible-playbook webserver.yml $ ansible-playbook webserver.yml --check # dry run mode $ ansible-playbook -i inventory/prod.ini webserver.yml $ ansible all -a "hostname" $ ansible-vault encrypt $ ansible-vault view | ansible-vault edit ``` #### EC2 Image Builder EC2 Image Builder je AWS-ov servis koji vam omogućuje da automatizirate proces kreiranja, održavanja i ažuriranja sigurnih i upotrebljivih AMI-ja (Amazon Machine Images). EC2 Image Builder vam omogućuje da definišete konfiguraciju operativnog sistema, softvera i ažuriranja paketa, a zatim da kreirate AMI-je na osnovu te konfiguracije. #### AWS Systems Manager AWS Systems Manager je AWS-ov servis koji vam omogućuje da centralizirano upravljate vašim AWS resursima. AWS Systems Manager vam omogućuje da automatizirate operacije i upravljate konfiguracijama vasih resursa unutar AWS cloud okruzenja. ### Snimci predavanja #### DevOps Mentorship Program - Week 14 - Server Configuration Management - Packer ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} #### DevOps Mentorship Program - Week 14 - Server Configuration Management - Ansible ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} ### Materijali za ucenje ### Korisni alati ### Zadatak ### Materijali za dodatno citanje * [YAML](/devops-learning-path/yaml) * [**Golden Image or Foil Ball? (repost)**](https://madstop.com/post/85950592485/golden-image-or-foil-ball-repost) * [**Packer Docs: Build an Image**](https://developer.hashicorp.com/packer/tutorials/aws-get-started/aws-get-started-build-image) * [**Packer Docs: Amazon AMI Builder**](https://developer.hashicorp.com/packer/plugins/builders/amazon) * [**Automated, immutable, and declarative**](https://justingarrison.com/blog/2022-11-04-immutable-declarative-automated/) * [**Ansible Documentation: Installing Ansible**](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html) # Week 15: Infrastruktura kao Kod (IaC) Postoji vise nacina na koje mozete kreirati i upravljati infrastrukturom unutar AWS. Nove resurse mozete podignuti koristeci korisnicki interfejs - AWS kozolu, komand line interfejs odnosno terminal ili koristeci Amazon Software Develpment Kit. Ukoliko manuelno kreiarte vase resurse, vrlo brzo cete shvatiti da taj pristup i nije najbolji, klikanjem kroz konzolu moze biti naporno i podlozno je greskama. Migracijom na cloud okruzenja omoguceno nam je da infrastrukturu konfigurisemo i radimo sa njom na drugacije nacine nego sto je to bio slucaj u standardnim data centrima. Kompletna infrastruktura vase aplikacije moze biti podignuta u nekoliko sekundi, skaliranje moze biti napravljeno bez unaprijed planiranog prosirenja kpaciteta a API svakog od servisa nam omogucava da sa njima komunicirarmo koristeci programske jezike koje vec koristimo za razvoj nasih aplikacija. Kako bi se dodatno udaljili od tradicionalnog manuelnog (rucnog) pristupa odrzavanju i konfiguraciji infrastrukture u upotrebu se uvelo nesto sto nazivamo Infrastruktura kao Kod. **Infrastructure as Code (IaC)** - je paradigma koja omogucava da se prema vasoj infrastrukturi odnosite na identican nacin kao i prema kodu bilo koje aplikacije. Zahvaljuci takvom pristupu vasa infrastruktura moze biti pohranjena unutar version kontrol sistema (git) gdje mozete pratiti izmjene napravljene nad vasom infrastrukturom,izvrsavati testove nad njom,ali takodjer planirati te kontrolisati izmjene. Takodjer vi na ovaj nacin uvijek imate poznato zadnje dobro stanje vase infrastrukture sto vam omogucava da uradite rollback izmjena ukoliko je doslo do problema. Neki od trenutno najpopularnijih alata za IaC su: * Amazon CloudFormation * Terrafrom * Plumi * Amazon CDK ### CloudFormation * **CloudFormation Template** * predstavlja dokument napisan u JSON-u ili YAML-u * definise LOGICKE resurse - ono STA kreiramo * koristi se za kreiranje ***Stack***-ova * **CloudFormation Stack** * koriste se za kreiranje FIZICKIH resursa iz logickih koji su definisani u ***template***-u * svaka izmjena nad logickih resursima unutar ***template*** fajla, nakon ***update***-a ***Stack***-a bice izvrsena nad fizickim resursima * brisanjem ***Stack***-a obrisati ce se i svi fizicki resursi * **Parametri** * **Template Parametri** prihvataju ***input***, ulazne podatke koji su uneseni putem Console/CLI/API. Koriste se za kreiranje ili ***update*** ***Stack***-a. * **Pseudo Parametri** - upravljane od strane AWS i zavise od okruzenja u kojem se kreira ***Stack*** * **AWS CloudFormation ChangeSet** - omogucava pregled izmjena nad resursima prije izvrsavanja nad ***Stack***-om * **Drift detection** - detekcija svih izmjena koje su izvrsene manuelno nad resursima koji su kreirani iz ***Stack***-a. ### Terrafrom
### Snimci predavanja #### DevOps Mentorship Program - Week 15 - Alma Kazija - IaC CloudFormation ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} #### DevOps Mentorship Program - Week 15 - Dragan Pavlovic - IaC Terrafrom ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} ### Materijali za ucenje ### Korisni alati ### Zadatak ### Materijali za dodatno citanje # Week 16: AWS CDK, AI on AWS ### Snimci predavanja #### DevOps Mentorship Program - Week 16 - Marin Radjenovic - AWS CDK ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} #### DevOps Mentorship Program - Week 16 - Marin Radjenovic - AI on AWS ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} ### Materijali za ucenje ### Korisni alati ### Zadatak ### Materijali za dodatno citanje # Week 17: CI/CD - Continuous Integration and Continuous Delivery/Deployment ### Snimci predavanja #### DevOps Mentorship Program - Week 17 - CI/CD ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1)\\ {% embed url="" %} #### DevOps Mentorship Program - Week 17 - CI/CD - AWS DevTools ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} ### Materijali za ucenje ### Korisni alati ### Zadatak ### Materijali za dodatno citanje # Week 18: Jenkins, Disaster Recovery on AWS ### Snimci predavanja #### DevOps Mentorship Program - Week 18 - CI/CD - Jenkins ([#tier](https://www.youtube.com/hashtag/tier)-1-group-2) {% embed url="" %} #### DevOps Mentorship Program - Week 18 - Disaster Recovery on AWS ([#tier](https://www.youtube.com/hashtag/tier)-1-group-1) {% embed url="" %} ### Materijali za ucenje ### Korisni alati ### Zadatak ### Materijali za dodatno citanje * [Disaster Recovery using Amazon Web Services (AWS) ](https://medium.com/@sqlheisenberg/disaster-recovery-using-amazon-web-services-aws-8a37b1a78925) * [\[AWS Whitepaper\] Disaster Recovery of Workloads on AWS: Recovery in the Cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html?did=wp_card\&trk=wp_card) * [\[AWS Whitepaper\] Disaster Recovery of On-Premises Applications to AWS](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-of-on-premises-applications-to-aws/abstract-and-introduction.html) * [\[AWS Well-Architected Framework\] - Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/reliability.html) # Week 19: Docker ### Snimci predavanja #### DevOps Mentorship Program - Week 19 - Docker {% embed url="" %} ### Materijali za ucenje ### Korisni alati ### Zadatak ### Materijali za dodatno citanje # Week 20: Building DevOps Blue/Green pipeline with Amazon ECS U 20. sedmici DevOps Mentorship programa smo radili na AWS workshop-u [Building DevOps Blue/Green pipeline with Amazon ECS](https://catalog.us-east-1.prod.workshops.aws/workshops/4b59b9fb-48b6-461c-9377-907b2e33c9df/en-US). ### Snimci predavanja #### DevOps Mentorship Program - Week 20 - Building DevOps Blue/Green pipeline with Amazon ECS - Part I {% embed url="" %} #### DevOps Mentorship Program - Week 20 - Building DevOps Blue/Green pipeline with Amazon ECS - Part II {% embed url="" %} ### Materijali za ucenje ### Korisni alati ### Zadatak ### Materijali za dodatno citanje # DevOps Mentorship Program - Office Hours Sesije Svako druge Subote organizovane su DevOps Mentorship Program - Office Hours sesije. Office Hours sesije su sluzile kako bi se napravila rekapitulacija obradjenih tema, odgovorilo na eventualna pitanja, kao i dale dodatne upute ako je to potrebno. Snimci sa Office Hours sesija su dostupni ispod: * [DevOps Mentorship Program - Office Hours 18.02.2023.](https://youtu.be/Ve7BY5WwRDw) * [DevOps Mentorship Program - Office Hours 04.03.2023.](https://youtu.be/NTlYCjF0ldY) * [DevOps Mentorship Program - Office Hours 19.03.2023.](https://youtu.be/x75Mg0BofFg) * [DevOps Mentorship Program - Office Hours 01.04.2023.](https://youtu.be/3OxR5wjBplE) * [DevOps Mentorship Program - Office Hours 15.04.2023.](https://youtu.be/w4GP-jHYffI) * [DevOps Mentorship Program - Office Hours 30.04.2023.](https://youtu.be/uaDfdZ-dK3o) * [DevOps Mentorship Program - Office Hours 13.05.2023](https://youtu.be/N8ff6se9gO4). * [DevOps Mentorship Program - Office Hours 27.05.2023.](https://youtu.be/SjPYe_uZT4s) * [DevOps Mentorship Program - Office Hours 17.06.2023.](https://youtu.be/VVjKOrplb4s) # DevOps Learning Path # YAML ## Uvod Kao DevOps praktikanti cesto koristimo razlicite konfiguracijske fajlove da bi alatima koje koristimo proslijedili odredjene informacije i konfiguracijska podesenja. Konfiguracijski fajlovi se najcesce pisu koristeci **DSL (Data Serialization Languages).** U racunarstvu (*eng. computing),* seralizacija oznacava proces prevodjenja strukture podataka ili stanja objekata u format koji moze da pohranjuje ili prenosi i kasnije rekonstruise na nacin da je razumljiv u razlicitim racunarskim okruzenjima. Neki od najpoznatijih DSL jezika su YAML, JSON i XML. Pored potrebe da se podaci predstave na nacin koji je lako citljiv i koji moze biti ponovo rekonstruisan bilo je potrebno omoguciti razlicitim programskim jezicima i racunarskim sistemima da razmjenjuju podatke na **interoperabilan** nacin (*interoperabilnost predstavlja sposobnost dvije ili vise komponenti ili sistema da razmjenjuju informacije i koriste informacije koje su razmijenjene*). ## YAML **YAML (*****YAML Ain’t Markup Language*****)** pripada grupi DSL jezika koji je kreiran da bi ljudima bio jednostavan za citanje i pisanje. Pored svoje jednostavnosti za citanje i pisanje, YAML radi odlicno sa modernim programskim jezicima. YAML za struktuisanje podataka koristi **indentaciju (eng. indentation**)**, nizove**, **mape** (parove *kljuc: vrijednost* / key: *value pairs*). Prije nego se detaljnije upoznamo sa YAML jezikom neophodno je da razumijemo sta svaki od ovih ranije pobrojanih pojmova za strukturiranja podataka predstavlja: * **indentacija (eng. indentation)** - odnosi se na nacin uredjivanja ili pomjeranja linija koda u odnosu na lijevu marginu radi vizuelne organizacije i strukturiranja blokova koda. Obicno se koristi tabulator (***tab***) ili niz razmaka (**space**) da bi se linije koda pomjerile udesno. **YAML koristi indentaciju (obicno sa razmacima) za oznacavanje hijerarhijske strukture podataka. Indentacija je vazna za odredjivanje koje elemente podatka cini dio drugih elementa (blokova).** * **mape -** se u YAML formatu definisu kao parovi **kljuc: vrijednost (key: value)**. Ova struktura podataka se u nekim jezicima naziva i kao **hash** ili **dictionary:** ```yaml sarajevo: 500000 zagreb: 800000 beograd: 1700000 podgorica: 200000 ``` Primjer mape sa setom osobina grupisanih zajedno bi bio: ```yaml sarajevo: drzava: "Bosna i Hercegovina" stanovnika: 500000 zagreb: drzava: "Hrvatska" stanovnika: 800000 beograd: drzava: "Srbija" stanovnika: 1700000 podgorica: drzava: "Crna Gora" stanovnika: 200000 ``` * **sekvence (nizovi / liste)** - (eng. Sequences arrays/lists) odnosno nizovi ili liste elemenata se u YAML-u predstavljaju kao lista elementa gdje svaki elemenat pocinje sa crticom i razmakom: ```yaml - sarajevo - zagreb - beograd - podgorica ``` * **skalari (brojevi / stringovi) -** predstavljaju osnovne elemente podataka kao sto su brojevi, stringovi, boolean (true/false) i null vrijednosti. U YAML-u, skalarne vrijednosti pisemo direktno. Brojevi se pisu kao brojevi, dok se stringovi pisu izmedju navodnih znakova: ```yaml broj: 123 string: "ovo je string" ``` Bitno je napomenuti da YAML podrzava ugnijezdjenja mapa i sekvenci sto znaci da se mape mogu koristiti kao vrijednosti unutar sekvenci i obrnuto, omogucavajuci slozenije strukture podataka. Ispod je jedan primjer slozene strukture podataka u YAML-u. ```yaml BiH: - grad: Sarajevo - stanovnika: 500000 Hrvatska: - grad: Zagreb - stanovnika: 800000 Srbija: - grad: Beograd - stanovnika: 1700000 CrnaGora: - grad: Podgorica - stanovnika: 200000 ``` **NOTE: Mape (Dictionary/Hash) su jednake bez obzira na poredak njihovih elemenata (eng. properties). U primjerima ispod mapa 1 je jednaka mapi 2.** ```yaml #PRIMJER MAPE 1 sarajevo: drzava: "Bosna i Hercegovina" stanovnika: 500000 #PRIMJER MAPE 2 sarajevo: stanovnika: 500000 drzava: "Bosna i Hercegovina" ``` **To nije slucaj sa listama, liste su poredane (eng. ordered) kolekcije podataka sto znaci da je poredak elemenata unutar liste bitan. Na primjeru ispod dvije liste nisu jednake iz razloga sto se poredak elemenata u listama razlikuje.** ```yaml # Lista 1 BiH: - sarajevo - mostar - tuzla - banjaluka - neum # Lista 2 BiH: - banjaluka - neum - mostar - tuzla - sarajevo ``` Takodjer bitno je napomenuti da je YAML superset JSON-a sto znaci da svaki validan JSON dokument takodjer predstavlja i validan YAML dokument. ## Dodatna Literatura Ukoliko zelite prosiriti svoje znanje o YAML-u preporuka je da pogledate sljedecu dodatnu literaturu: * [YAML Ain’t Markup Language (YAML™) version 1.2](https://yaml.org/spec/1.2.2/) * [YAML - Tutorials Point](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/resources/books/YAML_Tutorials_Point.pdf) # SSL - Secure Sockets Layer {% embed url="" %} **SSL** ili **Secure Sockets Layer** je protokol koji omogucava sigurnu komunikaciju te predstavlja unaprijedjenje TCP protokola na nacin da uvodi povjerljivost, integritet podataka, autentifikaciju servera i autentifikaciju klijenta. SSL se koristi za bezbijednost saobracaja koji se odvija preko HTTP protkola. Kako je SSL obezbjedjen od strane TCP protkola moze ga koristiti svaka aplikacija koja koristi, odnosno izvrsava se preko TCP protokola. SSL nudi jednostavan API sa soketima koji je slican API-ju koji nudi TCP protokol. Kada neka aplikacija hoce da koristi SSL ukljucuje se SSL klase i biblioteke. SSL se tehnicki nalazi u aplikacionom sloju ali iz perspektive programera to je transportni protokol koji koji pruza TCP usluge obogacene uslugama bezbjednosti. Na sljedecoj slici mozete vidjeti gdje se SSL nalazi unutar OSI modela.
Prilikom klijent server komunikacije preko SSL protokola komunikacija se odvija na sljedeci nacin: 1. Klijent salje spisak kriptografskih algoritama koje podrzava, zajedno sa klijentovim jednokratnim brojem 2. Server is tog spiska bira jedan simetrican kriptografski algoritam (npr: AES) i jedan algoritam javnih kljuceva (npr: RSA) i jedan MAC algoritam. Server nakon toga vraca klijentu svoj izbor, zajedno sa svojim jednokratnim brojem i certifikatom. 3. Klijent provjerava certifikat, izvlaci serverov javni kljuc, pravi PMS (PreMaster Secret) i kriptuje ga javnim kljucem servera. Nakon toga klijent salje serveru svoj izbor, zajedno sa svojim jednokratnim brojem i kriptovanom PMS. 4. Istom funkcijom za pripremu kljuce, klijent i server svako za sebe izracunava MS (Master Secret) na osnovu PMS i jednokratnih brojeva. Zatim se MS dijeli na dva kljuca za sifrovanje i dva MAC kljuca. Sve buduce poruke izmedju servera i klijenta ce biti sifrovane i autentifikovane pomoca MAC kljuca. 5. Klijent salje posebnu MAC poruku serveru, koja se koristi za potvrdu integriteta podataka. 6. Server salje klijentu posebnu MAC poruku, koja se koristi za potvrdu integriteta podataka. Na sljedecoj slici je prikazano kako izgleda SSL TLS handshake.
\*Slika preuzeta sa stranice [An overview of the SSL or TLS handshake](http://docs.blueworx.com/BVR/InfoCenter/V7/AIX/help/index.jsp?topic=%2Fcom.ibm.wvraix.voip.doc%2Fq009930_.html) ### Kako radi HTTPS Preduslov za sigurnu komunikaciju je da "vjerujete" da public key kriptografija i potpisivanje digitalnim potpisom rade kako treba. To znaci da su "vjerujete" sljedecim principima: * **Svaka poruka enkriptovana Serverovim javnim kljucem moze biti dekriptovana samo od strane Serverovog privatnog kljuca** * **Bilo ko sa pristupom Serverovom javnom kljucu moze verifikovati da je poruka (signature) mogla biti kreirana samo od strane nekoga ko ima pristup Serverovom privatnom kljucu.** Na sljedecoj slici mozete vidjeti pojednostavljeni prikaz HTTPS komunikacije.
### Certificate Authority **Certificate Authority CA** je entitet koji pohranjuje, potpisuje i izdaje digitalne certifikate. Kako bi mogli utvrditi da je server onaj za kojeg se predstavlja neophodan nam je Certificate Authority kako bi potvrdio njegov identitet. U primjeru sa slike iznad smo imali certifikat koji je potpisan od strane Google CA koji je potvrdio da je server koji salje poruku zaista server na kojem se nalazi web stranica sa domenskim imenom moja-web-stranica.com. Google CA se smatra Certified Authoritijem kojem mozemo vjerovati na interentu. Kao i bilo koji drugi CA, Google CA ima svoj par kljuceva. Jedan javni kljuc koji se koristi za potpisivanje certifikata, a drugi privatni kljuc koji se koristi za dekripciju poruka. Ako zelimo da nas web server koristi HTTPS vezu neophodno je da kreira svoj par kljuceva i da ga registruje kod CA. CA ce potpisati javni kljuc i vratiti nam certifikat koji mozemo koristiti za potvrdu identiteta servera. Proces registracije kljuca kod CA se zove Certificate Signing Request (CSR) i prikazan je na slici ispod.
Zahvaljujuci tome sto je Certificate Authority potpisao kljuceve koje server koristi, moze da se sprijeci Man in the Middle Attack gdje bi neka druga stranica / server mogao da se pretvara da je moja-web-stranica.com Na sljedecem [linku](https://docs.google.com/spreadsheets/d/e/2PACX-1vQ7Jtb4NxCSaEtCaisz2u3NQZcHejDUjI3Q-utBnL-C5E7w4crv6QZ9GRDb2bFGbLgUQsgQyF0Y8eoN/pubhtml) mozete vidjeti listu Certified Authoritija kojima vjeruje Chrome browser. ### Self Signed Certficates Ponekad nije neophodno da imate SSL certifikat potpisan od strane poznatog Certified Authoritija. Uzmimo za prijmjer da imate development okruzenje gdje zelite da enkriptujete svu komunikaciju. Potrebno je da kreirate par privatnog i javnog kljuca i nakon toga da kreirate CRS koji ce biti potpisan od strane vaseg vlastitog CA. Vlastiti CA kreirate na nacin da ste kreirali par kljuceva koji ce poptpisati kljuceve kreirane od strane servera u development okruzenju. Kako se radi o vasem vlastitom CA, tom certifikatu nece biti vjerovano ali kako se radi o development okruzenju vi mozete reci vasoj aplikaciji da vjeruje CA koji je koristen za potpisivanje certifikata. ### SSL Chain Of Trust Chain of trust (lanac povjerenja) u kontekstu SSL certifikata odnosi se na proces provjere valjanosti certifikata kako bi se osigurala sigurna veza izmedju browsera/klijenta i web servera. Lanac povjerenja sastoji se od niza certifikata koji se proteže od SSL certifikata krajnjeg korisnika do root certifikata, preko jednog ili više intermediate certifikata.
**Evo kako lanac povjerenja funkcionise za SSL certifikate:** * **Root certifikat:** Na vrhu lanca povjerenja je root certifikat, koji izdaje Certificate Authority (CA). Root certifikati su ugradjeni u web preglednike i operativne sisteme kao dio njihove liste pouzdanih certifikata. * **Intermediate certifikat(i):** Root CA izdaje intermediate certifikate, koji služe kao posrednici između root CA i krajnjih korisnika (SSL certifikata). Intermediate CA moze izdati SSL certifikate direktno krajnjim korisnicima ili drugim intermediate CAs, stvarajući lanac medjuposrednickih certifikata. * **SSL certifikat:** Na kraju lanca povjerenja je SSL certifikat koji je izdan od strane Intermediate CA. SSL certifikat se koristi za autentifikaciju web servera i šifriranje komunikacije izmedju browser i servera. Kada browser/klijent pokusava uspostaviti SSL/TLS vezu s web serverom, server salje svoj SSL certifikat, zajedno s potrebnim intermediate certifikatima. Browser provjerava lanac povjerenja na sljedeci nacin: * **Provjera valjanosti SSL certifikata:** Preglednik provjerava je li SSL certifikat važeći (npr. nije istekao) i potpisan od strane poznatog intermediate CA. * **Provjera intermediate certifikata:** Browser provjerava je li intermediate certifikat vazeci i potpisan od strane poznatog root CA ili drugog intermediate CA. * **Provjera root certifikata:** Browser uporedjuje root certifikat s onima iz svoje liste pouzdanih certifikata. Ako se root certifikat podudara s jednim od unaprijed instaliranih certifikata, lanac povjerenja smatra se ispravnim. Ako je lanac povjerenja ispravan, browser uspostavlja sifriranu vezu sa serverom koristeći SSL/TLS protokol. Ako lanac povjerenja nije ispravan, browser prikazuje upozorenje o sigurnosti, obavjestavajuci korisnika o potencijalnom problemu sa certifikatom ili sigurnoscu veze. Postoji nekoliko razloga zašto su intermediate certifikati važni: * **Dodatna sigurnost:** Koristenje intermediate certifikata pomaze u zastiti root CA (Certificate Authority) tako što se privatni kljuc root CA može drzati offline i na sigurnom mjestu. Ako bi privatni ključ root CA bio kompromitiran, to bi ugrozilo cijelu hijerarhiju povjerenja. Držanjem root CA offline, smanjuje se rizik od kompromitacije. * **Fleksibilnost i organizacija:** Intermediate certifikati omogucuju CA da organiziraju izdavanje certifikata po razlicitim kategorijama i namjenama. Npr, jedan intermediate CA moze biti zaduzen za izdavanje certifikata za e-trgovinu, dok drugi može biti zaduzen za izdavanje certifikata za bankarstvo. Ovo omogucuje bolju organizaciju i upravljanje certifikatima. * **Smanjenje rizika:** U slucaju da neki intermediate CA bude kompromitiran, posljedice su manje katastrofalne nego kad bi root CA bio kompromitiran. Ako je kompromitiran samo jedan intermediate CA, moze se povuci i zamijeniti, a ostatak PKI infrastrukture ostaje netaknut. * **Skalabilnost:** Koristenjem intermediate certifikata, CA može prosiriti svoju infrastrukturu kako bi podržao rast i razvoj poslovanja, bez potrebe za izmjenom root CA. Ukratko, intermediate certifikati dodaju dodatni sloj sigurnosti u hijerarhiju povjerenja, omogućavaju bolju organizaciju i upravljanje certifikatima, te pruzaju veću skalabilnost i fleksibilnost PKI infrastrukture. Neki od najpoznatijih root CA koji izdaju intermediate certifikate su DigiCert, Symantec, GoDaddy, Let's Encrypt, Comodo, GlobalSign, Thawte, i Entrust. ### Leaf Certificates **Leaf certifikati**, takodjer poznat kao end-entity certificate ili krajnji korisnicki certifikati, su SSL certifikati koji se koriste za autentifikaciju web servera i šifriranje komunikacije između web browsera i servera. Leaf certifikati se izdaju od strane intermediate CA, a ne od strane root CA. Leaf certifikati su najcesce SSL certifikati koji se koriste za HTTPS web stranice. U hijerarhiji povjerenja, leaf certifikat je izdan od strane intermediate CA ili u nekim slučajevima direktno od root CA. Kada web browser pokusava uspostaviti SSL/TLS vezu s web serverom, server salje svoj leaf certifikat i potrebne intermediate certifikate browseru kako bi se provjerila autenticnost certifikata kroz lanac povjerenja. Leaf certifikati sadrze sljedece informacije: * **Informacije o vlasniku:** Ime, organizacija, adresa i druge informacije o vlasniku certifikata. * **Javni kljuc:** Javni kljuc koji se koristi za sifriranje podataka u SSL/TLS komunikaciji. * **CA informacije:** Informacije o autoritetu za certificiranje koji je izdao certifikat (root CA ili intermediate CA). * **Vrijeme vazenja:** Period vazenja certifikata, nakon kojeg certifikat vise nije valjan i treba ga obnoviti. * **Digitalni potpis:** Digitalni potpis koji potvrduje autenticnost certifikata. U kontekstu PKI (Public Key Infrastructure), leaf certifikati su najniži u hijerarhiji povjerenja, ali igraju ključnu ulogu u šifriranju i autentifikaciji internetskog prometa. ### Setup Let's Encrypt SSL Certificate on EC2 Amazon Linux AMI3 (Nginx) U sljedecem primjeru cemo pokazati na koji nacin mozemo konfigurisati SSL Let's Encrypt certifikat na EC2 Amazon Linux 3 serveru koristeci Nginx web server. Za ovaj primjer cemo koristiti web aplikaciju i znanje koje smo stekli u tokom [Week-5](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/devops-mentorship-program/03-march/week-5-140323/00-class-notes.md) predavanja iz serije predavanja odrzanih tokom DevOps Mentorship Programa. To podrazumijeva da imamo EC2 instancu sa Amazon Linux 3 operativnim sistemom, Nginx web serverom i web aplikaciju koja je dostupna po HTTP protokolu na portu 80 koristeci nasu javnu IP adresu. 1. Kreirali smo Route 53 DNS zapis `http://ssl.awsbosnia.com/` i usmerili ga na nasu Public IP adresu nase EC2 instance na kojoj se nalazi nasa aplikacija. 2. Za kreiranje Lets Encrypt certifikata iskorisiti cemo [certbot](https://certbot.eff.org/) alat. Certbot je alat koji nam omogucava da automatski generisemo i instaliramo SSL certifikat. Na Amazon Linux Ami 3 cert bot cemo instalirati koristeci pip alat. ``` $ sudo dnf install python3 augeas-libs $ sudo python3 -m venv /opt/certbot/ $ sudo /opt/certbot/bin/pip install --upgrade pip $ sudo /opt/certbot/bin/pip install certbot certbot-nginx $ sudo ln -s /opt/certbot/bin/certbot /usr/bin/certbot $ sudo certbot certonly --nginx # I am feeling conservative :) you can use sudo certbot --nginx instead to automatize the process ``` Output komande `sudo certbot certonly --nginx`: ``` [root@ip-172-31-91-148 ~]# sudo certbot certonly --nginx Saving debug log to /var/log/letsencrypt/letsencrypt.log Please enter the domain name(s) you would like on your certificate (comma and/or space separated) (Enter 'c' to cancel): ssl.awsbosnia.com, www.ssl.awsbosnia.com Requesting a certificate for ssl.awsbosnia.com and www.ssl.awsbosnia.com Successfully received certificate. Certificate is saved at: /etc/letsencrypt/live/ssl.awsbosnia.com/fullchain.pem Key is saved at: /etc/letsencrypt/live/ssl.awsbosnia.com/privkey.pem This certificate expires on 2023-07-14. These files will be updated when the certificate renews. NEXT STEPS: - The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If you like Certbot, please consider supporting our work by: * Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate * Donating to EFF: https://eff.org/donate-le - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ``` Vidimo da su nasli ccertifikati na sljedecoj lokaciji: ``` Certificate is saved at: /etc/letsencrypt/live/ssl.awsbosnia.com/fullchain.pem Key is saved at: /etc/letsencrypt/live/ssl.awsbosnia.com/privkey.pem ``` 3. Kako bi NGINX mogao da primi HTTPS zahtijeve neophodno je da azuriramo NGINX konfiguraciju. ``` $ cp node-app.conf node-app.conf.bak # backup originalne konfiguracije ``` Nakon sto smo napravili backup upisujemo novi konfiguracijski fajl `node-app.conf`: ``` server { listen 80; server_name ; return 301 https://$server_name$request_uri; } server { listen 443 ssl; server_name ; ssl_certificate /etc/letsencrypt/live//fullchain.pem; ssl_certificate_key /etc/letsencrypt/live//privkey.pem; location / { proxy_pass http://127.0.0.1:8008; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } } ``` 4. Restartujemo NGINX web server: ``` $ sudo systemctl restart nginx ``` Nakon toga vidimo da mozemo pristupiti nasoj web aplikaciji preko sigurne HTTPS veze koristeci domensko ime`https:///`. ### Import Lets Encrypt into AWS Certificate Manager ``` # pozicioniramo se u folder sa certifikatima koje je generisao Lets Encrypt $ cd /etc/letsencrypt/live/ssl.awsbosnia.com/ ``` Dokumentacija za importovanje certifikata u AWS Certificate Manager se nalazi na [Importing certificates into AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html). ### Useful openssl commands **OpenSSL** je open source alat ([github repo](https://github.com/openssl/openssl) | [dokumentacija](https://github.com/allops-solutions/devops-aws-mentorship-program/blob/main/devops-learning-path)) koji se moze korisiti za upravljanje kljucevima i certifikatima, potpisivanje digiralnih potpisa i provjeru autenticnosti certifikata. ### Materijali za ucenje * [certbot - Intructions](https://certbot.eff.org/instructions?ws=nginx\&os=pip) * [certbot - Setting up automated SSL cert renewal](https://eff-certbot.readthedocs.io/en/stable/using.html#setting-up-automated-renewal) * [Configure SSL/TLS on Amazon Linux 2023](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2023.html) * [MIT OPEN COURSEWARE - SSL and HTTPS](https://youtu.be/q1OF_0ICt9A) * [Apache SSL](https://httpd.apache.org/docs/2.4/ssl/ssl_faq.html#aboutcerts) * [OpenSSL Certificate Authority - Create Self Signed Certificate](https://jamielinux.com/docs/openssl-certificate-authority/) # Amazon Web Services (AWS) # AWS Service Notes # Identity Access Management (IAM) **Identinty Access Management (IAM)** je AWS servis koji vam omogucava **autentifikaciju** i **autorizaciju** za rad sa AWS servisima unutar vaseg AWS racuna. Kada posaljete zahtjev prema AWS API-iju, bilo da radite sa servisima koristeci AWS konzolu,SDKs (Software Development Kit) ili AWS Command Line Interface (AWS CLI), IAM servis je taj koji verifikuje vas identitet i provjerava da li vam je dozvoljeno izvrsavanje zeljene akcije. IAM dakle kontrolise **KO (autentifikacija)** moze pristupiti vasem AWS racunu i **KOJE AKCIJE (autorizacija)** moze napraviti unutar AWS racuna. ### Jezik IAM Policy-a IAM Policy je napisan u JSON formatu. Svaki IAM Policy se sastoji od jednog ili vise **Statements**. Unutar **Statement** dijela mozemo imati sljedece elemente: * **Effect** - `The Why` - Oznacava da li ce request biti Allow / Allowed ili Deny / Denied * **Principal** - `The Who` - Ovaj element oznacava entitet / Entity kojem je pristup dozvoljen ili odbijen, primjetiti cete da ponekad Principa element nije sadrzan unutar Policy Statement-a. Ovaj element je jedino dostupan unutar **resource based** i **vpc-endpoint** polisija. Postoje cetiri moguca tipa **Principa** elementa: * **AWS** - Koristite AWS tip Principal Elementa da referencirate druge AWS racune, role, korisnike kao i Session Principals. AWS racun unutar principal elementa moze biti napisan na dva nacina: * `arn:aws:iam::123456789012:root` - ARN koji sadrzi ID AWS racuna * `123456789012` - ID AWS racuna bez `-` znakova U oba ova slucaja principal je AWS account sa ID-em `123456789012` * **Service** - Service Principal se koristi na nivou resursa da dozvoli pristup AWS servisu. Kada napisete AWS policy koji koristi Service Principal type obicno bi trebali ukljuciti Condition key element koji specificira source ARN ili source Account odakle request dolazi. Npr: ``` { "Effect": "Allow", "Principal": { "Service": "cloudtrail.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::MOJ-S3-BUCKET/*", "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:cloudtrail:us-east-1:123456789012:trail/MOJ-TRAIL" } } } ``` To se koristi iz razloga da se izbjegne [**confused deputy problem**](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) o cemu smo vise pisali u nastavku u dijelu Important Actions - iam:PassRole * **Federated** - Koristi se samo unutar IAM Trust Policies kako bi se dodijelio pristup za Web Idenity Session Principles od strane Web Idenity provajdera ili SAML Session Principle od strane SAML provajdera. * **Canonical User** (ne bi trebao da se koristi jer samo nekoliko slucajeva zahtijeva upotrebu ovog tipa Principal elementa) * **NotPrincipal** - Postoji i obrnuta varijanta **Principal** elementa. Medjutim nije ga preporuceno koristiti jer danas ne postoji use-case unutar AWS-a gdje bi ovaj element bio potreban. Umjesto toga mozete imati policy koji izgleda kao na primjeru ispod: ``` { "Effect": "Deny", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::MOJ-S3-BUCKET/*" "Condition": { "ArnNotEquals": { "aws:arn": "arn:aws:iam::123456789012:role/MOJA-ROLA" } } } ``` * **Action** - `The What` - Oznacava jednu ili vise Akcija koje su dozvoljene / Allowed ili odbijene / Denied. Set akcija koje su navedene unautar Action dijela se evaluira kao logicko `OR`. Postoje razlicite reprezentacije Action elementa, npr. `s3:PutObject`, `s3:*`, `s3:Put*`, `s3:*Object`, `s3:*Bucket`, `*`. Vrijednost Action elementa je podjeljena u dva dijela, `service prefix na lijevoj strani : ime akcije na desnoj strani`. Npr. `s3:PutObject` oznacava da je `service prefix` `s3` a `ime akcije` je `PutObject`. `*` oznacava wildcard za sve akcije. **NotAction** - Obrnuta varijanta **Action** elementa. Oznacava da je akcija koja je navedena u **NotAction** elementu zabranjena / Denied. Vise akcija unutar **Not Action** elementa se evaluiraju kao logicko `NOR`. * **Resource** - `The Where` - Oznacava jedan ili vise AWS resursa na koje se odnosi / primjenjuje Policy Statement. Resursi se specificiraju koristeci [ARN (Amazon Resource Name)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). ARN se pise u formatu `arn:partition:service:region:account-id:resource-type/resource-id`. Kada pogledate ARN razlicitih AWS Servisa vidjeti cete da nemaju svi servisi sve dijelove ARN-a. Npr: ARN S3 bucketa `arn:aws:s3:::MOJ-S3-BUCKET` ne ukljucuje account-id ili region. Umjesto kompletnog arn koda mozete korisiti i `*` wildcard da zamijenite dio ili citav ARN. **Resource element se evaluira kao logicko `OR` unutar jednog Statement-a.** * **ARN Fromat pojasnjenje:** * `partition` - odnosi se na to gdje se AWS resurs nalazi, npr. `aws` za AWS Region, `aws-cn` za AWS resurse u Kini, `aws-us-gov` za AWS Goverment resurse. * `service` - govori nam o kojem AWS servisu se radi * `region` - kod regiona u kojem se nalazi resurs. Npr. `us-east-1` za US East (N. Virginia) Region * `account-id` - ID AWS racuna bez `-` znakova * `resource-type` - govori nam o tipu resursa, npr. `s3` za S3 servis, `ec2` za EC2 servis itd. * `resource-id` - govori nam o ID-u resursa, npr. `MOJ-S3-BUCKET` za S3 Bucket, `i-1234567890abcdef0` za EC2 Instance itd. `resurce-id` moze biti Ime resursa, ID resursa ili [putanja](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html#arns-paths). * **NotResource** - Predstavlja inverzni element **Resource** elementa. Oznacava da je resurs koji je naveden u **NotResource** elementu zabranjen / Denied. Vise resursa unutar **NotResource** elementa se evaluiraju kao logicko `NOR`. Na njega mozete gledati i kao na **Exception** element. Ako pogledamo primjer: ``` { "Sid": "MojStatement" "Effect": "Denny", # <- Zabrani akcije "Action": ["s3:PutObject", "s3:GetObject"], "NotResource": "arn:aws:s3:::IME-S3-BUCKETA/*" # <- Osim na resursu koji je naveden u NotResource elementu } ``` Budite pazljivi sa koristenjem **NotResource** sa **Allow Effect** jer na taj nacin dodjeljuju pristup svim resursima osim onih koji su navedeni u **NotResource** elementu. * **Condition** - `The When` - Condition element oznacava konektekst unutar kojeg ce pristup biti razmotren odnosno kada ili pod kojim uslovom ce policy biti primjenjen. Npr. Statement u primjeru ispod se primjenjuje samo ukoliko je vrijednost za AWS sigurni prenos podataka (AWS Secure Transport) jednaka `true`, odnosno ako je request poslan preko HTTPS/TLS protokola. Polisije koji imaju **Condition** element mozete citati i na nacin da kazete: "Izvrsi sljedece akcije ali samo ako..." ``` { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::11111111:role/ImeIAMRole" }, "Action": ["s3:PutObject", "s3:GetObject"], "Resource": "arn:aws:s3:::IME-S3-BUCKETA/*", "Condition": { "Bool": { "aws:SecureTransport": "true" } } } ``` **Condition** element moze da se sastoji od nekoliko elemenata. Npr: ``` { "Effect": "Allow", "Action": "iam:CreateRole", "Resource": "*", "Condition": { "StringEquals": { # <- Operator "aws:RequestTag/Team": [ # <- Key "DevOps", # <- Value "SRE" ] } } } ``` ili ``` { "Effect": "Allow", "Action": "iam:CreateRole", "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestTag/Team": [ "DevOps", "SRE" ] } } } ``` ili ``` { "Effect": "Allow", "Action": "s3:CreateBucket", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalAccount":"111111111111", "aws:SourceVpc":"vpc-1234567890abcdef0" }, "StringLike": { "aws:PrincipalTag/Team":"Team-*" } } } ``` ili ``` { "Effect": "Deny", "Action": "s3:CreateBucket", "Resource": "*", "Condition": { "StringNotEquals": { "aws:PrincipalAccount":"111111111111", "aws:SourceVpc":"vpc-1234567890abcdef0" }, "StringNotLike": { "aws:PrincipalTag/Team":"Team-*" } } } ``` * **Operator** - Definise koje poredjenje IAM treba napraviti prije nego pokusa da poredi vrijednosti u vasem polisiju sa vrijednostima unutar **authorisation-context**. Postoji vise razlicitih [condition operatora](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), koji operator cete koristiti zavisi od tipa koju vrijednost operatora ima unutar **authorisation-context-a**. Mozete koristiti razlicite sufixe sa operatorima `Equals` ili `NotEquals` ili `Like` da bi dobili tacno podudaranje ili wildcard podudaranje. Kako bi znali koji `condition-key` mozemo koristiti sa kojim IAM pristupom i resursom pogledajte [Service Authorization Reference](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html). Unutar Service Authorization Reference dokumentacije za svaki AWS servis mozete pogledati koji `condition-key` mozete koristiti sa kojim tipom. Npr. za [EC2 servis](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-policy-keys) u koloni Type vidite koji tip mozete da koristite da biste radili poredjenje. **Condition keys** koji pocinju sa `aws:` mogu se koristiti sa svim AWS servisima.
* **Key** - Definise koja vrijednost iz **authorisation-context** treba da se poredi sa vrijednostima u vasem polisiju. * **Value** - Definise vrijednost koja se poredi sa vrijednostima u vasem polisiju. Da bi se polisiji mogao izvrsiti, vrijednosti u polisiju moraju biti jednake vrijednostima u **authorisation-context-u**. ### Kategorije / Vrste IAM Policy-a Postoji nekoliko kategorija / vrsta IAM Policy-a, npr. policy koji je pridruzen IAM User-u, IAM Role ili IAM Group te policy koji su pridruzeni AWS resursima, npr. S3 Bucket, SQS... * **Identity Based Policy** - Za polisije koji su pridruzeni korisniku, roli ili grupi kazemo da se zovu **Identity Based Policy**, jer se radi o polisijima koji su direktno zakaceni za identitet korisnika, role ili grupe i sadrze dozvole o akcijama koje korisnik, rola ili grupa korisnika moze da napravi. * **Resource Based Policy** - Za polisije koji su pridruzeni AWS resursima kazemo da se zovu **Resource Based Policy**, jer se radi o polisijima koji su zakaceni na AWS resurs. * **VPC endpoint policies** - predstavljaju polisije koji kontrolisu ko i moze pristupiti i koristiti odredjeni VPC endpoint. * **Service Control Policies (SPCs)** - Postoje i **Service Control Policies (SPCs)** koje se primjenjuju na nivou AWS organizacije i predstavljaju siru sigurnosnu politiku te se zahvaljujuci tome sto se dodjeljuju na nivou za AWS Organisation servisa primjenjuju se na vise AWS racuna unutar iste organizacije. * **Permission Boundaries** - predstavljaju napredna mogucnost polisija koja se obicno koristi za delegiranje prava za kreiranje IAM entiteta * **Session policies** - predstavljaju polisije koji se primjenjuju na pojedinacnu sesiju kada dolazi do Assume IAM Role. ### IAM Policy Statements Svaki tip polisija koji je nabrojan iznad moze da sadrzi jedan ili vise Statement-a. Unutar Statementa se osim iznad nabrojanih primarnih elemenata mogu nalaziti i sljedeci opcionalni elementi: * **Sid** - Oznacava jedinstveni identifikator za Statement. Primjer `idenity-based` policy statement-a: ``` { "Sid": "IdentitifkatorZaMojIAMPolisi", # <- Opcionalan parametar "Effect": "Allow", # <- Obavezan parametar "Action": "s3:GetObject", # <- Obavezan parametar "Resource": "arn:aws:s3:::IME-S3-BUCKETA/*", # <- Obavezan parametar "Condition": { # <- Opcionalan parametar "Bool": { "aws:SecureTransport": "true" } } } ``` Primjetite da ovaj polisi Statement ne sadrzi **Principal** element, to je zato sto se u ovom slucaju pricipal implicitan jer je sam polisiji pridruzen principal-u. Primjer `resource-based` policy statement-a: ``` { "Sid": "IdentitifkatorZaMojIAMPolisi", # <- Opcionalan parametar "Effect": "Allow", # <- Obavezan parametar "Principal": { # <- Obavezan parametar "AWS": "1111111111" }, "Action": "s3:GetObject", # <- Obavezan parametar "Resource": "arn:aws:s3:::IME-S3-BUCKETA/*", # <- Obavezan parametar "Condition": { # <- Opcionalan parametar "Bool": { "aws:SecureTransport": "true" } } } ``` Za razliku od `idenity-based` polisija, `resource-based` polisi mora da sadrzi **Principal** element. To je zato sto bilo koji **Principa** moze pokusati da napravi poziv prema resursu i onda je na nama da koristimo principal element da definisemo ko **MOZE** ili **NE MOZE** da pristupi resursu. U nastavku je dat primjer kompletnog IAM polisija koji se sastoji od vise Statement dijelova. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::IME-S3-BUCKETA/*" }, { "Sid": "Statement2", "Effect": "Allow", "Action": "dynamodb:PutItem", "Resource": "arn:aws:dynamodb:us-east-1:1111111111:table/IME-DynamoDB-TABELE" } ] } ``` Za razliku od dijelova polisija koje ste vidjeli iznad, u ovom kompletnom polisiju se nalazi i dio `"Version": "2012-10-17"` koji oznacava sintaksu i pravila jezika kojim je napisan polisij. Vise o tome mozete vidjeti u AWS dokumentaciji na [sljedecm linku](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_version.html). Kako se nas polisiji sastoji od vise Statement dijelova, onda poslije elementa `"Version": "2012-10-17"` dolazi element `"Statement": []` koji sadrzi niz Statement dijelova. ### IAM Policy Evaluation Postoje dva pravila evaluacije IAM polisija: * Najmanje jedan Statement sa Effect-om Allow mora da se podudari da bi se se akcija koju pokusavamo da napravimo kroz nas request dozvolila. * Podudarajuci Statement sa Effect-om Deny ima prednost u odnosu na Statement sa Effect-om Allow. Nije bitno u kojem poretku sa napisani Statement-i, ako se Effect Deny podudara sa nasim requestom, onda ce se request odbiti. Kada **Principal** napravi request prema AWS-u, AWS skuplja informacije o tom requestu i stavlja te informacije o requestu u ono sto nazivamo **authorisation context**. Authorisation context ukljucuje informacije o **Akciji** ili operaciji koju principa zeli da napravi, to moze biti akcija unutar AWS konzole ili kroz AWS CLI ili AWS API. Dalje sadrzi informacije o **resursu** nad kojim ce akcije biti napravljene. Sadrzi informacije o principalu, odnsosno osobi ili aplikaciji, koja zeli da napravit tu akciju. Informacije o principalu ukljucuju i polisiji koji je pridruzen entitetu kojeg je principal koristio za sign in. Pored navedenog **authorisation context** sadrzi informacije o IP adresi. Ispod je dat jedan ilustrativni primjer **authorisation context-a**: ``` Principal: AKIAACCESSKEY Action: s3:CreateBucket Resource: arn:aws:s3:::IME-S3-BUCKETA Context: aws:UserId=AKIAACCESSKEY:DzenanSession aws:PrincipalAccount=1111111111 aws:PrincipalOrgId=o-example aws:PrincipalARN=arn:aws:iam::1111111111:role/Dzenan aws:MultiFactorAuthPresent=false aws:CurrentTime=2023-05-08T12:00:00Z aws:EpochTime=1234567890 ``` IAM radi poredjenje **authorization context-a** sa **IAM polisijem** da bi saznao koji se Statement iz IAM polisija podudara i na kraju da bi odlucio da li je request Allowed ili Denied. **Request 1:** Korsnik **Dzenan** koristi svoju IAM rolu da bi dohvatio objekat **file.txt** iz S3 bucket-a pod naziovom **DZENAN-S3-BUCKET**. Korisnik Dzenan ima identity-policy sa sljedecim statement dijelovima zakacen za svoju IAM Rolu: ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Action": ["s3:GetObject","s3:PutObject"] "Resource": "arn:aws:s3:::DZENAN-S3-BUCKET/*" }, { "Sid": "Statement2", "Effect": "Deny", "Action": "s3:PutObject", "Resource": "*" }, { "Sid": "Statement3", "Effect": "Allow", "Action": "dynamodb:CreateTable", "Resource": "*" }, { "Sid": "Statement4", "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::DRUGI-BUCKET/*" }, ] } ``` #### Authorization context ``` Principal: AJIAACCESSKEY Action: s3:GetObject Resource: arn:aws:s3:::DZENAN-S3-BUCKET/file.txt Context: aws:UserId=AKIAACCESSKEY:DzenanSession aws:PrincipalAccount=1111111111 aws:PrincipalOrgId=o-example aws:PrincipalARN=arn:aws:iam::1111111111:role/Dzenan aws:MultiFactorAuthPresent=false aws:CurrentTime=2023-05-08T12:00:00Z aws:EpochTime=1234567890 aws:SourceIP=... aws:PrincipalTag/dept=123 aws:PrincipalTag/project=blue ``` Da bi utvrdio da li je request **Allow** ili **Deny** IAM ce raditi poredjenje ovog **authrisation context-a** sa svakim **statement**-om iz **identity-policy**-ja. IAM ce takodjer raditi poredjenje **authrisation context-a** i sa ostalim polisijama koje su spomenuti iznad ako oni postoje.
Rezultati evaluacije requesta korisnika odnosno poredjenja **authrisation context-a** sa **identity-policy**-jem je sljedeci: | | Effect | Matches? | | -------------- | --------- | -------- | | **Statement1** | **Allow** | **Yes** | | Statement2 | Deny | No | | Statement3 | Allow | Ignored | | Statement4 | Allow | Ignored | Vidimo da se samo Statement1 poklapa sa authorization context-om i kako je Effect Allow, onda ce request biti Allowed. Ako uporedimo sljedeci **authorization context** sa istim **identity-policy**-jem vidimo da se u `Statement1` dijelu `Resource` iz **authorization context-a** ne poklapa sa `Resource` iz **identity-policy**-ja. ``` Principal: AJIAACCESSKEY Action: s3:CreateBucket Resource: arn:aws:s3:::DZENAN-S3-BUCKET Context: aws:UserId=AKIAACCESSKEY:DzenanSession aws:PrincipalAccount=1111111111 aws:PrincipalOrgId=o-example aws:PrincipalARN=arn:aws:iam::1111111111:role/Dzenan aws:MultiFactorAuthPresent=false aws:CurrentTime=2023-05-08T12:00:00Z aws:EpochTime=1234567890 aws:SourceIP=... aws:PrincipalTag/dept=123 aws:PrincipalTag/project=blue ``` Ukoliko ne postoji bar jedna podudarnost izmedju **authorization context-a** i **identity-policy**-ja za Allow statement, onda ce request biti Denied (Implicit Denied). Kada dodje do podudarnosti za Deny Statement, svi ostali Statement se mogu ignorisati. Ukoliko vidimo da imamo dva matching statments, jedan Allow i jedan Deny, onda ce request biti Denied (Explicit Denied). ``` Principal: AJIAACCESSKEY Action: s3:PutObject Resource: arn:aws:s3:::DZENAN-S3-BUCKET/my-file.txt Context: aws:UserId=AKIAACCESSKEY:DzenanSession aws:PrincipalAccount=1111111111 aws:PrincipalOrgId=o-example aws:PrincipalARN=arn:aws:iam::1111111111:role/Dzenan aws:MultiFactorAuthPresent=false aws:CurrentTime=2023-05-08T12:00:00Z aws:EpochTime=1234567890 aws:SourceIP=... aws:PrincipalTag/dept=123 aws:PrincipalTag/project=blue ``` Moguci rezultati evaluacije requesta korisnika odnosno poredjenja **authrisation context-a** sa **identity-policy**-jem su sljedeci: * Emplicit allow - Najanje jedan Allow Statement, nema podudarajucih Denuy Statements * Implicit Deny - Nema podudarajucih Allow ili Deny Statements * Emplicit Deny - Najmanje jedan podudarajuci Deny Statement, ne postoji Explicit Allow Statement ``` Principal: AJIAACCESSKEY Action: iam:CreateRole Resource: arn:aws:iam:1111111111:role/Dzenan Context: aws:UserId=AKIAACCESSKEY:DzenanSession aws:PrincipalAccount=1111111111 aws:PrincipalOrgId=o-example aws:PrincipalARN=arn:aws:iam::1111111111:role/Dzenan aws:MultiFactorAuthPresent=true aws:SecureTransport=true aws:PrincipalTag/dept=123 aws:PrincipalTag/project=blue aws:TagKeys=dept,project ``` ### Important Actions - iam:PassRole Akcija **iam:PassRole** je specijalna akcija koja se koristi za delegiranje / dodjelu prava, ili kako se to naziva u AWS dokumentaciji radi se o **permission only** akciji. Ova akcija podrzava opciju specificiranja role koju korisnik moze da delegira / dodijeli drugom korisniku. Ova akcija se koristi u kombinaciji sa **resource-based policy**-jima. Npr. zamislite da imate scenario u gdje postoji IAM Rola `Administrators` koja ima administratorske privilegije nad vasim AWS racunom. Dalje zamislite da imate korisnika A koji ima permisije da kreira EC2 instancu i da toj instanci dodijeli IAM Rolu. Prilikom kreiranja EC2 instance, korisnik A ima opciju da odabere IAM Rolu koja ce biti pridruzena toj EC2 instanci. U tom slucaju se moze dogoditi da korisnik A, koji nije Administrator, moze da dodijeli IAM Rolu `Administrators` EC2 instanci. Tada bi korisnik koji nema administratorske privilegije, mogao da se spoji na tu EC2 instancu i sa nje izvrsi akcije koje mu orginalno nisu bile dozvoljene kroz njegovu rolu. Da bi sprijecili ovaj scenario, IAM zahtijeva da korisniku A, kroz `iam:PassRole` akciju bude dozvoljeno da EC2 instanci dodijeli navedenu rolu. Ako korisnik A nema dodjeljenu `iam:PassRole` akciju gdje je navedena Administratorska IAM Rola, on tu role nece moci dodijeliti EC2 instanci koju je kreirao. Dakle `iam:PassRole` akcija daje permisije korisnicima da proslijede rolu drugom servisu ili resursu. Zahvaljujuci tome, `iam:PassRole` akcija se koristi za sprijecavanje sigurnosnog propusta koji je poznat pod nazivom [**confused deputy problem**](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html). ### API Actions vs IAM Actions Za bilo koju akciju / komnadu koju korisnik zeli da izvrsi nad AWS servisima koristi se API akcija. Kada napravite poziv prema AWS API-u, AWS API ce autorizovati jednu ili vise IAM akcija Npr. za kreiranje EC2 instance koristi se API akcija `ec2:RunInstances`. Obicno su nazivi API akcija jednaki nazivu IAM akcija uz sljedece izuzetke. | API Action | IAM Action(s) | | -------------- | ----------------------------------------- | | S3 CopyObject | s3:ListBucket, s3:GetObject, s3:PutObject | | S3 ListBuckets | s3:ListAllMyBuckets | | Lambda Invoke | lambda:InvokeFunction | Npr: API akcija `S3 CopyObject` zahtijeva `s3:GetObject` permisije nad S3 bucketom iz kojeg kopirate objekat / podatke, `s3:PutObject` nad S3 bucketom u koji kopirate objekat / podatke kao i `s3:ListBucket` privilegije. Postoje IAM akcije koje imaju nesto drugacije ime nego njihov API action ekvivalent. Jedan od primjera je **Lambda Invoke** API akcija koja zahtijeva `lambda:InvokeFunction` IAM akciju. Preporuka je da provjerite AWS Dokumentaciju kako bi vidjeli koje tacno IAM akcije trebate kako bi korisnik mogao da izvrsi API akciju koju zelite. ### IAM Policy Evaluation: Policy Evaluation Chains Prvi principal koji pravi request je **Role session**. **IAM Role** uvijek ima odgovarajucu sesiju koja je ustvari principal koji pravi request. IAM Rola sama po sebi ne pravi request bez sesije. Sljedeci principal koji pravi request je **IAM User**. IAM Users nemaju sesije i oni prave requestove. **Federated user (using sts:GetFederationToken)** je principal koji je dobio pristupne podatke koristeci `sts:GetFederationToken` API. Ovo nije korisnik koji je federated od strane idenity provajdera. Vecina AWS korisnika ne koristi cesto ovaj tip Federated korisnika. **Anonymous** principal predstavlja korisnika koji pravi ne-autorizovani request prema AWS-u. **Root** korisnik je specijalni tip principala i ne bi trebao biti koristen za svakodnevnu upotrebu jer se radi o korisniku koji ima sve privilegije nad AWS racunom.
### Security best practices with AWS IAM ### IAM Tips and Tricks * [How can I troubleshoot access denied or unauthorized operation errors with an IAM policy?](https://aws.amazon.com/premiumsupport/knowledge-center/troubleshoot-iam-policy-issues/) * [How to read encoded authorization error messages in AWS](https://arpadt.com/articles/decode-encoded-error-message) ### Resources * [AWS re:Invent 2018: \[REPEAT 1\] Become an IAM Policy Master in 60 Minutes or Less (SEC316-R1)](https://youtu.be/YQsK4MtsELU) * [IAM Policy Evaluation Series: AWS IAM policy language explained - Part 1](https://youtu.be/qsF6Kauh2J4) * [IAM Policy Evaluation Series: policy evaluation chains](https://youtu.be/71-Gjo6a5Cs) * [AWS re:Inforce 2022 - Security best practices with AWS IAM (IAM201)](https://youtu.be/SMjvtxXOXdU) * [AWS Identity and Access Management Documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) * [How to monitor and query IAM resources at scale – Part 1](https://aws.amazon.com/blogs/security/how-to-monitor-and-query-iam-resources-at-scale-part-1/) * [How to monitor and query IAM resources at scale – Part 2](https://aws.amazon.com/blogs/security/how-to-monitor-and-query-iam-resources-at-scale-part-2/) * [GetAccountAuthorizationDetails](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountAuthorizationDetails.html) ## AWS Documentation * [Service Authorisation Reference](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html) # AWS Elastic Beanstalk AWS Elastic Beanstalk je jedan od najstarijih PaaS (Platfrom as a Service) servisa unutar AWS clouda. #### DevOps Mentorship Program - Week 13 - AWS Elastic Beanstalk PART I {% embed url="" %} #### DevOps Mentorship Program - Week 13 - AWS Elastic Beanstalk PART II {% embed url="" %} # AWS Certification ### Certifikacija u IT-u Postoje razlicita misljenja i stavovi vezani za certifikaciju u IT-u. Nisu rijetki oni koji su izriciti protivnici certifikata smatrajuci kako ne donose dodatnu vrijednost niti znanje. Smatram da razlog za takvo misljenje najviše lezi u cinjenici da su se certifikati pojedinih vendora sticali memorisanjem odogovara i kupovinom “dumpova”. “Dumpovi” bi sadrzavali par stotina pitanja u odgovora sa oznacenim tacnim odgovorima pa bi potom na certifikacijskom ispitu dolazila identicna pitanja gdje bi cak i poredak ponudjenih odgovora bio identican onom koji se mogao vec vidjeti u “dompovima”. Sticanje certifikata na takav nacin je slozit cemo se uzaludno i u krajnjoj tacki beskorisno, kako za vas tako i za vaseg poslodavaca. Naravno, postojali su i oni certifikati koje i nije bilo baš tako jednostavno poloziti i osobe koje su posjedovale takve certifikate su prije svega posjedovale zanje a certifikat je dolazio samo kao dodatna potvrda tog znanja. U red takvih certifikata spadao je Microsoft SQL Server Master certifikat kao i VMWare certifikati koji su ukljucivali pored teorijskog dijela i prakticni dio za uspjesno polaganje. Bez obzira koji od IT certifikata odlucite polagati, vrijednost tog certifikata zavisi samo od vas. Ono sto je vaznije od samog certifkata je znanje koje cete steci tokom pripreme za njegovo polaganje a njegovim uspjesnim polaganjem to znanje samo verifikujete. Takodjer vazno je napomenuti da niti jedan certifikat sam po sebi ne može zamijeniti niti nadomjesitit iskustvo rada u stvarnom okruzenju ili na stvarnim zadacima i problemima. ### AWS Certifikacija AWS certifikacija trenutno spada u red najtrazenijih certifikata na IT trzistu rada a za to postoji nekoliko razloga. Veliki broj kompanija koristi AWS kao cloud za svoju infrastrukturu gdje su i pored svih pogodnosti koje cloud sa sobom donosi potrebni kvalifikovani strucnjaci koji ce tu infrastrukturu pravilno odrzavati, konfigurisati itd. Drugi razlog je nacin na koji je koncipirana AWS certifikacija. Postoje nekolika nivoa certifikacija a pitanja su postavljena tako da se od vas traži teorijsko poznavanje servisa ali i stvarno iskustvo u radu sa njima. Takodjer mogucnost varanja uz pomoc “dumpova” je svedena na minimum jer se pitanja stalno osvjezavaju a certifikati obanavljaju. U kreiranju ispitnih pitanja učestuju timovi inženjera kao i ljudi iz zajednice koji su se već certifikovali i žele dati svoj doprinos kreiranju pitanja i odrzavanju kvaliteta certifikacije. Takodjer jos jedan od razloga zašto su AWS certifikati toliko trazeni na trzistu rada je i Amazon Partner Network (APN) program koji od kompanija koje zele biti dio tog programa izmedju ostalog kao jedan od preduslova postavlja i to da zaposleni moraju imati odredjen broj AWS certifikata. Biti dobar AWS Solutions Architect ili DevOps inzenjer ne zahtijeva polaganje bilo kojeg certifikata, poznajem jako veliki broj strucnjaka i istinskih AWS eksperata koji ne posjeduju niti jedan AWS certifikat. Međutim za pocetnike ili osobe koje dolaze iz neke druge IT oblasti AWS certifikacija predstavlja odlicnu putanju na osnovu koje mogu da prate svoj napredak ali i koja im postavlja nove zadatke i izazove te ih tjera da na tom putu sticanja AWS certifikata dobiju neophodno zanje. Prije nego se upustimo u analizu dostupnih AWS certifikata potrebno je napomenuti i da samo znanje o AWS servisima nije dovoljno. Vjestine administracije operativnih sistema, mreza, baza podataka poznavanje monolitne arhitekture, arhitekture mikro servisa,pisanje python i shell skripti, golang programskog jezika, poznavanje devops kulture i alate, sve to je još uvijek potrebno, usudio bi se reci cak i neophodno za kvalitetan rad sa AWS servisima. #### Pregled dostupnih AWS certifikata

AWS Certifikati

*\*Slika preuzeta sa zvanicnog AWS certifikacijskog* [*sajta*](https://aws.amazon.com/certification/). **AWS certifikacija je podijeljena u cetiri nivoa:** * **Foundational** - Nivo namjenjen onima koji nemaju nikakvog prethodnog hands-on iskustva u radu sa AWS servisima, u sklopu Fundational nivou certifikacije imate na raspolaganju sljedece certifikate: * [AWS Cloud Practitioner](/amazon-web-services-aws/aws-certification/aws-cloud-practitioner) * **Associate** - Nivo namjenjen onima koji vec imaju prethodno iskustvo u radu sa AWS servisima, u sklopu Associate nivou certifikacije imate na rasplaganju sljedece certifikate: * [AWS Solutions Architect Associate](/amazon-web-services-aws/aws-certification/aws-solutions-architect-associate) * [AWS SysOps Administrator Associate](/amazon-web-services-aws/aws-certification/aws-sysops-administrator-associate) * [AWS Developer Associate](/amazon-web-services-aws/aws-certification/aws-developer-associate) * **Proffesional** - Nivo certifikacije namjenjen iskusnim korisnicima AWS-a koji imaju minimalno 2 godine iskustva u radu sa AWS servisima, u sklopu Proffesional nivou certifikacije imate na raspolaganju sljedece certifikate: * [AWS Solutions Architect Proffesional](/amazon-web-services-aws/aws-certification/aws-solutions-architect-proffesional) * [AWS DevOps Engineer Proffesional](/amazon-web-services-aws/aws-certification/aws-devops-engineer-proffesional) * **Specialty** - Nivo certifikacije namjenjen iskusnim korisnicima AWS-a koji zele dodatno da se specijaliziraju u odredjenim oblastima AWS-a. U sklopu Specialty niva certifikacije imate na raspolaganju sljedece certifikate: * [AWS Security Specialty](/amazon-web-services-aws/aws-certification/aws-security-specialty) * [AWS Advanced Networking Specialty](/amazon-web-services-aws/aws-certification/aws-advanced-networking-specialty) * [AWS Database Specialty](/amazon-web-services-aws/aws-certification/aws-database-specialty) * [AWS Machine Learning Specialty](/amazon-web-services-aws/aws-certification/aws-machine-learning-specialty) * [AWS Data Analytics Specialty](/amazon-web-services-aws/aws-certification/aws-data-analytics-specialty) * [SAP on AWS Specialty](/amazon-web-services-aws/aws-certification/sap-on-aws-specialty) Za polaganje AWS certifikata ne postoje nikakvi preduslovi u smislu da prethodno morate imati polozen neki ulazni certifikat kako bi pristupili polaganju sljedeceg certifikata sa veceg nivoa. Ukoliko smatrate da ste spremni i posjedujete potrebni nivo znanja mozete u svakom trenutku izaci da polazete bilo koji od dostupnih certifikata. {% embed url="" %} {% embed url="" %} Kako se pripremiti za uspjesno polaganje AWS certifikata * [r/AWSCertifications](https://www.reddit.com/r/AWSCertifications/) # AWS Cloud Practitioner # AWS Solutions Architect Associate # Exam Notes - AWS SAA Ovdje mozete pronaci biljeske sa ispita ljudi koji su vec izasli na ispit i polozili ga. Ideja ovih biljeski je da vam daju uvid u tip pitanja / servise koje trebate poznavati kako bi uspjesno polozili ispit. #### Exam date: June 2022 -odrediti sta mozemo uraditi u slucaju da nam reserved instance nije vise potrebna * imamo jednu dx konekciju i 3 peered vpc, na koji nacin uspostaviti najotporniju vezu on premisses sa svim vpc, uzimajuci u obzir da je potrebno da bude sto isplativije rijesenje * imamo 3 tier app i sqs izmedju njih, na jednom tasku dolaze iste poruke vise puta. sta je uzrok. * kako doozvoliti samo premium korisnicima da pristupe sadrzaju u s3 * veliki dio pitanja je bio odrediti odgovarajuci database za scenario * na koji nacin prosiriti storage sa on premisses na aws tako da arhiva bude na aws a frekventna data ostane na on premisses * na koji način pristupiti resursima u s3 bez da se prenos podataka vrsi preko interneta * par pitanja bilo je odrediti koji tip hdd ili ssd koristiti za datu infrastrukturu uzimajuci u obzir navedene potrebe (koji tačno scenarij je bio , ne mog se sjetiti) * određivanje najisplativijeg storagge clas. -koji su benefiti koristenja RDS multi az deploy * kako postaviti sqs u multi tier app * analiza resource policy ( sta IAM može u navedenom bucketu) * najbrža intervencija u slučaju napada sa detektovanog range-a ip adresa * kakve postavke in/out odabrati ako zelimo da se bastionu može pristupiti samo sa korporacijskih ip adresa. * 2 pitanja su bila, ne mogu tacno da se sjetim scenarija, ali traži se određivanje kombinacije storage za data i načina kojim se vrsi query nad data #### Exam date: June 2022 AWS Macie AWS SageMaker AWS Textract AWS Kinesis Firehouse/Data Stream Pitanje bude tipa real time processing kada moramo iz razlicith sourcova da radimo pa je odgovor Firehouse dok Data streams ide iz jednog AWS Kinesis Data Analytics AWS Comperhand medical(bilo nesta oko medical fajlova pa da se ovaj izabere) Storovanje Seasion data u koji storage DynamoDb i elasticcache Step Function vs SWF kad koji iskoristit Glaven razlike su Step Functioon(serverless/short running,less complex) AWS(uses servers/asyhtonicus/complex custom) Pitanje koji tip endpointa je s3 i dynamo db (gateway) ostali su interface Sta upaliti da imamo “object using write once read many”(WORM) Object lock s3 Sa verzionisanjem da li svaki objekat moze imati razlicite rention periode Sta je potrebno za VPC peering site to site konekciju (prerequesites) Public ip na customer gatewayu na on premises i virtual private gateway na vpcu Sta se placa kad je Ec2 u hibrenate state EBS volumes i elastic ip koji je na njemu Ako nam treba high Iops koji tip isntance ce se koristi Ponudjeno (memory/.compute/general/storage) Storage tacno (msm) Volume Gateawy i volume gateway in cached mode Bilo je pitanja oko Fsx Luster i Fsx Windows file server koji kad iskoritit Bilo je ponudjeno koji ce se iskoristi ako nam treba da se poveze na manged active directory i to je ovaj Fsx windows file server Koji Raid iskoristi 0 ili 1 za data mirroring raid 0 je za improved perfomance raid 1 je za mirroring Sa cime cloudfront origin moze biti s3,ec2,elb,lambda\@edge Default time za coldown period kod auto scalling grupe 300 sekundi Bila su pitanja oko scalinga kad iskoristi target tracking a kad step scaling Kako najlakse automatizirati kreaciju i renetion period ili brisanje snapshotova kod EBS(Data Lifecycle Manager DLM) Sqs Retention period,gubitak nekih posle 7 dana jer je defaultni 4 dana pa se treba povecati na vise dana max je 14 dana Visiblity timeout za SQS i long pooling kako se stavlja Izabrati serverless servise od awsa ponudjeni tacni su s3 i dynamodb kako se moze konfigurisati instanca bez povezivanja na svaki ec2 instancu (run command) Koji gateawy koristi da se povuku s3 ojbekti kroz nfs i smb protkole(File gateway) Kako enkriptovati data in transit dok accessuje data iz amazon efs koristi se onaj mount helper da enkriptuje data in transit Na sta s3 moze slati notifikacije Sns,sqs,lambda i eventbridge Bilo je pitanje koji routing iskoristi iz route53 tacnije pitanje koji bi bio najbolje za blue green deployment Weighted routing I jos jedno pitanje je bilo kad hocemo da route53 vraca na dns queires sa vecim broje healthy recorda (mutlivalue) Kao data dva vpca pa onda imamo on premises i kako to povezati u jedan gateway koji ce actovati kao hub(transit Gateway) #### EXAM DATE: JULY 2022. Generalno je ispit jako fokusiran na detalje, šta znači na detalje. Jedan primjer jeste CF tj. kako automatizovati kreiranje infrastrukture kroz template, pa dobijemo sva četiri odgovora koja se razlikuju u gotovo samo jednome detalju. Za test je potrebno biti odmoran/na jer imamo 65 pitanja po 2 minute brzo prođe zaista, a pitanja su mnogo tricky. Obratiti pažnju da li se traži efikasnost, cost, dostupnost. Postoje odgovori koji su po svojoj strukturi točni, ali ne ispunjavaju tipa cost efektivnost. S3 Encryption CloudFormation RDS VPC ASG AWS Config Systems Manager Secrets Manager EC2 EFS SQS CloudWatch Alarmi Athena DynamoDB R53 EBS - ako imamo privremeno korištenje storage koju vrstu koristiti. Bilo je i pitanje koji disk koristiti za boot instance. Da li možemo jedan ebs volume nakačiti na više instanci. Snapshot. Je li EBS one AZ ili se nalazi kroz više AZ. NACL - kako omogućiti konekciju in i out rules. Bastion host - za šta koristimo, koju razinu sigurnosti pruža, još jedno pitanje vezano za bastion host, kako ograničavamo pristup samo partnerskim kompanijama prema našem sistemu kroz bastion host. RDS - kako možemo skalirati bazu podataka. S3 - kako zaštiti brisanje podataka iz bucketa. EFS - bursting i provisioning. Dostupnost kroz više AZ. Access points. Athena - kako vrši query podataka, da li mijenja podatke prilikom query operacije, te koja je prednost i cijena korištenja ovoga servisa. Lambda - trik pitanje koje navodi izvršavanje Lambda funkcije duže od 30 minuta, kako optimizovati troškove. Lambda funkcija ima max. izvršavanja 15 min. Direct Connect, EBS, EC2, VPC - ukoliko pristupamo podacima preko navednih servisa koju vrsta enkripcije za public internet je potrebno koristiti. Po defaultu ovi servisi nemaju doticaj s public internetom osim, ako mi to ne dopustimo. Baze podataka općenito - par pitanja gdje se navodi skaliranje, relacioni podatci, promjena schema baza. Na osnovu tih parametara možemo odlučiti da li potrebno NoSQL ili relacionu bazu koristiti. SQS - retention period 14 dana. Long and short pooling, Kinesis - potrebno voditi računa da li se traži real time obrada podataka ili postoji neki delay. Također pitanje zašto prilikom korištenja Kinesis servisa nakon 24 sata ne vidimo podatke. Par pitanja također o ASG. Zašto imamo nekontroliranu kreaciju instanci, pa je bilo je pitanje kako podesiti ASG da u slučaju pada jedne AZ podigne dovoljno instanci u drugim AZ. Load Balanceri - većina pitanja se bazirala na to kako da jednako rasporedimo saobraćaj po instancama. Jedno zanimljivo pitanje vezano za LB koje mi je baš ostalo u sjećanju. Ukoliko imamo više AZ s nejednakim brojem instanci, te uočimo da u jednoj zoni imamo veću iskorištenost resursa nego u drugoj, kako riješiti taj problem, tj. kako podesiti LB tako da sve instance koristi jednako. Bilo je odgovora za Health Checks, pa i tipova instanci, te cross zone lb. Koliko se sjećam ja sam tu stavio cross zone. VPC Peering - kako omogućiti komunikaciju između više VPC, a da smanjimo admin overhead. Transit Gateway. Još jedno pitanje gdje se navodi komunikacija kroz VPCove, tj. da li je komunikacija tranzitna kroz VPCs. Nije, jer je potrebno napraviti peering između VPCs za koje želimo ostvariti komunikaciju, a dodatak tome jeste podešavanje route tabla i SG, zavisno što je potrebno. VPN - prijenost podataka s on-prema u AWS s mrežom od 100 MB, ukoliko je potrebno više od 1.25 GBs potrebno je koristiti neko drugo riješenje. Cluster group - aplikacije koje zahtjevaju veliku computing snagu. #### Exam date: April 2021 Kreiranje novog računa i zaštita root user-a (da li se koriste IAM Access Keys, MFA i slično) EC2: prepoznati ispravnu naredbu u slučaju da EC2 instanca nema pristup podacima 169.254.169.254/latest/meta-data 169.254.169.254/user-data/iam-info EC2 Placement Groups (različite situacije u kojima treba prepoznati kad se koja koristi; visoka propusnost, niska latencija i sl) S3: Par pitanja u vezi enkripcije prije nego se podaci pošalju na S3 (encryption at rest) Prebacivanje između različitih S3 Object Storage Classes (primjer o neke količine podataka, koliko dana se koristi učestalo, koliko godina je potrebno sačuvati podatke i slično) AWS Shield: za koju vrstu napada se koristi # AWS SysOps Administrator Associate # Exam Notes - AWS SysOps Ovdje mozete pronaci biljeske sa ispita ljudi koji su vec izasli na ispit i polozili ga. Ideja ovih biljeski je da vam daju uvid u tip pitanja / servise koje trebate poznavati kako bi uspjesno polozili ispit. #### Exam date: June 2021 CloudWatch event vs CloudWatch Alarm Which one to choose when (attention to SNS notification) Service Catalog All logs must be send to S3, but prevent ‘some’ team to create buckets - Allow sending logs? * Iam policy? EBS Volume type Which one to choose (base on performance needed, access frequency…) AWS Config Find which costs at most with (Service for costs) RDS to stay after delete of CF stack (DeletionPolicy or deletion-prevention parameter)? CloudFormation * Deploy to another region (use parameters) * vs ElasticBeanstalk * Share CF template Check logs * ELB logs * VPC flowlogs * Access logs File deleted in EBS * Recover file from snapshot? CacheHitRatio<60%, CacheUsed>90% Route53: Records (A, CNAME,...) SQS high utilization, where to check Cloudwatch,... Maintenance window Where is enabled Patching AMI cause delay Elasticache - 2 approaches for improving performance Node instances, node type DB failure reasons LDAP -> use EC2 roles Policy bucket Session manager (what to allow to see instances) Install agent, IAM policy, allow traffic in security group ALB: Cross-siting NAT Gateway vs NAT instance For future uses: NAT gateway or large NAT instance Spot instance Application can tolerate interruptions Service control policy What is that? Status code 503 for accessing S3 bucket The team needs to start and stop instances but is not comfortable with configurations. What to do? Streaming service in us-east-1, delays in Asia? New prod env or CloudFront? #### Exam date: May 23, 2022 3 Lab Exams: Lab: You need to create 2 S3 Buckets: for data and logs you need to setup needed configuration: versioning, lifecycle configuration, public access Lab: Lambda function and rds database are created and you need to modify the function to communicate with rds You need to configure vpc, subnet, sg You need to attach corresponding execution role You need to update env variable for rds proxy Setup rds proxy idle timeout 3 min Lab You need to create vpc with defined CIDR, public and private subnets Create publicSG and privateSG with defined inbound rules Also you need to create route table All ip traffic needs to be logged in S3 bucket Questions: Parameter InstanceLimitExceed what means Lambda function is created in acc A and s3 bucket is created in acc B. What you need to set up to enable lambda function to access data on the s3 in acc B? You use CF which launches EC2 instances from the ami in different regions. It works in one region, but in another one it is not working. How to resolve this issue? You have CF which creates a lambda function, dynamodb table and s3 bucket. You want to delete the stack and all create resources except the dynamodb table. What do you need to use in this situation? AWS Organizations and scp Your ec2 instance has failed both status checks. What do you need to do? You are using RDS and got “too many connection errors”. How to resolve this? Memcached and low latency issue. How to resolve it? Cloudfront, mobile users got the desktop version of the app. How to resolve it? You have an app running on your ec2 and it cannot access on-prem server- Unresolvable domain error. How to resolve (answers: use R53 resolver with different outbound and inbound rules you need to choose correct rules) You have doman example.com and subdomain [www.exemple.com](http://www.exemple.com/). Also, you want to use a static website. How many bucket will you create and which names you will use) ALB, Cloudfront. First time when users use the website, everything is working, but when they refresh, they get an error. How to restrict access for cloudtrail logs The user wants to use AWS CLI with services, but it is not working. What is wrong? Aws control tower #### Exam date: September 16, 2022. Lab Exams: Cloudwatch metric: Create and set metric for log group. Create alarm for metric. Filter serverCode5xx WAF: Create rule for SQL injection. Create IP pool. Restrict IP pool. Rate based rule on 100 / 5 minutes on matching string “ /login “. Turn off metric for specific rule. Associate ACL with Load Balancer. Spot Request: Use launch template. Set VPC. Set Availabilty Zone. Set SSM Automation. The questions I had on the exam are pretty much the same as two above exams. #### Exam date: Oct, 2022. Lab Exams: Cloudwatch metric: Create and set metric for log group. Create alarm for metric. Filter serverCode5xx WAF: Create rule for SQL injection. Create IP pool. Restrict IP pool. Rate based rule on 100 / 5 minutes on matching string “ /login “. Turn off metric for specific rule. Associate ACL with Load Balancer. Spot Request: Use launch template. Set VPC. Set Availabilty Zone. Set SSM Automation. The questions I had on the exam are pretty much the same as two above exams + -cloudformation-deploy on multiple regions -cloudformation-keep existing resources -RDS proxy -protect multiple S3 buckets (disable public access) ali ne na ruke * s3 is public, but also CF is used. How to protect? -horisontal\&vertical scaling -missing nat route in routetable, where to put it #### Exam date: OCTOBAR 25 2022. Lab2: S3 public access Static website hosting Editovanje a recorda za alb Podesavanje failovera primary i seconday u route53 izmedju s3 i elb Lab3 Cloudformation ima vec templlate Editovati ga: Promjeniti sa t.2 na t.3 Rolu promjenit u roleB sa roleA Dodati ssh port za ip adresu neku na sg dev ec2 instance Updejtovati stack sa time ujljuciti deletion protection i koristiti neki poseban role za deploymen Output prod id iinstance proslijediti na kraju laba #### Exam date: Apr, 2023. Lab Exams: As of 28.3.2023, lab exams are not included until further notice. The exam consisted of 65 multiple choice questions. CloudFront and Route 53 A lot of questions were related to these two, such as DNS record types, and communication between CF/R53 and ELB, ASG and EC2 servers (example question I had - How would I set up failover with a R53 health check to two ELBs in different regions) Monitoring and reporting How to get access logs for ELB, VPC, S3, how to create a report out of them. High availability and redundancy A lot of questions were focused on establishing high availability with ASG, Multi-AZ DB failovers for Aurora DB, S3 backups that needed quick retrieval and Global Network failovers, such as R53 routing and failover. Session Manager A particularly high number of questions had to do with SSM, how to troubleshoot it if it doesn't work (permissions and SSM agent), how to use it to automate processes, how to run one-time scripts on it etc. VPC A couple of questions were related to NACLs, Security Groups, ephemeral ports and IPv4/IPv6 routing # AWS Developer Associate # Exam Notes - AWS Developer Ovdje mozete pronaci biljeske sa ispita ljudi koji su vec izasli na ispit i polozili ga. Ideja ovih biljeski je da vam daju uvid u tip pitanja / servise koje trebate poznavati kako bi uspjesno polozili ispit. #### Exam date: April, 2021. Elastic Beanstalk: Deployments: All at once, Rolling, Green/Blue Kinesis: Shards, resharding, number of instances to consume shards, number of records per instance, (num of instances <= num of shards), scale based on what (CPU of instance, not shards). Kinesis Data Stream vs Kinesis Data Firehouse (couple of question when you need to choose one of them from options). CloudWatch (Logs, Alarms - integrate with SNS, Lambda), CloudEvent (scheduled events that can be triggered e.g. each 10 min, 1 hour...), CloudTrail. Usually, not difficult questions, know when to use which one. Be careful with options (e.g. CloudTrail alarm, CloudWatch Log agent) Cognito (user pools - create new user for sign in, identity pools - what user can do, what credentials to give to the user, assumeRoleWithIdentity, SAML and 3rd party (web) identity provider) Load balancing, autoscaling - few questions, know the concept (HA, FT examples) DynamoDB: Streams as trigger for Lambda Transactions - TransactionWriteItem IAM controlling access (which policies to include, which actions to allow) RCU/WCU - how much do you need, notice when they need to increased, autoscaling capacity (on-demand) DAX - caching memory, read performance, eventually consistency read questions - use DAX TTL - for Dax and DynamoDB Exponential backoff - know when it is used GSI and LSI - which attribute to use for partition key PK and which one for sort key SK (based on operation - query and scan) How to improve scan operation (one answer was parallel scan) Lambda: Optimize runtime with using: handler, layers, memory (know how to optimize it with this, in which cases) Elasticache: Memcache and Redis: when to use one of them Lazy loading and write-through API gateway Few questions but tough Import API (swagger), deploy API (watch out for changes), create corresponding actions in API RDS: read replica and multi-AZ CI/CD CodeCommit CodeBBuild CodeDeploy CodePipeline Knowing basics will be enough, no difficult questions appeared. Also, recognize when to use, even in a combination with 3rd party. CloudFormation Beside the basics (IaaC,...), `Functions: Fn!`, `!GetAttr` S3 Encryption (S3, KMS) when to use each one. Who is the key owner? Who stores the key, who does encryption. Client side encryption also - if no AWS included in encryption and users are providing a key. PresignedURL (access with temporary cred.) KMS questions were a part of encryption of some another service (e.g. S3) CloudFront: example were CloudFront is an option, choose it when it is needed #### Exam date: November, 2022. There wasn’t anything new as the above exam, totally the same services. # AWS Solutions Architect Proffesional # AWS DevOps Engineer Proffesional # AWS Advanced Networking Specialty # AWS Security Specialty # AWS Database Specialty # AWS Data Analytics Specialty # AWS Machine Learning Specialty # SAP on AWS Specialty # AWS Learning Resources # Books Ovdje mozete pronaci listu knjiga koje preporucujemo da procitate odnosno da koristite kao izvore za ucenje i unaprijedjenje svog znanja. ### AWS * [AWS Cookbook](https://learning.oreilly.com/library/view/aws-cookbook/9781492092599/) * [AWS System Administration, 2nd Edition](https://learning.oreilly.com/library/view/aws-system-administration/9781492081562/) * [AWS Certified Database - Specialty (DBS-C01) Certification Guide](https://www.amazon.com/AWS-Certified-Database-Certification-comprehensive/dp/1803243104) * [Solutions Architect's Handbook](https://learning.oreilly.com/library/view/solutions-architects-handbook/9781838645649/) * [AWS Penetration Testing - Jonathan Helmus](https://learning.oreilly.com/library/view/aws-penetration-testing/9781839216923/) * [AWS FinOps Simplified](https://learning.oreilly.com/library/view/aws-finops-simplified/9781803247236/) ### Infrastructure as Code (IaC) * [Terraform: Up and Running, 3rd Edition](https://learning.oreilly.com/library/view/terraform-up-and/9781098116736/) * [Terrafrom Cookbook](https://learning.oreilly.com/library/view/terraform-cookbook/9781098108458/) * [Infrastructure as Code, 2nd Edition](https://learning.oreilly.com/library/view/infrastructure-as-code/9781098114664/) ### Linux / UNIX * [Linux BIBLE](https://learning.oreilly.com/library/view/linux-bible-10th/9781119578888/) * [UNIX and Linux System Administration Handbook, 5th Edition](https://learning.oreilly.com/library/view/unix-and-linux/9780134278308/) * [Linux Command Line and Shell Scripting Bible, 4th Edition](https://learning.oreilly.com/library/view/linux-command-line/9781119700913/) * [Linux Observability with BPF](https://learning.oreilly.com/library/view/linux-observability-with/9781492050193/) ### DevOps * [The Phoenix Project](https://learning.oreilly.com/library/view/the-phoenix-project/9781457191350/) * [The DevOps Handbook](https://learning.oreilly.com/library/view/the-devops-handbook/9781457191381/) * [The Unicorn Project](https://learning.oreilly.com/library/view/the-unicorn-project/9781098124175/) * [DevOps For Dummies](https://learning.oreilly.com/library/view/devops-for-dummies/9781119552222/) * [The DevOps Engineer's Career Guide](https://www.amazon.com/DevOps-Engineers-Career-Guide-Professionals-ebook/dp/B07NDDGNLS/) * [Effective DevOps](https://learning.oreilly.com/library/view/effective-devops/9781491926291/) * [Practice of System and Network Administration, The: DevOps and other Best Practices for Enterprise IT, Volume 1](https://learning.oreilly.com/library/view/practice-of-system/9780133415087/) * [Practice of Cloud System Administration, The: DevOps and SRE Practices for Web Services, Volume 2](https://learning.oreilly.com/library/view/practice-of-cloud/9780133478549/) * [Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation](https://learning.oreilly.com/library/view/continuous-delivery-reliable/9780321670250/) * [Continuous Architecture in Practice: Software Architecture in the Age of Agility and DevOps](https://learning.oreilly.com/library/view/continuous-architecture-in/9780136523796/) * [Modern DevOps Practices](https://learning.oreilly.com/library/view/modern-devops-practices/9781800562387/) * [Time Management for System Administrators](https://learning.oreilly.com/library/view/time-management-for/0596007833/) ### DevOps Tools * [Ansible: Up and Running, 3rd Edition](https://learning.oreilly.com/library/view/ansible-up-and/9781098109141/) * [Jenkins 2: Up and Running](https://learning.oreilly.com/library/view/jenkins-2-up/9781491979587/) * [NGINX Cookbook, 2nd Edition](https://learning.oreilly.com/library/view/nginx-cookbook-2nd/9781098126230/) ### Networks * [Computer Networking Problems and Solutions](https://learning.oreilly.com/library/view/computer-networking-problems/9780134762814/) * [DNS and BIND](https://learning.oreilly.com/library/view/dns-and-bind/0596100574/) ### Monitoring * Anatomy of an Incident * [Observability Engineering](https://learning.oreilly.com/library/view/observability-engineering/9781492076438/) ### Perfromance Optimisation * [BPF Performance Tools](https://learning.oreilly.com/library/view/bpf-performance-tools/9780136588870/) ### DevOps Programing Languages * [Python for DevOps](https://learning.oreilly.com/library/view/python-for-devops/9781492057680/) * [Python Crash Course, 2nd Edition](https://learning.oreilly.com/library/view/python-crash-course/9781492071266/) * [Hands-On Enterprise Automation with Python](https://learning.oreilly.com/library/view/hands-on-enterprise-automation/9781788998512/) * [Go for DevOps](https://learning.oreilly.com/library/view/go-for-devops/9781801818896/) * [Beginning Perl Programming: From Novice to Professional](https://learning.oreilly.com/library/view/beginning-perl-programming/9781484250556/) * [Perl by Example](https://learning.oreilly.com/library/view/perl-by-example/9780133593068/) * [DevOps Tools for Java Developers](https://learning.oreilly.com/library/view/devops-learning-path-for/9781492084013/) ### Docker * [Docker: Up & Running, 3rd Edition](https://learning.oreilly.com/library/view/docker-up/9781098131814/) * [Container Security](https://learning.oreilly.com/library/view/container-security/9781492056690/) ### Kubernetes * [Kubernetes in Action](https://learning.oreilly.com/library/view/kubernetes-in-action/9781617293726/) * [50 Kubernetes Concepts Every DevOps Engineer Should Know](https://learning.oreilly.com/library/view/50-kubernetes-concepts/9781804611470/) ### Databases * [Introduction to Database Systems](https://www.amazon.com/Introduction-Database-Systems-8th/dp/0321197844) * [Database in Depth](https://learning.oreilly.com/library/view/database-in-depth/0596100124/) * [Database Design and Relational Theory](https://learning.oreilly.com/library/view/database-design-and/9781449330187/) * [Database Internals](https://learning.oreilly.com/library/view/database-internals/9781492040330/) ### Architecture * [Cloud Strategy The Architect Elevator](https://www.amazon.com/Cloud-Strategy-Decision-based-Successful-Migration-ebook/dp/B094RJ9K2C/) * [Continuous Architecture in Practice: Software Architecture in the Age of Agility and DevOps](https://learning.oreilly.com/library/view/continuous-architecture-in/9780136523796/) * [Clean Code](https://learning.oreilly.com/library/view/clean-code-a/9780136083238/) * [Clean Architecture](https://learning.oreilly.com/library/view/clean-architecture-a/9780134494272/) * [Cracking the Coding Interview](https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/0984782850) * [Hunt/The Pragmatic Programmer, First Edition](https://learning.oreilly.com/library/view/hunt-the-pragmatic-programmer/020161622X/) * [Building Multi-Tenant SaaS Architectures](https://learning.oreilly.com/library/view/building-multi-tenant-saas/9781098140632/) ### Software Architecture * [Fundamentals of Software Architecture](https://learning.oreilly.com/library/view/fundamentals-of-software/9781492043447/) * [The Software Architect Elevator](https://learning.oreilly.com/library/view/the-software-architect/9781492077534/) * [Software Architecture: The Hard Parts](https://learning.oreilly.com/library/view/software-architecture-the/9781492086888/) # Testimonials # Contributors Hvala svima koji su svojim doprinosom pomogli da ovaj repozitorij bude sto je moguce bolji i kvalitetniji. Ispod pogledajte listu kontributora ovog projekta bez kojih ovaj projekat ne bi bio moguc.
Contributor NameContributions
Boris Bradic
Alma Beganovic Kazija
Dragan Pavlovic
Marin Radjenovic
Halid Osmanovic
Dzenana Dzevlan (She/Her)
Dzenan Dzevlan (He/Him)
Viktor Farcic
Urban Jurca
Goran Opacic
Igor Ivanovic
Milan Pavlovic
Aleksandra Ljuboje
Husein Bajrektarevic
Ismail Icanovic
Ahmed Srebrenica
Adin Pilavdzija
Samir Mujanovic
Miroslav Latinovic
Robert Zuljevic
Vedad Nuhic
Kenan Jazic
# Code of Conduct Molimo vas da se prilikom komunikacije sa polaznicima, mentorima, kontributorima i svim ucesnicima ovog programa odnosite sa postovanjem i uvazavanjem. Svako narusavanje ovog pravila ce biti sankcionisano na nacin da ce polaznik biti iskljucen iz programa. Detaljnija pravila ponasanja su definisana unutar [AWS Code of Conduct](https://aws.amazon.com/codeofconduct/). # License **AUTOR NE PREUZIMA ODGOVORNOST ZA BILO KOJU STETU, GUBITKE ILI DRUGE POSLJEDICE KOJE NASTANU IZ UPOTREBE OVOG MATERIJALA/DOKUMENTACIJE. KORISTENJE OVOG MATERIJALA/DOKUMENTACIJE ODVIJA SE NA VLASTITU ODGOVORNOST KORISNIKA.** Materijal/dokumentacija se distribuira u nadi da će biti koristan, ali BEZ IKAKVE GARANCIJE, cak ni podrazumijevane garancije prodaje ili prikladnosti za odredjenu svrhu. Korisnik preuzima svu odgovornost za koristenje ovog materijala/dokumentacije. Sadrzaj ovog repozitorija moze se koristiti samo u nekomercijalne svrhe. Svi materijali, informacije i usluge koje se pružaju na ovoj stranici pružaju se "kako jesu" bez ikakvih garancija, bilo izričitih ili implicitnih. Svi tutorijali i upute na ovoj stranici pružaju se samo u informativne svrhe. Autor ne preuzima nikakvu odgovornost za tacnost, potpunost ili aktualnost sadržaja. Upotreba informacija na ovoj stranici odvija se na vlastitu odgovornost korisnika. Autor ne odgovara za eventualnu stetu koja moze nastati upotrebom informacija ili povezanih s informacijama na ovoj stranici. Autor takodjer ne preuzima nikakvu odgovornost za sadrzaj na vanjskim linkovima koji su navedeni na ovoj stranici. Napominjemo da su neki sadrzaji u ovom materijalu/dokumentaciji preuzeti sa interneta, te se izricito ogranicava odgovornost autora za bilo kakvo krsenje autorskih prava na tim sadrzajima. Korisnik ovog materijala/dokumentacije preuzima odgovornost za koristenje takvih sadrzaja u skladu sa zakonima o autorskim pravima i drugim relevantnim propisima. Ako se materijali iz ovog repozitorija dijiele na internetu ili drugim medijima, molimo vas da dodate referencu na **DevOps Mentorship Program i AWS Community Bosnia.**