RedHat & OpenShift

Tutorijal-praktikum za Red Hat Enterprise Linux, OpenShift, Kubernetes, kontejnere, klastere, aplikacije, DevOps tok rada, mreže, storage, sigurnost i monitoring
RedHat & OpenShift – uvod u RHEL, OpenShift, Kubernetes, kontejnere, DevOps i cloud native aplikacije
Uvod

RedHat & OpenShift predstavlja važan most između stabilnog enterprise Linux sistema i savremenog cloud native načina rada. Red Hat Enterprise Linux je osnova za sistemsku administraciju, servise, mreže, korisnike, pakete, sigurnost i automatizaciju, dok OpenShift uvodi Kubernetes, kontejnere, aplikacione platforme, DevOps tokove rada i modernizaciju aplikacija.

U velikim organizacijama retko postoji nagli prelazak sa klasičnih servera na kontejnere. Mnogo češće postoji slojevita stvarnost: deo sistema radi na Linux serverima, deo aplikacija se izvršava u virtuelnim mašinama, deo se postepeno kontejnerizuje, a novi servisi se sve češće razvijaju kao cloud native aplikacije. RedHat & OpenShift upravo tu ima svoju ulogu: povezuje postojeće Linux znanje sa Kubernetes platformom.

RHEL obezbeđuje stabilnu osnovu: operativni sistem, korisnike, grupe, procese, systemd servise, mrežna podešavanja, skladištenje, SELinux, firewall, pakete, logove i administraciju. OpenShift na tu osnovu dodaje Kubernetes sloj, rad sa kontejnerima, upravljanje klasterima, aplikacioni deployment, internal registry, sigurnosne politike, observability i saradnju razvojnih i infrastrukturnih timova.

Da bismo razumeli RedHat & OpenShift, prvo moramo razumeti odnos između Linux servera, kontejnera i Kubernetes klastera. Linux server je osnovno okruženje u kome se izvršavaju procesi i servisi. Kontejner je lakši način pakovanja aplikacije i njenih zavisnosti, pri čemu više kontejnera deli kernel operativnog sistema domaćina ili node-a na kome se izvršavaju.

Klasični Linux servisi su odlični za mnoge stabilne sisteme, baze, middleware, administrativne servise i tradicionalne aplikacije. Kontejneri su odlični za aplikacije koje se brzo razvijaju, skaliraju, redeploy-uju i prenose između okruženja. OpenShift ne kaže da se sve staro mora odmah zameniti novim, već omogućava da se postojeće znanje proširi ka uređenom Kubernetes svetu.

Kubernetes je centralni pojam u OpenShift svetu. On služi za orkestraciju kontejnera: pokretanje aplikacija, održavanje željenog broja replika, povezivanje servisa, upravljanje konfiguracijom, skaliranje, oporavak nakon greške i organizaciju workload-a. Umesto da ručno pokrećemo kontejnere jedan po jedan, Kubernetes upravlja celim aplikacionim okruženjem.

OpenShift je enterprise Kubernetes platforma koja Kubernetes proširuje dodatnim alatima, sigurnosnim pravilima, korisničkom konzolom, CLI alatima, registry sistemom, operatorima, route mehanizmom, build procesima i integracijom sa razvojnim tokovima rada. Zbog toga OpenShift nije samo „još jedan Kubernetes“, već platforma za rad timova u ozbiljnom organizacionom okruženju.

Jedan od važnih pojmova je OpenShift Container Platform. To je Red Hat-ova enterprise platforma za pokretanje i upravljanje kontejnerskim aplikacijama zasnovana na Kubernetes-u. Ona omogućava da organizacija ne pravi svaki Kubernetes klaster ručno i različito, već da ima standardizovan, podržan i upravljiv model za razvojna, testna i produkciona okruženja.

OKD je zajedničko, open source izdanje OpenShift platforme. Ono je važno za razumevanje ekosistema, jer pokazuje da OpenShift ima snažnu vezu sa otvorenim tehnologijama. Sa druge strane, komercijalna OpenShift Container Platform donosi enterprise podršku, integracije, sertifikovane komponente i stabilan životni ciklus za kompanije koje platformu koriste u produkciji.

Control Plane je upravljački sloj OpenShift klastera. On brine o stanju klastera, API zahtevima, raspoređivanju workload-a, konfiguraciji, kontrolerima i osnovnoj logici Kubernetes sistema. Kada korisnik zatraži da aplikacija ima tri replike, Control Plane je deo sistema koji radi na tome da stvarno stanje odgovara željenom stanju.

