VMware & Tanzu
Poslednjih godina način razvoja, implementacije i održavanja poslovnih aplikacija doživeo je jednu od najvećih promena od šireg uvođenja serverske virtuelizacije. Organizacije koje su godinama ili decenijama gradile pouzdane data centre zasnovane na VMware infrastrukturi danas istovremeno uvode kontejnere, Kubernetes, automatizovane CI/CD tokove, GitOps pristup, platform engineering, infrastrukturu kao kod i cloud-native arhitekture.
U realnim enterprise okruženjima cilj najčešće nije potpuno napuštanje postojećih sistema niti jednostavna zamena virtuelnih mašina kontejnerima. Veliki broj poslovnih aplikacija i dalje zavisi od tradicionalnih serverskih arhitektura, baza podataka, mrežnih servisa, specifičnih operativnih sistema i infrastrukturnih komponenti koje imaju sopstveni životni ciklus i zahteve dostupnosti. Istovremeno, nove aplikacije zahtevaju bržu isporuku, horizontalno skaliranje, deklarativno upravljanje, automatizaciju i standardizovane razvojne platforme.
Upravo na toj raskrsnici infrastrukture, automatizacije i aplikacione modernizacije nalazi se VMware & Tanzu. U ovom tutorijalu taj izraz koristimo kao praktičnu oznaku za okruženje u kome se VMware infrastrukturni sloj povezuje sa Kubernetes i Tanzu tehnologijama, uz svest da se nazivi proizvoda, pakovanja, licenci, komponenti i podržanih arhitektura kroz vreme menjaju i da se za svaku konkretnu implementaciju mora proveriti dokumentacija odgovarajuće verzije.
VMware & Tanzu predstavlja mnogo više od mogućnosti da se Kubernetes klaster pokrene na VMware infrastrukturi. Reč je o skupu infrastrukturnih sposobnosti, Kubernetes mehanizama, platformskih servisa, arhitektonskih obrazaca i operativnih praksi pomoću kojih se virtuelizacija, compute resursi, mreže, storage, identiteti, bezbednosne politike, kontejnerske aplikacije, automatizovani tokovi promena i sistemi za nadzor povezuju u jednu upravljivu celinu.
Takva platforma prirodno prelazi granice jednog administrativnog tima. U njenom radu učestvuju VMware administratori, Kubernetes i platform administratori, DevOps i SRE timovi, razvojni timovi, mrežni stručnjaci, storage administratori, bezbednosni timovi, administratori identiteta, stručnjaci za backup i disaster recovery, kao i vlasnici poslovnih aplikacija. Zbog toga tehnički uspešna instalacija sama po sebi nije dovoljna. Potrebno je jasno definisati vlasništvo, granice odgovornosti, način odobravanja promena, modele pristupa, operativne procedure i način dokazivanja da platforma funkcioniše očekivano.
Ovaj tutorijal nastao je sa ciljem da čitaocu pruži celovito i sistematično razumevanje tog složenog okruženja. Njegov zadatak nije samo da predstavi pojedinačne VMware, Tanzu ili Kubernetes komponente, već da objasni kako one međusobno sarađuju, od čega zavise, gde se završava odgovornost jedne komponente i počinje odgovornost druge, kao i na koji način se kompletna platforma bezbedno koristi, nadzire, menja i oporavlja u svakodnevnom enterprise radu.
Za razliku od priručnika koji odmah prelaze na komande, YAML manifeste i konfiguracione procedure, ovde se znanje gradi postepeno. Najpre se uspostavlja konceptualna osnova, zatim se objašnjava arhitektura i raspodela odgovornosti, a tek potom se prelazi na praktičan rad sa klasterima, aplikacijama, mrežama, storage-om, identitetima, bezbednošću, automatizacijom, monitoringom i operativnim održavanjem.
Cilj nije da čitalac zapamti niz komandi ili putanju kroz određeni grafički interfejs. Važnije je da razvije administratorski i platformski način razmišljanja: da pre promene utvrdi početno stanje, razume zavisnosti i rizike, predvidi očekivani rezultat i način povratka, tokom rada sačuva relevantne dokaze, a nakon promene potvrdi ne samo stanje pojedinačnog objekta već i funkcionalnost servisa koji od tog objekta zavisi.
VMware već dugo predstavlja jedan od važnih temelja enterprise infrastrukture. ESXi hostovi, vCenter Server, vSphere klasteri, virtuelne i distribuirane mreže, datastore sistemi, visoka dostupnost, kontrola resursa, centralizovano upravljanje i automatizacija omogućili su organizacijama da fizički hardver pretvore u fleksibilan infrastrukturni sloj na kome mogu pouzdano da izvršavaju veliki broj poslovnih sistema.
Virtuelizacija je razdvojila životni ciklus operativnog sistema i aplikacije od pojedinačnog fizičkog servera. Virtuelna mašina može biti kreirana, klonirana, premeštena, nadgledana, zaštićena i oporavljena bez potrebe da njen identitet bude vezan za jedan konkretan komad hardvera. Time je infrastruktura postala znatno fleksibilnija, ali su i dalje operativni sistem, konfiguracija servera i veliki deo aplikativnog okruženja ostali administrativna odgovornost.
Kontejnerizacija uvodi sledeći nivo apstrakcije. Aplikacija se više ne posmatra prvenstveno kao servis instaliran na određenom serveru, već kao skup komponenti upakovanih u container image-e i izvršavanih kroz standardizovani runtime. Kubernetes zatim uvodi deklarativni model upravljanja u kome administrator ili razvojni sistem ne opisuje samo pojedinačnu naredbu, već željeno stanje aplikacije i infrastrukture dostupne toj aplikaciji.
Kubernetes je postao široko prihvaćen temelj za orkestraciju kontejnerskih workload-a koji se često menjaju, horizontalno skaliraju, automatski ponovo raspoređuju i distribuiraju kroz više čvorova. Deployment, StatefulSet, Service, ConfigMap, Secret, PersistentVolumeClaim, NetworkPolicy i drugi API objekti postaju deo modela kojim se opisuje ne samo gde aplikacija radi, već i kakvo stanje platforma treba da održava.
VMware & Tanzu ne pokušava da jedan od tih svetova jednostavno zameni drugim. Njegova vrednost nalazi se upravo u povezivanju postojećeg vSphere infrastrukturnog modela sa Kubernetes načinom upravljanja aplikacijama i platformskim resursima.
Organizacija tako može zadržati postojeće znanje o hostovima, klasterima, mrežama, storage-u, identitetima, politici dostupnosti, lifecycle-u i infrastrukturnoj kontroli, a iznad tog sloja izgraditi Kubernetes platformu koja razvojnim i DevOps timovima pruža standardizovan model za implementaciju i upravljanje savremenim aplikacijama.
Time modernizacija ne mora da bude nagli prelaz sa „starog“ na „novo“. Virtuelne mašine, baze podataka, tradicionalne aplikacije i Kubernetes workload-i mogu postojati u istom širem informacionom sistemu, ali uz različite operativne modele. Ključni zadatak arhitekture jeste da njihove zavisnosti, granice odgovornosti i tokove promena učini jasnim, kontrolisanim i proverljivim.
Razumevanje Tanzu okruženja počinje razumevanjem infrastrukture ispod Kubernetes-a. Kubernetes objekti ne postoje izvan fizičke stvarnosti. Njihovo izvršavanje na kraju zavisi od procesora, memorije, mrežnih kartica, fizičkih i virtuelnih svičeva, VLAN-ova, rutiranja, DNS-a, storage sistema, datastore-a, load balancer-a, sertifikata i identiteta.
vSphere i vCenter Server zato nisu samo mesto na kome se „nalaze virtuelne mašine“. Oni čine upravljački i infrastrukturni sloj koji obezbeđuje compute, mrežne i storage resurse neophodne platformi. Dizajn klastera, dostupni kapacitet, HA i DRS politike, mrežna topologija, storage mogućnosti, pristupni modeli i lifecycle hostova direktno utiču na Kubernetes sloj iznad njih.
U arhitekturama koje koriste Supervisor, Kubernetes sposobnosti integrišu se u vSphere okruženje i omogućavaju da infrastrukturni resursi budu izloženi kroz Kubernetes model upravljanja. Supervisor pri tome ne treba posmatrati kao izolovani dodatak vCenter-u, već kao deo šire platforme u kojoj infrastrukturne odluke i Kubernetes objekti postaju međusobno povezani.
Iznad ili uz takav sloj mogu postojati klasteri namenjeni aplikativnim workload-ima i razvojnim timovima. Njihovi konkretni nazivi, način kreiranja i lifecycle zavise od verzije, arhitekture i korišćenog Tanzu rešenja, ali zajednička ideja ostaje ista: platforma mora omogućiti kontrolisano izdvajanje resursa, upravljanje čvorovima, verzijama i kapacitetom i jasnu granicu između upravljanja infrastrukturom i upravljanja aplikacijama.
Namespace u tom modelu nije samo logičko ime. On može predstavljati granicu organizacije, politike, kvote, pristupa, vlasništva ili tima. Pravilno projektovani namespace-i, resursne kvote, politike i prava pristupa omogućavaju da više timova deli zajedničku platformu bez pretpostavke da svi imaju ista ovlašćenja ili iste infrastrukturne potrebe.
Takav model uvodi važnu promenu u načinu razmišljanja. VMware administrator više ne upravlja samo hostovima i virtuelnim mašinama, Kubernetes administrator više ne posmatra samo API objekte, a razvojni tim ne može pretpostaviti da je platforma beskonačan skup resursa. Svaki sloj ima sopstvene odgovornosti, ali rezultat zavisi od njihove koordinacije.
Ako workload ne može da se pokrene, uzrok može biti nedostatak Kubernetes resursa, problem u schedulingu, neodgovarajuća politika, storage provisioning, mrežna dostupnost, nedovoljan vSphere kapacitet ili kvar infrastrukture. Zbog toga troubleshooting u Tanzu okruženju gotovo uvek zahteva razumevanje više slojeva.
Isto važi i za dostupnost. Kubernetes može ponovo kreirati Pod, klaster može imati više worker čvorova, a vSphere može imati HA i DRS. Međutim, poslovna usluga neće biti pouzdana ako svi njeni delovi zavise od iste tačke otkaza, ako nema dovoljno rezervnog kapaciteta, ako je storage nedostupan ili ako spoljašnji load balancer, DNS ili identitetski servis predstavljaju neprepoznatu zavisnost.
Rad sa Tanzu platformom zahteva čvrsto razumevanje Kubernetes osnove. Platformski sloj može automatizovati instalaciju, lifecycle ili integraciju pojedinih komponenti, ali ne ukida logiku Kubernetes API-ja, kontrolnih petlji, schedulinga, workload kontrolera, mrežnog modela i trajnog skladištenja.
Pod predstavlja osnovnu izvršnu jedinicu, ali se poslovna aplikacija gotovo nikada ne projektuje kao ručno održavan pojedinačni Pod. Deployment i ReplicaSet obezbeđuju željeni broj replika i kontrolisani rollout stateless aplikacija, dok StatefulSet dodaje stabilniji identitet i vezu sa trajnim podacima za workload-e kojima su takva svojstva potrebna.
Service odvaja stabilni servisni identitet od promenljivog skupa Podova. Njegova funkcionalnost zavisi od selektora, odgovarajućih endpoint-a, mrežnog sloja i dostupnosti backend aplikacije. Zbog toga Service koji postoji u API-ju nije automatski dokaz da je aplikacija dostupna korisniku.
Ingress ili drugi mehanizmi spoljnog rutiranja povezuju aplikaciju sa korisnicima van klastera, ali njihovo ponašanje zavisi od konkretnog kontrolera, DNS-a, sertifikata, load balancer-a i mrežnih pravila. U enterprise okruženju spoljašnja dostupnost aplikacije gotovo uvek predstavlja saradnju Kubernetes platforme i infrastrukture van samog klastera.
ConfigMap i Secret omogućavaju razdvajanje konfiguracije i poverljivih vrednosti od samog container image-a. Međutim, Secret objekat nije automatski kompletno rešenje za upravljanje tajnama. Potrebno je razumeti pristupne politike, način čuvanja podataka, rotaciju kredencijala, integraciju sa spoljnim sistemima za tajne i audit pristupa.
Container image predstavlja izvršnu osnovu aplikacije, ali njegova upotreba otvara dodatna pitanja: ko je image napravio, iz kog izvornog koda, kojim pipeline-om, sa kojim zavisnostima, gde je skeniran, ko je odobrio njegovu upotrebu i u kom registry-ju se nalazi. U zrelom okruženju poreklo image-a postaje deo lanca poverenja, a ne samo tehnički detalj deployment-a.
Zbog toga Kubernetes osnove u ovom tutorijalu nisu predstavljene kao izolovane definicije. Pod, Deployment, Service, Ingress, ConfigMap, Secret, PersistentVolumeClaim, NetworkPolicy i drugi objekti posmatraju se kao povezani delovi aplikativnog sistema koji zajedno zavise od platforme, infrastrukture i operativnih pravila.
Kubernetes klaster nije statičan skup servera koji se jednom instalira i zatim neograničeno koristi. On ima verziju, komponente, sertifikate, čvorove, mrežne i storage zavisnosti, politike, kompatibilnosti i sopstveni lifecycle.
U Tanzu okruženju kreiranje i upravljanje klasterima predstavljaju važan deo platformskog sloja. Administrator mora razumeti kako se definišu control plane i worker resursi, kako se upravlja grupama ili pool-ovima čvorova, kako se dodeljuje kapacitet i kako se platforma ponaša kada je potrebno skaliranje, održavanje ili zamena čvora.
Različite generacije i arhitekture Tanzu tehnologija mogu koristiti različite modele upravljanja i terminologiju, ali operativna pitanja ostaju ista: ko kreira klaster, ko određuje njegovu verziju, koji infrastrukturni resursi su mu potrebni, kako se proverava kompatibilnost, kako se obavlja nadogradnja i na koji način se reaguje ako promena ne uspe.
Nadogradnja Kubernetes verzije zato nije samo pokretanje komande. Potrebno je proveriti podržani put nadogradnje, kompatibilnost platforme, CNI i CSI komponenti, ingress ili gateway sloja, dodatnih operatora i aplikacija, stanje klastera pre promene, raspoloživi kapacitet i način oporavka.
Isto važi za skaliranje. Dodavanje worker čvorova ima smisla samo ako infrastruktura raspolaže potrebnim compute, mrežnim i storage resursima. Skaliranje Kubernetes sloja ne može stvoriti fizički kapacitet koji u vSphere okruženju ne postoji.
Upravljanje lifecycle-om zato mora povezati dva sveta: Kubernetes stanje i stanje vSphere infrastrukture. Tek kada se oba sloja posmatraju zajedno moguće je pravilno planirati održavanje, kapacitet, dostupnost i kontrolisane promene.
Aplikacija u Tanzu okruženju nije samo Pod koji je uspešno dostigao stanje Running. Ona može zavisiti od više Deployment-a, Service objekata, tajni, konfiguracija, baza podataka, persistent storage-a, spoljašnjih API servisa, DNS-a, sertifikata, load balancer-a i sistema identiteta.
Implementacija aplikacije zato mora imati jasno definisan početak i kriterijum uspeha. Potrebno je znati koji image se implementira, koja verzija konfiguracije se koristi, koje zavisnosti moraju biti dostupne i kojim signalima se potvrđuje da je aplikacija zaista spremna za korisnički saobraćaj.
Rollout i rollback predstavljaju deo istog procesa. Promena nije bezbedna samo zato što postoji mogućnost da se nova verzija postavi; bezbedna je tek kada postoji način da se rezultat proveri i kada je poznato pod kojim uslovima se treba vratiti na prethodno stanje.
Mrežni sloj predstavlja jednu od najvažnijih tačaka integracije između Kubernetes-a i VMware infrastrukture. Komunikacija Podova, Service objekata, ingress sloja, load balancer-a, DNS-a i spoljašnjih mreža zavisi od kombinacije Kubernetes mrežnog modela i konkretne infrastrukturne implementacije.
NetworkPolicy omogućava definisanje dozvoljene komunikacije između workload-a, ali njen stvarni efekat zavisi od mrežne implementacije koja je podržava. Pravilno napisana politika koja se ne sprovodi u izabranom mrežnom sloju predstavlja samo deklaraciju bez očekivanog bezbednosnog rezultata.
Load balancer takođe nije samo Kubernetes objekat. Iza njega može postojati poseban infrastrukturni servis, IP adresni opseg, mrežna politika, firewall pravilo, DNS zapis i operativna odgovornost drugog tima. Zato problem sa spoljašnjom dostupnošću mora biti analiziran od aplikacije do krajnjeg korisnika, a ne samo iz perspektive jednog manifesta.
Trajni podaci predstavljaju drugi veliki spoj aplikativnog i infrastrukturnog sveta. PersistentVolume i PersistentVolumeClaim omogućavaju Kubernetes aplikaciji da zahteva skladišni resurs, dok StorageClass i CSI sloj povezuju taj zahtev sa konkretnim storage sistemom.
Aplikativni tim pri tome može videti jednostavan PVC objekat, dok se iza njega nalaze datastore politika, storage infrastruktura, kapacitet, performanse, dostupnost i pravila zaštite podataka. Upravo zato platformski tim mora znati šta se dešava ispod Kubernetes API-ja.
Snapshot storage resursa nije automatski kompletna strategija backup-a, a postojanje rezervne kopije ne dokazuje mogućnost oporavka dok restore nije izveden i validiran. Potrebno je znati da li se štiti samo persistent volume, kompletna aplikacija, njena konfiguracija, tajne, baza podataka ili širi skup zavisnih servisa.
Bezbednost u VMware & Tanzu okruženju ne može biti dodatak koji se uvodi nakon završene instalacije. Ona počinje od administrativnih identiteta, pristupa vSphere infrastrukturi i Kubernetes API-ju, a nastavlja se kroz RBAC, servisne naloge, politike workload-a, tajne, image-e, mrežnu segmentaciju, sertifikate i audit trag.
Princip najmanjih privilegija primenjuje se i na ljude i na automatizovane procese. Korisnik treba da ima samo prava koja su mu potrebna za odgovornost koju obavlja, a servisni nalog samo dozvole neophodne aplikaciji ili automatizaciji koju predstavlja.
Posebno je važno razdvojiti infrastrukturnu i aplikativnu administraciju. Činjenica da razvojni tim treba mogućnost da kreira Deployment ne znači da mu je potreban administrativni pristup vCenter Serveru. Isto tako, VMware administrator ne mora automatski imati pravo da menja svaku aplikativnu tajnu ili namespace politiku.
RBAC zato nije samo tehnički mehanizam već način modelovanja odgovornosti. Uloge, grupe i dozvole treba povezati sa stvarnim poslovnim i operativnim funkcijama, a ne sa trenutnom potrebom da se neka zabrana brzo zaobiđe.
Container image predstavlja još jednu bezbednosnu granicu. Potrebno je kontrolisati poreklo image-a, ranjivosti, registre iz kojih je dozvoljeno preuzimanje, pristupne kredencijale i pravila koja sprečavaju nekontrolisano izvršavanje neproverenog koda.
Tajne zahtevaju sopstveni lifecycle. Kredencijal koji je jednom unet u sistem ne bi trebalo smatrati trajnim. Potrebno je planirati njegovu zaštitu, distribuciju, rotaciju i eventualno opozivanje, kao i način na koji se proverava da li je promena kredencijala pravilno preneta do aplikacije.
Audit trag daje mogućnost da se administrativna ili automatizovana promena kasnije rekonstruiše. Zrela platforma treba da omogući odgovor na pitanja: ko je izvršio promenu, kada, nad kojim resursom, na osnovu kog odobrenja i sa kakvim rezultatom.
CI/CD i GitOps predstavljaju prirodan nastavak deklarativnog upravljanja aplikacijama. Kada se konfiguracija čuva u verzionisanom repozitorijumu, promena više ne mora da bude niz ručnih komandi koje postoje samo u terminal istoriji jednog administratora.
Build proces kreira novi artefakt ili container image, testovi proveravaju očekivano ponašanje, registry obezbeđuje mesto kontrolisanog čuvanja, a deployment proces uvodi novu verziju u ciljno okruženje. Svaki korak može ostaviti dokaz koji se kasnije povezuje sa izvorom promene.
GitOps dodatno uvodi ideju da repozitorijum predstavlja deklarisani izvor željenog stanja platforme ili aplikacije, dok automatizovani kontroler pokušava da stvarno stanje približi deklarisanom. Time se olakšava pregled promena, istorija, odobravanje i otkrivanje konfiguracionog drifta.
Ipak, automatizacija sama po sebi nije garancija kvaliteta. Loša promena može biti automatizovano sprovedena jednako brzo kao i dobra. Zbog toga pipeline mora imati jasne kriterijume prihvatanja, validaciju, kontrolu pristupa, ograničen obim promene i definisanu reakciju na neuspeh.
Isto važi i za GitOps. Repozitorijum može biti izvor istine samo ako postoje jasna pravila ko ga menja, kako se promene pregledaju, šta pripada određenom okruženju, kako se čuvaju tajne i na koji način se rešava neslaganje između deklarisanog i stvarnog stanja.
Cilj nije samo brže objavljivanje aplikacije. Cilj je uspostavljanje procesa u kome se promena može objasniti, ponoviti, pregledati, dokazati i po potrebi vratiti.
Produkciona platforma mora biti merljiva. Bez pouzdanih signala administrator ne može znati da li sistem radi očekivano, da li se približava kapacitetskom ograničenju ili da li je određena promena izazvala degradaciju.
Monitoring, metrike, logovi, Kubernetes događaji, audit zapisi, vSphere događaji i infrastrukturni alarmi predstavljaju različite izvore dokaza. Njihova prava vrednost nastaje tek kada se povežu sa vremenom, simptomom, zahvaćenim objektima i nedavnim promenama.
Problem koji se vidi na aplikaciji može nastati u samom kodu, container image-u, konfiguraciji, Secret objektu, Kubernetes kontroleru, schedulingu, mrežnoj politici, DNS-u, registry pristupu, storage provisioningu, sertifikatu, worker čvoru ili vSphere infrastrukturnom sloju.
Zbog toga troubleshooting ne treba da počne nasumičnim menjanjem resursa. Prvo se definiše simptom: šta tačno ne radi, od kada, kome i u kom obimu. Zatim se prikupljaju dokazi, razdvajaju slojevi, formira hipoteza i bira najmanja bezbedna intervencija kojom se hipoteza može proveriti.
Posle korekcije potrebno je potvrditi ne samo da je upozorenje nestalo ili da je Pod ponovo pokrenut, već da je poslovna funkcija vraćena, da se problem ne ponavlja i da intervencija nije proizvela dodatnu posledicu na drugom sloju.
Zrela observability praksa omogućava i retrospektivno učenje. Incident ne završava vraćanjem usluge. Potrebno je razumeti osnovni uzrok, uslove koji su omogućili problem, nedostajuće signale, nejasne procedure i korektivne mere koje smanjuju verovatnoću ponavljanja.
Produkciona VMware & Tanzu platforma ne postoji izolovano od ostatka organizacije. Ona mora biti povezana sa sistemima identiteta, CMDB rešenjima, infrastrukturnim inventarom, VMware tagovima, procesima upravljanja promenama, monitoring platformama, bezbednosnim sistemima, registry-jima, backup servisima, DNS-om, mrežom i drugim infrastrukturnim uslugama.
Nije dovoljno znati da određeni klaster, namespace ili workload postoji. Potrebno je znati kome pripada, koju poslovnu uslugu podržava, u kom okruženju radi, kakvu kritičnost ima, ko odobrava njegove promene, ko reaguje na incidente i kakav lifecycle treba očekivati.
Inventar zato nije samo tehnički spisak. On predstavlja vezu između API objekta i poslovnog značenja. VMware folderi, tagovi i kategorije, Kubernetes labels i annotations, CMDB podaci i standardi imenovanja mogu zajedno izgraditi sliku vlasništva i zavisnosti.
Kada ti podaci nisu uređeni, automatizacija može pomoći u prikupljanju tehničkog stanja, ali ne može sama izmisliti poslovni kontekst. Administrator može automatski prikupiti ime klastera, verziju, resurse ili tagove, ali neko i dalje mora potvrditi ko je vlasnik aplikacije, koliko je kritična i kakvu politiku održavanja zahteva.
Upravljanje promenama predstavlja drugi važan enterprise sloj. Kubernetes i GitOps omogućavaju brzu tehničku primenu konfiguracije, ali organizacija i dalje mora znati ko je promenu odobrio, kada se ona sme izvršiti, kakav uticaj se očekuje, kojim dokazima se potvrđuje rezultat i pod kojim uslovima se aktivira rollback.
Dobra platforma ne pokušava da ukloni sve procese, već da nepotrebne ručne korake zameni automatizacijom, a stvarne kontrole učini jasnim i proverljivim.
Jedna od važnih tema ovog tutorijala jeste interoperabilnost sa drugim Kubernetes okruženjima. Aplikacija koja radi na Tanzu platformi može sadržati veliki broj standardnih Kubernetes objekata, ali to ne znači automatski da se bez izmene može preseliti u Vanilla Kubernetes, OpenShift, managed cloud servis ili neku drugu distribuciju.
Prenosivost mora biti analizirana po slojevima. Deployment, Service ili ConfigMap mogu biti standardni Kubernetes resursi, dok storage klasa, ingress kontroler, load balancer integracija, identity provider, operator, prilagođeni resurs, policy mehanizam ili način upravljanja tajnama mogu biti vezani za konkretnu platformu.
Storage je naročito važan. Manifest može zahtevati PersistentVolumeClaim, ali konkretni CSI drajver, StorageClass ime, snapshot mehanizam, performanse, topologija i način migracije podataka zavise od ciljnog okruženja.
Slično važi za mrežu. NetworkPolicy može biti standardni objekat, ali CNI implementacija, ingress model, load balancer, dostupni IP opsezi, DNS i firewall pravila razlikuju se između okruženja.
Identiteti, tajne i bezbednosne politike predstavljaju dodatni sloj. Korisnik ili ServiceAccount koji postoji u jednom sistemu ne mora imati odgovarajući identitet, dozvole ili integraciju u drugom.
Migracija zato nije samo kopiranje YAML manifest fajlova. Ona zahteva inventar zavisnosti, klasifikaciju standardnih i platformski specifičnih resursa, plan prenosa podataka, proveru mrežnih putanja, identiteta, registry-ja, sertifikata, politika, automatizacije, monitoringa i operativnih procedura.
Cilj ove teme nije da se platformske razlike predstavljaju kao nedostatak. Svaka platforma dodaje sopstvene sposobnosti zato što pokušava da reši određene infrastrukturne i operativne probleme. Važno je znati gde se završava prenosivi Kubernetes koncept, a gde počinje konkretna implementacija.
Teorijsko razumevanje platforme dobija punu vrednost tek kada se proveri kroz praktičan rad. Zato laboratorije u ovom tutorijalu nisu zamišljene kao izolovani niz komandi koje treba slepo ponoviti, već kao kontrolisani scenariji u kojima se povezuju arhitektura, infrastruktura, Kubernetes objekti, mreža, storage, bezbednost, automatizacija i operativna validacija.
Početne laboratorije treba da omoguće upoznavanje sa vSphere i Tanzu infrastrukturnim slojem, organizacijom resursa, pristupom platformi i osnovnim Kubernetes objektima. Cilj je da čitalac pre složenijih scenarija nauči da razlikuje šta posmatra na infrastrukturnom, šta na platformskom, a šta na aplikativnom nivou.
Kasniji praktikumi povezuju implementaciju aplikacije sa Service i ingress slojem, storage zahtevima, tajnama, politikama pristupa i monitoringom. Promena se smatra završenom tek kada je potvrđena funkcionalnost kompletnog servisa, a ne samo kada je objekat prihvaćen od Kubernetes API-ja.
Integrisani projekti povezuju infrastrukturnu pripremu, Kubernetes resurse, mrežu, storage, sigurnost, automatizaciju, monitoring, dokumentovanje i završnu validaciju. Takav projekat više liči na realni zadatak platformskog tima nego na klasičnu vežbu iz jednog proizvoda.
Važan deo laboratorijskog rada predstavljaju i kontrolisani kvarovi. Čitalac treba da vidi šta se dešava kada aplikacija nije spremna, kada image ne može da se preuzme, kada storage nije dostupan, kada mrežna politika blokira saobraćaj, kada čvor postane nedostupan ili kada promena proizvede neočekivani rezultat.
Cilj takvih scenarija nije proizvodnja greške radi same greške. Cilj je razvijanje sposobnosti da se stanje prikupi, simptom ograniči, uzrok dokaže, izvrši minimalna korekcija i potvrdi da je sistem zaista vraćen u očekivano stanje.
Struktura knjige prati prelaz od infrastrukturne osnove ka upravljanoj cloud-native platformi. Gradivo nije organizovano kao katalog funkcionalnosti, već kao put kojim čitalac postepeno prelazi od razumevanja postojeće VMware infrastrukture do projektovanja, korišćenja, održavanja i povezivanja Tanzu i Kubernetes okruženja sa širim enterprise sistemom.
U početnim celinama objašnjava se put od virtuelnih mašina i tradicionalne vSphere infrastrukture do kontejnera i Kubernetes modela. Cilj je da čitalac razume šta se virtuelizacijom već rešava, koje nove probleme uvodi kontejnerski model i zašto organizaciji može biti potrebna platforma koja povezuje ta dva sveta.
Sledeće celine posvećene su arhitekturi VMware & Tanzu okruženja, infrastrukturnim preduslovima, Supervisor sloju tamo gde ga izabrana arhitektura koristi, Kubernetes klasterima, namespace organizaciji, resursnim ograničenjima i granicama odgovornosti između infrastrukturnog, platformskog i aplikativnog tima.
Nakon toga se Kubernetes objekti obrađuju kroz Tanzu praksu. Podovi, Deployment-i, Service objekti, konfiguracija, tajne i routing više nisu samo definicije, već elementi aplikacije koja mora da bude raspoređena, dostupna, bezbedna i proverljiva.
Posebne celine povezuju mrežu i load balancing sa fizičkom i virtuelnom infrastrukturom, a PersistentVolume, StorageClass i CSI sa storage sistemom koji se nalazi ispod Kubernetes-a. Na taj način API objekat stalno ostaje povezan sa stvarnim resursom koji ga omogućava.
Bezbednosni deo povezuje identitete, RBAC, ServiceAccount naloge, tajne, image-e, mrežne politike, sertifikate, audit i granice administrativne odgovornosti. Bezbednost se ne posmatra kao izdvojeno poglavlje koje dolazi nakon izgradnje platforme, već kao svojstvo svakog sloja sistema.
CI/CD, GitOps i automatizacija zatim uvode kontrolisani tok promena. Cilj je pokazati kako aplikativna i platformska konfiguracija prelaze od ručnih intervencija ka verzionisanom, ponovljivom i proverljivom modelu.
Produkcione celine obrađuju monitoring, logove, observability, sistematičan troubleshooting, lifecycle, nadogradnje, kapacitet, oporavak i operativnu dokumentaciju. Ovde čitalac prelazi sa pitanja „kako se resurs kreira“ na pitanja „kako se njime dugoročno upravlja, kako se dokazuje njegovo stanje i kako se sistem vraća kada dođe do problema“.
Enterprise integracije proširuju pogled izvan samog klastera. Inventar, CMDB, tagovi, identiteti, registry sistemi, backup, monitoring, change management i drugi organizacioni sistemi posmatraju se kao deo šire platforme.
Interoperabilnost i migracioni scenariji zatim proveravaju koliko je čitalac razumeo razliku između Kubernetes standarda i platformske implementacije. Cilj nije samo preneti objekte, već razumeti koje se zavisnosti moraju ponovo projektovati u ciljnom okruženju.
Završne laboratorije i integrisani projekti povezuju sve prethodne slojeve. Čitalac treba da bude sposoban da pripremi preduslove, definiše cilj, utvrdi početno stanje, uvede promenu, prikupi dokaze, potvrdi funkcionalnost, izvede rollback ili oporavak kada je potrebno i ostavi dokumentaciju iz koje drugi član tima može da razume postupak.
Materijal je namenjen sistem administratorima koji žele da svoje znanje VMware infrastrukture prošire prema Kubernetes, Tanzu i cloud-native platformama. Čitalac koji već razume ESXi, vCenter, mreže, storage i virtuelne mašine ovde može da vidi kako se postojeće infrastrukturno znanje povezuje sa kontejnerima, Kubernetes API-jem, workload-ima i platformskim servisima.
Koristan je DevOps i platform inženjerima koji žele dublje da razumeju infrastrukturni sloj na kome njihove aplikacije rade. Kubernetes objekat može izgledati potpuno deklarativno iz perspektive API-ja, ali njegovo stvarno izvršavanje zavisi od kapaciteta, mreže, storage-a, load balancer-a, DNS-a i drugih infrastrukturnih servisa.
Materijal je namenjen i developerima koji žele širu sliku načina na koji se njihove aplikacije izvršavaju, štite, nadziru i održavaju u enterprise okruženju. Razumevanje platforme pomaže da se aplikacija projektuje tako da bude pogodnija za horizontalno skaliranje, automatizovano raspoređivanje, oporavak i observability.
Koristan može biti mrežnim, storage, bezbednosnim i backup stručnjacima koji sarađuju sa platformskim timovima. Tanzu i Kubernetes ne ukidaju njihove oblasti odgovornosti; naprotiv, često ih čine još važnijim zato što infrastrukturne sposobnosti treba izložiti kroz standardizovane i automatizovane platformске interfejse.
Namenjen je i tehničkim arhitektama, konsultantima i administratorima koji učestvuju u planiranju modernizacije, konsolidacije, integracije ili migracije aplikacionih platformi. Za takve zadatke nije dovoljno poznavati samo ciljnu tehnologiju. Potrebno je razumeti zavisnosti sistema koji se menja i posledice odluka na mrežu, storage, bezbednost, identitete, operacije i organizaciju timova.
Materijal može biti koristan i čitaocima koji već rade sa OpenShift, Vanilla Kubernetes ili managed Kubernetes servisima i žele da razumeju kako se isti osnovni Kubernetes principi primenjuju kada je infrastrukturna osnova vSphere i kada deo odgovornosti preuzima Tanzu platformski sloj.
Posebnu vrednost može imati za administratore u nedovoljno dokumentovanim okruženjima. Kada nisu jasni vlasnici klastera, namespace-a, virtuelnih mašina, mreža, storage resursa, registry-ja ili aplikacija, sposobnost da se stanje prikupi, klasifikuje, poveže i pretvori u održivu dokumentaciju postaje jednako važna kao tehničko upravljanje platformom.
Za mene je ovaj materijal istovremeno uređena mapa znanja koja povezuje VMware infrastrukturu, Kubernetes, aplikacije i DevOps procese. Umesto da informacije ostanu rasute između infrastrukturne dokumentacije, Kubernetes dokumentacije, laboratorijskih beleški i iskustava iz različitih sistema, organizovane su tako da se mogu učiti, obnavljati, porediti i dalje produbljivati.
Čitalac koji tek ulazi u ovu oblast trebalo bi da lekcije prati redom. VMware & Tanzu spaja više tehnoloških slojeva, pa preskakanje temelja lako pretvara praktičan rad u niz komandi i manifest fajlova bez razumevanja infrastrukture na kojoj se izvršavaju.
Teško je pravilno razumeti Tanzu Kubernetes workload bez osnovnog razumevanja vSphere klastera, resursa i mreže. Isto tako, nije moguće pouzdano razumeti Service ili ingress samo iz infrastrukturne perspektive ako se ne razumeju Podovi, selektori, endpoint-i i Kubernetes mrežni model.
Nije potrebno zapamtiti svaku komandu, YAML strukturu ili putanju kroz interfejs pri prvom čitanju. Važnije je razumeti odnose: workload se izvršava na Kubernetes čvoru, čvor koristi infrastrukturne resurse, mrežna komunikacija prolazi kroz više virtuelnih i fizičkih slojeva, persistent storage se oslanja na konkretan storage sistem, a pristup zavisi od identiteta, uloga i politika.
Kada su ti odnosi jasni, promena verzije proizvoda, naziva pojedine komponente ili položaja opcije u interfejsu ne briše stečeno znanje. Administrator i dalje razume problem koji pokušava da reši, slojeve koje mora da proveri i dokaze kojima može potvrditi rezultat.
Svaku praktičnu vežbu treba izvoditi u kontrolisanom i bezbednom laboratorijskom okruženju. Pre promene potrebno je zabeležiti ciljni klaster, namespace ili infrastrukturni resurs, relevantne verzije, početno stanje, cilj, pretpostavke, očekivani rezultat i poznate zavisnosti.
Pre izvršenja treba definisati način validacije i mogućnost povratka. Ako promena utiče na aplikaciju, treba znati kako se proverava njena funkcionalnost. Ako utiče na mrežu, potrebno je proveriti putanju saobraćaja. Ako utiče na storage, treba proveriti pristup i integritet podataka. Ako menja infrastrukturu, mora se proceniti uticaj na klastere i druge workload-e.
Posle izvršenja nije dovoljno videti da komanda nije prijavila grešku ili da Kubernetes objekat ima očekivani status. Potrebno je proveriti stvarnu funkcionalnost: stanje Podova, Service endpoint-e, mrežnu dostupnost, logove, događaje, metrike, storage, zavisne servise i ponašanje aplikacije iz perspektive njenog korisnika.
Posebno je korisno voditi sopstveni repozitorijum manifesta, skripti, konfiguracionih primera i operativnih beleški. Treba zapisivati početno stanje, vreme događaja, izvršene promene, greške, relevantne izlaze komandi, alarme, logove, dokaze, hipoteze i rezultat korekcije.
Beleške o neuspelim pokušajima često su vrednije od idealnog postupka bez konteksta. One pokazuju kako sistem reaguje kada pretpostavka nije tačna i pomažu da se sličan problem sledeći put prepozna brže i preciznije.
Dobar tehnički zapis treba da omogući drugom članu tima da razume šta je urađeno, zbog čega, kakvo je stanje postojalo pre promene, koji su rizici razmatrani, kako je rezultat potvrđen i na koji način bi se postupak mogao ponoviti ili vratiti.
Iskusniji čitaoci mogu koristiti knjigu kao mapu i referentni vodič. Mogu se neposredno vratiti na Tanzu arhitekturu, Kubernetes workload-e, mrežu, load balancing, storage, RBAC, registry, CI/CD, GitOps, monitoring, troubleshooting, enterprise integracije ili migraciju na drugu platformu, a zatim pratiti unazad zavisnosti koje su potrebne za potpuno razumevanje konkretnog problema.
Pri takvom načinu korišćenja posebno je važno stalno razdvajati tri pitanja: šta pripada vSphere infrastrukturi, šta pripada Kubernetes mehanizmu i šta je dodatna sposobnost konkretne Tanzu implementacije. Ta podela pomaže i u troubleshootingu i pri proceni prenosivosti znanja na druge platforme.
Najvažnija ideja ove knjige jeste da VMware & Tanzu platforma nije samo vSphere infrastruktura kojoj je dodat Kubernetes, niti je Kubernetes samo skup YAML manifest fajlova postavljen iznad virtuelnih mašina. Pouzdana platforma nastaje tek kada se compute, mreža, storage, identiteti, bezbednost, Kubernetes kontrolne petlje, aplikacije, automatizacija, observability, backup, lifecycle, dokumentacija i odgovornosti timova povežu u jednu funkcionalnu celinu.
Poznavanje pojedinačne komponente zato nije dovoljno bez razumevanja njenih zavisnosti. Pod zavisi od schedulinga i čvora; čvor od vSphere resursa; Service od selektora i mreže; ingress od kontrolera, load balancer-a, DNS-a i sertifikata; PersistentVolume od CSI implementacije i storage infrastrukture; GitOps od repozitorijuma, pristupa, kontrolera i pravila promene.
Isto važi za dostupnost. Kubernetes replike, vSphere HA, redundantna mreža i backup rešavaju različite probleme. Nijedan od tih mehanizama samostalno ne predstavlja potpunu strategiju otpornosti poslovne usluge.
Inventar bez vlasništva ima ograničenu vrednost, alarm bez konteksta proizvodi buku, automatizacija bez ograničenja obima može ubrzati širenje greške, a backup bez testiranog restore-a ne dokazuje oporavljivost. Platform engineering zato nije samo izgradnja tehničkog sloja, već organizovanje načina na koji se taj sloj bezbedno koristi.
Zbog toga se kroz knjigu stalno vraćamo istom obrascu: utvrditi početno stanje, razumeti zavisnosti, proceniti rizik, izvršiti kontrolisanu promenu, sačuvati dokaze, potvrditi funkcionalnost i dokumentovati rezultat.
Od prve veze između vSphere i Kubernetes sloja do završnih enterprise i migracionih scenarija zadržana je ista namera: platformu posmatrati kao sistem u kome svaki sloj utiče na druge. Ako knjiga pomogne čitaocu da ne izvršava komande naslepo, da sigurnije razlikuje infrastrukturni problem od Kubernetes ili aplikativnog problema, dokumentuje odluke, proverava oporavak i razume granice odgovornosti između timova, onda je ispunila svoju svrhu.
Ovaj materijal predstavlja slobodan i sistematično organizovan obrazovni vodič kroz VMware infrastrukturu, Tanzu, Kubernetes i odgovorno upravljanje cloud-native platformom u enterprise okruženju. Namenjen je učenju, povezivanju pojmova, laboratorijskom radu, razumevanju infrastrukturnih i aplikativnih zavisnosti i razvoju praktičnog administratorskog, DevOps i platformskog načina razmišljanja.
Materijal nije zvanična dokumentacija proizvođača ili Kubernetes projekta, nije program ovlašćene profesionalne obuke i nije zamena za rad pod nadzorom iskusnih stručnjaka. Njegovo čitanje samo po sebi nije garancija polaganja određenog sertifikacionog ispita niti dovoljan osnov za samostalnu intervenciju u kritičnom produkcionom okruženju.
VMware i Tanzu proizvodi, Kubernetes verzije, podržane arhitekture, nazivi komponenti, licence, API-ji, mrežne i storage integracije, programi obuke, sertifikacioni zahtevi i preporučeni postupci mogu se menjati. Za profesionalnu primenu potrebno je proveravati aktuelnu zvaničnu dokumentaciju, dokumentaciju Kubernetes projekta i konkretnih dodataka, matrice kompatibilnosti, politike podrške, bezbednosne preporuke i procedure organizacije.
Primeri, manifesti, konfiguracije, skripte, API pozivi, pipeline definicije i laboratorijske vežbe služe učenju. Pre produkcione primene potrebno je proceniti uticaj i rizik promene, potvrditi postojanje odgovarajućeg backup-a i mogućnost oporavka, razumeti infrastrukturne, mrežne, storage, identitetske, bezbednosne i aplikativne zavisnosti, obezbediti potrebna odobrenja i pripremiti kontrolisan rollback.
Poseban oprez potreban je pri promenama vSphere klastera, mrežnih segmenata, load balancer konfiguracije, storage politika, Kubernetes klastera, RBAC pravila, tajni, sertifikata, registry pristupa, admission i mrežnih politika, GitOps automatizacije, nadogradnji i migracionih procedura.
Destruktivne ili teško reverzibilne operacije treba najpre proveriti u kontrolisanom laboratorijskom okruženju nad tačno određenim ciljem. Posebnu pažnju treba obratiti na automatizaciju koja može zahvatiti veliki broj resursa, jer pogrešno definisan selektor, scope ili cilj može veoma brzo proširiti posledice greške.
Za produkcionu primenu nije dovoljno da određena operacija tehnički može da se izvrši. Potrebno je znati ko je vlasnik sistema, ko odobrava promenu, kada se ona izvršava, kakav se uticaj očekuje, kojim signalima se prati stanje, gde se čuvaju dokazi, pod kojim uslovima se od promene odustaje i kako se sistem vraća u poznato i provereno stanje ako rezultat nije prihvatljiv.
Digitalna biblioteka TASHIZZA nastaje sa ciljem da složene stručne oblasti učini preglednim, sistematičnim i razumljivim bez pojednostavljivanja njihove suštine. Svaka knjiga predstavlja uređenu celinu koja povezuje teorijske osnove, praktične primere, laboratorijske vežbe, administrativne postupke i realne scenarije iz profesionalnog okruženja.
Cilj nije da se obuhvati svaka pojedinačna funkcionalnost određene tehnologije niti da se predstavi samo skup komandi ili koraka kroz grafički interfejs. Mnogo je važnije izgraditi stabilno razumevanje načina na koji sistemi funkcionišu, kako su međusobno povezani i zbog čega se određena rešenja primenjuju u stvarnim informacionim sistemima.
Poseban značaj pridaje se razumevanju celokupne infrastrukture. Serveri, operativni sistemi, mreže, storage sistemi, baze podataka, bezbednost, backup, monitoring, automatizacija, cloud platforme i DevOps alati posmatraju se kao međusobno povezani delovi jedinstvenog informacionog sistema, a ne kao izolovane tehnologije.
Pored tehničkog znanja, naglasak je stavljen na razvijanje infrastrukturnog načina razmišljanja. Svaka promena posmatra se kroz njene uzroke, posledice, zavisnosti, bezbednosne rizike, uticaj na druge sisteme i dugoročnu održivost. Takav pristup omogućava da se pojedinačne tehnologije povežu u jednu logičnu i funkcionalnu celinu.
Praktičan rad zauzima jednako važno mesto kao i teorija. Laboratorijska okruženja, praktični tutorijali, enterprise scenariji, mini projekti i završni integracioni projekti omogućavaju da stečeno znanje bude proverljivo, primenljivo i upotrebljivo u svakodnevnom radu.
Digitalna biblioteka nije zamišljena samo kao zbir pojedinačnih knjiga, već kao povezan sistem znanja. Oblasti poput Linux-a, VMware-a, Docker-a, Kubernetes-a, OpenShift-a, Oracle-a, automatizacije, programiranja, veštačke inteligencije i drugih tehnologija međusobno se dopunjuju i zajedno grade širu sliku savremene IT infrastrukture.
Posebna pažnja posvećena je sistematičnosti, jasnoći i dugoročnoj upotrebljivosti sadržaja. Svaka knjiga organizovana je tako da čitalac može postepeno napredovati od osnovnih pojmova, preko administracije i automatizacije, do realnih enterprise scenarija, bez potrebe da prethodno poseduje veliko praktično iskustvo.
Krajnji cilj digitalne biblioteke TASHIZZA jeste da predstavlja pouzdan, pregledan i dugoročno održiv izvor znanja koji pomaže razumevanju tehnologije, razvijanju profesionalnog načina razmišljanja i sigurnijem snalaženju u savremenim informacionim sistemima.
Ovaj tutorijal deo je slobodne digitalne biblioteke TASHIZZA. Osim kada je uz pojedinačni materijal izričito navedeno drugačije, autorski tekstovi, objašnjenja, knjige, tutorijali, praktikumi, beleške, originalne ilustracije, slike i drugi obrazovni sadržaji za koje je autorka nosilac odgovarajućih prava objavljeni su pod licencom Creative Commons Attribution 4.0 International – CC BY 4.0.
Licenca CC BY 4.0 omogućava čitanje, preuzimanje, kopiranje, deljenje, prevođenje, prilagođavanje, dopunjavanje i dalje objavljivanje sadržaja, uključujući njegovu komercijalnu upotrebu. Prilikom takvog korišćenja potrebno je na odgovarajući način navesti autorku i izvor, postaviti vezu ka licenci i jasno označiti da li je izvorni materijal menjan. Navođenje izvora ne sme stvarati utisak da autorka podržava novu verziju, njenog izdavača ili način na koji je sadržaj upotrebljen.
Kao osnovni podatak o izvornom delu navodi se: Nataša Mihajlović, TASHIZZA, https://tashizza.com. Puni uslovi licence dostupni su na stranici Creative Commons Attribution 4.0 International i u pratećem dokumentu LICENSE.
Osim kada je izričito navedeno drugačije, originalni primeri programskog i skriptnog koda, HTML struktura i šabloni, CSS, JavaScript, Bash skripte, PowerShell i PowerCLI skripte, YAML manifesti, pipeline definicije, SQL i PL/SQL primeri i drugi tehnički kod za koji je autorka nosilac odgovarajućih prava objavljeni su pod MIT licencom. MIT licenca dozvoljava korišćenje, kopiranje, menjanje, povezivanje, objavljivanje, distribuciju, podlicenciranje i prodaju kopija koda, pod uslovom da se u kopijama ili značajnim delovima koda sačuvaju obaveštenje o autorskim pravima i tekst MIT licence. Autorski i obrazovni tekst unutar HTML dokumenata ostaje obuhvaćen licencom CC BY 4.0.
Slobodno korišćenje sadržaja ne znači da su nazivi proizvoda, projekata, zaštitni znakovi, logotipi i tehnologije pomenuti u tutorijalu vlasništvo autorke ili sajta TASHIZZA. Nazivi VMware proizvoda, vSphere, ESXi, vCenter Server, Tanzu, OpenShift, Kubernetes, Oracle i drugih pomenutih proizvoda, projekata i tehnologija pripadaju njihovim odgovarajućim nosiocima prava. U ovom tutorijalu koriste se isključivo radi identifikacije, stručnog objašnjenja, obrazovanja i informisanja i ne podrazumevaju povezanost, sponzorstvo, odobrenje ili podršku njihovih vlasnika.
Licence TASHIZZA primenjuju se samo na originalne materijale za koje je Nataša Mihajlović nosilac odgovarajućih prava. One ne menjaju uslove koji važe za citate, fotografije, ilustracije, zaštitne znakove, delove dokumentacije, delove koda i druge sadržaje trećih lica. Takvi materijali koriste se i dalje prenose u skladu sa pravima, licencama i pravilima njihovih odgovarajućih izvora.
Cilj otvorenog pristupa jeste da uređeno znanje ne ostane zatvoreno u ličnim beleškama. Čitalac je slobodan da uči, vraća se lekcijama, koristi ih kao osnovu za sopstveno istraživanje, razvija nove verzije i doprinosi daljem širenju znanja, uz poštovanje jednostavnih i jasno navedenih uslova odgovarajuće licence.