Worker node je radni čvor na kome se izvršavaju aplikacije i platformski servisi. Na njemu rade podovi, kontejneri i komponente potrebne za komunikaciju sa ostatkom klastera. Ako Control Plane možemo posmatrati kao upravljački mozak, worker node-ovi su radni prostor u kome aplikacije zaista žive.

etcd, API server i scheduler čine srce Kubernetes upravljanja. etcd čuva stanje klastera, API server prima zahteve i predstavlja ulaz u sistem, a scheduler odlučuje na koji node će se smestiti novi workload. Razumevanje ovih komponenti pomaže da OpenShift ne deluje kao magija, već kao uređen sistem sa jasnim ulogama.

Project i namespace su osnovni pojmovi organizacije u OpenShift-u. Namespace je Kubernetes logički prostor, dok OpenShift često koristi pojam project kao korisnički bliži način rada sa tim prostorom. Kroz projekte se razdvajaju timovi, aplikacije, razvojna okruženja, testna okruženja, produkcija i pristupi.

Operator je poseban način automatizovanog upravljanja aplikacijama i platformskim komponentama. Umesto da administrator ručno instalira, podešava i održava složene sisteme, operator u sebi nosi znanje o tome kako se određena aplikacija ili servis instalira, nadgleda, ažurira i oporavlja.

Pod je osnovna jedinica izvršavanja aplikacije u Kubernetes-u i OpenShift-u. U njemu se nalazi jedan ili više kontejnera koji dele određene resurse. Kada kažemo da aplikacija radi u OpenShift-u, često zapravo mislimo da se njeni kontejneri izvršavaju unutar podova koje klaster raspoređuje po node-ovima.

Deployment opisuje kako aplikacija treba da radi: koliko replika treba da postoji, koji container image se koristi, kako se aplikacija ažurira i kako se vraća na prethodnu verziju ako nešto pođe naopako. Deployment uvodi red, ponovljivost i kontrolu u rad sa aplikacijama.

Service omogućava stabilan pristup aplikaciji. Podovi mogu nestajati, menjati se i ponovo kreirati, ali aplikaciji je potreban stabilan način komunikacije. Service rešava taj problem jer obezbeđuje trajnu logičku adresu preko koje drugi delovi sistema pristupaju aplikaciji.

Route je jedan od prepoznatljivih OpenShift pojmova. Ona omogućava da se aplikacija izloži spoljnim korisnicima kroz adresu, najčešće preko HTTP ili HTTPS saobraćaja. Dok Kubernetes poznaje Ingress, OpenShift Route je veoma praktičan i često korišćen mehanizam za pristup aplikacijama izvan klastera.

ConfigMap i Secret služe za odvajanje konfiguracije od aplikacionog koda. ConfigMap čuva obične konfiguracione vrednosti, dok Secret čuva poverljivije podatke kao što su lozinke, tokeni i ključevi. Ovo je važno jer moderna aplikacija ne treba da nosi sve vrednosti tvrdo upisane u kodu.

oc CLI je komandna linija za rad sa OpenShift klasterom. Kroz nju se korisnik prijavljuje na klaster, bira project, pregleda podove, servise, route-ove, logove, deployment-e, build-ove i druge resurse. Za administratore i DevOps inženjere, oc postaje svakodnevni alat.

Web Console je grafički interfejs OpenShift platforme. Ona omogućava pregled projekata, aplikacija, resursa, logova, događaja, operatora, build procesa i stanja klastera. Konzola je posebno korisna za učenje, vizuelno razumevanje i timove koji ne rade sve isključivo iz komandne linije.

Container image je zapakovana verzija aplikacije. On sadrži aplikaciju i sve što joj je potrebno da se pokrene. Kada razvojni tim napravi novu verziju aplikacije, ona se često pakuje u novi image, označava verzijom i čuva u registry sistemu.

Internal Registry je skladište container image-a unutar OpenShift platforme. Može se posmatrati kao unutrašnja biblioteka aplikacionih slika iz koje klaster povlači ono što treba da pokrene. U enterprise okruženju registry mora biti zaštićen, kontrolisan, organizovan i povezan sa procesima skeniranja sigurnosti.

BuildConfig je OpenShift mehanizam koji omogućava izgradnju aplikacije iz izvornog koda ili drugog ulaznog materijala. To znači da platforma može učestvovati ne samo u pokretanju aplikacije, već i u njenoj izgradnji. Time se OpenShift približava CI/CD toku rada.

Deploy aplikacije u OpenShift okruženju znači mnogo više od samog pokretanja kontejnera. Potrebno je znati koji image se koristi, koji project je namenjen aplikaciji, koja konfiguracija je potrebna, koji service je izlaže, da li postoji route, da li aplikacija ima persistent storage i kako će se pratiti njeno stanje.

Rollback je važan deo pouzdanog rada. Ako nova verzija aplikacije ne radi kako treba, potrebno je brzo i kontrolisano vratiti prethodnu verziju. Kubernetes i OpenShift pristup omogućavaju da se promene ne rade kao improvizacija, već kroz verzije, deklarativne opise i jasne korake.

Mreža u OpenShift okruženju ima više slojeva. Postoji mreža fizičke infrastrukture, mreža node-ova, mreža podova, servisa, route-ova, ingress kontrolera i load balancer-a. Problem u komunikaciji može nastati na bilo kom od tih slojeva, pa je važno razviti dobru sliku celog puta saobraćaja.

Route i Ingress omogućavaju ulaz u aplikacije iz spoljnog sveta. U ozbiljnom okruženju oni se povezuju sa domenima, TLS sertifikatima, load balancer-ima i sigurnosnim pravilima. OpenShift Route je posebno važna jer omogućava jednostavno izlaganje aplikacije bez potrebe da korisnik odmah ručno gradi ceo ingress sloj.

Network Policy omogućava kontrolu komunikacije između aplikacija i projekata. Bez pravila, aplikacije mogu imati previše otvorenu komunikaciju. Sa Network Policy pristupom, moguće je preciznije odrediti ko sme da komunicira sa kim, što je važno za sigurnost i segmentaciju.

Storage je posebno važan kada aplikacije nisu potpuno stateless. Mnoge aplikacije imaju podatke, fajlove, baze ili stanje koje mora preživeti restart poda. Kubernetes i OpenShift koriste pojmove Persistent Volume, Persistent Volume Claim i Storage Class da bi aplikacije dobile trajno skladištenje podataka.

Storage Class omogućava da se različiti tipovi skladištenja ponude aplikacijama na standardizovan način. Jedna aplikacija može zahtevati brži storage, druga veći kapacitet, treća posebnu politiku dostupnosti. OpenShift povezuje te zahteve sa stvarnim storage sistemima koji postoje u organizaciji.

Sigurnost u RedHat & OpenShift okruženju obuhvata više nivoa: pristup RHEL serverima, pristup klasterima, RBAC, project ograničenja, sigurnost image-a, čuvanje Secret vrednosti, mrežnu segmentaciju, SELinux, security context, SCC, patching node-ova, kontrolu registry-ja i pregled logova. To nije jedna funkcija, već način razmišljanja kroz ceo sistem.

RBAC, odnosno Role-Based Access Control, omogućava da se prava korisnika i timova definišu prema ulozi. Ne treba svaki korisnik da ima administratorska prava. Razvojni tim može imati pravo da deploy-uje aplikaciju u svoj project, ali ne i da menja celu platformu ili pristupa tajnama drugih timova.

Security Context i SCC su veoma važni u OpenShift svetu. Oni određuju pod kojim korisnikom i sa kojim privilegijama kontejner sme da se pokrene. OpenShift je poznat po strožem sigurnosnom pristupu, što ponekad traži dodatno podešavanje aplikacija, ali donosi bolju zaštitu platforme.

Sigurnost container image-a postaje sve važnija. Ako aplikacija koristi image sa ranjivim bibliotekama, zastarelim paketima ili nepoznatim poreklom, rizik se prenosi u klaster. Zato se image-i proveravaju, skeniraju, potpisuju i čuvaju u kontrolisanim registry sistemima.

CI/CD je prirodan deo OpenShift priče. Moderna aplikacija se ne menja jednom godišnje, već često prolazi kroz build, test, security check, image build, push u registry i deploy u odgovarajuće okruženje. OpenShift se uklapa u takav tok jer omogućava ponovljiv i automatizovan deployment.

GitOps ide korak dalje i uvodi ideju da se stanje sistema opisuje u Git repozitorijumu. Umesto da se promene rade ručno, konfiguracija klastera i aplikacija čuva se kao kod. To donosi bolji trag promena, lakši rollback, preglednost i saradnju između timova.

Monitoring je neophodan za svako ozbiljno OpenShift okruženje. Potrebno je pratiti klastere, node-ove, podove, aplikacije, potrošnju resursa, greške, restartovanja, latenciju, dostupnost i trendove. Bez monitoringa, Kubernetes može delovati kao crna kutija, posebno kada se broj aplikacija poveća.

Logovi su drugi veliki izvor istine. Kada aplikacija ne radi, često prvi trag dolazi iz logova poda, aplikacije, route-a, kontrolera ili sistemskih komponenti. U OpenShift i Kubernetes okruženju važno je znati gde se logovi nalaze, kako se čitaju i kako se povezuju sa događajima u klasteru.

Troubleshooting u RedHat & OpenShift svetu traži strpljenje i razumevanje slojeva. Problem može biti u image-u, konfiguraciji, Secret-u, mreži, DNS-u, storage-u, RBAC pravilima, security context-u, resursnim ograničenjima, node-u, klasteru, RHEL osnovi ili fizičkom okruženju. Zato se problemi ne rešavaju napamet, već kroz tragove, komande, događaje i logove.

Važno je razumeti da OpenShift nije samo alat za programere niti samo alat za administratore. On se nalazi između ta dva sveta. Razvojnom timu daje način da aplikacije isporučuje brže i standardizovanije, a infrastrukturnom timu daje mogućnost da zadrži kontrolu nad resursima, sigurnošću, mrežom, storage-om i pravilima.

U organizacijama koje već koriste Red Hat Enterprise Linux, OpenShift može biti prirodan korak ka modernizaciji. Umesto da se sve seli odjednom u javni cloud ili potpuno novu platformu, postojeće Linux znanje i administrativna praksa šire se Kubernetes mogućnostima. To je posebno korisno tamo gde postoje stroga pravila, osetljivi podaci, interne aplikacije i velika ulaganja u stabilnu infrastrukturu.

RedHat & OpenShift je važan i za DevOps učenje. DevOps nije samo pisanje pipeline-a. DevOps podrazumeva razumevanje aplikacije, infrastrukture, automatizacije, verzionisanja, deploy procesa, monitoringa, incidenta i saradnje. OpenShift pokazuje kako se ti elementi spajaju u enterprise okruženju.

Za sistem administratore, RedHat & OpenShift je prilika da se postojeće znanje o Linux-u proširi ka Kubernetes-u i kontejnerima. Za developere, to je prilika da bolje razumeju gde njihova aplikacija zaista radi. Za DevOps inženjere, to je odličan prostor za spajanje oba pogleda.

U ovom praktikumu nećemo posmatrati OpenShift samo kao skup naziva i proizvoda. Posmatraćemo ga kroz praktične pojmove: šta je klaster, šta je project, kako se aplikacija deploy-uje, kako se povezuje mreža, kako se koristi storage, kako se čuvaju tajne, kako se prati stanje i kako se rešavaju problemi.

Kroz lekcije ćemo graditi sliku postepeno. Prvo ćemo razumeti zašto se OpenShift pojavljuje u Red Hat svetu, zatim kako izgleda arhitektura, potom ćemo preći na Kubernetes osnove, oc CLI, web konzolu, aplikacije, mreže, storage, sigurnost, CI/CD, GitOps, monitoring i troubleshooting.

U završnim lekcijama radićemo mini projekte. Jedan će biti mali RedHat & OpenShift lab za učenje i vežbu, a drugi model enterprise aplikacije na OpenShift platformi. Cilj je da se vidi kako jedna tradicionalna organizacija može postepeno uvesti Kubernetes i cloud native pristup bez gubitka kontrole nad infrastrukturom.

Cilj ovog tutorijala nije da odmah obuhvati svaku OpenShift komponentu i svaku moguću arhitekturu. Cilj je da se izgradi stabilna osnova: da znamo šta je RedHat & OpenShift, zašto je važan, kako povezuje RHEL i Kubernetes, kako rade klasteri, kako se deploy-uju aplikacije i kako se razmišlja o sigurnosti, mreži, storage-u i operativnom radu.

RedHat & OpenShift zato možemo posmatrati kao platformu prelaza. Sa jedne strane stoji stabilan Linux sistem, a sa druge strane savremeni svet kontejnera, automatizacije i cloud native razvoja. Kada razumemo oba sveta, mnogo lakše razumemo kako izgleda moderna IT infrastruktura u velikim organizacijama.

Povratak na sadržaj Sledeća lekcija →