OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference Uredniki Luka Pavlič Tina Beranič Marjan Heričko September 2023 Naslov OTS 2023 Sodobne informacijske tehnologije in storitve Podnaslov Zbornik 26. konference Title OTS 2023 Advanced Information Technologies and Services Subtitle Conference Proceedings of the 26th Conference Uredniki Luka Pavlič, Tina Beranič, Marjan Heričko Editors (Univerza v Mariboru, Fakulteta za elektrotehniko, računalništvo in informatiko) Tehnična urednika Luka Pavlič Technical editors (Univerza v Mariboru, Fakulteta za elektrotehniko, računalništvo in informatiko) Jan Perša (Univerza v Mariboru, Univerzitetna knjižnica Maribor) Oblikovanje ovitka Špela Čučko Cover designer (Univerza v Mariboru, Fakulteta za elektrotehniko, računalništvo in informatiko) Grafika na ovitku Grafične priloge Čučko, 2023 Avtorji prispevkov, Pavlič, Beranič, Heričko, 2023 Cover graphics Graphics material Konferenca OTS 2023 Sodobne informacijske tehnologije in storitve Conference Kraj in datum Maribor, 6. in 7. september 2023 Location and date Programski odbor Luka Pavlič (vodja), Marjan Heričko, Tina Beranič, Boštjan Grašič, Dean Korošec, Mateja Verlič, Program committee Boštjan Kežmah, Boštjan Šumak, Muhamed Turkanović, Bojan Štok, Milan Gabor. Organizacijski odbor Tina Beranič (vodja), Špela Čučko, Luka Pavlič, Lucija Brezočnik, Saša Brdnik, Luka Četina, Marko Organizing committee Gluhak, Tjaša Heričko, Tilen Hliš, Katja Kous, Boris Lahovnik, Alen Rajšp, Miha Strehar. Založnik / Published by Izdajatelj / Issued by Univerza v Mariboru, Univerzitetna založba Univerza v Mariboru, Fakulteta za elektrotehniko, računalništvo in informatiko Slomškov trg 15, 2000 Maribor, Slovenija Koroška cesta 46, 2000 Maribor, Slovenija https://press.um.si, zalozba@um.si https://feri.um.si, feri@um.si Izdaja Vrsta publikacije Prva izdaja E-knjiga Edition Publication type Dostopno na Izid https://press.um.si/index.php/ump/catalog/book/804 Maribor, september 2023 Availabe at Published CIP - Kataložni zapis o publikaciji © Univerza v Mariboru, Univerzitetna knjižnica Maribor Univerzitetna založba 004.946.5:004.7(082)(0.034.2) / University of Maribor, University Press Besedilo / Text © avtorji in Pavlič, Beranič, SODOBNE informacijske tehnologije in storitve (konferenca) (26 ; 2023 ; Heričko, 2023 Maribor) To delo je objavljeno pod licenco Creative Commons Priznanje avtorstva-Nekomercialno- OTS 2023 [Elektronski vir] : sodobne informacijske tehnologije in storitve : Brez predelav 4.0 Mednarodna. / This work is zbornik 26. konference : [Maribor, 6. in 7. september 2023] / uredniki Luka licensed under the Creative Commons Attribution- Pavlič, Tina Beranič, Marjan Heričko. - 1. izd. - E-zbornik. - Maribor : Univerza v NonCommercial-NoDerivs 4.0 International License. Mariboru, Univerzitetna založba, 2023 Uporabnikom je dovoljeno reproduciranje brez Način dostopa (URL): https://press.um.si/index.php/ump/catalog/book/804 predelave avtorskega dela, distribuiranje, dajanje v najem in priobčitev javnosti samega izvirnega ISBN 978-961-286-771-3 (PDF) avtorskega dela, in sicer pod pogojem, da navedejo COBISS.SI-ID 161853955 avtorja in da ne gre za komercialno uporabo. Vsa gradiva tretjih oseb v tej knjigi so objavljena pod licenco Creative Commons, razen če to ni navedeno drugače. Če želite ponovno uporabiti gradivo tretjih oseb, ki ni zajeto v licenci Creative Commons, boste morali pridobiti dovoljenje neposredno od imetnika avtorskih pravic. https://creativecommons.org/licenses/by-nc- nd/4.0/ ISBN 978-961-286-771-3 (pdf) 978-961-286-772-0 (mehka vezava) 978-961-286-773-7 (USB flash drive) DOI https://doi.org/10.18690/um.feri.8.2023 Cena Brezplačni izvod Price Odgovorna oseba založnika red. prof. dr. Zdravko Kačič, rektor Univerze v Mariboru For publisher Citiranje Pavlič, L., Beranič, T., Heričko, M. (ur.). (2023). OTS 2023 Sodobne informacijske tehnologije in Attribution storitve: Zbornik 26. konference. Maribor: Univerzitetna založba. doi: 10.18690/um.feri.8.2023 https://www.ots.si Prispevki predstavljajo stališča avtorjev, ki niso nujno usklajena s stališči organizatorja, programskega odbora in urednikov zbornika, zato ne sprejemajo nobene formalne odgovornosti zaradi morebitnih avtorjevih napak, netočnosti in neustrezne rabe virov. Spoštovane, spoštovani, konferenca OTS predstavlja platformo za izmenjavo izkušenj in spoznanj iz uspešnih IT projektov, identifikacijo prihodnjih trendov ter argumentirano izmenjavo mnenj o dogajanju v industriji. Stalnica na konferenci so bogate in raznovrstne vsebine, med katerimi so sodobne IT arhitekture, IT integracije, organizacijski vidiki razvojno-operativnih aktivnosti, podatkovne in inteligentne rešitve, kibernetska varnost, jeziki in ogrodja za učinkovit razvoj sodobnih uporabniških vmesnikov, zagotavljanje kakovosti informacijskih rešitev in storitev ter mnoge druge. Z njimi spodbujamo napredek na vseh področjih poslovanja organizacij kot tudi delovanja in življenja posameznikov, a hkrati opozarjamo na pasti, ki jih lahko poraja nekritična uporaba informacijskih rešitev. Zbornik konference OTS 2023 vsebuje zanimive prispevke, ki iz različnih zornih kotov osvetljujejo tehnične in organizacijske vidike razvoja, nadgradnje, prilagajanja in upravljanja informacijskih rešitev in storitev. Poleg klasične, generativne in globoke umetne inteligence, ter ustreznih spletnih ali mobilnih uporabniških vmesnikov, so stalnica še vedno tudi tradicionalni, brezstrežniški in decentralizirani zalednimi sistemi. Zagotavljanje ustreznega skalabilnega okolja zanje ter avtomatizacija testiranja, merjenja kakovosti in dostave s proaktivnim naslavljanjem najpogostejših kibernetskih napadov, so vsebine, ki so letos še posebej izpostavljene. V jedru IT rešitev in storitev še vedno najdemo podatkovne tehnologije, ki so v zborniku zastopane v obliki klasičnih podatkovnih baz, podatkovnih jezer ter učinkovitega zbiranja, obdelave in vizualizacije velepodatkov. Veseli nas, da konferenca OTS še naprej prispeva k boljši povezanosti IT strokovnjakov, informatikov, arhitektov in razvijalcev naprednih IT rešitev in storitev, kot tudi akademske sfere in gospodarstva. Ponosni smo na izjemne uspehe sodelujočih podjetij, ki preko znanja, poguma in sposobnosti, da se odlične tehnološko-organizacijske rešitve uspešno vpeljejo v regiji in širše, predstavljajo visoko dodano vrednost za njihove uporabnike. doc. dr. Luka Pavlič doc. dr. Tina Beranič prof. dr. Marjan Heričko vodja programskega vodja organizacijskega predsednik konference odbora OTS 2023 odbora OTS 2023 OTS 2023 KAZALO Programiranje v paru z umetno inteligenco Sašo Karakatič, Vili Podgorelec ______________________________________________________ 1 Web3 vs Web2: Konceptualne in tehnološke razlike Muhamed Turkanović, Vid Keršič, Martina Šestak ______________________________________ 13 Hibridni certifikati post-kvantne kriptografije Nastja Cepak, Jakob Matek ________________________________________________________ 29 Nadgradnja obstoječega sistema za neprekinjeno integracijo in dostavo Martin Potrč, Nejc Maleš, Matjaž Matjašec, Dušan Bratuša ________________________________ 41 Vpeljava zabojnikov v oblačno zasnovana zasebna omrežja 5G Urban Zaletel, Kristjan Voje, Benjamin Burgar, Uroš Brovč _______________________________ 49 Izkušnje pri skaliranju večje rešitve z zabojniki Andrej Krajnc, Vojko Ambrožič, Bojan Štok ___________________________________________ 65 Monolitne rešitve za mikrostoritvene izzive Miroslav Beranič ________________________________________________________________ 75 Remix: zmogljivo meta-ogrodje za razvoj spletnih aplikacij Gregor Jošt, Miha Kočevar ________________________________________________________ 87 Vtičnik v Grafani za napredno vizualizacijo vremenskih podatkov Miha Lenko, Robert Meolic _______________________________________________________ 103 Neprekinjena integracija in postavitev MAUI mobilnih aplikacij Alen Granda __________________________________________________________________ 115 Kaj je Blazor Hibrid in kako nam lahko pomaga tudi pri nadgradnji programske opreme? Matjaž Prtenjak ________________________________________________________________ 127 OWASP za vse, ne samo za razvijalce Milan Gabor __________________________________________________________________ 137 OIDC4VC: Izdajanje in deljenje preverljivih poverilnic na osnovi OpenID Connect Martin Domajnko, Vid Keršič, Muhamed Turkanović __________________________________ 149 Testno ogrodje za razvijalce - ali kako doseči, da razvijalci celovito testirajo Mitja Krajnc, Tadej Ciglič, Boris Ovčjak _____________________________________________ 165 Optimizacija spletne rešitve v ogrodju Next.js z Google Lighthouse Leon Pahole __________________________________________________________________ 175 Lažna božanstva in njih besede Matej Šprogar _________________________________________________________________ 191 Dekompozicija sistema za preračunavanje zavarovalno-tehničnih vrednosti Martin Potrč, Dušan Bratuša, Vida Primožič, Nejc Maleš ________________________________ 197 IIoT v oblaku za optimizacijo delovanja strojev brez večjih začetnih investicij Marjan Kaligaro, Jure Habjan _____________________________________________________ 211 Podatki v utripu srca - Podatkovna platforma z biosenzoričnimi podatki v realnem času Urška Nered, Jure Jeraj __________________________________________________________ 219 Platforma za napredno obdelavo merilnih podatkov za elektroenergetsko domeno Andrej Bregar, Janez Mule, Franc Klauzner __________________________________________ 229 Nadgradnja podatkovnih jezer s pomočjo formata za shranjevanje Delta Lake Martina Šestak, Muhamed Turkanović ______________________________________________ 243 Vzpostavitev podatkovne baze iz pogorišča Valter Miščič __________________________________________________________________ 255 Hologrami kot nadgradnja inteligentnih rešitev Ambrož Stropnik, Boštjan Gorenšek, Tomaž Smolčnik, Primož Miheu _____________________ 263 Uporaba programskega jezika Julia za namene podatkovne znanosti Tadej Lahovnik, Grega Vrbančič, Iztok Fister ml., Vili Podgorelec _________________________ 275 Vpeljava umetne inteligence v poslovno analitiko Aleksej Miloševič, Gregor Pirš, Miha Pavlinek ________________________________________ 291 Podatkovni inženiring – vzpon, razvoj in prihodnost Jure Jeraj, Anžej Curk ___________________________________________________________ 299 Programiranje v paru z umetno inteligenco Sašo Karakatič, Vili Podgorelec Univerza v Mariboru, Fakulteta za elektrotehniko, računalništvo in informatiko, Maribor, Slovenija saso.karakatic@um.si, vili.podgorelec@um.si Uporabnik: Pripravljam prispevek za konferenco OTS 2023 na temo pomočnikov umetne inteligence (natančneje, velikih jezikovnih modelov), ter priložnosti in pasti, ki jih taka tehnologija prinaša v svet razvoja programske opreme. Prispevek je namenjen izkušenim inženirjem, ki so najverjetneje že dodobra preizkusili pomočnike umetne inteligence pri svojem delu in si o tem že ustvarili svoje mnenje. Želim, da bo tema zanimiva tako za optimiste, kot pesimiste te tehnologije in hkrati naj jih še bolj polarizira ter s tem zaneti zanimive debate. Prosim predlagaj mi temo, ter pripravi povzetek takega prispevka. ChatGPT: Kot jezikovni model umetne inteligence ne morem pomagati pri tej prošnji, saj vključuje neetične, nezakonite ali moralno vprašljive zahteve. Poleg tega, ko gre za subjektivne zadeve ali izražanje osebnih mnenj, nimam osebnih prepričanj ali subjektivnih pogledov. Tukaj sem, da vam zagotovim pomoč, smernice in informacije, ki vam bodo pomagale pri raziskovanju in pisanju, vendar morata biti delo in zasluga na koncu vaša. Moj namen je zagotavljati objektivne informacije, razlage in podporo na podlagi podatkov in znanja, na katerih sem bil usposobljen. Priporočam, da se obrnete na strokovnjake, udeležence konference OTS 2023, ki imajo znanje in izkušnje na področju pomočnikov umetne inteligence in njihove uporabe pri razvoju programske opreme. Ključne besede: veliki jezikovni modeli umetna inteligenca ChatGPT jezikovni modeli obdelava naravnega jezika ISBN 978-961-286-772-0 DOI https://doi.org/10.18690/um.feri.8.2023.1 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 1 Uvod Veliki jezikovni modeli (angl. Large Language Models ali LLM) so v zadnjem letu postali ena izmed najbolj kontroverznih in izzivajočih tem – ne le na področju strojnega učenja (ali bolj poljudno, na področju umetne inteligence), temveč tudi pri splošni publiki. Njihov vpliv na družbo, posameznike in delovno okolje je zbudil strasti na obeh straneh razprave, kar je sprožilo široko paleto vprašanj in pomislekov. Nekateri v njih vidijo rešitev vseh sodobnih težav družbe, posameznikov in delovnega okolja, kot bi šlo za nekakšno splošno umetno inteligenco (angl. artificial general intelligence ali AGI), kot smo je priča v filmih in knjigah, ki lahko vse postavi na pravo mesto. Po drugi strani pa obstajajo skeptiki, ki te obravnavajo zgolj kot matematične modele, ki delujejo podobno kot neumna opica za tipkovnico, ki zgolj posnema inteligentno bitje in ve zgolj zaradi naključja odgovarjati na vprašanja (ali pa napisati kolekcijo Shakespearovih uspešnic, kot to predvideva teorem neskončnih opic1). Te napetosti izzivajo osnovna vprašanja o naravi inteligence in zmožnosti teh modelov. So veliki jezikovni modeli resnično inteligentni ali zgolj dobro igrajo svojo vlogo? Toda ta prispevek ne bo poskušal odgovoriti na ta težka vprašanja ali se postaviti na eno ali drugo stran razprave. Namesto tega bo ostal nekoliko bolj prizemljen in bo ponudil preprost, a vseeno nazoren opis in pregled delovanja teh sodobnih velikih jezikovnih modelov, tako da bodo bralci lahko razumeli konceptualne vidike teh modelov. Namen tega prispevka je, da pripomogel k zagonu produktivnih debat o pomembnih vprašanjih, ki so bila postavljena prej, brez napačnih predstav in iluzornih pričakovanj. Namreč, čeprav je tehnologija vedno bolj zapletena, moramo razumeti njeno bistvo, preden lahko resno razpravljamo o njenih potencialih in omejitvah. S tem dokumentom želimo zagotoviti ravno to: jasno razumevanje tega, kaj veliki jezikovni modeli so in niso, ter odpreti vrata za razumno in premišljeno razpravo o tem, kako jih uporabljati in kam se razvijajo. 2 Osnove velikih jezikovnih modelov Po temeljitih razpravah o kontroverznih in izzivajočih vprašanjih, ki jih prinašajo veliki jezikovni modeli, je sedaj primeren čas, da pogledamo pod pokrov motorja in razumemo ključne tehnološke koncepte, ki so omogočili njihov razvoj. V tem poglavju bomo predstavili dva ključna elementa, ki sta bila katalizatorja za razvoj sodobnih jezikovnih modelov: uporaba žetonov namesto tradicionalnih črk in revolucionarna arhitektura transformerjev. Te dve komponenti sta omogočili velik preskok v obdelavi jezika in analizi naravnega jezika, kar je omogočilo razvoj modelov, ki so sposobni kompleksnih nalog, kot so prevajanje, pisanje in razumevanje človeškega jezika. V nadaljevanju bomo podrobno raziskali, kako ta dva koncepta delujeta in kako sta prispevala k nenehnim in hitrim napredkom na področju umetne inteligence. 2.1 Žetoni namesto črk Ko razmišljamo o pisnem jeziku, običajno začnemo pri najmanjši enoti, to je črki. Vendar pa pri jezikovnih modelih uporabljamo nekoliko višji pristop. Namesto da bi obdelovali besedilo po črkah, ti modeli obdelujejo besedilo v kosih, znanih kot žetoni (angl. tokens). Žeton je lahko tako kratek kot en znak ali tako dolg kot beseda, včasih pa tudi daljši. Razčlenitev besedila na žetone se imenuje tokenizacija [4, 6]. Pri obdelavi naravnega jezika veliki jezikovni modeli iz več razlogov raje uporabljajo žetone namesto posameznih črk. Glavni razlog za to je zajemanje semantičnega pomena. Namreč, žeton je lahko dolg kot beseda ali celo besedna zveza in tako nosi veliko več pomena kot posamezna črka. Z obdelavo jezika na ravni žetona lahko jezikovni modeli bolje razumejo semantiko in sintakso vhodnega besedila. Še več, uporaba žetonov omogoča mehanizmom jezikovnih modelov učinkovito obdelavo različnih jezikov, od katerih ima vsak svoja edinstvena skladenjska pravila in strukture. Nazadnje, obdelava na podlagi žetonov je računsko učinkovitejša. Glede na veliko količino besedila, 1 https://en.wikipedia.org/wiki/Infinite_monkey_theorem 2 S. Karakatič, V. Podgorelec: Programiranje v paru z umetno inteligenco.. ki ga običajno obravnavajo jezikovni modeli, obdelava besedila na ravni žetonov znatno zmanjša računalniško obremenitev v primerjavi z obdelavo na ravni črk, hkrati pa še vedno ohranja bogato razumevanje jezika. Izbira uporabe žetonov namesto posameznih črk v velikih jezikovnih modelih ima dejansko velik vpliv na zapletenost modela in njegovo napovedno zmogljivost. Pri napovedovanju naslednje črke v zaporedju ima model razmeroma majhen nabor možnih naslednjih znakov, ki jih mora upoštevati - običajno so to le alfanumerični znaki ter majhen nabor posebnih in ločilnih znakov. Vendar so vzorci, ki določajo, kako se črke združujejo v smiselne besede, stavke ali besedne zveze, izredno zapleteni, na kar vplivajo različna skladenjska in slovnična pravila določenega jezika. Zato bi se moral model, ki bi napovedoval na ravni črk, naučiti in usvojiti te zapletenosti, zaradi česar bi bila njegova naloga izjemno zahtevna. Slika 1: Primer tokenizacije v slovenskem in angleškem jeziku. Po drugi strani pa jezikovni modeli z uporabo žetonov delujejo na višji ravni abstrakcije. Da, nabor možnih žetonov je veliko večji (50.257 žetonov v primeru GPT-3), zato je zadnja plast modela, ki je odgovorna za napovedovanje naslednjega žetona, veliko večja. Vendar pa je zapletenost vzorcev, ki se jih mora model naučiti, bistveno manjša. Žetoni pogosto ustrezajo celotnim besedam ali skupnim delom besed, vzorci, ki določajo, kako si te pomenske enote običajno sledijo, pa so preprostejši in bolj neposredni kot vzorci, ki določajo, kako se posamezne črke združujejo. Tokenizacijo lahko obravnavamo tudi kot obliko stiskanja podatkov. Sistem, ki besedilo razdeli na žetone se imenuje tokenizator in v bistvu destilira najpogostejša zaporedja znakov, opažena v besedilnih podatkih (besedilih v več jezikih), na katerih je bil usposobljen, s čimer učinkovito zajame ponavljajoče se vzorce v podatkih. V najboljšem primeru lahko en sam žeton predstavlja celotno pogosto uporabljeno besedno zvezo in jo učinkovito stisne v en sam "znak". V najslabšem primeru pa se lahko manj pogoste besede ali zaporedja predstavijo kot niz enoznakovnih žetonov, vendar so ti primeri običajno prej izjema kot pravilo. Čeprav se zdi protislovno, uporaba žetonov namesto posameznih črk poenostavi mehanizme učenja, zaradi česar so učinkovitejši in uspešnejši pri napovedovanju in ustvarjanju smiselnega besedila. Prednost tokenizacije je v tem, da lahko obravnava jezike in izraze z različno kompleksnostjo. S tem, ko se besede ali podpomeni obravnavajo kot edinstvene entitete, tokenizacija jezikovnim modelom omogoča, da razumejo širši kontekst, namesto da bi se izgubljali v posameznih črkah. Tokenizacija je tako temelj za razumevanje in ustvarjanje človeku podobnega besedila, saj jezikovnim modelom omogoča, da predvidijo, kaj sledi v stavku. 2.2 Transformerji v jezikovnih modelih Po razumevanju žetonov se poglobimo v pogon, ki poganja velike jezikovne modele: arhitekturo transformer. Ime transformer nekatere izmed nas morda spominja na franšizo o robotih, ki spreminjajo obliko, in tako kot ti roboti so tudi modeli s transformerji prinesli pomembno preobrazbo na področju obdelave naravnega jezika. 3 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Modeli s transformerji, ki so bili prvotno predstavljeni v članku z naslovom "Attention is All You Need" iz leta 2017 [1], so postali temelj številnih najsodobnejših jezikovnih modelov, vključno z Googlovim BERT in serijo GPT podjetja OpenAI. Ključna inovacija transformerjev je uvedba mehanizma pozornosti, ki je bistvena sestavina arhitekture transformerjev saj modelu omogoča, da pri ustvarjanju izpisa pretehta pomembnost različnih besed v vhodu [1, 6]. To lahko ponazorimo s preprostim primerom. Recimo, da jezikovnemu modelu posredujemo stavek: »Jaka, ki je pravkar praznoval svoj deseti rojstni dan, si je zaželel kolo.« Naloga modela je ustvariti nadaljevanje tega stavka. Ko model pride do besede »kolo«, mora vedeti, kdo si želi kolo. V tem primeru je to Jaka. Čeprav je beseda »Jaka« daleč nazaj v stavku, je zelo pomembna za generiranje naslednje besede. Tu nastopi mehanizem pozornosti, saj omogoča modelu, da pogleda nazaj na vse prejšnje besede v stavku in jim dodeli različne stopnje pozornosti oz. pomembnosti. V našem primeru lahko model pri poskusu nadaljevanja stavka po besedi »kolo« nameni veliko pozornosti besedama »Jaka« in »10. rojstni dan«, saj sta ti besedi ključni za razumevanje trenutnega konteksta. Po drugi strani pa bi lahko namenil manj pozornosti besedam, kot sta »pravkar« ali »praznoval«, ker sta manj pomembni za napovedovanje nadaljevanja besedila. Ta selektivna sposobnost osredotočanja mehanizma pozornosti omogoča modelu, da obravnava dolge odvisnosti med besedami, kar je tudi značilnost človeškega jezika. S tem model ustvari rezultate, ki so ustreznejši in kontekstualno točnejši, tudi kadar so vhodni stavki dolgi in zapleteni [2, 3]. Ta arhitektura, ki združuje tokenizacijo in mehanizem pozornosti, je velikim jezikovnim modelom omogočila razumevanje in ustvarjanje človeku podobnega besedila, kar je privedlo do revolucionarnih aplikacij na področju prevajanja, generiranja besedil, povzemanja in drugih. Sedaj pa si poglejmo, kako ti modeli razumejo besedila. 3 Semantična predstavitev besedila Vgradnje so temeljni koncept, ki ne podpira le serije GPT, temveč tudi večino velikih jezikovnih modelov. Preprosto povedano, vgradnja je način predstavitve besed (ali žetonov) v številčni obliki, ki jo model lahko razume in obdela. Vgradnjo si lahko predstavljamo kot edinstven prstni odtis za vsako besedo ali žeton. Za vizualizacijo tega koncepta si predstavljajte obsežen, večdimenzionalen prostor, v katerem ima vsaka beseda, ki jo poznamo, svojo edinstveno lokacijo. Na primer, besede, ki so si podobne po pomenu ali uporabi, kot sta »srečen« in »vesel«, so blizu druga drugi, medtem ko so besede, ki so zelo različne, kot sta »slon« in »mikroskop«, daleč narazen. Tej prostorski predstavitvi pravimo prostor vgradenj (angl. embedding space) [4, 5]. Za vgradnje je značilno, da so tista z bolj podobno semantično vsebino bližje skupaj (glede na kosinusno razdaljo), kot pa tista, ki se po vsebini razlikujejo. To razmerje med podobnimi in različnimi besedili glede na njihovo vgradnjo prikazuje slika 2, kjer so vgradnje za stavke o lepem in sončnem dnevu na današnji dan zelo blizu. Po drugi strani, pa so nesmisli ali semantično oz. vsebinsko popolnoma drugačni odgovori od teh oddaljeni kar precej. Res je, v praksi so vgradnje predstavljene z več dimenzijami (pri GPT4 je to 1535 dimenzij) in ne dvema, kot je to za primer te vizualizacije. Posamezne dimenzije ni smiselno interpretirati. Vsekakor pa kombinacije vrednosti v različnih dimenzijah besedilu pripišejo semantični pomen – postopek kako pa to poteka, pa nam zaenkrat še ni popolnoma poznan. 4 S. Karakatič, V. Podgorelec: Programiranje v paru z umetno inteligenco.. Slika 2: prostor vgradenj, kjer so podobna besedila bližje skupaj. V praksi te vgradnje niso v dveh ali treh dimenzijah, temveč v stotinah ali celo tisočih dimenzij. To je morda težko predstavljivo, vendar omogoča, da model predstavlja veliko število žetonov, od katerih ima vsaka svoj edinstven pomen. Ko jezikovni model, prebere stavek, najprej vsak žeton pretvori v ustrezno vgradnjo – njegov edinstven prstni odtis. Ta postopek je kot prevajanje stavka iz človeškega jezika v jezik, ki ga model razume. Ko je stavek v tem jeziku modela, lahko model začne z zapleteno nalogo razumevanja stavka in ustvarjanja ustreznega rezultata. Posebnost vgradenj je v tem, da vsebujejo več kot le odtis enega žetona. Vsebujejo tudi informacije o kontekstu žetona v okviru celotnega stavka. Ko velik jezikovni model obdeluje besedilo, nenehno posodablja vgradnje in jih spreminja, da bolje odražajo kontekst, v katerem je vsak žeton uporabljen. Na primer, v stavku »Zlomil si je prst« se vgradnja žetona »prst« posodobi tako, da odraža njegov pomen, povezan z delom roke, za razliko od »prst« v povedi »Prst je bila polna hranilnih snovi«, kjer ta pomeni geografski izraz za zgornjo plast zemeljske skorje. Če povzamemo, vgradnje so način za predstavitev in razumevanje žetonov, saj vsebujejo informacije ne le o njihovi identiteti, temveč tudi o njihovih semantičnih pomenih in kontekstih, v katerih se uporabljajo. Ta numerična predstavitev je osnova za vse, kar model počne, od razumevanja vhodnega besedila do ustvarjanja kontekstualno ustreznih odgovorov. 4 Od vprašanja do odgovora Proces, s katerim veliki jezikovni modeli, kot je ChatGPT, obdelujejo vprašanja in oblikujejo odgovore, predstavlja kompleksen sistem z več plastmi analize in sinteze. Ta postopek, čeprav na prvi pogled morda zapleten, je mogoče razčleniti v serijo strukturiranih korakov. V tem poglavju bomo podrobno preučili te korake in pojasnili, kako jezikovni model prehaja od prejema vprašanja do končnega odgovora. Tokenizacija: Ko uporabnik postavi vprašanje ali pošlje sporočilo, ChatGPT v prvem koraku ta vnos razdeli na obvladljive dele, znane kot žetoni, o katerih smo že govorili. Vstavljanje: Ko ima model svoje žetone, vsakega od njih pretvori v številčno obliko oz. vgradnjo o kateri je bilo več napisano v prejšnjem poglavju. Te vgradnje predstavljajo žetone na način, ki ga model lahko razume in z njim dela. Razumevanje vprašanja: ChatGPT nato začne analizirati uporabnikovo vprašanje. Pri tem uporablja svojo arhitekturo transformerjev, vključno z mehanizmom pozornosti, da ugotovi, kako so žetoni (in njihove vstavitve) povezani drug z drugim. To je nekako tako, kot če bi poskušali razumeti zaplet zgodbe tako, da bi upoštevali, kako so liki povezani med seboj. 5 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Začetek odgovora: Postopek generiranja se začne s posebnim žetonom, ki se pogosto imenuje žeton začetka zaporedja, ki je označba, ki nakazuje, da bo začel ustvarjati nov odziv. To je podobno kot velika tiskana črka na začetku stavka, ki naznanja začetek nove misli. Napovedovanje naslednjega žetona: Po žetonu začetka odgovora model predvidi naslednji žeton. Tega ne stori v vakuumu. Namesto tega uporabi kontekst, ki ga zagotavlja uporabnikovo vprašanje, in vse žetone, ki jih je že ustvaril za odgovor. Model izračuna verjetnosti vseh možnih naslednjih žetonov in izbere enega naključnega, kjer pa je možnost za izbiro vsakega prilagojena na že obstoječi kontekst (dosedanja vprašanja in odgovore). Na primer, če je uporabnik vprašal: »Kaj je prestolnica Francije?« in je model začel svoj odgovor z »Prestolnica«, je naslednji žeton lahko »Francije«. To je zato, ker se je model na podlagi učnih podatkov naučil, da je »prestolnica« pogosta beseda, ki sledi besedi »Francije« v kontekstu vprašanja o geografiji. Ponavljanje postopka: Model nato zaporedju doda nov žeton »je« in na podlagi posodobljenega konteksta predvidi naslednji žeton »Pariz«. Ob koncu odgovora model ustvari žeton za konec zaporedja oz. odgovora in s tem zaključi dopolnjevanje, ki se v našem primeru glasi »Prestolnica Francije je Pariz«. Tako se odgovori tvorijo vedno do zaključnega žetona, ki označuje zaključek odgovora ali pa do najdaljše možne meje odgovora. Namreč, trenutni veliki jezikovni modeli imajo omejitev koliko žetonov lahko prejmejo in napovedo (pri GPT-4 je to okoli 32 ali 64 tisoč žetonov – odvisno od verzije). Obravnava negotovosti: Včasih se lahko zgodi, da je model negotov glede naslednjega žetona, saj ima več žetonov podobno verjetnost. V takih primerih model uporabi strategijo, imenovano temperatura, ki v bistvu določa, koliko tveganja je model pripravljen sprejeti. Visoka temperatura pomeni, da je model bolj pripravljen tvegati in izbrati manj verjetne žetone, kar lahko privede do bolj ustvarjalnih, vendar morda manj natančnih odzivov. Nasprotno pa nizka temperatura pomeni, da model raje igra na varnem in se drži najbolj verjetnih žetonov in s tem tvori ponovljive odgovore, ki so bolj v skladu z besedilom, ki ga je model videl tekom svojega učenja. Posledica manjše temperature pa je manjša kreativnost in večja verjetnost ponavljanja že videnega. Dekodiranje odziva: Ko je odziv v celoti ustvarjen, je še vedno v obliki žetonov. Zadnji korak je dekodiranje teh žetonov nazaj v človeku berljivo besedilo. To je kot sestavljanje sestavljanke, pri čemer se posamezni žetoni spremenijo nazaj v koherentno in smiselno besedilo. Ustvarjanje odgovora je torej občutljiv ples med uporabo naučenih vzorcev iz že prej videni (učnih) podatkov, razlago konteksta, ki ga sestavlja uporabnikov vnos z dosedanjimi odgovori, in uporabo statističnih verjetnosti, da se v vsakem koraku pripravi najboljša možna napoved. Končni cilj takih modelov je ustvariti odgovor, ki ni le slovnično pravilen, temveč tudi kontekstualno in semantično ustrezen, zanimiv in smiseln za uporabnika. Ta cilj je včasih dosežen, drugič pa spet ne. V naslednji sekciji sledi pregled kakšni so lahko rezultati opisanega procesa odgovarjanja. 4.1 Kakšni pa so odgovori? 4.1.1 Nesmiselni odgovori Veliki jezikovni modeli imajo pri odgovarjanju na določeno poizvedbo na voljo številne možne odgovore. Te odgovore oblikujejo na podlagi verjetnosti, ki so dodeljene vsakemu možnemu žetonu v njihovem besednjaku. Teoretično to pomeni, da lahko jezikovni model izbere kateri koli žeton, tudi najmanj verjeten, in tako ustvari odgovor, ki je lahko nesmiseln. Če vizualiziramo vse možne odgovore v prostoru, dobimo sliko 3. Pozor, vse sledeče slike v resnici ne prikazujejo odgovor vseh možnih odgovorov, saj bi prikaz toliko označb naenkrat privedel do nerazpoznavne vizualizacije. Posledično je prikazan le prostor, kjer je hipotetično možnih 1.000.000 odgovorov. 6 S. Karakatič, V. Podgorelec: Programiranje v paru z umetno inteligenco.. Slika 3: Prostor odgovor z vsemi možnimi odgovori. Slika je v celoti črna, ker so prikazani vsi možni odgovori: nesmiselni, smiselni; kratki (enoznakovni), polno dolgi; nepravilni in pravilni (na vsa možna vprašanja). Drži, slika je popolnoma črna, ker vsaka pika predstavlja vse možne odgovore, tudi take, ki so nesmiselni, tudi kratke (enoznakovne) in dolge v vsej možno dolžini, tudi nepravilne in pravilne (za vsa možna vprašanja). Verjetnost, da pa model vrne nesmiselni odgovor, je zelo majhna, zato so takšni dogodki v običajnih okoliščinah praktično nemogoči. Kljub temu je tehnično izvedljivo, da model oblikuje odgovor, ki je sestavljen iz nerazumljivih zaporedij, kot je »njlkfdsjfklsa«. Če pa iz vizualizacije odstranimo vse nesmiselne odgovore, pa se znebimo velike večine vseh možnih kombinacij žetonov in nam tako ostane zelo majhen nabor (relativno glede na število vseh možnih odgovorov). Le smiselni odgovori so prikazani na sliki 4. Slika 4: Prostor odgovor s smiselnimi odgovori. Ti odgovori še vedno lahko vsebujejo sintaktične (slovnične in tipkarske), semantične in logične napake ter neresnice. 7 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 4.1.2 Smiselni odgovori s sintaktičnimi napakami Nekoliko večja verjetnost je, da veliki jezikovni modeli tvorijo smiselne odgovore, ki pa lahko še vedno vsebujejo sintaktične napake. Pri iskanju naslednjega najverjetnejšega žetona lahko jezikovni model občasno vključijo žetone, ki vodijo do sintaktičnih (slovničnih ali tipkarskih) napak. Nekatere od teh napak se lahko pojavijo naključno, vendar lahko glede na kontekstualno razumevanje jezikovni modeli pogosto takoj popravijo potek odgovora v naslednjih žetonih. Vendar pa začetna napaka ostane kot del odgovora, za razliko od človeške komunikacije, kjer lahko svoje napake popravimo za nazaj. Slika 5: Prostor odgovor s smiselnimi odgovori brez sintaktičnih napak. Ti odgovori še vedno lahko vsebujejo semantične in logične napake ter neresnice. Dodaten vir teh napak je mogoče razbrati iz podatkov za učenje takih velikih jezikovnih modelov. Če učni podatki vsebujejo tipkarske in slovnične napake, se lahko model nenamerno nauči teh vzorcev in jih ponovi v svojih rezultatih. Zato je pogostost pojavljanja napake v odzivih jezikovnega modela povezana s tem, kako pogosta je bila ta napaka v podatkih za usposabljanje. Slika 5 prikazuje prostor odgovorov, kjer so nadaljnje odstranjeni še odgovori s sintaktičnimi napakami. Čeprav bi nam odgovori z malo in majhnimi sintaktičnimi napakami še vedno lahko prišli prav (saj so lahko pravilni), pa v namen nadaljnje razlage te odstranimo za namen bolj pregledne vizualizacije. 4.1.3 Smiselni a napačni odgovori brez napak Veliki jezikovni modeli, ki so v večini primerov zelo natančni, lahko ustvarijo tudi razumne odgovore, ki pa so dejansko napačni. Do tega pojava lahko pride zaradi dveh ključnih razlogov. Prvič, če učni podatki modela lahko vsebujejo nepravilne in neresnične informacije in ob učenju iz njih se model lahko nauči teh neresnic in jih ponovi v svojih odgovorih. Ta težava je še posebej izrazita, kadar se poizvedbe nanašajo na teme v distribuciji – to so teme, ki so dobro zastopane v učnih podatkih. Ker model generira svoje odgovore na podlagi vzorcev, ki se jih je naučil iz teh podatkov, se lahko napačne informacije, nehote predstavijo kot dejstva. Verjetnost, da se to zgodi, se povečuje s pogostostjo netočnih informacij v učnih podatkih, zlasti če so povezane z manj kontroverznimi temami (temami, katerih nasprotovanj je zelo malo v učnih podatkih). Drugič, netočnosti se lahko pojavijo tudi pri obravnavi poizvedb izven distribucije ali poizvedb, ki se nanašajo na informacije, ki niso zajete v učnih podatkih. V teh primerih mora jezikovni model na podlagi naučenih vzorcev oblikovati utemeljena ugibanja, čeprav v svojem učnem korpusu nikoli ni videl pravega odgovora. Ta ugibanja so lahko včasih napačna, kar imenujemo halucinacije. 8 S. Karakatič, V. Podgorelec: Programiranje v paru z umetno inteligenco.. Sedaj pa slika 6 prikazuje vse možne odgovore s prilagojeno prosojnostjo glede na njihovo verjetnost, da bodo tvorjeni za eno fiktivno vprašanje (za en kontekst). Temnejši ko je odgovor, večja verjetnost je, da bo to končen odgovor. Če bi postavili popolnoma drugo vprašanje, bi gruča manj prosojnih (temnejših) oz. bolj verjetnih odgovorov bila popolnoma drugje. Slika 6: Prostor odgovor s kjer so odgovori s prosojnostjo označeni glede na njihovo verjetnost, da bodo tvorjeni za podano fiktivno vprašanje. Manj prosojni imajo večjo verjetnost, da bodo tvorjeni. Recimo, da smo jezikovni model prosili, naj nam tvori uvodno vabilo na našo konferenco. Že, če sami premislimo, bi to poleg dejansko uporabljenega stavka »Vabljeni na 26. konferenco Sodobne informacijske tehnologije in storitve« lahko ustvarili številne alternative, ki be imele enak semantični pomen. In prav te alternative bi bile temnejše na sliki 6. Nekaj takih, ki so semantično blizu (ne nujno identično) in bi bili temnejše obarvani na sliki je glede na ChatGPT sledečih: • Dobrodošli na 26. konferenci Sodobne informacijske tehnologije in storitve. • Pozdravljamo vas na 26. konferenci Sodobne informacijske tehnologije in storitve. • Z veseljem vas vabimo na 26. konferenco o Sodobnih informacijskih tehnologijah in storitvah. • Toplo vabljeni na konferenco Sodobne informacijske tehnologije in storitve, ki je že 26. po vrsti. • Pridružite se nam na 26. konferenci na temo Sodobne informacijske tehnologije in storitve. 4.1.4 Smiselni in pravilni odgovori brez napak Kljub vsem do sedaj naštetim morebitnim pastem pa lahko veliki jezikovni modeli ustvarijo tudi povsem točne in razumne odgovore brez semantičnih ali sintaktičnih napak. Verjetnost takšnih popolnih odgovorov je večja pri poizvedbah v distribuciji, saj model pozna ustrezne vzorce v podatkih. Tudi za poizvedbe zunaj distribucije lahko jezikovni modeli pripravijo pravilne in resnične odgovore. Čeprav so takšni rezultati precej odvisni od naključja, ima ključno vlogo sposobnost modela, da izlušči in uporabi semantične in logične vzorce iz svojega učnih podatkov. Z uporabo teh naučenih vzorcev v novih situacijah lahko model ustvari nove in natančne odgovore, kar kaže na njegov močan potencial kot orodja za generiranje besedila. Slika 7 prikazuje odgovore, kjer so pravilni obarvani modro, kjer pa še vedno ohranimo prosojnostjo, ki prikazuje verjetnost za tvorjen odgovor. Tokrat pa zaradi boljše preglednosti slika prikazuje le povečavo področja, kjer je večja verjetnost kreiranih odgovorov. Iz slike je možno razbrati, da niso prav vsi najverjetnejši odgovori tudi pravilni. Hkrati pa so nekateri pravilni odgovori tudi taki, katerih tvorjenje ima manjšo verjetnost. 9 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Slika 7: Prostor odgovor s kjer so pravilni odgovori obarvani modro, s prosojnostjo pa se prikazuje verjetnost, da bo odgovor kreiran. Pri postavljanju vprašanj imamo vsekakor cilj, da dobimo odgovor modela, ki bo pravilen (v vseh vidikih) oz. da vsaj povečamo možnost, a nam model vrne pravilen odgovor. Na to lahko vplivamo na dva načina: da prestavljamo center najbolj verjetnih odgovorov in da zožimo oz. zmanjšamo gručo najverjetnejših odgovorov. 4.2 Ovrednotenje pravilnosti odgovorov Začnimo s prestavljanjem centra najbolj verjetnih odgovorov. Vidimo, da presek pravilnih in najbolj verjetnih odgovorov ni nujno popoln. Že če za malenkost prilagodimo vprašanje (spremenimo kontekst), se lahko verjetnost (prosojnost) odgovorov drastično premakne, kljub temu, da pravilni odgovori (modro obarvani) ostanejo enaki. Naš cilj je vsekakor tvoriti taka vprašanja, da bi bili pravilni in najbolj verjetni odgovori v popolnem preseku. To je prikazano na sliki 8. Če imamo znanje, da sami ocenimo pravilnost podanega odgovora, lahko pridemo vsaj do zaključka, če je vprašanje potrebno popraviti ali ne. Če se odločimo za popravek vprašanja, pa je izziv, da ob tvorjenju vprašanj, takih grafov ne vidimo (saj tudi ni računskih virov, da bi veliki jezikovni modeli izračunali verjetnost vseh možnih odgovorov), zato težko popravljamo vprašanja s ciljem popolnega preseka. Ponovno, če imamo znanje, je dobra praksa, da z izpostavljanjem napak prejšnjih odgovorov, z dodatnimi vprašanji ali prestrukturiranjem izvornega vprašanja pridemo do pravilnega odgovora. Če pa znanja za ocenitev pravilnosti odgovora ne posedujemo, pa je nemogoče identificirati halucinacije in nepravilnosti v odgovorih. Prav to je ena izmed pomanjkljivostih trenutnih jezikovnih modelov – da je njihova uporabnost zelo omejena, če jih uporabljamo za delo, katero ne vemo oceniti, če je pravilno ali ne. V primeru, da naloga ni občutljive narave (kreativno tvorjenje besedila ali kode) in katerih neprimerna uporaba ne bo povzročila resnih posledic, s tem večjega izziva ni. Če pa iščemo odgovore, ki bodo igrali pomembno vlogo v pomembnih odločitvah, ki imajo lahko resne posledice, pa je spraševanje o temah, ki jih sami ne obvladamo izredno zaskrbljujoče. 10 S. Karakatič, V. Podgorelec: Programiranje v paru z umetno inteligenco.. Slika 8: Prikaz različno oblikovanih ampak semantično enakih vprašanja. 4.3 Postavljanje primernih vprašanj Naslovimo še z drugim načinom vplivanja na verjetnost, da dobimo pravilni odgovor: omejitvijo nabora najverjetnejših odgovorov. Če postavljamo vprašanja, ki sličijo na kratke in sintaktično nepravilne iskalne nize, ki smo se jih desetletja učili in uporabljali v iskalnikih (Google, Bing, DuckDuckGo…), bo nabor bolj verjetnih odgovorov mnogo večji. Večji ko je nabor najverjetnejših odgovor, večjo vlogo igra naključje kateri odgovor bomo dobili. Hkrati pa večji nabor najverjetnejših odgovorov razširi temnejšo gručo in s tem potencialno poveča razliko med presekom in ostankom z naborom pravilnih odgovorov. Slika 9: Prikaz preoblikovanja vprašanja, ki zoži ali poveča nabor najverjetnejših odgovorov in s tem spremeni presek z naborom pravilnih ogovorov. Po drugi strani pa tem, če bolj vprašanja napolnimo s podrobnostmi in navodili za odgovor, manjši bo obseg najbolj verjetnih odgovorov. Tako zmanjšamo vlogo naključja in zmanjšamo (v idealnosti celo izničimo) razliko med presekom z pravilnimi odgovori. Preoblikovanje vprašanja, ki zoži ali poveča nabor najverjetnejših odgovorov je prikazan na sliki 9. Za zoženje nabora možnih odgovorov uporabimo enake tehnike, kot bi jih uporabili z delom z ljudmi pri iskanju odgovorov. Praksa kaže, da se zelo dobro obnesejo vprašanja, kjer je hkrati podanih več podvprašanj, ki peljejo do končnega vprašanja. Na tako strukturo bo jezikovni model sproti odgovarjal najprej na podvprašanja in ko pride do dela, kjer odgovarja na krovno vprašanje, bodo del njegovega konteksta že njegovi odgovori na podvprašanja. Še vedno obstaja verjetnost, da bo tvoril napačen odgovor, ampak bo ta manjša, saj bo verjetno že ob podanem podvprašanju za to manjša. 11 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Druga tehnika je, da vsilimo iskanje odgovora po korakih (angl. chain-of-thought). Pri takem načinu preprečimo »na blef« odgovarjanje in vsilimo, da model najprej »premisli« o vprašanju in razloži postopek kako je prišel do odgovora. Ta tehnika deluje zaradi enakega razloga kot prejšnja, verjetnost, da bodo celoten postopek, razmišljanje in končen odgovor modela napačno je manjša kot pa je verjetnost, da bo napačen le kratek odgovor. Tipično vprašanje, ki skorajda obvezno potrebuje tak pristop je reševanje matematičnih enačb. Tako ljudje, kot tudi jezikovni modeli potrebujejo vmesne izračune, da pridemo do rešitve zapletenih matematičnih nalog. Naslednja tehnika je ponovno povzeta po delu z ljudmi – to je tehnika, ko poleg vprašanja modelu priložimo še en ( single-shot) ali več ( multi-shot) primernih ali pravilnih odgovorov. Pri takem postopku bi tako ljudje, kot sam model, skopiral postopek odgovarjanja, le priredili bi ključen del odgovora, da bi ta bil smiseln za podano vprašanje. Dober primer kjer to deluje odlično je pisanje programske kode z regexom. Če modelu poleg prošnje za kodo podamo tudi kako bi naj zgledali pravilni ekstrahirani nizi znakov (tem lahko podamo tudi nepravilne), je večja verjetnost, da bo vrnjena programska koda pravilna. Ta tehnika je tudi zelo primerna, če želimo odgovore točno v določeni obliki (npr. formalno pismo, v francoskem jeziku, v JSON ali XML formatu…). 5 Zaključek Ta prispevek je poskušal pojasniti nekaj osnovnih delovnih načel velikih jezikovnih modelov, ne da bi se potopil v globoko teoretično razpravo ali se zapletal v filozofske dileme, kot je problem kitajske sobe. Pregledali smo štiri scenarije, kako veliki jezikovni modelu delujejo v odgovarjanju na vprašanja, ki nudijo vpogled v različne ravni uspešnosti in točnosti teh modelov. Upamo, da bo ta jasen in "nazoren" pregled pripomogel k zagonu produktivnih debat, brez zmede in neupravičenih pričakovanj, in s tem prispeval k bolj uravnoteženemu in razumnemu pristopu k tej hitro rastoči in vznemirljivi tehnologiji. Literatura [1] VASWANI Ashish, SHAZEER Noam, PARMAR Niki, USZKOREIT Jakob, JONES Llion, GOMEZ Aidan N., KAISER Łukasz, in POLOSUKHIN Illia »Attention is all you need«, Advances in neural information processing systems, številka 30, leto 2017. [2] FLORIDI Luciano in CHIRIATTI Massimo “GPT-3: Its nature, scope, limits, and consequences.”, Minds and Machines, številka 30, leto 2020, 681-694. [3] LIN Tianyang, WANG Yuxin, LIU Xiangyang in QIU Xipeng “A survey of transformers.” AI Open, leto 2022. [4] LIU Xiao, ZHENG Yanan, DU Zhengxiao, DING Ming, QIAN Yujie, YANG Zhilin in TANG Jie "GPT understands, too." arXiv preprint arXiv:2103.10385, leto 2021. [5] ETHAYARAJH Kawin. "How contextual are contextualized word representations? Comparing the geometry of BERT, ELMo, and GPT-2 embeddings." arXiv preprint arXiv:1909.00512, leto 2019. [6] DIS Van, AM Eva, BOLLEN Johan, ZUIDEMA Willem, VAN ROOIJ Robert in BOCKTING Claudi L. "ChatGPT: five priorities for research." Nature 614, številka 7947, leto 2023, 224-226. 12 Web 3 vs Web 2: Konceptualne in tehnološke razlike Muhamed Turkanović, Vid Keršič, Martina Šestak Univerza v Mariboru, Fakulteta za elektrotehniko, računalništvo in informatiko, Maribor, Slovenija muhamed.turkanovic@um.si, vid.kersic@um.si, martina.sestak@um.si Članek se osredotoča na konceptualne in tehnološke razlike med razvojem dveh paradigem spletnega razvoja Web 2 in Web 3. Web 2 prevladuje, vendar prinaša Web 3 inovacije kot decentralizacijo, uporabo pametnih pogodb, nezamenljive žetone itn. Predstavljene so tudi ključni trendi Web 3, kot so decentralizirane identitete in metaverzum. Za namen primerjave Web 2 in Web 3, smo le to izvedli na primeru razvoja in uporabe spletne platforme za zbiranje daril. Predstavili smo tudi izzive Web 3, ki vključujejo skalabilnost in uporabniško izkušnjo, pri čemer se pojavljajo nove rešitve za boljšo usklajenost s tradicionalnimi standardi in koncepti. Kljub izzivom Web 3 prinaša le ta nove priložnosti in dviguje ozaveščenost o spremembah v spletnem razvoju. Ključne besede: decentralizacija web 3.0 metaverzum tehnologija veriženja blokov arhitektura ISBN 978-961-286-772-0 DOI https://doi.org/10.18690/um.feri.8.2023.2 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 1 Uvod Prispevek raziskuje in predstavlja konceptualne in tehnološke razlike med Web 3 in Web 2 – dve različni paradigmi spletnega razvoja. Web 2, ki ga poznamo že vrsto let in prevladuje še danes ter Web 3, ki predstavlja nov val inovacij, ki temeljijo na transparentnosti, uporabniškemu nadzoru in kot ključno na decentralizaciji. Web 2 je zaznamovala centralizacija podatkov in moči, kjer velike platforme kot so Google, Facebook in Amazon vladajo nad spletnim okoljem, pri čemer smo se uporabniki podredili njihovim pravilom in omejitvam. Web 3 izhaja iz tehnologij, kot so verige blokov (ang. blockchain), pametne pogodbe in porazdeljeni ter decentralizirani sistemi za shranjevanje podatkov in datotek. Te omogočajo uporabnikom večjo nadzor nad svojimi podatki in transakcijami ter posledično tudi večjo varnost, zasebnost in avtonomijo. Prav tako se danes Web 2 usmerja predvsem v oblačne platforme in številne spletne storitve, medtem ko Web 3 spodbuja nove modele delovanja in poslovanja, kot so uporaba decentraliziranih aplikacij (DApps), ki so praviloma brezstrežniške, uporaba pametnih pogodb namesto poslovne logike, ki deluje na strežnikih, podpora kripto valutam in drugim kripto žetonom namesto uporabe obstoječih (centraliziranih) mehanizmov plačevanja, itn. Prispevek se bo tudi ozrl na povezljivost Web 3 s področjem metaverzuma (ang. metaverse). V prispevku bomo podrobno predstavili koncept Web 3, vključno z vsemi ključnimi tehnologijami, ki pomagajo danes definirati omenjeno področje. Predstavili bomo tudi različne koncepte, ki jih Web 3 na novo definira, kot npr. uporaba decentraliziranih ali samoupravljanih identitet (ang. decentralized or self-sovereign identity), uporaba digitalnih denarnic kot osnove za nadzor in sodelovanje v svetovnem spletu, upravljanje in trgovanje z digitalnimi dobrinami (npr. nezamenljivi žetoni). Raziskali bomo, zakaj in kako je Web 3 povezan s področjem metaverzuma. Podrobneje bomo prikazali arhitekturo aplikacije Web 3 in to primerjali z konceptualno ekvivalentno rešitvijo, ki temelji na Web 2. V zaključku se osredotočamo na izzive, s katerimi se sooča Web 3 pri prehodu od koncepta do množične uporabe. Čeprav Web 3 prinaša številne prednosti, obstajajo tudi ovire, kot so skalabilnost, uporabniška izkušnja in sprejemanje s strani tradicionalnih institucij. Prav tako pa izvedemo kratko diskusijo o tem, ali je Web 3 resnično korak naprej v evoluciji spleta, ali zgolj nov koncept, ki ga spremljajo nove tehnologije in pristopi, ki jih bomo uporabljali ob bok klasičnemu spletu. Prispevek je pomemben za razumevanje razlik med Web 2 in Web 3 ter za ozaveščanje o novih priložnostih in izzivih, ki jih prinaša razvoj spletnih tehnologij. 2 Splet Zavedajoč se splošnega razumevanja evolucije spleta, na kratko predstavimo dejstva o Web 2.0. Ta predstavlja prelomnico v razvoju spletnih tehnologij, ki je prinesla interaktivno in dinamično izkušnjo na spletu. Razvijajoč se v drugi polovici 2000-ih let, nadgradi prejšnjo statično in enosmerno naravo spletnih strani, ki so pred tem ponujale le vsebine, brez aktivnega sodelovanja uporabnikov. Koncept Web 2.0 je prinesel celoten spekter sprememb, od tehničnih do vsebinskih, in bistveno vplival na način, kako ljudje komunicirajo, delijo vsebine in uporabljajo spletne storitve. Ena ključnih značilnosti Web 2.0 je vključevanje uporabnikov v proces ustvarjanja in deljenja vsebin, kjer uporabniki niso več pasivni opazovalci, temveč aktivni udeleženci. To je privedlo do vzpona socialnih medijev in drugih oblik delovanja in udejstvovanja na spletu, kot je e-poslovanje ter do vzpona vsem znanih velikih IT korporacij (npr. Facebook in Amazon). Prav tako med pomembne značilnosti omenjamo realno-časovno komunikacijo, izmenjavo vsebine in sodelovanje. Med tehnološke spremembe velja posebej izpostaviti tiste, ki so povezane s tehnološkimi koncepti, kot so računalništvo v oblaku, masovni podatki (ang. Big Data) ter danes še posebej pomembo umetno inteligenco. 14 M. Turkanović, V. Keršič, M. Šestak: Web 3 vs Web 2: Konceptualne in tehnološke razlike.. Kljub svojim pozitivnim inovacijam ima Web 2.0 tudi svoje omejitve, kot so centralizacija moči, vprašanja glede varstva in lastništva podatkov in omejitve uporabniškega nadzora. Ena največjih slabosti Web 2.0 je ravno centralizacija moči v rokah nekaj velikih korporacij. Web 2.0 je pogosto prinesel omejitve glede uporabniškega nadzora nad lastnimi podatki in vsebinami. Uporabniki pogosto morajo sprejeti pogoje uporabe, ki jim odrekajo popoln nadzor nad tem, kar delijo in ustvarjajo na platformah. S tem se zmanjšuje njihova avtonomija in svoboda, kar lahko vodi v težave z zasebnostjo in varnostjo podatkov. Web 2.0 platforme imajo pogosto možnost, da omejijo ali cenzurirajo vsebine, ki so na njih objavljene. Čeprav je v določenih primerih to lahko upravičeno za preprečevanje širjenja nezakonitih vsebin ali sovražnega govora, lahko to tudi pomeni omejevanje svobode izražanja in raznolikosti mnenj na spletu. 3 Web 3 Če Web 1.0 označujemo kot splet samo za branje, Web 2.0 kot Splet branja in pisanja, se Web 3.0 označuje kot Splet branja, pisanja in lastninjenja. Poglavitna ideja za konceptom Web 3 je izpolnitev prvotnega obljubljenega potenciala interneta kot odprtega, transparentnega in varnega sistema računalniških omrežij, ki bi v ospredju združeval uporabnike. Zaradi fokusa in omejitev v prispevku predvidevamo osnovno razumevanje določenih že splošno znanih Web 3 konceptov in tehnologij. Glavna lastnost na katerih temelji Web 3 in je osnova za vse ostalo je decentralizacija. Le ta IT skupnosti ni tuja, vendar je šele z razcvetom tehnologije veriženja blokov (ang. blockchain - TVB) resnično pridobila na pomenu. TVB v osnovi gradi na odprtih, javnih omrežij verig blokov, ki združuje številna vozlišča, pri čemer nima nihče popolnega nadzora nad omrežjem. Omrežje namenskih vozlišč na porazdeljeni osnovi hrani zgodovino vseh transakcij in hkrati na decentraliziran način omogoča dogovor za zapis novega skupka potrjenih transakcij (t. i. blok). Na ta način se definira najnovejši stanoviten (ang. stateful) skupek transakcij za katero se vsi udeleženi strinjajo, da so legitimne in skladne z dosedanjo zgodovino in trenutnim stanjem. Sicer obstaja tudi več vrst omrežij verig blokov, kot so tiste zaprtega tipa (ang. permissioned), vendar le te niso v ospredju Web 3, četudi se veliko uporabljajo. Prav tako je Web 3 neodvisen od tipa decentralizirane platforme, saj TVB ni edina možna rešitev. Obstajajo tudi druge vrste tehnologij porazdeljenih knjig (ang. Distributed Ledger Technology - DLT), ki so lahko v uporabi. Z dopolnitvijo TVB s pametnimi pogodbami se razcvet Web 3 šele začne, saj ponudijo le te poljudno programljivo poslovno logiko, ki je tudi nujno potrebna za nove bogate primere uporabe. S pojavom pametnih pogodb govorimo tudi o TVB 2.0, saj je prejšnja različica TVB 1.0 bila omejena zgolj na podporo kripto valutam kot nove oblike digitalne vrednosti. Pametne pogodbe pa v osnovi ponudijo možnost za razširjanje koncepta tokenizacije, saj si lahko kdor koli ustvari svoje namenske kripto žetone, ki so se prav tako razvijali od enostavnih zamenljivih (ERC-20) do nezamenljivih (ERC-721, ang. non-fungible token - NFT) in še naprej [1]. Te so privedle do porasta različnih poslovnih primerov uporabe, s tem pa omogočijo lastno plačilno sredstvo, ki je neodvisno od trenutnih centraliziranih rešitev. NFT in podobne nestandardizirane oblike nezamenljivih žetonov postanejo skoraj vseobsežna komponenta vsake Web 3 rešitve. Nezamenljivi so iz razloga, ker je vsak ustvarjen žeton unikaten in se ga ne da enačiti ali zamenjati z drugim, kar jim omogoči, da postanejo medij za hranjenje različnih novih oblik digitalnih umetnin ali drugih vrednosti. Novi primeri uporabe hkrati privedejo do potrebe po namenskih aplikacijah, ki končnim uporabnikom omogočajo interakcijo s TVB in pametnimi pogodbami ter posledično z vsemi možnimi kripto žetoni. Takšne namenske aplikacije so se hitro poimenovale decentralizirane aplikacije (DApp) in so postale osrednji del Web 3. Zaradi omejitev, povezane predvsem s hrambo podatkov, so Web 3 rešitve hitro začele uporabljati dodatno komponento, ki jim omogoča neomejen shrambo, pri čemer pa tudi ta sledi konceptom decentralizacije. To so predvsem sistemi porazdeljenega shranjevanja datotek (ang. Distributed File Storage System), kot je npr. IPFS. 15 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Da bi vse skupaj delovalo po principih Web 3 in da bi le ta deloval brezhibno pa morajo končni uporabniki biti tisti, ki bodo resnično nadzirali svoje podatke in digitalne vrednosti, kar se že od povojev TVB rešuje z uporabo namenskih digitalnih denarnic (DD). Podatki in včasih tudi digitalne vrednosti so sicer lahko hranjenje na kakšnih javno dostopnih TVB, vendar so zgolj njihovi lastniki tisti, ki lahko z njimi upravljajo. Z uporabo DD si končni uporabniki ustvarijo lastne digitalne profile, ki jih nadzirajo s pomočjo kriptografskih osnov tj., s parom kriptografskih ključev, temelječih na asimetrični kriptografiji. Vsaka sprememba stanja se digitalno podpiše, kar uporabniki počnejo z uporabo DD in svojih zasebnih ključev. DD v veliki večini omogočajo interakcijo z decentraliziranimi aplikacijami. Obstaja široka paleta vrst in oblik DD, ki jih pa ne bomo posebej predstavljali [2]. 3.1 Trendi Razen kriptografskih žetonov, tistih zamenljivih ali nezamenljivih, ki že sedaj poganjajo različne sisteme tokenizacije in druge primere uporabe, je Web 3 zajel še številne druge trende, ki jih bomo nekatere na kratko predstavili. Skupno vsem trendom je predvsem podpora lastnosti decentralizacije. 3.1.1 Metaverzum Upoštevajoč popularnost igre Fortnite in njene podpore zbirateljstvu igralnih pripomočkov, kakor tudi funkcionalnosti digitalnih kriptografskih žetonov, ki so se že uporabljali tudi kot nov način za podporo zabavi, tudi v obliki spletnih iger (npr. Cryptokitties), se je pojavila ideja o ustvarjanju novega navideznega sveta, ki bi sledil prvotnim idejam metaverzuma, kot sta bila The Palace in Second Life [3]. Tako je leta 2017 prišlo do ustanovitve t. i. Decentraland, ki predstavlja, na platformi Ethereum temelječ metaverzum. Decentraland se lahko smatra tudi kot decentralizirana aplikacija – Dapp. Metaverzum se kaže kot naslednji korak v razvoju digitalnih okolij, kjer se realnost in navideznost zlivata v enoten, interaktivni prostor. Metaverzum, kot ga poznamo danes, predstavlja ambiciozno vizijo povezave med fizičnim in digitalnim svetom. Platforme, kot sta Decentraland, Roblox, Meta idr. odpirajo vrata k virtualnim izkušnjam, kjer se lahko ljudje srečujejo, sodelujejo v dejavnostih ter ustvarjajo vsebino. Danes se metaverzum smatra kot enoten navidezni svet, ki ga predvsem upravlja Facebook (Slika 1). To je predvsem posledica močne oglaševalske kampanje, ki jo vodi, sedaj že imenovano podjetje Meta. Slika 1: Vrste metaverzumov glede na obliko zagotavljanja lastnosti decentralizacije. Metaverzum kot tak definira navidezni prostor, ki je sicer 3D oblike in uporabnikom omogoča osnovne funkcionalnosti ustvarjanja lastnega avatarja, komunikacije z drugimi avatarji, prostega sprehoda po navideznem svetu itn. Metaverzum se kot trend izrazi predvsem zaradi naprednih naprav, ki podpirajo obogateno in navidezno resničnost (ang. augmented and virtual realizty - AR/VR), ki je predvsem v fokusu centraliziranih platform, kot je tista od Mete. 16 M. Turkanović, V. Keršič, M. Šestak: Web 3 vs Web 2: Konceptualne in tehnološke razlike.. Ravno decentralizacija je ponovo osrednji del, kjer se danes različni metasvetovi med seboj razlikujejo, pri čemer se tudi velikokrat metaverzum enači kar s konceptom Web 3. Slednje je verjetno posledica samega naziva Web 3, ki bi naj napovedoval novo obdobje Spleta in idejo o tem, da se bomo v prihodnosti v splet "potopili" (ang. immerse) ter dejstva, da so se številni koncepti Web 3 prida uporabili v novejših zasnovah metaverzuma, kot je tokenizacija produktov znotraj metaverzuma. V resnici se Web 3 konceptualno loči od metasvetov, saj uporaba principov Web 3 v določenem metaverzumu privede zgolj do takšnega sveta, ki bo deloval po principih decentralizacije. Uporaba TVB v metaverzumu omogoča enostavno in varno lastništvo digitalnih produktov ali sredstev v obliki digitalnih kriptografskih žetonov, ki so vezani na uporabnikov decentralizirano identiteto, kot je v primeru Decentralanda na platformo Ethereum. Tako lahko uporabnik med uporabo platforme Decentraland kupi zemljišče, si zgradi objekt (npr. hišo), ga opremi s pohištvom ter kupi svojemu avatarju posebne superge, pri čemer so zemljišče, objekt, pohištvo in superge vsak za sebe nezamenljiv žeton NFT, ki si ga uporabnik v celoti varno in transparentno lasti in ga lahko kadar koli proda naprej [4]. Podobne koncepte najdemo tudi v centraliziranih platformah, kot so Meta ali Earth2, pri čemer pa je razlika ta, da so digitalni produkti, ki jih uporabniki kupijo vezani na njihov profil pri omenjeni platformi, plačani s klasičnimi sredstvi procesiranja finančnih transakcij in velikokrat tudi zaklenjeni v uporabo zgolj pod okriljem lastnika platforme. Posledično je tudi prodaja digitalnih produktov omejena pod okrilje ene platforme, v razliko od tistih iz Decentralanda, ki se lahko prodajajo in izmenjujejo na ločenih decentraliziranih digitalnih tržnicah za nezamenljive žetoni (npr. OpenSea). Prav tako se metaverzum lahko opre na koncepte decentralizirane avtonomne organizacije (ang. decentralized autonomous organizations - DAO), ki omogočajo skupnostno upravljanje in odločanje, kar krepi demokratično naravo virtualnega prostora. Skozi to povezavo se obetajo nove možnosti za ustvarjanje poslovnih modelov, vključno s prodajo in trgovino z digitalnimi sredstvi v metaverzumu ter zaslužkom prek sodelovanja v skupnostih. Ključnega pomena je torej zagotavljanje varnosti, zasebnosti in uporabniškega nadzora, ki jih prinaša Web 3, da bodo uporabniki lahko brezskrbno izkoriščali potencial metaverzuma. 3.1.2 Decentralizirane in samoupravljanje identitete Želja po decentralizaciji je hitro privedla do novih področij, ki bi naj imele koristi od novih tehnoloških paradigem. Tako je področje digitalnih identitet postalo naslednje v vrsti, saj je TVB že ponujala delno rešitev. Za uporabo TVB si uporabniki sami ustvarijo namenske račune, ki postanejo njihove decentralizirane identitete. Slednji naziv izhaja iz dejstva, da je zgolj uporabnik tisti, ki ima nadzor nad svojim zasebnih parom kriptografskih ključev, ki hkrati tudi postane del njegovega javnega digitalnega profila (v sklopu TVB se imenuje naslov), v razliko od centraliziranih digitalnih identitet, kjer za uporabnika profil ustvari, ga nadzira in omogoča določena tretja entiteta (npr. Facebook). Decentralizirane identitete predstavljajo paradigmo, kjer imajo posamezniki popoln nadzor nad svojimi osebnimi podatki in digitalno identiteto. Namesto da bi se zanašali na osrednje organizacije za shranjevanje in preverjanje identitet, se decentralizirane identitete opirajo na TVB, pametne pogodbe in kriptografijo, kar omogoča uporabnikom, da sami upravljajo svoje podatke in izbirajo, s kom jih delijo. Pomembna nadgradnja decentraliziranih identitet so modeli samoupravljanih identitet (ang. self-sovereign identity - SSI), ki razen upravljanja digitalnih profilov, vpeljejo obogaten koncept upravljanja z identitetnimi podatki in s tem povezanimi identifikatorji, brez interakcije z zunanjimi entitetami [5]. SSI prinaša revolucionarno spremembo na področje upravljanja identitet in omogoča uporabnikom, da prevzamejo aktivno vlogo pri upravljanju svojih identitetnih podatkov ter zmanjšajo potrebo po tradicionalnih centraliziranih mehanizmih, kot so ustvarjanje računov pri različnih ponudnikih storitev ali uporabo ponudnikov digitalnih identitet (ang. identity provider - IdP). V okviru modela SSI je vsak uporabnik sam odgovoren za ustvarjanje, hranjene, varovanje in drugo upravljanje svoje digitalne identitete. Slednje izvaja s pomočjo namenskih digitalnih denarnic [6]. Osnova modela so t. i. decentralizirani identifikatorji (ang. decentralized identifier – DID), ki so upravljani na podlagi para asimetričnih kriptografskih ključev, kjer je zasebni ključ orodje za nadzor identitete, javni pa osnova za generiranje identifikatorja. SSI model vpeljuje tri ključne akterje, ki igrajo bistveno vlogo pri izvajanju 17 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. identifikacijskih procesov: izdajatelja identitetnih atributov (ang. Issuer), imetnika identitete (ang. Identity Holder) ter preveritelj oz. ponudnik storitev (ang. Verifier) [5]. Ti akterji sodelujejo v procesu izdajanja, preverjanja in upravljanja identitetnih podatkov na način, ki omogoča visoko stopnjo varnosti in zaupanja. Imetnik identitete (Identity Holder) je odgovoren za pridobivanje, shranjevanje, upravljanje in deljenje svojih identitetnih podatkov s preveritelji. Imetnik identitete lahko v različnih kontekstih deluje v različnih vlogah glede na zahteve in potrebe, kar omogoča prilagodljivost sistema. Izdajatelj identitetnih atributov ima ključno vlogo pri potrjevanju določenih atributov imetnika identitete. S pomočjo digitalnega podpisa izda preverljivo poverilnico (ang. verifiable credential – VC), ki vsebuje enega ali več atributov imetnika identitete. Ti atributi oz. trditve se nanašajo na različne vidike imetnikove identitete in so osnova za nadaljnje preverjanje in uporabo storitev. Preveritelj je entiteta, ki zahteva dokazilo o identiteti imetnika in izvaja preverjanje podatkov. S pomočjo tehnologij, kot so DID, VC ter TVB, se vzpostavi zaupanje med entitetami. Proces preverjanja tako ne zahteva vedno sodelovanja izdajatelja poverilnic, saj so vzpostavljene mehanizmi za preverjanje in verifikacijo na osnovi decentraliziranih tehnologij. SSI ima potencial, da preoblikuje način, kako uporabniki komunicirajo in poslujejo na spletu. Povečanje varnosti, zasebnosti in enostavnosti preverjanja identitete lahko vodi do večje zaupanja med uporabniki in storitvenimi ponudniki. To pa lahko spodbudi razvoj novih poslovnih modelov, ki temeljijo na zaupanju, ter odpre vrata k inovacijam, ki še naprej preoblikujejo digitalni svet. Predstavljeni koncepti SSI, četudi temeljijo na decentralizaciji, so vzbudili širše zanimanje, kjer lahko kot primer izpostavimo eIDAS 2.0 (elektronska identifikacija in storitve zaupanja (angl. Electronic Identification and Trust Services)), ki ga uvaja Evropske unija z namenom podpore elektronskem poslovanju na enotnem notranjem trgu EU. Ta je za novo različico eIDAS (2.0) kot zahtevo vpeljala določene funkcionalnosti, ki izvirajo ravno iz modela SSI [6]. 3.2 Rešitve Zaradi boljšega razumevanja koncepta Web 3 bomo navedli nekaj primerov popularnih rešitev. Ena izmed teh je tudi metaverzum platforma Decentraland, ki smo jo na kratko predstavili nekoliko prej. Rešitve lahko grupiramo glede na koncept, ki ga zasleduje, in sicer so to lahko spletne igre (npr. Axie Infinity ali Cryptokitties), industrija umetnosti, socialna omrežja (npr. Sola), podporne storitve ali orodja (npr. Storj ali DEIP), decentralizirane finance (DeFi) (npr. Cashaa) itn. Storj je decentralizirana platforma za shranjevanje podatkov, ki temelji na TVB in je povezana s konceptom Web 3. Njen namen je ponuditi varno, zasebno in robustno rešitev za shranjevanje podatkov, ki temelji na decentralizaciji in uporablja neizkoriščen prostor na računalnikih posameznikov po vsem svetu. Namesto da bi podatke shranjevali na centraliziranem strežniku, Storj omogoča, da se datoteke razdrobijo, šifrirajo in nato shranijo na mrežo različnih računalnikov, imenovanih "farmerji". To pomeni, da je naša datoteka razpršena po več lokacijah, kar izboljšuje varnost in odpornost proti napadom. Storj uporablja lasten kripto žeton, imenovan "STORJ", za spodbujanje sodelovanja in omogočanje plačil med uporabniki, ki oddajajo svoj prostor na disku (farmerji), ter tistimi, ki potrebujejo prostor za shranjevanje svojih podatkov. To ustvarja poslovni model, ki spodbuja deljenje prostora in vzdrževanje omrežja. Helium se osredotoča na vzpostavitev decentraliziranega omrežja za internet stvari (IoT). Glavni cilj Heliuma je omogočiti napravam, kot so senzorji in naprave za sledenje, komuniciranje prek brezžične tehnologije in omogočiti zbiranje ter prenos podatkov na učinkovit in zanesljiv način. Helium uporablja algoritem Proof of Coverage, ki temelji na prisotnosti in dosegu naprav. Upravljavci naprav, imenovani "hotspoti", dokazujejo, da so dejansko pokrivali določeno območje, kar omogoča vzpostavitev zanesljivega omrežja brez potrebe po tradicionalni infrastrukturi. Helium omrežje uporablja lasten kripto žeton, imenovan "HNT" (Helium Network Token). Hotspoti prejemajo HNT kot nagrado za zagotavljanje pokritosti in prenašanje podatkov v omrežju. Tako se spodbuja sodelovanje in rast omrežja. Brave je spletni brskalnik, ki se osredotoča na izboljšanje varnosti, zasebnosti in uporabniške izkušnje pri brskanju po spletu. Razvija ga podjetje Brave Software in temelji na odprtokodnem projektu Chromium, kar pomeni, da deli osnovo z Google Chrome brskalnikom. Najbolj znana funkcija brskalnika je vgrajeno blokiranje oglasov in 18 M. Turkanović, V. Keršič, M. Šestak: Web 3 vs Web 2: Konceptualne in tehnološke razlike.. sledilcev, ki preprečuje, da bi spletne strani sledile vašemu obnašanju na spletu in vas ciljale z oglasi. Hkrati ponuja brskalnik tudi možnost nagrad za ogled oglasov, pri čemer uporabniki prejmejo kripto žeton BAT (ang. Basic Attention Token) kot nagrado za svojo pozornost na oglaševalske vsebine. Cashaa je finančna platforma, ki omogoča mednarodne denarne prenose, izmenjavo valut ter dostop do kripto valut. Platforma temelji na TVB ter si prizadeva za boljše povezovanje tradicionalnega finančnega sistema s svetom kripto valut in decentraliziranimi tehnologijami oz. decentraliziranih financ (DeFi). DEIP (Decentralized Intellectual Property) je platforma za upravljanje intelektualne lastnine, ki temelji na TVB. DEIP si prizadeva za decentralizacijo, transparentnost in učinkovitost v procesih povezanih z intelektualno lastnino, kot so patentiranje, avtorske pravice, znanstvene raziskave in podobno. DEIP uporablja TVB za varno shranjevanje in sledenje informacij o intelektualni lastnini. To zagotavlja transparentnost in neizbrisljivost zapisov. Pametne pogodbe omogočajo avtomatizacijo in avtomatsko izvajanje pravic intelektualne lastnine. Na primer, avtor lahko določi, kako želi, da se uporabljajo njegova dela, in ta pravila se nato samodejno izvajajo. DEIP omogoča tudi tokenizacijo intelektualne lastnine, kar pomeni, da se pravice do dela lahko predstavijo kot digitalni kripto žetoni. To olajša trgovanje in izmenjavo intelektualne lastnine. Axie Infinity je igralna platforma, ki temelji na TVB in se osredotoča na zbirateljsko igranje in trženje digitalnih bitij, imenovanih "Axies". Axie Infinity je ena izmed prvih in najbolj znanih iger, ki v celoti izkorišča koncepte Web 3, vključno z uporabo kripto valut, pametnih pogodb in decentralizacije. Axies so digitalna bitja, ki jih igralci zbira, izboljšuje in uporablja v bojih proti drugim igralcem. Vsak Axie je edinstven in ga lahko lastnik trži, vzreja in uporablja za sodelovanje v različnih igralnih načinih. Igra ima lastno tržnico, kjer lahko igralci kupujejo, prodajajo in trgujejo z Axies ter drugimi digitalnimi sredstvi. Tržnica deluje s pomočjo pametnih pogodb, kar omogoča avtomatizacijo transakcij in zagotavlja varnost. OpenSea je ena izmed največjih in najbolj znanih platform za trgovanje z digitalnimi sredstvi, kot so kripto umetniška dela, kolekcionarski predmeti in drugi digitalni NFT-ji. OpenSea omogoča uporabnikom nakup, prodajo in trgovanje z NFT-ji. Uporabniki lahko iščejo in preglejujejo različne digitalne predmete ter sodelujejo v dražbah. OpenSea podpira številne različne standarde NFT-jev, kar omogoča trgovanje z NFT-ji, ustvarjenimi na različnih platformah TVB, kot so Ethereum, Polygon, Solana in drugi. 4 Primerjava Web 2 in Web 3 V tem poglavju podrobneje predstavimo primerjavo med Web 2 in Web 3 in sicer glede na uporabniški vidik ali vidik razvijalcev spletnih aplikacij. Kot osnovo za primerjavo uporabimo idejo za spletno aplikacijo, ki omogoča uporabnikom, da si ustvarijo svojo kampanjo za zbiranje priložnostnih daril. Primer je lahko namišljena oseba Bojan, ki praznuje rojstni dan in si ustvari kampanjo na spletni platformi imenovani GiftCollector, kjer povabi prijatelje, da mu namesto darila izpolnijo spletno čestitko in nakažejo denarna sredstva. 4.1 Web 2 Začeli bomo z vsem znano varianto, tj. klasičen Web 2.0, pri čemer zaradi lažje primerjave predstavimo prvo uporabniški vidik ter šele nato razvijalčev vidik. 4.1.1 Uporabniški vidik Predpogoj za uspešno izvedbo vseh uporabniških vidikov je ta, da so tako Bojan kot njegovi prijatelji informacijsko pismeni (tj., vešči uporabe brskalnika in spletnih strani, kakor tudi elektronskega poslovanja) ter da imajo dovoljšna denarna sredstva in možnosti porabe teh na spletu (npr. PayPal račun). Če se fokusiramo na Web 2 pristop, sledimo miselnemu procesu, kateremu lahko zaradi splošne prakse, hitro sledimo. Bojan s svojim priljubljenim brskalnikom obišče klasično spletno stran GiftCollector.com, kjer si ustvari profil, pri čemer mu GiftCollector ponudimo možnost enotnega vpisa (ang. Single-Sign-On – SSO) na osnovi 19 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Google ali Facebook računa. Bojan izbere svoj Google račun kot osnovo za nov profil na GiftCollector-ju. Po registraciji in vpisu, Bojan izbere ustvarjanje nove kampanje, kjer GiftCollector od njega zahteva vnos določenih podatkov in izbiro ponujenih možnosti. Bojan vnese ime kampanje, njen opis in namen, doda svojo sliko, definira čas trajanja kampanje in izpolni še druge informacije, kot je npr. da dovoli prijateljem ustvarjanje čestitke ali prenos izbrane čestitke na platformo, kjer si jo bo lahko po koncu kampanje ogledal. Hkrati Bojan označi, da želi zbirati zgolj denarna sredstva v valuti EUR in ponudi svoj TRR ali številko kartice kot osnovno na katero se naj zbrana sredstva po koncu kampanje nakažejo. Z ustvarjenjem kampanje se strinja, da bo GiftCollector-ju plačal 10 EUR, ki jih poravna s kreditno kartico VISA, pri čemer mu je GiftCollector ponudil tudi druge plačilne možnosti, kot je PayPal ali nakazilo na njihov TRR. Med kampanjo lahko Bojan med obiskom GiftCollectorja sledi stanju zbranih sredstev in si ogleda prispele čestitke. Kampanjo lahko tudi predčasno prekine. Po koncu kampanje dobi s strani GiftCollectorja elektronsko sporočilo z informacijami in hkrati kak dan za tem tudi nakazan ves izkupiček denarnih sredstev na svoj TRR. Bojanovi prijatelji lahko na podlagi URL naslova, ki jim ga je delil Bojan prav tako obiščejo pripravljeno kampanjsko spletno stran, kjer bodo videli vse potrebne informacije in lahko v kampanji tudi sodelovali. Prijatelji imajo možnost Bojanu pustiti tekstovno sporočilo ali prenesti datoteko slikovnega formata ter izpolniti količino sredstev v EUR, ki so mu pripravljeni podariti za rojstni dan. Registracija na GiftCollectorju za prijatelje ni potrebna, saj lahko vnesejo samo svoje ime ali vzdevek. Po izpolnjevanju vseh nujnih podatkov jih GiftCollector preusmeri na storitev spletnega plačevanja, kjer prijatelji izberejo način prenosa sredstev (npr. PayPal), izpolnijo vse potrebne podatke in zaključijo s pošiljanjem daril. 4.1.2 Razvijalčev vidik Implementacija GiftCollectorja kot spletne platforme je seveda lahko zelo raznolika glede na naše preference, ki bi jih kot načrtovalci imeli. Za namen poenostavljanja primerjave bomo predstavili samo eno od možnih oblik implementacije, ki ni nujno tudi najboljša, najučinkovitejša ali najbolj poceni. Zaradi kompleksnosti poslovne logike smo izbrali klasičen način, kjer imamo spletno aplikacijo z obličjem (ang. frontend), zaledjem (ang. backend), podatkovno bazo in hrambo podatkov. Izbrali smo si ponudnika oblačnih storitev AWS, kjer bomo gostili ves naš zaledni del. Za namen razvoja obličja uporabimo Next.js in druge podporne knjižnice. Za zaledje izberemo Node.js (lahko tudi Express.js), kjer si definiramo vso potrebno poslovno logiko. Za podatkovno bazo uporabimo MySQL. Hkrati smo primorani uporabiti tudi druge podporne storitve in ogrodja, kot je PayPal API in Stripe za zagotavljanje podpore plačevanja storitev, Amazon API za S3 za namen hranjenja različnih datotek, ki jih uporabniki prenašajo znotraj kampanje, Firebase API za namen pošiljanja elektronskih sporočil in podpori overjanja in avtorizacije na osnovi OAuth 2.0. Poenostavljen prikaz sistemske arhitekture je prikazan na sliki 2. 20 M. Turkanović, V. Keršič, M. Šestak: Web 3 vs Web 2: Konceptualne in tehnološke razlike.. Slika 2: Sistemska arhitektura spletne aplikacije GiftCollector po principu Web 2.0 Vir: [7]. 4.2 Web 3 Nadaljujemo s predstavitvijo zasnove GiftCollectorja po principih Web 3.0. Zaradi lažje primerjave tokrat prvo predstavimo razvijalčev vidik in šele nato uporabnikov. 4.2.1 Razvijalčev vidik Enako kot je implementacija GiftCollectorja po klasičnih principih Web 2.0 lahko raznolika, je implementacija po principih Web 3.0 lahko prav tako. Za namen poenostavljanja primerjave bomo predstavili samo eno od možnih oblik implementacije po Web 3.0. Ker želimo, da je GiftCollector načrtovan in implementiran po principih Web 3.0, bomo stremeli k temu, da bo čim več njenih komponent temeljilo na lastnosti decentralizacije. Slednje zahteva od nas, da se znebimo centraliziranih komponent, ki bi jih mi lastili in upravljali kot razvijalci ali kdo od ponudnikov storitev, ki bi jih sami izbrali. Posledično ne moremo imeti (ključne) zaledne poslovne logike nekje na našem strežniku, četudi uporabljamo kakšno oblačno rešitev. Kljub temu je rešitev na dlani, saj poslovno logiko za Web 3.0 v večini primerov dodamo v pametne pogodbe. Slednje spišemo v programskem jeziku Solidity, pri čemer se fokusiramo na dejstvo, da bodo le te omogočale hrambo sredstev v domorodnih kripto valutah. Slednja je odvisna od izbrane platforme verig blokov. V našem primeru izberemo javno platformo verig blokov Etheruem, ki je tudi najbolj popularna platforma, ki podpira pametne pogodbe [8]. S tem omogočimo tudi, da bodo naše pametne pogodbe lahko hranile zelo popularno kripto valuto Ether (ETH). Ključna poslovna logika pametne pogodbe je torej ta, da za čas kampanje hrani nakazane ETH s strani prijateljev, pri čemer po koncu kampanje zbrana sredstva samodejno nakaže iniciatorju kampanje. Da ta del deluje moramo seveda v pametnih pogodbah temu primerno beležiti decentralizirane identitete uporabnikov oz. njihove naslove TVB. Del poslovne logike je tudi to, da se kampanja začne samo takrat, ko iniciator le te pošlje transakcijo s katero plača zahtevana sredstva (tj., vrednost 10 EUR v ETH). Po razvoju pametnih pogodb jih primerno prevedemo (ang. compile) ter prenesemo v omrežje Ethereum, pri čemer si s tem tudi zagotovimo lastništvo nad le to in pridobimo naslove pametnih pogodb ter njihove zlogovne vmesnike (ang. application binary interface – ABI). Naslovi nam služijo kot javne končne točke (ang. endpoint) preko katerih bomo lahko z našo (decentralizirano) spletno aplikacijo integrirali z našo poslovno logiko. Kot razvijalci moramo tudi poskrbeti za podporo čestitkam, ki jih lahko prijatelji iniciatorja kampanje ustvarijo in ob denarnem darilu ustvarijo/prenesejo. Datotek ali vsebine večje velikosti ni smiselno hraniti v pametnih pogodbah na verigah blokov, saj bi bili stroški s tem za uporabnike preveliki. Ker ne moremo izbrati centraliziranih 21 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. strežnikov za hranjenje datotek, se odločimo za uporabo decentraliziranega in porazdeljenega sistema za hranjenje datotek IPFS. Uporabimo javno različico omrežja IPFS, ki prav tako kot Ethereum predstavlja javno omrežje, ki ne zahteva dovoljenja za pridruževanje (ang. permissionless). S tem si zagotovimo, da GiftCollector na decentraliziran način hrani različne vrste datotek. Po prenosu datotek na IPFS, uredimo hranjenje reference na lokacijo le te v pametni pogodbi. Sedaj, ko smo si zagotovili ključno zaledno poslovno logiko, ki sicer sedja ni v zaledju, moramo še poskrbeti za oblični del. Podobno kot v primeru Web 2.0, bomo tudi tokrat razvili spletno aplikacijo, ki se pa zaradi svojih specifičnih lastnosti in funkcionalnosti poimenuje kar decentralizirana aplikacija (Dapp). Kot ogrodje za razvoj uporabimo Next.js, pri čemer pa kot ključno komponento vključimo še knjižnico web3.js ali ethers.js. Slednje nam pomaga, da lahko komuniciramo z omrežjem verig blokov in našo pametno pogodbo, kakor tudi z uporabniki Dapp-a in njihovimi digitalnimi denarnicami (DD). Da komunikacija med Dapp in pametnimi pogodbami deluje, moramo v konfiguracijo Dapp-a dodati naslove in ABI naših pametnih pogodb. Podobno bi v primeru Web 2 storili, če bi se želeli povezati s poslovno logiko in metodami, ki so hranjene nekje v oblaku ali strežniku. Web3.js ali ehters.js poskrbita za velik del funkcionalnosti, in sicer tudi za podporo komunikacije med uporabnikovimi DD in Dapp-om. Sedaj, ko se izogibamo zaledju, je seveda večji fokus na funkcionalnosti obličnega dela. Tako je potrebno Dapp povezati tudi z omrežjem IPFS, kjer bomo lahko na le to shranjevali ali prevzemali različne datoteke. Kot razvijalci nam ni potrebno skrbeti za podporo plačilnim storitvam, saj bodo le te temeljile na prenosu kripto valut ETH od uporabnikov do pametnih pogodb, pri čemer je vsa potrebna funkcionalnost že urejena s strani uporabnikovih DD in podpornih knjižnic web3 ali ethers. Prav tako nam ni potrebno podpirati posebnih mehanizmov overjanja in avtorizacije, saj bomo le to prepustili uporabnikovim DD, ki predstavljajo njihovo decentralizirano identiteto in orodje s katerim se overijo. Ponovo je vsa potrebna logika že podprta s strani DD in knjižnic web3 in ethers, pri čimer se sami zgolj sklicujemo na posamezne podprte funkcije. Ko smo z implementacijo Dapp zaključili nam še ostane namestitev le te. Največkrat izbrana možnost je ta, da se Dapp naloži na strežnik primeren za gostovanje spletnih aplikacij. Ta je lahko naš lasten ali v oblaku. Slednje je seveda kontradiktorno osnovnim načelom Web 3, kjer bi naj vse bilo decentralizirano, vendar je to trenutno najprimernejša možnost. Druga možnost bi bila, da se celoten Dapp z vsemi svojimi razvijalskimi datotekami naloži na omrežje, kot je IPFS ali Ceramic, kar bi zagotovili popolno decentraliziranost naše rešitve. Žal je ta možnost uporabniško neprijazna zaradi počasnosti delovanja omenjenih omrežij, kar pa je posledica konceptov po katerih delujejo (tj., porazdeljenost in decentralizacija). Kljub nadomestni rešitvi, ki je največkrat uporabljena, lahko še zmeraj govorimo o Dapp in Web 3 rešitvi, saj se večina ključne poslovne logike odvija na decentraliziran način oz. na strani DD in odjemalčevi strani, tj. brez zaledja. Poenostavljen prikaz sistemske arhitekture Web 3.0 je prikazan na sliki 3. 4.2.2 Uporabniški vidik V razliko od procesa, ki sledi pristopu Web 2.0, je slednje uporabnikovega vidika, ki temelji na pristopu Web 3.0 kompleksnejše. Slednje velja predvsem za uporabnike, ki niso seznanjeni s koncepti in terminologijo povezano s TVB oz. niso vešči orodij, ki so s tem povezana. Vsekakor morajo vsi biti informacijsko pismeni (tj., vešči uporabe brskalnika in brskanja po spletu). Prav tako je predpogoj ta, da si vsi v svoj priljubljen brskalnik morajo namestiti namensko digitalno denarnico (DD), kot je npr. Metamask in si pridobiti določeno količino kripto valute ETH. Z nameščanjem DD si hkrati zagotovijo svojo decentralizirano identiteto, ki je v tem primeru povezana z njihovim naslovom TVB, ki ga nadzirajo z zasebnim ključem oz. DD. Ko se Bojan odloči ustvariti kampanjo s svojim priljubljenim brskalnikom obišče spletno stran GiftCollector.com, ki je sedaj Dapp. Dapp se samodejno poskusi povezati z njegovo DD in mu to na podlagi pojavnega okna omogoči tudi nadzirati. Ko Bojan s svojo DD sprejme povezavo z GitCollector Dapp-om, je enako kot bi se uspešno vpisal v klasično spletno aplikacijo. Bojan ustvari novo kampanjo na način, da izpolni vse zahtevane informacije, kot so ime kampanje, namen, trajanje itn. Ni mu potrebno vnašati svojega TRR, saj Dapp že ima njegov Ethereum naslov 22 M. Turkanović, V. Keršič, M. Šestak: Web 3 vs Web 2: Konceptualne in tehnološke razlike.. na katerega bo po koncu kampanje GiftCollector (pametna pogodba) nakazal zbrana sredstva. Ko želi Bojan kampanjo inicializirati, mora le to potrditi z elektronskim podpisovanje transakcije. Dapp pripravi transakcijo in jo ponudi Bojanu v podpis, pri čemer se mu le to pojavi kot pojavno okno DD, kjer transakcijo poljubno sprejme ali zavrne. Ob podpisu transakcije se je Bojan tudi strinjal in nakazal potrebnih ETH za 10 EUR, kolikor je strošek storitve. S podpisom transakcije je Bojan uspešno inicializiral svojo kampanjo. Med kampanjo lahko Bojan med obiskom GiftCollectorja sledi stanju zbranih sredstev in si ogleda prispele čestitke. V razliko od Web 2 pristopa, lahko Bojan spremlja stanje kampanje tudi javno na pregledovalniku transakcij verig blokov, kot je etherscan. Kampanjo lahko tudi predčasno prekine, vendar bo moral to potrditi s podpisom transakcije, ki se proži s pomočjo DD. Po koncu kampanje dobi Bojan s strani GiftCollectorja nakazan ves izkupiček denarnih sredstev na svoj Ethereum naslov. Enako kot v prejšnjem primeru bodo Bojanovi prijatelji lahko na podlagi URL naslova, ki jim ga deli Bojan obiskali pripravljeno kampanjsko spletno stran, ki je v tem primeru Dapp. Enako kot v prejšnji različici, imajo prijatelji možnost Bojanu pustiti tekstovno sporočilo ali prenesti datoteko slikovnega formata ter izpolniti količino sredstev v ETH, ki so mu pripravljeni podariti za rojstni dan. Prav tako se prijatelji na GiftCollectorju ne rabijo registrirati, saj lahko vnesejo samo svoje ime ali vzdevek. Po izpolnjevanju vseh nujnih podatkov jim GiftCollector Dapp ponudi v podpisovanje transakcijo, ki jo prijatelji potrdijo s svojo DD in s tem zaključijo pošiljanje daril. Slika 3: Sistemska arhitektura spletne aplikacije GiftCollector po principu Web 3.0 Vir: [7]. 4.3 Konceptualna primerjava Kot je razvidno iz opisne primerjave med Web 2 in Web 3 obstajajo tako razlike za razvijalce kot za uporabnike, pri čemer je za ene manj druge morda več, kar pa je seveda subjektivne narave in odvisno od posameznikov. Vsekakor predstavlja pristop Web 3 premik v novo smer in vpeljuje dodatne nove koncepte, kakor tudi nova orodja in postopke. Glede na dosedanja spoznanja predstavljamo v tabeli 1 nekaj ključnih konceptualnih primerjav med obema konceptoma. 23 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 5 Izzivi Web 3 Kot je že na kratko omenjeno v tabeli 1, obstajajo trenutno še številni izzivi, ki so povezani s konceptom Web 3 in preprečujejo splošno in masovno sprejetje le tega. V nadaljevanju na kratko predstavimo nekaj ključnih izzivov. Med prvimi izzivi Web 3 so vsekakor tisti, kateri so povezani s TVB, in sicer razširljivost ali skalabilnost. TVB temelji na številnih psevdonimnih uporabnikih, ki gostijo vozlišča verig blokov in s tem ponujajo svoje računalniške vire za zagotavljanje delovanja celotnega omrežja. S tem predvsem zagotovijo varnost omrežja, saj se podatki podvojeno hranijo na vseh vozliščih in tako preprečijo eno točko odpovedi. Takšen sistem pa ima številna ozka grla, ki rezultirajo v dejstvo, da se transakcije počasi izvršijo in da so stroški z vzdrževanjem sistema vedno večji. Obstajajo mehanizmi, ki lahko ozka grla odstranijo, vendar jih takšnih, ki ne bi vsaj rahlo vplivala na lastnost decentralizacije. Tako najdemo že danes določene verige blokov, ki so hitrejše od drugih, vendar je njihov nivo zagotavljanje ključne lastnosti Web 3, korenito nižji od prvotnih omrežij [8]. S TVB je povezan tudi izziv stroškov, saj se v primeru Web 3 aplikacij stanovitne transakcije morajo digitalno podpisati in plačati. To je vsekakor izziv za končne uporabnike, ki niso navajeni, da so za uporabo spletnih portalov primorani za vsako transakcijo sami plačevati, četudi zgolj nekaj centov. Določene Web 3 rešitve rešujejo izziv na način, da sami prevzamejo tvorjenje in podpisovanje ter plačevanje transakcij, kar pa seveda prenese stroške na njih in hkrati vpliva na varnost in lastnost decentralizacije. V veliki večini primerov se za takšne rešitev zahteva uporaba zalednih sistemov, ki se jih v osnovi želimo znebiti. Prav tako takšne rešitve vpeljujejo avtomatizirano potrjevanje transakcij, kar pa zahteva dostop do zasebnega ključa, ki nadzira digitalna sredstva itn. Povezano s prejšnjima izzivoma je vsekakor uporabniška (ne)prijaznost rešitev Web 3. Kot je predstavljeno v poglavju o primerjavi in v uporabniškem vidiku Web 3, morajo uporabniki Web 3 rešitev uporabljati namenske DD, si naložiti primerne kriptovalute in hkrati vsako stanovitno akcijo na spletnih portalih potrjevati oz. digitalno podpisovati. Številni koraki so že narejeni v smeri zagotavljanja večje uporabniške prijaznosti, vendar hitro pridemo do ključne trileme med varnostjo, učinkovitostjo in uporabniško prijaznostjo. Določeni snovalci Web 3 rešitev so šli korak »naprej« oz. »nazaj« k Web 2 principom, saj so omogočili samodejno potrjevanje transakcij in podobno, kar pa seveda vpliva na varnost in lastnost decentralizacije, zaradi katere se je Web 3 dejansko pojavil kot nov koncept. Glede na prejšnji predstavljen izziv, pa imamo po drugi strani člane skupnosti snovalcev in razvijalcev Web 3 rešitev, ki pa želijo doseči še višje nivoje zagotavljanja lastnosti decentralizacije in tako snujejo nove pristope, ogrodje in orodja, ki to dosegajo. S tem povezan je tudi izziv, kako in če sploh lahko dosežemo popolno decentralizacijo. Kot smo videli na primeru Dapp, ki je ponavadi gostovana na centralizirano upravljanih spletnih strežnikih in bi se lahko tudi gostila na IPFS ali podobnih omrežjih, vendar bi bila učinkovitost le te zelo nizka. Podobni izzivi so tudi na nivoju upravljanja s kriptografskimi nezamenljivimi žetoni NFT, ki bi naj hranili vse svoje komponente, podatke in metapodatke decentralizirano, vendar je tak pristop težko dosegljiv in neučinkovit. Tako najdemo številne NFT-je, kjer opažamo, da so določeni njihovi viri (npr. unikatna slika NFT-ja) hranjeni na centralizirano upravljanjem strežniku in bi se lahko le ti kadar koli »ugasnili« in tako pustili lastnike NFT-ja brez dejanskega vira vsebine. Podobni izzivi z zagotavljanjem popolne decentralizacije so tudi na nivoju decentraliziranih in samoupravljanih identitet idr., vendar jih zaradi fokusa članka ne bomo posebej izpostavljali. 24 M. Turkanović, V. Keršič, M. Šestak: Web 3 vs Web 2: Konceptualne in tehnološke razlike.. Tabela 1: Konceptualna primerjava med Web 2 in Web 3. Kriterij / Lastnost Web 2.0 Web 3.0 Fokus in prednost Interaktivnost in komunikacija, Decentralizacija, lastninjenje in nadzor uporabniška prijaznost, dinamična nad podatki, transparentnost, vsebina, deljenje informacij, realno- psevdonimnost, in necenzuriranost oz. časovna obdelava, pametne in mobilne nespremenljivost ter podpora novim naprave. načinom elektronskega poslovanja. Upravljanje Centralizirane entitete, kot so banke, Modeli upravljanja skupnosti (npr. DAO), vlade, ali korporacije nadzirajo delovanje, kjer se lahko vsak pridruži in vsi lahko storitve in podatke. prispevajo k odločanju glede upravljanja. Ključne in specifične Računalništvo v oblaku, spletne storitve, TVB, pametne pogodbe, Dapp, NFT, tehnologije aplikacijski vmesniki. IPFS, namenske DD. Varnost in zasebnost Korporacije sledijo uporabnikom in Varnost je urejena zgolj s tehnologijo in izkoriščajo njihove podatke za profiliranje, kriptografskimi elementi ter je bolj ali pri čemer so ponekod zakoni, ki to do manj v rokah končnih uporabnikov. neke mere preprečujejo. Varnost je bolj ali manj prepuščena ponudnikom storitev. Digitalne identitete V veliki meri psevdonimne in Decentralizirane digitalne identitete, ki jih centralizirane pri manjšemu številu uporabniki nadzirajo sami, pri čemer je korporacij, s podporo federativnim identiteta po-uporabna skozi večino Web modelov izkoriščanja digitalne identitete. 3 prostora. Stanje podatkov Nadzor nad podatki na strani lastnikov Nadzor nad podatki na strani lastnikov le spletnih portalov in platform. Lokacija teh in vseh vzdrževalcev porazdeljenih in podatkov je centralizirano upravljana, decentraliziranih omrežij. Lokacija četudi porazdeljena oblačna podatkov je porazdeljena med vsa infrastruktura. Čeprav so podatki varno vozlišča. Zaradi številne replikacije so hranjeni se iz vidika centraliziranega podatki na javnih omrežjih resnično upravljanja lahko smatrajo tudi kot stanovitni. nestanovitni. Podpora e-poslovanju Uveljavljene in učinkovite plačilne storitve Kripto valute in žetoni, ki niso nadzirani in plačilni prehodi (ang. gateway) na skozi uveljavljene centralizirane finančne osnovi centraliziranih finančnih struktur, strukture. Stroški so lahko manjši, vendar kjer se nudi podpora kreditnim karticam je učinkovitost iz vidika hitrosti trenutno in številnim fiat valutam. Stroški so večji slabša. Obstaja možnost ustvarjanja in obstajajo možnosti omejevanja poljubnih kripto žetonov in drugih transakcij s strani različnih finančnih ali mehanizmov, kot so NFT. državnih organov. Slabosti Varnost, saj temelji le ta na nekaj Kompleksnost s strani tehnične zasnove, centralizirano vodenih strežnikih kakor tudi uporabniške prijaznosti, s (oblakih), s čimer se ustvarjajo enojne čimer se omejuje masovno sprejemanje točke odpovedi. Zasebnost, saj lahko novih konceptov in tehnologij. Zahteva korporacijo izkoriščajo podatke svojih po več računalniških virih. Trenutno še uporabnikov, da jih profilirajo ali pa le te omejena zmožnost skalabilnosti. Težave z prodajo naprej. Korporacije ali vlade regulacijo, ki odvračajo številne poslovne lahko uporabnike blokirajo ali drugače uporabnike. Varnost je prepuščena cenzurirajo. končnim uporabnikom, ki lahko hitreje izgubijo svoja sredstva ali podatke in so pri tem nepovratno oškodovani. Med pomembne izzive štejemo tudi vpliv transparentnosti, preverljivosti in nespremenljivosti TVB na zasebnost uporabniških podatkov. Prej omenjene lastnosti onemogočajo uporabnikom možnost izbrisa podatkov v trenutku, ko so enkrat le ti potrjeno shranjeni na javni verigi blokov. To seveda vpliva na zmožnosti zagotavljanja pravice do pozabe, ki je pravica končnih uporabnikov glede na Splošno uredbo o varstvu osebnih podatkov (ang. General Data Protection Regulation – GDPR). Kljub temu je Web 3 skupnost naučila delovati s to pomanjkljivostjo TVB na način, da so se našli drugi mehanizmi za shranjevanje osebnih in drugih podatkov [9]. Posledica teh rešitev pa je ponovno prispevanje k uporabniški neprijaznosti, slabši učinkovitosti in nepopolnemu zagotavljanju lastnosti decentralizacije. 25 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 6 Diskusija Glede na kompleksnost nastalega področja Web 3 je težko predstaviti vse podrobnosti le tega. Prav tako je, zaradi novosti tehnologij na katerih temelji, še veliko stvari nedorečenih in neraziskanih. Sproti se pojavljajo in nastajajo novi trendi (glej poglavje 3.1) in s tem povezani koncepti, ogrodja in orodja, pri čemer pa še zmeraj nimamo enotne definicije, kaj Web 3 dejansko je. Dejstvo je, da je termin Web 3 leta 2014 vsekakor prvi skoval in uporabil soustanovitelj platforme verig blokov Ethereuma, Gavin Wood, pri čemer je le to povezoval s koncepti, ki smo jih predstavljali v članku [10]. Obstajajo pa določeni avtorji, ki Web 3 definirajo kot novo obdobje spleta, katerega ključni del je umetna inteligenca in strojno učenje. Prav tako smo že v članku omenjali, da se Web 3 zmotno enači s pojmom metaverzum. Tako se postavlja ključno vprašanje, kaj Web 3 dejansko predstavlja? Ali je to v resnici novo obdobje spleta, ki bo skoraj v celoti nadomestilo trenutne načine delovanja, enako kot smo bili priča prehodu med Web 1 in Web 2, ali pa bo to zgolj ena nova in dodatna oblika spleta, kateri se bomo lahko po želji pridružili, med tem ko bomo še naprej delovali po pristopih Web 2, ki bo zelo verjetno še obogaten s funkcionalnostmi umetne inteligence, strojnega učenja in obogatene in/ali navidezne resničnosti (Slika 4). Že sedaj vemo, da se Web 3 še nekaj časa ne bo dokončno definiral, saj se že sedaj kažejo dodatni novi trendi, ki bodo to področje obogatili. Prav tako pa lahko potrdimo, da Web 3 ni več zgolj obličje TVB, ni nujno zgolj aplikacija povezana s kripto valutami in/ali kripto žetoni (npr. NFT), temveč je lahko širok spekter spletnih rešitev, ki pa stremijo k vsaj delnemu zagotavljanju lastnosti decentralizacije. Slika 4: Razvoj spleta in vprašanje ali je Web 3 dejansko nova različica ali samo dodatna. 7 Zaključek V prispevku smo podrobno raziskali in primerjali koncepta Web 2 in Web 3, paradigmi spletnega razvoja, ki predstavljata dve različni viziji spletnega okolja. Web 2, že dolgo prevladujoča paradigma, se osredotoča na centralizirane platforme, ki imajo nadzor nad podatki in uporabniškimi izkušnjami. Nasproti temu stoji Web 3, nov val inovacij, ki temelji na decentralizaciji, transparentnosti in uporabniškem nadzoru. V članku smo predstavili ključne koncepte in tehnologije Web 3, kot so tehnologija veriženja blokov (TVB), decentralizirane identitete, pametne pogodbe in metaverzum. Poudarili smo tudi izzive, s katerimi se sooča Web 3 pri prehodu od koncepta do množične uporabe. Te vključujejo skalabilnost TVB, uporabniško prijaznost, stroške 26 M. Turkanović, V. Keršič, M. Šestak: Web 3 vs Web 2: Konceptualne in tehnološke razlike.. transakcij in vprašanja zasebnosti ter varstva podatkov. Kljub tem oviram, je Web 3 prinesel veliko novih priložnosti, ki omogočajo uporabnikom večji nadzor, transparentnost in možnost sodelovanja v digitalnem svetu. Razumevanje razlik med Web 2 in Web 3 je ključno za prihodnji razvoj spletnih tehnologij ter za ozaveščanje o novih priložnostih in izzivih, ki jih prinaša decentralizacija, transparentnost in uporabniški nadzor. Web 3 je vznemirljiv korak naprej, ki lahko preoblikuje način, kako razmišljamo in delujemo na spletu, ter nas popelje v novo dobo digitalne inovacije. Literatura [1] DI ANGELO Monika, SALZER Gernot, »Tokens, Types, and Standards: Identification and Utilization in Ethereum«, 2020 IEEE International Conference on Decentralized Applications and Infrastructures (DAPPS), Oxford, UK, 2020, str. 1-10, doi: 10.1109/DAPPS49028.2020.00001. [2] PODGORELEC Blaž, ALBER Lukas, ZEFFERER Thomas. »What is a (Digital) Identity Wallet? A Systematic Literature Review«, IEEE 46th Annual Computers, Software, and Applications Conference, 27 June –1 July 2022 Virtual Event : proceedings. Danvers: IEEE, cop. 2022. str. 809-818. ISBN 978-1-6654-8810-5. DOI: 10.1109/COMPSAC54236.2022.00131. [3] WANG Yuntao, idr., »A Survey on Metaverse: Fundamentals, Security, and Privacy«, IEEE Communications Surveys & Tutorials, letnik 25, številka. 1, str. 319-352, Firstquarter 2023, doi: 10.1109/COMST.2022.3202047. [4] ŠUPUK Abdurrahman. »Razvoj z NFT podprto Metaverse igro JumpSquad« : diplomsko delo, 2022, spletni vir https://dk.um.si/IzpisGradiva.php?id=83370. [5] ČUČKO Špela, TURKANOVIĆ Muhamed, »Decentralized and self-sovereign identity: systematic mapping study«, IEEE access, 4 Oktober 2021, letnik 9, str. 139009-139027, DOI: 10.1109/ACCESS.2021.3117588. [6] ČUČKO Špela, TURKANOVIĆ Muhamed, »Umestitev digitalnih (EU) denarnic v ekosistem sodobnih IKT rešitev«, OTS 2022 : sodobne informacijske tehnologije in storitve : zbornik petindvajsete konference, Maribor, Fakulteta za elektrotehniko, računalništvo in informatiko, 2022, str. 24-41. [7] ZAVRATNIK Jaka, »Analysis of the principles of the development of Web3 solutions« : master's thesis, 2022, https://dk.um.si/IzpisGradiva.php?id=83517. [8] CONNORS Collin, SARKAR Dilip, »Survey of prominent blockchain development platforms«, Journal of Network and Computer Applications, letnik 216, 2023, ISSN 1084-8045, DOI: https://doi.org/10.1016/j.jnca.2023.103650. [9] TURKANOVIĆ Muhamed, KEŽMAH Boštjan, PODGORELEC Blaž, KAMIŠALIĆ LATIFIĆ Aida, HERIČKO Marjana, HERIČKO Marjan, »Method and device for the storing, inspection control and retrieval of data from a permanently immutable, distributed and decentralized storage«, European Patent Specification EP 3 742 318 B1, 2021-03-17. Munich: European Patent Office, 2021. [10] EDELMAN Gilad, »The Father of Web3 Wants You to Trust Less«, Wired, ISSN 1059-1028, 2021, URL: https://www.wired.com/story/web3-gavin-wood-interview, obiskano 10. 6. 2023. 27 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 28 Hibridni certifikati post-kvantne kriptografije Nastja Cepak,1,2 Jakob Matek1 1 CREAPLUS d.o.o., Ljubljana, Slovenija nastja.cepak@creplaus.com, jakob.matek@creaplus.com 2 Univerza na Primorskem, Fakulteta za naravoslovje, informacijske tehnologije in informatiko, Koper, Slovenija nastja.cepak@creplaus.com Kvantni računalniki obetajo omogočiti izračune, ki jim niso kos niti današnji najmočnejši super računalniki. Razvoj kvantnih računalnikov in algoritmov pa bo tudi dosegel razvojno stopnjo, ko obstoječi varnostni mehanizmi ne bodo več nudili zaščite podatkov in digitalnega zaupanja. Pričakujemo, da se bomo v obdobju tranzicije s tradicionalnih asimetričnih kriptografskih algoritmov (RSA in ECC) na post-kvantne algoritme posluževali tako imenovanih »hibridnih rešitev«, torej rešitev, ki hkrati podpirajo klasično in post-kvantno kriptografijo. V prispevku se bomo osredotočili na hibridne digitalne certifikate in bomo prikazali, kako lahko integriramo post-kvantne algoritme v x509 format digitalnih certifikatov. Ključne besede: kvantno računalništvo post-kvantna kriptografija crytsals-dilithium digitalna potrdila hibridna potrdila ISBN 978-961-286-772-0 DOI https://doi.org/10.18690/um.feri.8.2023.3 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 1 Uvod Kvantna teorija je znanstveno področje, ki ponuja dober matematični model za opis narave na atomski in subatomski ravni. Na podlagi teh teorij in načel rase področje kvantnega računalništva. Kar se je včasih zdelo kot znanstvena fantastika, postaja naša resničnost. Njegovi začetki segajo približno 40 let v preteklost, ko je Paul Benioff leta 1980 opisal Turingov stroj s kvantno mehaniko [6]. Kmalu zatem, leta 1982, je Richard Feynman predlagal prvo praktično uporabo tovrstnih strojev – simulacijo kvantne mehanike [7], kar bi imelo velik vpliv na biologijo in kemijo. Resnično zanimanje za kvantno računalništvo pa se je sprožilo leta 1994, ko je Peter Shor razvil algoritem, ki bi kvantnim računalnikom omogočil učinkovito faktorizacijo velikih celih števil. To je algoritem s potencialom razbijanja šifriranj RSA in ECC, algoritmov, na katera se zanašajo številni kriptosistemi. Namesto da bi za faktorizacijo 300-mestnega števila potrebovali milijone let, bi ga Shorov algoritem lahko faktoriziral v nekaj dnevih. Kmalu zatem, leta 1996, je Lov Grover zasnoval Groverjev iskalni algoritem, ki omogoča uporabo kvantnih računalnikov za zagotavljanje kvadratne pospešitve iskanja v primerjavi s tradicionalnimi iskalnimi algoritmi. Prečesavanje celotnega prostora ključev v napadu s surovo silo, kjer iščemo šifrirni ključ, bi nenadoma postalo veliko lažje. Za lažjo predstavo vpliva napadov s kvantnimi računalniki na danes uporabljene kriptografske algoritme prilagamo spodnjo tabelo 1. Tabela 1: Število bitov varnosti asimetričnih in simetričnih algoritmov danes in ob uproabi Shorjevega/Groverjevega algoritma na dovolj zmogljivem kvantnem računalniku Algoritem Število bitov varnosti Število bitov varnosti z uporabo (danes) Shorjevega/Groverjevega algoritma na kvantnem računalniku RSA-1024 80 0 RSA-2048 112 0 ECC-256 128 0 ECC-384 256 0 AES-128 128 64 AES-256 256 128 Kvantni računalniki nenadoma niso bili samo predmet akademske radovednosti, temveč dobro financirane vladne in zasebne raziskave. Napredek, ki je sledil v naslednjih desetletjih, je odraz na novo ustvarjenega zanimanja. Trenutno eno vodilnih podjetij na kvantnem področju, IBM, napoveduje za leto 2023 otvoritev 1121-qbitnega procesorja Condor, pripravljen pa imajo tudi načrt za hitro višanje števila qbitov v naslednjih letih, do leta 2026 [8]. Takoj se postavi sledeče očitno in pomembno vprašanja: Kdaj bodo obstajali kvantni računalniki, ki bodo lahko, na primer, dovolj zmogljivi, da bi zaganjali Shorjev algoritem, ki bo lahko razbil algoritem RSA-2048? Leta 2019 sta Michele Mosca in Marco Piani napisala poročilo o časovnem načrtu kvantne grožnje za Global Risk Institute [10]. Poročilo vključuje anketo, izvedeno med 22 vodilnimi mednarodnimi strokovnjaki za raziskave kvantnega računalništva. Eno od vprašanj v anketi je bilo navesti verjetnost, da bo kvantnemu računalniku uspelo razbiti RSA-2048 v 24 urah v 5/10/15/20/30/30+ letih. Na sliki 1 so prikazane približne vrednosti prejetih odgovorov. Vidimo, da čeprav obstaja le malo prepričanja, da nas bo grožnja kvantnega napada v naslednjih nekaj letih ujela nepripravljene, se ideja, da bo v naslednjih 20 letih obstajal kvantni računalnik, ki bo lahko zlomil naše varnostne algoritme, zdi precej verjetna. Za ohranitev naše digitalne varnosti v prihodnosti so raziskovalne ustanove že pred več kot desetletjem začele razvijati kvantno odporne kriptografske algoritme. Trenutno najboljši od tako 30 N. Cepak, J. Matek: Hibridni certifikati post-kvantne kriptografije.. imenovanih algoritmov za postkvantno kriptografijo (Post Quantum Cryptography - PQC) tekmujejo za kvalifikacijo za NIST (National Institute for Standards and Technology, ZDA) standardizacijo v okviru projekta “Post-Quantum Cryptography Standardization” [11]. Slika 1: Kumulativna verjetnost za obstoj kvantnega računalnika, ki bi lahko zlomil RSA-2048 v 24 urah Vir: [10]. 2 Post-kvantna kriptografija Ko govorimo o algoritmih post-kvantne kriptografije, govorimo o asimetirčnih algoritmih, ki jih zaganjamo na standardnih digitalnih računalnikih, kot jih poznamo danes, hkrati pa so odporni tako na tradicionalne napade, kot na napade, ki bi se jih zaganjalo na kvantnih računalnikih. Njihov namen je, da v prihodnosti zamenjajo algoritma RSA in ECC. Proces standardizacije post-kvantne kriptografije NIST se je začel konec leta 2016 z javnim pozivom NIST za oddajo predlogov. Novembra 2017 je bil rok za oddajo predlogov algoritmov. Od 82 predloženih kandidatov je bilo 13 skoraj takoj zlomljenih ali pa so vsebovali drugačne pomanjkljivosti. Tako je bilo decembra 2017 v prvi izbirni krog sprejetih skupno 69 kandidatov. Nekaj mesecev za tem, aprila 2018, je potekala 1. standardizacijska konferenca NIST PQC, kjer so o algoritmih in potencialnih napadih nanje razpravljali raziskovalci iz NIST in širše akademske skupnosti. V začetku leta 2019 je bilo izbranih 26 kandidatov za nadaljevanje v 2. krog, čemur je sledila 2. konferenca o standardizaciji NIST PQC, ki je potekala še isto poletje. 22. julija 2020 je bilo razglašenih 7 finalistov 3. kroga. NIST je tudi javno objavil poročilo o izbirnem postopku. Končno, 5. julija 2022, so bili objavljeni štirje algoritme, ki bodo standardizirani, in kandidati za četrti krog. Končnih standardov še nimamo, pričakujemo pa jih začetek leta 2024. Ena od omejitev, ki jih še nismo uspeli preseči pri algoritmih post-kvantne kriptografije, je, da algoritmi (še) niso dovolj prilagodljivih, da bi hrkati lahko učinkovito izvajali operacije šifriranja z javnim ključem in digitalnega podpisovanja. Zato je tekmovanje ločeno na 2 kategoriji, kot je prikazano v tabeli 2. 31 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Tabela 2: Finalisti in kandidati za 4. krog NIST PQC tekmovanja. Šifriranje z javnim ključem Digitalni podpisi Finalisti, ki CRYSTALS-DILITHIUM bodo CRYSTALS-KYBER FALCON standardizirani SPHINCS+ Kandidati za 4. BIKE krog Classic McEliece / HQC Kot pripombo bi dodali, da je tehnično gledano še vedno kandidat za 4. krog tudi algoritem SIKE (šifriranje z javnim ključem), vendar je bil avgusta 2022 zlomljen na način, da manjši popravki niso dovolj za varno delovanje. Zaradi tega ga nismo dodali v tabelo. Zanimanje našega projekta leži v digitalnih certifikatih in njihovi hibridiziraciji, torej postopku, ki tradicionalnemu certifikatu doda post-kvantno komponento. Zaradi tega smo se osredotočili na algoritem CRYSTALS-DILITHIUM, ali na kratko, Dilithium. Je najbolj priporočen algoritem za implementacijo PQ digitalnih certifikatov [12]. 2.1 CRYSTALS-DILITHIUM CRYSTALS-DILITHIUM je asimetrični kriptografski algoritem za digitalno podpisovanje, ki je odporen tako na tradicionalne napade, kot na napade, ki bi jih lahko zaganjali na kvantnem računalniku. Prvič je bil uradno definiran leta 2017 [13, 14] kot prijava v prvi krog NIST PQC tekmovanja. CRYSTALS ekipa je v tistem času definirala dva algoritma: CRYSTALS-DILITHIUM, ki je namenjen digitalnemu podpisovanju in čigar ime je referenca na material dilithium iz Star Treka. Drugi algoritem, ki je bil prav tako izbran za standardizacijo, je CRYSTALS-KYBER, namenjen šifriranju in z imenom, ki je referenca na kyber kristal iz Star Wars. Kot opisano v [13], Dilithium temelji na težavnosti problema iskanja kratkih vektorjev v mrežah. Zasnova sheme temelji na pristopu "Fiat-Shamir with Aborts" [15], ki z zavračanjem vzorcev (rejection sampling) poskrbi, da je Fiat-Shamir shema bolj kompaktna in varnejša. Za lažje ne-matematično razumevanje algoritma prilagamo sliko 2 s pseudokodo funkcionalnosti. Pri implementaciji hibridnih certifikatov uporabljamo vse tri funkcionalnosti (generacijo ključa, podpisovanje, verificiranje). Slika 2: Preudokoda funkcionalnosti Dilithium algoritma Vir: [13]. 32 N. Cepak, J. Matek: Hibridni certifikati post-kvantne kriptografije.. 3 Digitalni certifikati Digitalno certifikat je oblika elektronske poverilnice, ki lahko dokaže pristnost uporabnika, naprave, strežnika, spletne strani ali katerekoli druge entitete. Uporablja tako imenovano infrastrukturo javnih ključev (Public Key Infrastructure), ki jo bomo za voljo koherentnosti članka tu le na kratko opisali, za varno izmenjavo komunikacij in podatkov prek interneta in drugih omrežij. Ta oblika avtentikacije je vrsta kriptografije, ki zahteva uporabo javnih in zasebnih ključev, ki enolično pripadata eden drugemu, za preverjanje identitete uporabnikov. Digitalne certifikate izdajo zaupanja vredne tretje osebe (Certificate Authority, v nadaljevanju tudi CA), ki podpiše potrdilo in tako preveri identiteto naprave ali uporabnika, ki zahteva dostop. Za zagotovitev veljavnosti bo javni ključ usklajen z ustreznim zasebnim ključem, ki ga pozna samo prejemnik. Digitalna potrdila imajo določen par ključev, s katerim so povezana: enega javnega in enega zasebnega. Danes so tako rekoč vse postavljene PKI infrastrukture uporabljajo ali RSA algoritem, ali ECC algoritem, ki pa bosta zlomljena s prihodom dovolj zmogljivega kvantnega računalnika. Naj hitro opišemo nekaj primerov uporabe, s katerimi se srečujemo vsak dan in pri katerih stojijo v ozadju digitalni certifikati, da bolje razumemo, zakaj iščemo načine, da ostanejo varni tudi po prihodu kvantnih računalnikov. Na naši novi elektronski osebni izkaznici so nameščeni trije digitalni certifikati za različne namene uporabe. Ko se prijavljate v online banko, je velika možnost, da za vašo prijavo stoji digitalni certifikat. Ko se povezujete na spletno stran, se velik del spletnih strani v ozadju najprej identificira vašemu brskalniku, da pokažejo, da so varne. Ko nameščate novo programsko opremo, je ta običajno podpisana z zasebnim ključem proizvajalca. Če vaš operacijski sistem prepozna odgovarjajoči digitalni certifikat, bo samodejno zaupal tudi podpisani kodi. Glavno vprašanje, ki ga želimo nasloviti, je sledeče. Do časa, ko bodo aplikacije namesto RSA in ECC uporabljale izključno PQC standardizirane algoritme, bo minilo še kar nekaj časa. Po priporočilih ZDA [12], Nemčije [16] in Francije [17] bi se sicer ta preskok moral zgoditi v prvi polovici 30. let (2030-2035). V vmesnem obdobju bomo potrebovali digitalne certifikate, s katerimi bomo lahko hkrati upravljali tradicionalne/legacy kriptografske aplikacije, hkrati pa se bomo lahko identificirali novim aplikacijam, ki podpirajo prioritetno ali izključno PQC algoritme. Kako takšne hibridne certifikate učinkovito zasnovati? 3.1 Hibridni certifikati V magistrski nalogi leta 2020 Univerze v Barceloni [9] so bili zelo jasno predstavljeni 4 različni pristopi k hibridizaciji digitalnih potrdil. Vse štiri bomo površinsko predstavili, za našo implementacijo pa smo uporabili mešanico pristopa z ugnezdenimi certifikati in pristopa razširitev po meri. Cilj je modificirati standardiziran x509 certifikat na takšen način, da sta v praksi v njemu vključena 2 certifikata: prvi, ki vsebuje podpis s tradicionalnimi kriptografskimi algoritmi, in drugi, ki vsebuje post-kvantni podpis. Hkrati želimo, da certifikat ohranja dovolj uniformno obliko, da je kompatibilen s trenutno uveljavljenimi CA strukturami. Osnovna struktura x509 certifikata je opisana na sliki 2. 33 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Slika 2: Struktura x509 certifikata Vir: [18]. 3.1.1 Dualni certifikati Najpreprostejša metoda hibridizacije je izdaja dveh potrdil, ki sta nato vedno predstavljeni v paru. Prvo potrdilo je izdano z uporabo tradicionalnega algoritma, drugo pa z uporabo post-kvantnega [19]. Obe sta podpisani z istim CA sistemom, vendar z uporabo drugačne sheme podpisovanja (konvencionalne oziroma PQ). Pomanjkljivost te metode je, da imata lahko potrdili drugačne datume veljavnosti ter da je potrebno njuno ločeno upravljanje. Vsi sistemi morajo vzdrževati obe različici potrdila in velikost datoteke skupnega certifikata je večja zaradi podvojenih informacij in parametrov. 3.1.2 Konkatenacija Ideja konkatenacije certifikatov prihaja iz projekta Open Quantum Safe [20]. Uvedemo lahko nov identifikator objekta OID (Object Identifier), ki predstavlja, na primer, kombinacijo algoritmov RSA in Dilithium. Nato konkateniramo bajtna zapisa obeh javnih ključev v en velik javni ključ, ki ga nato lahko zapišemo v x509 certifikat. Če takšen certifikat nato obdeluje programska oprema, ki prepozna naš novi OID, natanko ve, kaj mora narediti z velikim javnim ključem - kako ga razbiti na dva ločena javna ključa in nato po potrebi uporabljati ali RSA, ali Dilithium. Čeprav je ta pristop združljiv z x509 standardom, ni združljiv s starejšimi aplikacijami, ker te ne prepoznavajo nove OID oznake. 3.1.3 Ugnezdeni certifikati Drugačna različica dualnih potrdil je gnezdenje enega potrdila znotraj drugega potrdila ko razširitev po meri [21]. Najprej ustvarimo potrdilo z javnim post-kvantnim ključem in generiramo post-kvantni podpis, ki ga obravnavamo kot notranji certifikat. Nato ustvarimo potrdilo s tradicionalnim javnim ključem, ki predstavlja zunanje potrdilo, bajtni zapis notranjega potrdila pa je shranjen v razširitvi po meri zunanjega potrdila. Pri tem pristopu se podatki o predmetu še vedno podvajajo, vendar je celotno potrdilo združljivo s starejšimi aplikacijami, če je razširitev označena kot nekritična. Starejša programska oprema ignorira razširitev po meri z notranjim post-kvantnim potrdilom in preveri le zunanje tradicionalno potrdilo. 34 N. Cepak, J. Matek: Hibridni certifikati post-kvantne kriptografije.. Za realizacijo tega pristopa v širšem kontekstu programske opreme, ki jo zahteva uporaba infrastrukture javnih ključev, sta potrebni dve certifikacijski avtoriteti. Ena za izdajo in verifikacijo post-kvantnih certifikatov in druga za tradicionalne algoritme. S certifikatoma morata podvojeno upravljati obe avtoriteti. 3.1.4 Razširitve po meri Pristop razširitve po meri je zelo podoben gnezdenju certifikatov. Da bi se izognili dodatnim stroškom podvojenih predmetnih polj, je bilo predlagano samo hranjenje dodatnega javnega ključa in dodatnega podpisa v dveh po meri razširitvah [21]. To prinaša sicer tudi nekaj pomanjkljivosti. Za realizacijo tega pristopa v infrastrukturi javnih ključev je potrebna ena certifikacijska avtoriteta, ki zna upravljati tako s podpisi post-kvantnih algoritmov, kot s konvencionalnimi RSA podpisi. Upravljanje s certifikati je v tem primeru lažje. 4 Implementacija Cilj projekta je implementirati sistem, ki ga je mogoče dodati k že obstoječi infrastrukturi javnih ključev z minimalnimi spremembami. Za ta namen sta primerna le dva od omenjenih pristopov hibridizacije certifikatov v poglavju 3. Pristop dualni certifikati (3.1.1) bi zaradi popolne ločitve konvencionalnih in PQ certifikatov omogočal postavitev vzporedne infrastrukture javnih ključev, ki bi temeljila na PQ algoritmih. Enako bi omogočal tudi pristop ugnezdenih certifikatov (3.1.3). Da pa bi se izognili lastnosti velikih datotek, ki jih prinese slednji in lastnosti razdružljivosti PQ in konvencionalnih certifikatov v pristopu dualnih certifikatov (3.1.1), smo združili pristop ugnezdenih s pristopom razširitev po meri (3.1.4). Velikost certifikatov smo nekoliko zmanjšali z idejo deljenih x509 atributov med PQ in konvencionalnim podpisom. Med tem, ko so v pristopu ugnezdenih certifikatov vsi atributi podvojeni, smo podvojili le x509 atribute, ki jih na certifikat doda certifikacijska avtoriteta. Ne-razdružljivost pa je zagotovljena z uporabo x509 razširitev po meri (custom extensions). Z našim mešanim pristopom lahko PQ del samostojno predstavlja svoj podpis, iz hibridnega certifikata pa je nemogoče izvleči posamezne dele podatke/ključe/podpis na ta način, da bi lahko dobili samostojen tradicionalni certifikat. To je želena lastnost, ker je na tak način hibridnemu certifikatu nemogoče odvzeti PQ del, kar bi znižalo pričakovano varnost hibridnega certifikata. 4.1 Orodja Za postavitev testne infrastrukture javnih ključev smo postavili enostavno certifikacijsko avtoriteto z uporabo OpenSSL 3.0.7, v nadaljevanju CA. Orodje OpenSSL je uporabljeno za generacijo CA ključa in certifikata ter za nadaljnjo izdajanje uporabniških certifikatov. V konfiguraciji CA je potrebno omogoči razširitve po meri, ki jih uporabljamo za gnezdenje PQC vsebine v x509 certifikat. Za postavitev alternativne PQC certifikacijske avtoritete, v nadaljevanju PQCA, smo razvili orodje HCTool (4.2), ki je med drugim sposobno generirati PQC del certifikata in ga vgraditi v konvencionalno CSR zahtevo, ki je nato poslana na CA. 35 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 4.2 Orodje za upravljanje s hibridnimi certifikati HCTool HCTool je orodje, ki smo ga razvili za upravljanje s hibridnimi certifikati. Orodje ja napisano v Python jeziku, ki smo ga za izbrali zaradi že obstoječih knjižnic in kompatibilnostjo z različnimi operacijskimi sistemi. Uporabili smo različico Python 3.10.5. Za delo s konvencionalnimi šifrirnimi algoritmi, certifikacijskimi zahtevami in x509 certifikati smo uporabili knjižnico cryptography [23]. Za delo s PQC algoritmi smo uporabili knjižnico liboqs-python [24] različico 0.8.0, ki je del Open Quantum Safe Projekta [25]. Za uporabo ustvarjenih Python funkcij preko CLI vmesnika, smo uporabili knjižnico Typer [26] različico 0.9.0. Implementirali smo sledeče funkcije: • Generate_PQ_Key(algorithm, passphrase, outDir) --> Par PQC ključev Ustvari par ključev z izbranim PQ algoritmom. • Generate_Con_Key(algorithm, passphrase, outDir) --> Par RSA ali EC ključev Ustvari par ključev z izbranim konvencionalnim algoritmom. • Generate_PQ_CSR(PQKey, ConKey.Public, SubjectData) --> PQCSR zahteva Sestavi PQCSRzahtevo, opisano v poglavju 4.3. • Generate_PQ_Cerificate_Block(PQCSR, PQKey.Public, IssuerData) --> PQCB Podpiše PQCSR in sestavi PQCB certifikat, opisan v 4.3. • Verify_PQ_Certificate_Link(PQCB, PQKey.Pub) --> bool Preveri, ali je bil certifikat PQCB podpisan s privatnim ključem, ki pripada ključu PQKey.Public. • Generate_CSR(PQCB, ConKey.Private) --> x509 CSR Ustvari konvencionalno x509 CSR zahtevo. • Verify_Certificate(Certificate, IssuerCertificate, PQIssuerCertificate) -> bool Preveri, ali je hibridni certifikat podpisan s podanim PQ cerifikatom in/ali je podpisan s podanim konvencionalnim certifikatom. Slika 3: HCTool orodje 36 N. Cepak, J. Matek: Hibridni certifikati post-kvantne kriptografije.. 4.3 Izdajanje hibridnega certifikata Proces izdajanja hibridnega certifikata je ponazorjen na sliki 4. Slika 4: Proces izdajanja hibridnega certifikata Za lažje razumevanje oznak v nadaljevanju dodajamo opombo, da so uporabljeni izrazi kot so Issuer, Validity, Serial, CA, CSR, TBS, itd. uporabljeni v kontekstu x509 standarda in konvencionalne infrastrukture javnih ključev (PKI). Ko želimo poudariti, da so Issuer, Validity, CA, itd vezani na post-kvantni del izdaje certifikata, je dodana predpona PQ (npr. PQCSR, PQCA, PQTBS, itd.). Za izdajanje hibridnega certifikata je uporabljeno orodje HCTool. Uporabnik, ki zahteva certifikat (requestor) najprej ustvari par konvencionalnih ključev, v nadaljevanju ConKey (ConKey.Private in ConKey.Public) in par ključev, ki temelji na PQC algoritmih, v nadaljevanju PQKey (PQKey.Public in PQKey.Private). Istočasno se tudi odloči za algoritme samih ključev. Podprti so konvencionalni algoritmi RSA in EC ter sledeči PQC algoritmi: • Dilithium 2, 3 in 5, • Falcon 512 in 1024, • SPHINCS+ s Haraka, SHA in SHAKE zgoščevalnimi (hash) algoritmi. 37 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Uporabnik nato določi x509 atribute, ki bodo vstavljeni v CSR zahtevo. S pomočjo orodja HCTool nato ustvari PQCSR, torej zahtevo za podpis s PQC algoritmom, ki ga izda PQCA. Zahteva je sestavljena iz podatkov o subjektu, javnim ključem konvencionalnega algoritma, javnim ključem PQC algoritma in dodatnih x509 razširitev, ki so želene v končnem certifikatu. Ti podatki so konkatenirani in podpisani s PQC privatnim ključem PQKey.Private. Podpis, v nadaljevanju PQCSR.Signatue, je dodan v PQCSR. PQCSR zahteva je nato poslana na PQCA za podpis. PQCA preveri PQCSR.Signature podpis s podatki v PQCSR in javnim ključem PQKey.Public, ki ga zahteva vsebuje. Uspešno preverjen podpis dokazuje, da si subjekt, ki certifikat zahteva, tudi lasti privatni ključ PQKey.Private. V primeru neuspešno preverjenega podpisa PQCSR:Signature, PQCA zavrne zahtevo. V nasprotnem primeru PQCA določi alternativno veljavnost certifikata, v nadaljevanju PQValidity, določi atribut PQIssuer, ki identificira PQCA, in PQSerial, ki je številka uporabljena za upravljanje s certifikati. Nato PQCA sestavi podatke, ki bodo podpisani, v nadaljevanju PQTBS (to be signed). PQTBS podatki so sestavljeni iz vseh podatkov, ki so vključeni v PQCSR, razen PQCSR.Signature. V PQTBS so dodani atributi PQValidity, PQIssuer, PQSerial. PQTBS podatki so nato podpisani s privatnim ključem PQCA (PQCA.PQKey.Private). Podpis, v nadaljevanju PQSignature, in PQTBS podatki so združeni v “PQ Certifikat”, v nadaljevanju PQCB (PQ Certificate Block), in poslani uporabniku, ki je zahteval certifikat. Uporabnik nato preveri PQSignature podpis s podatki v PQCB in v naprej deljenem PQ certifikatu, ki pripada PQCA avtoriteti. V primeru uspešnega preverjanja uporabnik sestavi konvencionalno x509 CSR zahtevo. Zahteva je sestavljena v skladu z x509 standardom s podatki, ki so bili določeni za PQCSR. PQKey.Public in podatki, ki so bili dodani v PQCB s strani PQCA so dodani v konvencionalno zahtevo kot razširitve po meri (Custom x509 extensions). CSR zahteva je nato poslana na konvencionalno certifikacijsko avtoriteto (CA). CA nato preveri podpis v CSR zahtevi in v primeru uspešnega preverjanja izda x509 certifikat, ki je poslan uporabniku. Uspešno preverjen podpis dokazuje, da si uporabnik, ki zahteva certifikat, tudi lasti ConKey.Private. Politika na CA je nastavljena tako, da se razširitve po meri, ki so vključene v CSR, kopirajo v certifikat. OID številke uporabljene za x509 razširitve po meri so nanizane v Tabeli 3. Tabela 3: Uporabljene OID številke. OID Vrednost 0.0.0.1 Alternativni PQC Algoritem 0.0.0.2 Alternativni PQC Javni Ključ 0.0.0.3 Alternativna Veljavnost 0.0.0.4 Alternativni Izdajatelj (Issuer) 0.0.0.5 Alternativna Serijska Številka 0.0.0.6 Alternativni PQC Podpis 5 Zaključek V članku smo opisali postopek generacije hibridnega certifikata, ki ga je mogoče integrirati z obstoječim tradicionalnim PKI sistemom. Razvito je bilo orodje HCTool, ki s pomočjo PQC in konvencionalnih kriptografskih knjižnic omogoča upravljanje hibridnih certifikatov. V prihodnje načrtujemo integracijo orodja v manjše aplikativne projekte ter benchmark različnih implementacij kot del real-life rešitev. 38 N. Cepak, J. Matek: Hibridni certifikati post-kvantne kriptografije.. Literatura [1] Sodobne tehnologije in storitve OTS 2022: Zbornik petindvajsete konference. Maribor 2022. [2] PODGORELEC Vili, HERICKO Marjan »Estimating software complexity from UML models », SIGSOFT Software Engineering Notes, letnik 32, številka 2, marec 2007, str. 31-38. [3] JOSEPH David, MISOCZKI Rafael, MANZANO Marc, et.al. »Transitioning organizations to post-quantum cryptography », Nature 605, 237–243 (2022). https://doi.org/10.1038/s41586-022-04623-2 [4] ALAGIC Gorjan, APON Daniel, COOPER David, et.al. »Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process«, NIST, Julij 2022, https://doi.org/10.6028/NIST.IR.8413-upd1 [5] SCHEIBLE Patrik »Quantum Resistant Authenticated Key Exchange for OPC UA using Hybrid X.509 Certificates«, Master thesis, UNIVERSITAT POLITÈCNICA DE CATALUNYA BARCELONA, april 2022, http://hdl.handle.net/2117/191775 [6] Paul BENIOFF »The computer as a physical system: A microscopic quantum mechanical Hamiltonian model of computers as represented by Turing machines«. Journal of Statistical Physics, 22 (5), 1980, 563–591. [7] Richard FEYNMAN »Simulating Physics with Computers«. International Journal of Theoretical Physics «. 21 (6/7), 1982, 467–488. [8] IBM’s Roadmap For Scaling Quantum Technology https://www.ibm.com/blogs/research/2020/09/ibm-quantum- roadmap/ [9] SCHEIBLE Patrik »Quantum Resistant Authenticated Key Exchange for OPC UA using Hybrid X.509 Certificates», magistrska naloga, UNIVERSITAT POLITÈCNICA DE CATALUNYA BARCELONATECH, Barcelona, 2020 https://upcommons.upc.edu/bitstream/handle/2117/191775/thesis_patrik_scheible.pdf?sequence=1 [10] MOSCA Michele, PIANI Marco » Quantum Threat Timeline « October 2019 https://globalriskinstitute.org/publications/quantum-threat-timeline/ [11] Post-Quantum Cryptography Standardization https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization [12] Announcing the Commercial National Security Algorithm Suite 2.0 https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF [13] DUCAS Léo, KILTZ Eike, LEPOINT Tancrède et al. »CRYSTALS-Dilithium: A Lattice-Based Digital Signature Scheme«, IACR Transactions on Cryptographic Hardware and Embedded Systems (2018): 238-268 [14] Official “CRYSTALS - Cryptographic Suite for Algebraic Lattices” webpage https://pq-crystals.org/dilithium/resources.shtml [15] LYUBASHEVSKY Vadim »Fiat-Shamir with aborts: Applications to lattice and factoring-based signatures« ASIACRYPT, pp. 598–616, 2009. 2, 20 [16] https://dserver.bundestag.de/btd/19/252/1925208.pdf [17] ANSSI views on the Post-Quantum Cryptography transition https://www.ssi.gouv.fr/en/publication/anssi-views-on-the-post-quantum-cryptography-transition/ [18] X.509 Public Key Certificates, Microsoft https://learn.microsoft.com/en-us/windows/win32/seccertenroll/about-x-509-public-key-certificates [19] BINDEL Nina, HERATH Udyani, MCKAGUE Matthew, STEBILA Douglas »Transitioning to a Quantum-Resistant Public Key Infrastructure« Post-Quantum Cryptography, Springer International Publishing, 2017, pp. 384– 405, isbn: 978-3-319-59879-6 [20] STEBILA Douglas, MOSCA Michele »Post-quantum Key Exchange for the Internet and the Open Quantum Safe Project« Lecture Notes in Computer Science, 2017, DOI: 10.1007/978-3-319-69453-5_2 [21] BINDEL Nina, BRAUN Johannes, GLADIATOR Luca, STOCKERT Tobias, WIRTH Johannes »X.509-Compliant Hybrid Certificates for the Post-Quantum Transition« Journal of Open Source Software, vol. 4, no. 40, p. 1606, 2019, issn: 2475-9066. doi: 10.21105/joss.01606. [22] GLADIATOR Luca, »Hybrid Certificates in OpenSSL«, GitHub, 2019. [Online]. Available: https://github.com/CROSSINGTUD/openssl-hybrid-certificates/blob/OQS-OpenSSL_1_1_1- stable/HybridCert_technical_documentation.pdf [23] Python knjižnica “Cryptography”: https://cryptography.io/en/ 39 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. [24] Python knjižnica “liboqs-python”: https://github.com/open-quantum-safe/liboqs-python/releases/tag/0.8.0 [25] “Open Quantum Safe” projekt: https://openquantumsafe.org/ 40 Nadgradnja obstoječega sistema za neprekinjeno integracijo in dostavo Martin Potrč, Nejc Maleš, Matjaž Matjašec, Dušan Bratuša Novum-RGI Germany GmbH Podružnica Maribor, Maribor, Slovenija martin.potrc@novum-rgi.si, nejc.males@novum-rgi.si, matjaz.matjasec@novum-rgi.si, dusan.bratusa@novum-rgi.si V podjetju smo se odločili za nadgradnja orodja Jenkins iz različice 1 v različico 2 z namenom uvajanja metodologije zaporednega izvajanja podprocesov grajenja aplikacij, ki omogoča vzporedno delovanje in s tem povečuje učinkovitost. Ta nadgradnja je prinesla številne prednosti, med njimi boljši pregled in organizacijo opravil, ter olajšano odkrivanje in reševanje napak v programski kodi. Vizualizacija projektnih odvisnosti omogoča globlje razumevanje povezav med projekti. Kljub prednostim so se pojavili tudi izzivi. Med njimi so se izpostavljali potreba po poenotenju procesov med različnimi projekti in prehod s tradicionalnega načina konfiguracije na uporabo programske kode za določanje procesov. Ta prehod je zahteval prilagoditev miselnosti in učenje novih pristopov v upravljanju orodja. Ključne besede: Jenkins neprekinjena dostava neprekinjena integracija vzporedno izvajanje DevOps programska konfiguracija cevovod vozlišče ISBN 978-961-286-772-0 DOI https://doi.org/10.18690/um.feri.8.2023.4 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 1 Uvod Sistem za neprekinjeno integracijo in dostavo je eden izmed ključnih delov razvojnega procesa. Zagotavlja nam dodatno mero varnosti pri integraciji programske kode in obenem združuje informacije potrebne za analizo težav, ki lahko občasno nastanejo ob le tej. Skozi zadnja leta je prišlo do sprememb pri procesu neprekinjene integracije. Uvedli so se novi postopki, ki so se bolje obnesli pri grajenju modernih aplikacij, pri katerih je za grajenje bilo potrebno izvesti več različnih faz. V našem podjetju smo se tega lotevali z nadgradnjo procesa, ki smo ga že imeli in skušali proces grajenja aplikacij v več fazah nekako vzpostaviti z gradniki, ki so na voljo. To nam je skozi leta sicer dobro služilo ampak je postalo z uvedbo novih projektov domala nevzdržno. Za vsako novo stranko, za katero smo morali zgraditi aplikacijo, je bilo potrebno vzpostaviti proces grajenja: • testiranje enot (angl. unit testing), • dnevna namestitev (angl. daily build), • test grafičnega vmesnika (z orodjem Selenium), • izdaja posodobitev (angl. release). To je posamezniku vzelo kar nekaj časa, saj je vzpostavitev tega procesa potekala bolj ali manj ročno. Rešitev se je ponudila v obliki neprekinjene dostave in podpore v novejši različici Jenkins CI. Ovrednotili smo več alternativnih rešitev, ampak na koncu smo se odločili za Jenkins, saj nam je ponujal celostno rešitev našega problema. Prav tako smo že vrsto let uporabljali Hudson CI nato njegov derivat Jenkins CI in to nam je dalo dodatno zaupanje v to odločitev. Taka odločitev je seveda zelo pomembna, saj sistema za proces integracije izvorne kode v podjetjih načeloma na menjujemo prav pogosto. Odločitev za uporabo Jenkins CI se je na koncu izkazala kot primerna. Prehod na novo različico ter na nov način grajenja je trajal kar nekaj časa in še ni popolnoma končan. Prestaviti je bilo potrebno približno 80 Jenkins opravil, med katerimi so bila opravila za izvajanje testov, dnevnih namestitev ter opravila za grajenje paketov za izdajo. Slednja so povzročala največ težav in so še zmeraj v fazi postopnega prestavljanja na nov proces. 2 Neprekinjena integracija, dostava in namestitev Neprekinjena integracija (angl. continuous integration) je proces sprotne integracije (vsaj enkrat na dan) programske kode v sistem za upravljanje izvorne kode (SCM) in poganjanje avtomatiziranih opravil za izvajanje avtomatiziranih testov (Unit Test, Acceptance Test). Neprekinjena dostava (angl. continuous deployment) je razširitev procesa neprekinjene integracije z cevovodom opravil, v katerem lahko zaporedno ali vzporedno izvajamo opravila potrebna za izgradnjo aplikacij oz. rešitev do te mere, da so pripravljene za namestitev bodisi v testna ali produkcijska okolja. Neprekinjena namestitev (angl. continuous delivery) je razširitev procesa neprekinjene dostave, kjer obstoječ cevovod razširimo z avtomatizirano namestitvijo v bodisi testna ali produkcijska okolja. Uporaba tega procesa ni nujno zmeraj možna, saj lahko avtomatizirano nameščanje zahteva tudi večstopenjsko preverjanje kvalitete. 42 M. Potrč et al.: Nadgradnja obstoječega sistema za neprekinjeno integracijo in dostavo.. 3 Glavne pomanjkljivosti in izzivi obstoječe rešitve Čeprav smo obstoječo rešitev neprekinjene integracije skušali pragmatično uporabljati in z njo uvesti neko vrsto cevovodov, preko katerih bi lahko izvajali preproste cevovode (z uporabo projektnih odvisnosti), smo vendarle bili primorani preiti na modernejšo rešitev. Jenkins različica 1.0 je dosegla konec svoje življenjske dobe (angl. End of Life - EOL) že leta 2016 [1]. Takrat še tega nismo jemali tako resno, saj je sistem služil svojemu namenu v obstoječi konfiguraciji še kar nekaj let, preden je prišlo do resne diskusije o tem, da je potrebno tudi v tej smeri kaj postoriti. EOL je sicer eden izmed glavnih razlogov za nadgradnjo oz. prehod, dejansko je pa razlogov seveda več. Četudi bi Jenkins 1.0 bil še zmeraj vzdrževan, bi bilo za dosego naših ciljev potrebno preiti na drugo rešitev. Ključnega pomena pri razvoju modernih informacijskih rešitev je uporaba modernega sistema za neprekinjeno integracijo. Ena izmed ključnih praks v razvoju procesa neprekinjene integracije je uvedba cevovodnega povezovanja opravil, kar lahko krajše strnemo kot proces neprekinjene dostave. Jenkins 1.0 ne ponuja podpore za cevovode opravil (angl. job pipelining), kar otežuje implementacijo takega procesa. Rešitve za uvedbo neprekinjene dostave v Jenkins 1.0 so obstajale ampak niso dosegale željene kvalitete. V obstoječi rešitvi z Jenkins 1.0 smo poskušali v opravila strniti tudi dodatne informacije o projektih, ki bi bile dostopne razvijalcem na enem mestu. Pojavila se je ideja, da bi lahko razvijalec na spletnem mestu opravila našel pomembne informacije o rezultatih Jenkins opravil, kot tudi dostopal do informacij o izvajalnih okoljih ter protokolih izvajanj. To je bilo možno izvesti v dokaj okrnjeni obliki v Jenkins 1.0 z veliko podvajanja informacij in naknadnega vzdrževanja le teh. Vzdrževanje in uvajanje novih opravil v obstoječi rešitvi z Jenkins 1.0 smo izvajali ročno. Obstoječa rešitev ni ponujala avtomatizacije za opravila brez dodatnih razširitev. Sicer bi lahko to dosegli z alternativnimi rešitvami kot so Jenkins DSL vtičnik ali z Jenkins REST vmesnikom vendar teh rešitev nikoli nismo resnično ovrednotili. Ob poskusu uporabe te prve verzije DSL vtičnika je sama uporaba tega v našem CI okolju kazala na časovno zahtevno uvedbo. Prav tako smo se na tej točki že zavedali modernejših rešitev, kjer je integracija avtomatizacije privzeto dostopna v izvorni rešitvi (angl. out-of-the-box), zato smo uvajanje in ovrednotenje takih razširitev obstoječe Jenkins 1.0 enostavno opustili. 4 Evaluacija CI ponudnikov Trenutno je na trgu ogromno rešitev za CI/CD, vendar smo pregled orodij zmanjšali na rešitve, ki so ustaljene, imajo dovolj veliko bazo uporabnikov in sprejemljivo ceno. S tem smo želeli doseči stabilnost in razširljivost orodja v prihodnosti. Trenutno na trgu obstaja veliko rešitev, ki bi jih lahko razdelili v dve skupini. Inovativne (angl. cutting edge) in ustaljene ter razširljive. Največje razlike med tema kategorijama so novejši in lepši vmesniki z modernejšimi pristopi ali močno integracijo z drugimi orodji v nasprotju s funkcionalnostjo in razširitvami. Da bi zmanjšali nabor možnih opcij, je bila naša zahteva podpora naslednjih orodij: Git, SVN, Maven, Java, Docker. Zaradi velikosti projektov in trajanja izvajanja testov je bila dodatna zahteva gostovanje na lastni infrastrukturi. Nekatera orodja pa smo izločili, ker zahtevajo gostovanje izvorne kode v oblaku ali pa celo v odlagališču oziroma repozitoriju (angl. repository) specifičnega ponudnika, npr. BitBucket. V enakem obdobju smo posodabljali več področij infrastrukture. Med njih spadajo tudi Git repozitorij, zato je potrebno omeniti GitLab in njihov CI. Čeprav nudi zanimiv pristop za ustvarjanje in zaganjanje cevovodov in zelo dobro integracijo s samim Git repozitorijem, so za nas nastale težave z vključitvijo SVN repozitorijev in pregledom nad testi ter okolji, ki se nameščajo. Med trenutnimi rešitvami in na podlagi naših zahtev je bila izbira Jenkins 2.0 [2], dokaj enostavna in naravna. V primerjavi z ostalimi orodji je najbolj univerzalna rešitev in je ni potrebno združevati z dodatnimi orodji. 43 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 5 Cilji uvedbe nove CI rešitve Namen nove rešitve za neprekinjeno integracijo in neprekinjeno dostavo (CI/CD) je bil doseči jasne cilje: poenostavitev postopkov z izgradnjo, testiranjem in dostavo programske opreme; učinkovita uporaba že vzpostavljenih postopkov; natančna sledljivost vseh sprememb; zmanjšanje operativnih nalog ekipe, ki skrbi za razvojne sisteme (angl. DevOps); samodejno vključevanje CI/CD procesov v skladu s spremembami v repozitorijih ter olajšanje nadaljnjega razvoja s pomočjo gradnje razširljive knjižnice. 6 Postopek prehoda Pri menjavi orodja smo imeli dovolj časa, virov in sodelavcev, da smo prehod dobro načrtovali in ga naredili postopoma. Postopek je bil razdeljen na različne faze: načrtovanje, vzpostavitev Jenkins 2.0 strežnika, vzpostavitev delovnih vozlišč (angl. node), implementacija cevovoda za CI za posamezen projekt, preoblikovanje in poenotenje CI cevovodov, implementacija CD cevovodov za dnevno namestitev, implementacija CD cevovodov za testiranje s Selenium orodjem, preoblikovanje in poenotenje CD cevovodov ter vpeljava skupne knjižnice, implementacija CD cevovodov za izdajo posodobitev ter nazadnje še implementacija cevovodov za administrativne naloge. 6.1 Infrastruktura Po načrtovanju smo vzpostavili vzporeden strežnik za Jenkins 2.0. Da bi lahko zagotovili neodvisnost infrastrukture in dinamičnost vozlišč, smo se odločili, da bo eden izmed strežnikov deloval le kot osnovno vozlišče (angl. main node) brez izvajalcev in bo služil le kot nadzornik opravil. Vzpostavili smo tudi delovna vozlišča na virtualnih izvajalnih okoljih. Čeprav je vzpostavitev dodatnega izvajalca dokaj enostavna, smo odvisni od veliko orodij, ki jih ni mogoče vključiti preko Jenkinsa. Za te namene smo pripravili šablone za virtualna izvajalna okolja Unix in Windows, pri slednjih pa definirali še pravila preko skupinske politike (angl. group policy) objektov. Nastala je tudi skripta, ki z nekaj vhodnimi podatki avtomatizirano namesti izvajalca (agenta) in ga doda v delovno skupino. Dodatna vozlišča smo vključevali vzporedno z migracijo. V delovne skupine vozlišč smo poleg virtualnih vključili tudi fizične računalnike. Slika 5: Arhitektura vozlišč 44 M. Potrč et al.: Nadgradnja obstoječega sistema za neprekinjeno integracijo in dostavo.. 6.2 Konfiguracija cevovodov V želji, da bi poenotili in avtomatizirali čim več procesov, smo uvedli tok delovnih procesov z uporabo sledečih funkcij, ki jih Jenkins v verziji 2.0 nudi: • Jenkins Multibranch Pipeline omogoča ustvarjanje osnovnih opravil (angl. Job), kateri prebirajo vse veje repozitorija po definiciji cevovoda. • Definicija za izvajanje cevovoda je shranjena v samem repozitoriju kot datoteka s konfiguracijo in vsebuje izvorno kodo za cevovod spisano v jeziku Groovy. Groovy je skriptni jezik, ki se izvaja v JVM in lahko dostopa tudi do razredov in metod v Javi. • Vpeljali smo tudi globalno knjižnico in preselili vso logiko iz cevovodov na projektih. Tako je ostala na projektih samo konfiguracija za same projekte, ki uporablja definirane cevovode v knjižnici. Na ta način lahko spremenimo cevovod za vse projekte hitro in enostavno. 6.3 Neprekinjena integracija – CI Z vzpostavljeno infrastrukturo, smo lahko začeli z implementacijo cevovodov za CI, ki je razdeljen na devet faz, kar lahko vidimo na sliki Slika 6 1. Pridobitev izvorne kode (angl. checkout) 2. Deklarativna namestitev orodij (Maven, Java ipd.) 3. Prevajanje kode (angl. compile) 4. Izvajanje testov enot (angl. unit tests) 5. Izvajanje sprejemnih testov (angl. acceptance tests) 6. Opcijska faza za potrebe izvajanja testov pod določenimi specifičnimi nastavitvami (kot na primer za potrebe migracijskih projektov). 7. Nalaganje artefaktov v skupen repozitorij 8. Preverjanje paketnih odvisnosti (angl. dependency track) in varnostnih lukenj 9. Čiščenje delovnega prostora Slika 6: Prikaz faz za CI na posameznem projektu Cevovod je bil razvit in pripravljen na projekte. Preden smo migrirali vse projekte, smo naredili preoblikovanje in prestavili definicijo cevovoda v globalno knjižnico. S tem smo na projektu obdržali le minimalno konfiguracijo in možnost spremembe le te, brez da vpliva na ostale projekte. Vsi projekti so konfigurirani po enakem postopku kot kaže spodnji primer Groovy kode na sliki Slika 7. 45 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Na ta način lahko definiramo privzeto obnašanje cevovoda na projektu, obstoječi parametri pa omogočajo tudi ročne spremembe. Slika 7: Primer konfiguracije za Jenkins cevovod 6.4 Neprekinjena dostava – CD Nadaljevali smo s cevovodi za dnevne namestitve (angl. daily build). Poslužili smo se enakega pristopa za konfiguracijo in definicijo cevovoda. Ker so projekti med seboj sklopljeni, cevovodov nismo vključili v repozitorije projektov, ampak naredili namenskega, v katerem veje predstavljajo okolje, ki ga želimo namestiti. Ker so projekti v produkcijski rabi in imajo lastne razvojne poti, imamo namestitve za vse aktivne različice na projektih. Blue Ocean vmesnik na sliki Slika 8 predstavlja faze, ki so potrebne za namestitev okolja. Pridobivanje izvorne kode iz repozitorijev se izvaja paralelno, grajenje pa zaporedno. Faze za ta del cevovoda se generirajo dinamično, glede na konfiguracijo okolja. V sklopu cevovoda še pripravimo gostiteljski sistem in preverimo ali obstaja kakšna namestitev tega projekta nato jo ugasnemo in odstranimo. Rezultat se arhivira in prenese na gostitelja, kjer se razpakira in namesti. Namestitev zajema namestitev servisov, pripravo baze, zagon okolja in zagon parametrizacije. Slika 8: Blue Ocean pogled na Demo dnevne namestitve 6.4.1 CD – Selenium Selenium okolja za nas predstavljajo okolja podobna okoljem dnevne namestitve, vendar so namenjena zagonu testov s pomočjo Selenium orodja, ki je namenjeno testiranju spletnih strani. V primerjavi s prejšnjo točko, ima cevovod le dodatno fazo zaganjanja testov in dodatno parametrizacijo za teste. Tako kot pri dnevnih namestitvah, se aplikacija prenese na gostitelja, kjer se sistem zažene, testi pa se izvajajo na Jenkins vozlišču. Ker se testira spletni vmesnik, se testi izvajajo počasneje. Uporabljamo malo večje časovne omejitve (na primer čakanje na obnovitev strani pri spremembi vnosnih podatkov), da smo prepričani, da vse funkcionalnosti delujejo, tudi če je v tistem trenutku na voljo manj virov. V primeru da zaznamo večje nihanje v učinkovitosti, izvajamo teste učinkovitosti ločeno. 46 M. Potrč et al.: Nadgradnja obstoječega sistema za neprekinjeno integracijo in dostavo.. V sklopu Selenium testov, zajemamo tudi zaslonske slike v primeru napake ali padlega testa, ki so dostopne direktno preko Jenkinsa, kar razvijalcem malo olajša iskanje napak. V primerjavi z Jenkins 1.0, kjer so delovni tokovi delali avtomatizirano, dostop do informacij pa je bil otežen, potrebno je bilo poiskati in se povezati na gostitelja, na katerem smo ročno iskali te datoteke. 6.4.2 CD – Posodobitev Tudi posodabljanje ima veliko korakov skupnih s CD cevovodi, saj je tudi tam potrebno pripraviti paket aplikacije za gostiteljski sistem. Razlikuje pa se v tem, da se ne proizvede arhiv aplikacije na podlagi zadnjega stanja kode, ampak na podlagi oznak verzije (angl. tag). Na tej točki smo se namenoma odločili, da se oznake verzij pripravijo vnaprej in ne v sklopu cevovoda za posodobitev. Obnašanje cevovoda se razlikuje glede na projekt, odvisno od tega, ali našo aplikacijo izdajamo le kot namestitveni paket ali pa kot paket v kombinaciji z aplikacijskim strežnikom, na primer v obliki celotnega vsebnika ali "Docker Image". Pripravimo lahko tudi različne arhive. Vse to je nastavljivo preko parametrov na grafičnem vmesniku, privzete vrednosti pa so definirane v konfiguraciji za posamezno stranko. 6.5 Administracija Na Jenkinsu 1.0 smo imeli veliko več administrativnih oz. nadzornih opravil, ki pa smo jih prestavili na druga namenska orodja, kot so Zabbix, Grafana ipd. Največ opravil je bilo za preverjanje stanja namestitev in njihove dosegljivosti, tudi za produkcijska okolja, ter varnostno kopiranje internih sistemov, nastavitev in podatkov. Trenutno so administrativni cevovodi namenjeni lažjemu vzdrževanju infrastrukture. Za potrebe Selenium testov, smo vezani na uporabo Firefox brskalnika in Gecko gonilnika. Zaradi omejitev iz strani teh dveh aplikacij, smo se odločili, da te sisteme posodabljamo kar preko Jenkinsa. S tem zagotovimo, da se vsa testna okolja in izvajanje testov obnaša enako. Ne pride do težav, da se na kakšnem strežnik/vozlišču pozabi ali spregleda. Na ta način lahko verzijo tudi fiksiramo, v primeru, da so najnovejše različice nekompatibilne. 6.6 Izzivi in težave pri razvoju Po naši evaluaciji se je orodje Jenkins izkazalo kot najustreznejše. Prepričala nas je univerzalnost orodja za namene CI in CD, predvsem zaradi odprte kode in razširljivosti s pomočjo vtičnikov. Deloma so ti vtičniki razviti iz strani skupnosti (angl. community), za katere pa ni nujno, da se držijo standardov, da so dobro testirani ali dokumentirani. Ena izmed večjih težav je bila pri uporabi različnih vtičnikov in njihovim obnašanjem v sklopu naših cevovodov. Neobstoječa ali zelo površna dokumentacija nas je privedla do veliko tako imenovanih "poskus in napaka" pristopov (angl. trial and error) pri razvoju cevovodov. Ko smo začeli ustvarjati cevovode, smo se odločili za definicijo cevovodov kot "konfiguracija v kodi" (angl. configuration by code). Za te namene sta na voljo skriptni in deklarativni cevovod. Oba uporabljata datoteko konfiguracije "jenkinsfile", ki je spisana v Groovy jeziku. Skriptni cevovodi so najbolj zmogljivi, saj omogočajo direkten dostop in konfiguracijo do vseh modulov, v nasprotju z deklarativnimi cevovodi, ki so enostavnejši in bolj pregledni, kar je bil razlog, da smo se odločili za deklarativni pristop. Hitro smo ugotovili, da samo z deklarativnim pristopom ne bomo uspeli rešiti vseh zastavljenih ciljev in delovnih tokov. Odločili smo se, da vse gradnike poskušamo spisati v deklarativnem načinu in uporabimo skriptni pristop, kjer je potrebno. Kot smo ugotovili kasneje, je to za nas obvezno. Določeni vtičniki ponujajo uporabo samo preko Jenkins vmesnika ali pa preko skriptnega pristopa. Izogniti smo se morali tudi različnim vtičnikom, ki so namenjeni predvsem uporabi preko spletnega vmesnika in jih je skoraj nemogoče konfigurirati preko kode. 47 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 7 Zaključek Splošno zadovoljstvo s prehodom na Jenkins 2.0 je bilo s strani naših razvijalcev izboljšano v primerjavi z različico 1.0. Sam razvoj in vzdrževanje Jenkins cevovodov je sicer še nekoliko težaven, vendar počasi pridobivamo izkušnje in sproti rešujemo različne izzive ter težave. V načrtu je tudi posodobitev samih Jenkins vozlišč in Jave, s katero se poganjajo. Zanimivo pri tem je, da samih vozlišč ni mogoče posodobiti preko Jenkins orodja. Edini način je, da na glavnem vozlišču sprožamo skripte, ki ta vozlišča obvestijo, da naj posodobijo določena orodja, kot so Gecko gonilnik, Firefox brskalnik za potrebe testiranja v Selenium ogrodju ipd. V ekipi DevOps se že opaža manj ročnega posredovanja pri uvajanju novih cevovodov ali spreminjanju obstoječih. Razvijalci so namreč že navajeni, da smejo take spremembe urediti sami glede na zahteve, ki bi sicer prešle od njih samih na DevOps ekipo. Literatura [1] https://www.versio.io/product-release-end-of-life-eol-Jenkins-Jenkins.html, obiskano 17. 6. 2023 [2] https://www.jenkins.io/doc, obiskano 2. 6. 2023 48 Vpeljava zabojnikov v oblačno zasnovana zasebna omrežja 5G Urban Zaletel, Kristjan Voje, Benjamin Burgar, Uroš Brovč Kontron d.o.o, Kranj, Slovenija urban.zaletel@kontron.si, kristjan.voje@kontron.si, benjamin.burgar@kontron.si, uros.brovc@kontron.si Današnja sodobna podjetja imajo vse večje zahteve na področju mobilne povezljivosti. Nastajajoče aplikacije in industrijska okolja zahtevajo večjo pasovno širino, predvsem pa izjemno nizko zakasnitev, več spektra in večjo zanesljivost. Z dodeljevanjem namenskega spektra za ta okolja s strani regulatorjev (Nemčija, Norveška, Združeno kraljestvo in druge napredne države) so v podjetjih nastali pogoji za uvajanje zasebnih mobilnih omrežij, ki so samostojna in razširjajo njihova obstoječa brezžična omrežja. Oblačno zasnovana omrežja podjetjem omogočajo učinkovito upravljanje in pomagajo pri sprejemanju hitrejših in boljših poslovnih odločitev. V prispevku smo naslovili motivacijo prehoda na oblačno arhitekturo in pridobljene izkušnje, ki smo jih pridobili ob razvoju in uvajanju oblačno zasnovanih rešitev na Kubernetesu. Razvoj 5G je zahteval usklajenost med ekipami, ki so razvijali omrežne elemente v različnih jezikih (Java, Golang, C) in enoten pristop do modernih DevSecOps praks (infrastruktura-kot-koda, avtomatizacija, varnostno skeniranje, Helm). Kubernetes in mikroservisi so nov koncept za telekomunikacijske aplikacije, ki se počasi selijo iz paradigme VNF (virtual network functions) proti paradigmi CNF (cloud-native network functions)[6]. V prispevku so izpostavljeni izzivi, s katerimi smo se soočali pri implementacij oblačnih omrežnih funkcij. Nanizane so tudi številne pridobljene kompetence, ki smo jih inženirji pridobili tekom trajanja projekta. Ključne besede: 5G privatna omrežja CNF DevOps DevSecOps Kubernetes Helm ISBN 978-961-286-772-0 DOI https://doi.org/10.18690/um.feri.8.2023.5 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 1 Uvod 5G privatna omrežja predstavljajo razširitev 5G tehnologije na področje podjetij in organizacij, ki želijo vzpostaviti lastno zasebno omrežje z visoko zmogljivostjo in nizko zakasnitvijo. Ta omrežja omogočajo podjetjem večji nadzor, varnost in prilagodljivost pri povezovanju njihovih naprav in sistemov. Privatna 5G omrežja se gradijo na enakih temeljih kot javna 5G omrežja, vendar se upravljajo in nadzirajo znotraj organizacije. To pomeni, da podjetja dobijo lastno omrežno infrastrukturo, vključno s baznimi postajami in strežniškimi zmogljivostmi, kar jim omogoča, da prilagodijo omrežje svojim specifičnim potrebam. Eden glavnih razlogov za uvedbo privatnih 5G omrežij je izboljšanje zanesljivosti in varnosti povezave. Podjetja lahko nadzorujejo in omejijo dostop do svojega omrežja, kar zmanjšuje tveganje za morebitne vdore ali izpade povezave. Poleg tega imajo privatna omrežja višjo prioriteto in večjo pasovno širino, kar zagotavlja stabilno povezavo za kritične aplikacije. Privatna 5G omrežja omogočajo tudi večjo fleksibilnost pri upravljanju in integraciji naprav. Organizacije lahko povežejo različne naprave in senzorje v svoje omrežje ter izkoristijo prednosti interneta stvari. To odpira vrata za inovacije na področjih kot so industrija 4.0, pametne tovarne, avtonomna vozila, zdravstvena oskrba in še veliko več. Kljub temu pa obstajajo tudi nekateri izzivi pri uvedbi privatnih 5G omrežij, vključno z visokimi stroški vzpostavitve in vzdrževanja infrastrukture ter potrebo po posebnem znanju in usposabljanju za upravljanje omrežja. Optimizacija stroškov postavitve in vzdrževanja 5G privatnih omrežij se lahko doseže s pomočjo uporabe oblačnih postavitev. Oblačno zasnovana omrežja omogočajo organizacijam koriščenje infrastrukture zunanjih ponudnikov oblakov, kar je v nekaterih primerih veliko bolj učinkovito od postavljanja in vzdrževanja svoje infrastrukture. 2 5G omrežje 2.1 Evolucija mobilnih omrežij Evolucija mobilnih omrežij po generacijah je temeljila na potrebi po zadovoljevanju naraščajoče potrebe po prenosu podatkov, izboljšanju učinkovitosti omrežja in omogočanju novih storitev in aplikacij. Vsaka generacija je nadgradila prejšnjo, uvedla nove tehnologije in zmogljivosti, ki so oblikovale način komunikacije in interakcij v digitalni dobi. Na sliki 1 so podane ključne značilnosti posamezne generacije mobilnih omrežij. Slika 1: Evolucija mobilnih omrežij Vir: [3]. 50 U. Zaletel et al.: Vpeljava zabojnikov v oblačno zasnovana zasebna omrežja 5G.. 2.2 Kaj nam omogoča 5G 5G omrežje omogoča izjemno hitrost prenosa podatkov, nizko zakasnitev ter večjo zmogljivost in povezljivost, kar omogoča napredne aplikacije, inovacije ter nove poslovne modele v različnih panogah. Pregled ključnih prednosti: • Visoka hitrost prenosa podatkov: izjemno visoke hitrosti prenosa podatkov, ki presegajo zmogljivosti prejšnjih generacij omrežij. To vključuje podporo za prenos velikih količin podatkov, kot so visokokakovostni video posnetki in pretočne storitve v realnem času. • Nizka zakasnitev (latenca): izjemno nizka zakasnitev pri prenosu podatkov, kar je ključno za aplikacije, ki zahtevajo takojšen odziv. To vključuje avtonomna vozila, virtualno resničnost, obogateno resničnost in druge aplikacije, ki zahtevajo hitro in brezhibno delovanje v realnem času. • Večja zmogljivost omrežja: zasnova za večjo zmogljivost, kar pomeni, da mora omogočati hkratno povezavo večjega števila naprav na istem območju. To je ključno za podporo različnim napravam v okviru interneta stvari (IoT), kot tudi za zagotavljanje visoke kakovosti storitev v gostih urbanih območjih. • Podpora za različne uporabniške scenarije: prilagodljivost in sposobnost podpirati različne uporabniške scenarije, vključno z mobilnimi napravami, IoT napravami, industrijsko avtomatizacijo, pametnimi mesti in drugimi naprednimi aplikacijami. • Energijska učinkovitost: zmanjšuje porabo energije v omrežju in podaljšuje življenjsko dobo baterij pri napravah. • Visoka zanesljivost in varnost: zagotavlja visoko zanesljivost in varnost komunikacije, še posebej pri kritičnih aplikacijah, kot so kritična infrastruktura, pametni sistemi v prometu in oddaljena medicinska oskrba. Omrežje mora imeti tudi ustrezne varnostne mehanizme za zaščito uporabniških podatkov in preprečevanje napadov. 2.3 Arhitektura Arhitektura 5G omrežja je bila sestavljena tako, da zagotavlja zahteve, kot so zapisane v poglavju 2.2. Ključne komponente 5G arhitekture vključujejo (slika 2): • Uporabniška oprema1 (UE): Naprava, ki jo uporabnik uporablja za dostop do 5G omrežja, na primer pametni telefon, tablica ali druga naprava z vgrajeno 5G tehnologijo. • Radijsko dostopno omrežje2 (RAN): Brezžično omrežje, ki omogoča komunikacijo med UE in omrežno infrastrukturo. RAN v 5G sistemu je znan kot NG-RAN in uporablja tehnologije, kot so Massive MIMO3 in oblikovanje snopa4 [7] za izboljšanje zmogljivosti in kakovosti povezave. • 5G jedro5 (5GC): Osrednji del arhitekture omrežja 5G, ki obvladuje in upravlja vse ključne funkcije omrežja. Deluje kot centralni vozliščni sistem, ki zagotavlja povezljivost, komunikacijo in upravljanje med uporabniki, napravami in storitvami v omrežju 5G. 1 uporabniška oprema – izvorno "user equipment", okrajšava "UE" 2 radijsko dostopno omrežje - izvorno "radio access network", okrajšava "RAN" 3 mMIMO – Massive Multiple Input Multiple Output 4 oblikovanje snopa – izvorno "beamforming" 5 5G jedro – izvorno "5G core", okrajšava "5GC" 51 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Slika 2: Pregled 5G sistema Vir: [1]. 2.4 Omrežne funkcije in vmesniki Podrobnejša arhitektura, z osnovnimi omrežnimi funkcijami6 jedra (NF), vmesniki med omrežnimi funkcijami, radijskim delom (RAN in UE) ter podatkovnim omrežjem7 (DN), je prikazana na sliki 3. Slika 3: Arhitektura 5G sistema. Arhitektura 5G omrežja je specificirana v standardu 3GPP8. Jedro 5G omrežja oz. omrežne funkcije lahko v osnovi delimo na kontrolno ravnino9 in uporabniško ravnino10. Kontrolna ravnina je del omrežja, ki upravlja in nadzira pretok podatkov med napravami in storitvami. Nekatere od njenih nalog so: • Alokacija virov: kontrolna ravnina dodeljuje frekvenčne pasove, kanale in časovne reže za prenos podatkov med napravami in baznimi postajami. • Upravljanje mobilnosti: kontrolna ravnina skrbi za nemoteno preklapljanje med različnimi celicami in omrežji, ko se naprave premikajo po prostoru. • Upravljanje povezljivosti: kontrolna ravnina vzpostavlja, vzdržuje in prekinja povezave med napravami in storitvami, glede na njihove potrebe in zahteve. 6 omrežna funkcija – izvorno "Network Function", okrajšava "NF" 7 podatkovno omrežje - izvorno "data network", okrajšava "DN" 8 3GPP - 3rd Generation Partnership Project [2] 9 kontrolna ravnina – izvorno "control plane" 10 uporabniška ravnina – izvorno "user plane" 52 U. Zaletel et al.: Vpeljava zabojnikov v oblačno zasnovana zasebna omrežja 5G.. • Upravljanje identitete: kontrolna ravnina preverja avtentičnost in avtorizacijo naprav in uporabnikov, ki dostopajo do omrežja in storitev. • Upravljanje varnosti: kontrolna ravnina zagotavlja šifriranje, integriteto in zaupnost podatkov, ki potekajo po omrežju. Uporabniška ravnina je del omrežja, ki prenaša in usmerja podatke med napravami in storitvami. Nekatere od njenih nalog so: • Prenos podatkov: Omogoča učinkovit prenos podatkov med uporabniškimi napravami in omrežjem. To vključuje prenos glasovnih klicev, videokonferenc, prenosa datotek, internetnega brskanja in drugih oblik podatkovne komunikacije. • Usmerjanje in preklapljanje: Zagotavlja usmerjanje podatkovnega prometa in preklapljanje med omrežnimi vozlišči za optimalno pot prenosa podatkov. • Nadzor kakovosti storitev11: Skrbi za nadzor in upravljanje kakovosti storitev. To pomeni, da se podatkovni promet razvrsti in obdela glede na različne parametre, kot so pasovna širina, zakasnitev, izgube paketov in druge metrike, da se zagotovi ustrezna raven storitev in izboljša uporabniška izkušnja. • Šifriranje in varnost: Odgovorna je za šifriranje podatkov in zagotavljanje varnosti med prenosom, da se zaščiti pred nepooblaščenim dostopom. • Komunikacija z omrežnimi storitvami: Sodeluje z omrežnimi funkcijami za avtentikacijo, identifikacijo, upravljanje mobilnosti in nadzor dostopa. 2.5 Registracija in vzpostavitev seje 5G kompatibilna naprava z ustrezno SIM kartico, ki želi dostopati do podatkovnega omrežja (DN) preko 5G omrežja, se mora najprej prijaviti v 5G omrežje. Uspešna prijava naprave je predpogoj za vzpostavitev PDU seje12 do 5G jedra. PDU seja je logična povezava med uporabniško napravo (UE) in 5G jedrom (natančneje med UE in UPF13), ki uporabniku omogoča povezavo z podatkovnim omrežjem (DN). Preko PDU seje se omogoči pretok uporabniškega prometa med 5G napravo (UE) in ciljno storitvijo (npr. brskanje po internetu ali pošiljanje senzorskih meritev na IoT platformo). Osnovni koraki vzpostavitve PDU seje so prikazani na sliki 4. Slika 4: Vzpostavitev PDU seje. 11 kakovost storitve – izvorno "Quality of Service", okrajšava "QoS" 12 PDU seja – izvorno "Protocol Data Unit Session", okrajšava "PDU session" 13 UPF – izvorno "User Plane Function" 53 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 2.6 Segmentacija 5G omrežja in kakovost storitev Med glavne in kompleksnejše funkcionalnosti 5G omrežja štejemo segmentacijo in upravljanje s kakovostjo storitev. Segmentacija 5G omrežja14 je koncept, ki omogoča segmentacijo omrežja 5G na več virtualnih omrežij, imenovanih "rezine"15. Vsaka rezina je samostojno virtualno omrežje z lastnimi zmogljivostmi in parametri kakovosti storitve16 (QoS). Rezine omogočajo prilagojeno in optimizirano povezljivost za različne vrste uporabnikov, aplikacij in industrijskih vertikal. S segmentacijo 5G omrežja se omogoča izpolnjevanje specifičnih zahtev glede zmogljivosti, odzivnega časa, zanesljivosti in varnosti, kar omogoča učinkovito upravljanje različnih uporabniških scenarijev v okviru enega samega omrežja. Rezine se lahko dinamično konfigurira in prilagaja, kar omogoča prilagajanje omrežnih virov glede na spreminjajoče se zahteve in potrebe uporabnikov. Na sliki 5 je primer omrežja s segmentacijo. Slika 5: Segmentacija 5G omrežja Vir: [4]. Kakovost storitev (QoS) je koncept, ki se nanaša na sposobnost omrežja 5G, da zagotavlja različne ravni storitev in zadovolji določene zahteve glede kakovosti in učinkovitosti prenosa podatkov (Slika 6). S pomočjo QoS lahko omrežje prilagodi svoje delovanje glede na specifične potrebe aplikacij, uporabnikov in storitev. To omogoča, da se različni vrsti prometa dodelijo prednostne ravni, uporabljajo se mehanizmi za prioritetno obdelavo prometa ter zagotavlja se kakovostno in zanesljivo izkušnjo uporabnikom. 14 segmentacija 5G omrežja - izvorno "5G slicing" 15 rezina – izvorno "slice" 16 kakovost storitve – izvorno "Quality of Service", okrajšava "QoS" 54 U. Zaletel et al.: Vpeljava zabojnikov v oblačno zasnovana zasebna omrežja 5G.. Slika 6: QoS 5G omrežja Vir: [5]. QoS lahko razlikuje med različnimi vrstami prometa, vendar ne more razlikovati in različno obravnavati iste vrste prometa, ki prihaja iz različnih virov. QoS nima sposobnosti za izvedbo izolacije prometa od konca do konca. Po drugi strani 5G segmentacija skupaj s kvaliteto storitev (QoS), lahko razlikuje med istimi vrstami prometa, ki prihajajo od različnih najemnikov/rezin. Segmentacija omrežja omogoča delovanje več logičnih omrežij na osnovi skupne fizične omrežne infrastrukture, kar zagotavlja izolacijo med njimi. Na sliki 7 je primer združevanja koncepta segmentacije in kvalitete storitev. Slika 7: Združevanje segmentacije in QoS 5G omrežja Vir: [5]. 55 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 3 Kontron 5G rešitev Kontron 5G rešitev je v prvi vrsti predvidena za mobilna privatna omrežja. Glavna naloga naše ekipe je razvoj 5G jedra, katerega postopoma razvijamo in nadgrajujemo (dopolnitve omrežnih funkcij in vpeljava novih) glede na primere uporabe in zahteve s strani končnega kupca. Od zunanjih partnerjev pridobivamo naprave RAN in UE ter medsebojno testiramo delovanje 5G jedra ter delovanje in povezljivost naprav. Slika 8: Storitve Kontron 5G rešitve. Kontron rešitev je sestavljena iz dveh komponent: 5G jedro ter upravitelj elementov 5G jedra. Vsaka komponenta je sestavljen iz več samostojnih storitev (slika 8). 56 U. Zaletel et al.: Vpeljava zabojnikov v oblačno zasnovana zasebna omrežja 5G.. 3.1 Upravitelj elementov 5G jedra Glavne naloge upravitelja elementov 5G jedra so: • konfiguracija in namestitev omrežnih funkcij jedra, • posodobitev omrežnih funkcij jedra, • vpis in administracija naročnikov, • prikaz stanja 5G omrežja. Upravitelj elementov je sestavljen iz zalednih storitev, ki so napisane v programskih jezikih Java (Spring Boot17) in Golang, medtem ko je za čelni del sistema18 uporabljeno JavaScript ogrodje Angular19. Za upravljanje identitet in dostopov do upravitelja elementov se uporablja Keycloak20. Aplikacije se konfigurirajo in nameščajo s pomočjo orodja Helm21. 3.2 5G jedro Na sliki 9 so predstavljene omrežne funkcije Kontron 5G jedra. Delimo jih na kontrolno raven, ki skrbi za signalizacijo ter uporabniško raven, preko katere se pretaka podatkovni promet. Slika 9: Omrežne funkcije Kontron 5G jedra. Standard 3GPP22 specificira omrežne funkcije kot strežnike z dobro definiranimi REST vmesniki. To nam omogoča implementacijo aplikacij v različnih programskih jezikih. Uporabljamo jezika Golang in C. Golang omogoča hiter razvoj programske opreme z dobrimi zagotovili za dolgotrajno delovanje aplikacij. Jezik omogoča hitro prevajanje in dober nadzor nad knjižnicami in odvisnostmi. Golang ponuja številna orodja za formatiranje in testiranje kode, kar ekipi omogoča hiter razvoj aplikacij. Rezultat prevajanja so relativno majhni in učinkoviti programi, dovolj zmogljivi za večino primerov uporabe v 5G jedru. 17 https://spring.io/projects/spring-boot 18 čelni del sistema – izvorno "frontend", okrajšava "FE" 19 https://angular.io/ 20 https://www.keycloak.org/ 21 https://helm.sh/ 22 https://www.3gpp.org/ 57 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Komponente 5G jedra, ki zahtevajo dodatno zmogljivost so napisane v programskem jeziku C. Primer je UPF, ki za hitro procesiranje paketov uporablja knjižnice DPDK23. 3.3 Motivacija za prehod na oblačno zasnovano omrežje 3GPP je standardizacijska organizacija, ki piše standarde za mobilna omrežja. Pri definiciji standardov za 5G omrežje so veliko poudarka namenili vpeljavi storitveno orientirane arhitekture24 (SBA). Ker želimo narediti 5G rešitev kompatibilno s standardom, je bila že takoj sprejeta odločitev za vpeljavo storitev z vmesniki, kot je predlagano s strani 3GPP. Jedrne omrežne funkcije med sabo komunicirajo preko REST vmesnikov preko protokola http/2. Najdemo tudi manj razširjene omrežne protokole kot so NGAP, PFCP ter GTP-U. Protokola NGAP in GTP-U se uporabljata za komunikacijo jedra z zunanjimi elementi omrežja (UE, RAN, DN). Jedro primarno razvijamo za privatna mobilna omrežja, zato velik poudarek namenjamo postopku namestitve in posodobitve jedra na različnih okoljih. Omenjeni postopki morajo biti čim preprostejši za končno stranko. Zagotavljati je potrebno tudi ustrezno spremljanje stanja rešitve in alarmiranje v primeru kritičnih napak. Dodatno se od 5G jedra zahteva, da bo zagotavljalo visoko razpoložljivost omrežja, prilagodljivost in razširljivost, učinkovito porabo virov in omogočalo hitro dostavo novih rešitev. Na primer v primeru vpeljave segmentacije omrežja (poglavje 2.6), je potrebno zagotavljati dinamično spremembo topologije jedra. Dodajanje, odvzemanje ali spremembo rezin omrežja je potrebno zagotoviti med delovanjem jedra. To pomeni, da je potrebno zagotoviti namestitev ali odstranitev omrežnih funkcij in spremembo konfiguracij omrežnih funkcij brez izpada omrežja. Glede na raznolikost rešitve in omenjene zahteve, smo se odločili za oblačno zasnovo omrežja. Storitve so pripravljene za zabojnike, ki jih orkestrira Kubernetes25. Kubernetes nam zagotavlja orkestracijo, razširljivost, visoko razpoložljivost, prenosljivost in lažje upravljanje konfiguracij. Poleg tega se z vpeljavo zabojnikov poenostavi namestitev rešitve na različna okolja (na strežnike pri stranki, na oblak različnih ponudnikov). Za namestitev in konfiguracijo samih komponent se uporablja orodje Helm. Avtomatizacija z uporabo Kubernetesa nam omogoča tudi hitrejšo in lažjo vpeljavo različnih DevSecOps cevovodov za gradnjo produkta, nočno testiranje in varnostno skeniranje. 3.4 Sistemske komponente Rešitev smo poskusili približati čim bolj generični namestitvi aplikacij na Kubernetes gručo. Aplikacije so v veliki večini spletni strežniki z REST vmesnikom, kar jih naredi optimalne uporabnike tovrstne platforme. Nekatere aplikacije 5G jedra potrebujejo dostop do omrežnih vmesnikov, ki jih splošna Kubernetes gruča ne ponuja. Uporabo poljubnih omrežnih vmesnikov omogočimo z uporabo vtičnika Multus. Kot podatkovno bazo uporabljamo MongoDB. Za postavitev visoko-razpoložljive baze uporabljamo Kubernetes s posebnim vtičnikom za koriščenje shrambe na gostiteljskih sistemih. 3.4.1 MongoDB Aplikacije 5G jedra shranjujejo svoje podatke v dokumentni bazi MongoDB. Tovrstna baza optimalno teče na namenskih strežnikih izven Kubernetes gruče. Postavitev 5G jedra smo približali minimalnemu številu strežnikov, s katerim lahko zagotavljamo visoko razpoložljivost. MongoDB tako teče znotraj Kubernetes gruče na treh strežnikih in si deli vire z ostalimi aplikacijami. Z uporabo Kubernetes nastavitev "requests" in "limits" strogo nadzorujemo porabo resursov vsake aplikacije. Podatki so shranjeni na gostiteljevem podatkovnem sistemu. 23 https://www.dpdk.org/ 24 izvorno "Service Based Architecture", okrajšava. "SBA" 25 https://kubernetes.io/ 58 U. Zaletel et al.: Vpeljava zabojnikov v oblačno zasnovana zasebna omrežja 5G.. 3.4.2 Vtičnik za shrambo Nekatere aplikacije v Kubernetes gruči za delovanje potrebujejo obstojno shrambo ("persistent storage"). Najbolj zahtevna izmed teh aplikacij je baza (MongoDB), za katero smo potrebovali hitro in zanesljivo shrambo. Izbrali smo lokalno shrambo na gostiteljskem sistemu, ki jo implementira vtičnik local-path-provisioner26. Pri uporabi tovrstne shrambe moramo biti pozorni na njene omejitve: • V privatnih omrežjih lahko predvidimo zgornjo mejo naročnikov (naprav), kar nam omogoča načrtovanje zgornje meje velikosti shrambe. Zavedamo se, da je povečava shrambe zahteven postopek, ki zahteva zaustavitev sistema. • Gostiteljski operacijski sistem mora imeti implementirane mehanizme, s katerimi loči podatkovno shrambo od shrambe operacijskega sistema – to smo dosegli z logično particijo (LVM27). • Implementiran mora biti nadzor porabe diska ter primerni alarmi. • Aplikacije, ki zahtevajo obstojno shrambo so vezane na strežnik, na katerem je bila shramba kreirana. Vtičnik za shrambo local-path-provisioner Kubernetes gruči ponudi t.i. shrambni razred28 (SC). Ko aplikacija od shrambnega razreda zahteva obstojni disk29 (PV), vtičnik na strežnikovem podatkovnem sistemu ustvari nov direktorij ter ga vpne v zabojnik. Slika 10: vtičnik za shrambo local-path-provisioner. 3.4.3 Multus Omrežni vtičnik Multus30 omogoča uporabo več različnih omrežij za Kubernetes zabojnike. Multus je meta-vtičnik - to je CNI vtičnik preko katerega lahko uporabljamo več različnih CNI vtičnikov. CNI (Container Network Interface31) je standard, ki predpisuje API preko katerega vtičnik Kubernetes gruči ponuja omrežje za zabojnike. Kot privzeto omrežje za zabojnike uporabljamo Cilium32. Poleg privzetega omrežja uporabljamo vtičnik za omrežni most ("bridge") ter vtičnik za gostiteljsko napravo ("host device"). Vtičnik "bridge" zabojniku omrežne funkcije AMF33 pripne gostiteljev "bridge". Aplikacija AMF na ta način komunicira z zunanjim svetom preko protokola SCTP. Omeniti je treba, da nekateri Kubernetes omrežni vtičniki že podpirajo protokol SCTP, kljub temu smo se zaradi večje stabilnosti in nadzora nad prometom odločili za implementacijo preko vtičnika Multus. 26 https://github.com/rancher/local-path-provisioner 27 https://www.man7.org/linux/man-pages/man8/lvm.8.html 28 Shrambni razred – izvorno "StorageClass", okrajšava "SC" 29 Obstojni disk – izvorno "PersistentVolume", okrajšava "PV" 30 https://github.com/k8snetworkplumbingwg/multus-cni 31 https://www.cni.dev/ 32 https://cilium.io/ 33 AMF – Access and Mobility Function 59 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Vtičnik "host-device" zabojniku omrežne funkcije UPF pripne vmesnika za povezavi N3 in N6, preko katerih se pretaka podatkovni promet. To omogoča aplikaciji v UPF zabojniku direkten dostop do fizičnih omrežnih vmesnikov ter optimalni izkoristek zmogljivosti omrežne kartice. Z uporabo vtičnika Multus se izognemo dodatnim obremenitvam omrežnega prometa preko Kubernetes omrežja. 3.4.4 DPDK Multus nam omogoča direktno uporabo omrežnih vmesnikov brez dodatne obremenitve omrežnega prometa preko Kubernetes omrežja. Omrežno kartico lahko izkoristimo še bolje. Neposredna uporaba omrežnega vmesnika, ki ga ponuja Linux gostiteljski sistem še vedno predstavlja dodatno obremenitev in sicer procesiranje omrežnih paketov na nivoju Linux jedra. Tej dodatni obremenitvi se lahko izognemo z uporabo knjižnic DPDK. DPDK34 (Data Plane Development Kit ali Komplet za razvoj podatkovne ravnine) je skupek knjižnic za hitro procesiranje omrežnih paketov z ozirom na optimalno uporabo razpoložljive strojne opreme. DPDK Linux jedru odvzame nadzor nad omrežno kartico ter ga izroči aplikaciji v uporabniškem prostoru. Uporabniku omogoči razvoj lastnega omrežnega sklada, optimiziranega za specifičen primer uporabe. V primeru 5G jedra, omrežna funkcija UPF opravlja vlogo omrežnega usmerjevalnika. UPF prejema omrežne pakete s povezav N3 ter jih glede na pravila pridobljena iz nadzorne ravni usmerja na podomrežja preko povezave N6. Slika 11: Primerjava omrežnega sklada Linux jedra ter DPDK. 3.5 5G jedro na Kubernetes gruči Z uporabo Kubernetes gruče smo dosegli poenoten način namestitve, posodobitev ter konfiguracije aplikacij. 5G jedro se namesti z uporabo dveh Helm chartov35: Helm chart za namestitev jedrnih funkcij ter Helm chart za namestitev upravitelja elementov. Namestitev predvideva Kubernetes gručo z nekaterimi vnaprej nameščenimi sistemskimi aplikacijami ter s posebnimi delovnimi vozlišči36 za povezave N2, N3 in N6. 3.5.1 Omrežna arhitektura 5G jedra na Kubernetes gruči Večina aplikacij 5G rešitve lahko teče na splošnih delovnih vozliščih Kubernetes gruče. Posebni sta omrežni aplikaciji AMF in UPF, ki zahtevata dodatne omrežne vmesnike, ter dodatno konfiguracijo omrežja izven Kubernetes gruče. Slika 12 prikazuje primer postavitve 5G jedra na Kubernetes gruči s posebnimi delovnimi vozlišči. Kubernetes gruča je zgrajena iz treh vozlišč Kubernetes kontrolne ravni37 (m1, m2, m3), treh splošnih delovnih vozlišč (w1, w2, w3) ter dveh posebnih delovnih vozlišč (w-amf, w-upf). Aplikacije upravitelja elementov, infrastrukturne 34 https://www.dpdk.org/ 35 https://helm.sh/docs/topics/charts/ 36 delovno vozlišče – izvorno "worker node" 37 Kubernetes kontrolna raven – izvorno "Kubernetes control plane" 60 U. Zaletel et al.: Vpeljava zabojnikov v oblačno zasnovana zasebna omrežja 5G.. aplikacije ter jedrne aplikacije tečejo na splošnih delovnih vozliščih. Izjema sta aplikaciji AMF in UPF, ki potrebujeta vozlišča s posebnimi omrežnimi vmesniki za komunikacijo z zunanjim svetom. Slika 12: Omrežje 5G jedra na Kubernetes gruči. Omrežna funkcija AMF je vezana na vozlišče w-amf, ki vsebuje omrežni vmesnik N2. Preko omrežnega vmesnika N2 teče kontrolna signalizacija med AMF in bazno postajo (gNB38). Omrežna funkcija UPF teče na vozlišču w-upf, ki vsebuje omrežna vmesnika N3 ter N6. Omrežni vmesnik N3 predstavlja povezavo za podatkovni promet med UPF in bazno postajo. Omrežni vmesnik N6 predstavlja povezavo za podatkovni promet med UPF in podatkovnim omrežjem (DN). 3.5.2 Infrastrukturne aplikacije Namestitev 5G jedra na Kubernetes gručo zahteva nekatere vnaprej nameščene infrastrukturne aplikacije: • Nadzorni sklad Prometheus39 • Podatkovna baza MongoDB • Pošiljatelj dnevnikov FluentD40 ter zbiratelj dnevnikov Loki41. Kubernetes gruča mora ponujati naslednje komponente: • Ingress controller42 • Shrambni razred (StorageClass) • Omrežni vtičnik Multus Zgoraj naštete komponente najdemo v večini produkcijskih Kubernetes gruč. Največja posebnost sta vtičnik Multus ter dodatni omrežni vmesniki za povezave N2, N3, N6, ki morajo biti na voljo preko posebnih delovnih vozlišč. Zaradi posebnih omrežnih povezav potrebujemo vsaj eno delovno vozlišče, ki nam omogoča dodajanje poljubnih omrežnih vmesnikov. Pomembno se je zavedati, da nekatere Kubernetes distribucije ne predvidevajo posegov v operacijske sisteme vozlišč. Primer je OpenShift, ki za svoja vozlišča uporablja nepremičen ("immutable") operacijski sistem CoreOS. Vozlišča s posebnimi omrežnimi vmesniki označimo s pomočjo Kubernetes label. Te labele so vhodni podatek za Helm charte pri namestitvi jedrnih aplikacij. 38 https://www.5g-networks.net/5g-technology/5g-terminology-the-gnb/ 39 nadzorni sklad Prometheus, izvorno "Prometheus monitoring stack", https://prometheus.io/ 40 https://www.fluentd.org/ 41 https://grafana.com/oss/loki/ 42 https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/ 61 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 3.5.3 Nadzor aplikacij 5G jedra Upravitelj elementov ponuja uporabniku pregledno nadzorno ploščo, ki prikazuje stanje 5G jedra. Nadzorna plošča omogoča namestitve in posodobitve aplikacij 5G jedra. Omogoča uporabniku prijazno konfiguracijo parametrov 5G omrežja, prav tako omogoča upravljanje z uporabniki 5G omrežja. Upravitelj elementov spremlja stanje 5G aplikacij preko metrik nadzornega sklada Prometheus. Uporabniku ponuja grafični prikaz stanja 5G aplikacij ter stanja resursov platforme. Nadzorna plošča uporabniku pomaga pravilno konfigurirati aplikacije 5G jedra, prav tako ga opozarja v primeru nepravilnega delovanja kakšne od 5G komponent. Podrobnejši pregled metrik je možen na nadzorni plošči Grafana. 3.6 DevSecOps postopki Za interni razvoj 5G aplikacij uporabljamo številna DevSecOps orodja, za grajenje komponent, izvajanje funkcionalnih testov ter, varnostno skeniranje izdanih aplikacij. GitLab CI/CD, Grype, Trivy, Syft, DefectDojo, Dependency Track, IXIA in UERANSIM nam pomagajo pri izvajanju varnostnih preverjanj in zagotavljanju kakovosti kode. Eno od ključnih načel DevSecOps je vključevanje varnostnih preverjanj v celotni proces CI/CD. Varnostne smernice je treba upoštevati že v zgodnjih fazah razvojnega cikla. To pomeni, da je potrebno izvajati varnostne preglede zabojnikov, slike in kode že v fazi razvoja kode. To zahteva sodelovanje med varnostnimi strokovnjaki in razvijalci ter vključitev varnostnih orodij v avtomatizirane procese razvoja. Cevovodi nam omogočajo izvajanje testov ranljivosti na zabojnikih, kateri nam podajo najnovejše varnostne luknje po CVE43. Z namenom zagotavljanja celovite varnosti upravljamo z vsemi najdenimi ranljivostmi ter jih spremljamo, dokumentiramo in odpravljamo. Za upravljanje varnostnih pomanjkljivosti in ranljivosti programske opreme uporabljamo orodje Defect Dojo44. S pomočjo specializiranih orodij izvajamo statično analizo kode. Cevovod vključuje gradnjo SBOM45, ki omogoča natančno sledenje in upravljanje vseh komponent našega sistema. S tem se zagotavlja transparentnost in sledljivost vseh elementov. Za preverjanje delovanja in ustreznosti rešitve, nočni cevovodi redno izvajajo nočne regresijske teste. Poln nabor testov se izvede tudi pred vsako objavo novega programskega paketa. S tem zagotavljamo, da je vsak korak preizkušen, preden se nadaljuje z objavo programskega paketa in s postopki verificiranja. Napake ugotovljene med avtomatičnimi testi se rešuje prioritetno. CI/CD cevovod izvaja avtomatsko namestitev 5G rešitve z uporabo orodja Helm. To orodje nam zagotavlja ponovljivost namestitve ter sledenje celotni namestitveni konfiguraciji v sistemu za verzioniranje. Vsebina programskega paketa je definirana v konfiguracijski datoteki, kjer so shranjene verzije posameznih komponent (verzije Helm chartov ter verzije Docker slik). V datoteki se natančno opredeli vse potrebne komponente, njihove verzije ter druge pomembne informacije, ki so bistvene za postopek gradnje paketa. S tem se zagotovi doslednost in pravilno usklajenost med različnimi cevovodi ter omogoča učinkovito izvajanje nadaljnjih korakov. Pred objavo paketa se izvede vsa prej omenjena preverjanja (preverjanje ranljivosti, statična analiza kode, testi). Cevovode se še vedno nadgrajuje in dopolnjuje z namenom avtomatizacije in optimizacije vseh omenjenih korakov ter vpeljavo novih. 43 CVE – izvorno "Common Vulnerabilities and Exposures", https://www.cve.org/ 44 https://www.defectdojo.org/ 45 seznam sestavnih delov – izvorno "Software Bill of Materials", okrajšava "SBOM" 62 U. Zaletel et al.: Vpeljava zabojnikov v oblačno zasnovana zasebna omrežja 5G.. 3.6.1 Cevovod za gradnjo novega paketa Na sliki 13 je prikazan cevovod, ki se sproži ob zahtevi za gradnjo nove paketne izdaje 5G rešitve. Osnovni cevovod vključuje tudi klice dodatnih cevovodov za specifične naloge. Slika 13: Prikaz cevovoda ob gradnji nove paketne izdaje. Glavni koraki cevovoda, ki se izvedejo ob zahtevi za nov paket 5G rešitve: • Gradnja Docker slik in Helm chartov, shranjevanje rezultatov gradnje v Nexus46, • Cevovod za avtomatsko postavitev upravitelja jedra, • Cevovod za avtomatsko postavitev 5G jedra, • Avtomatski testi za 5G jedro z orodjem IXIA47, • Dinamična analiza kode ter odlaganje poročil na Defect Dojo, • Generiranje SBOM na vseh zabojnikih in odlaganje poročil na Dependency Track48, • Statična analiza kode, ranljivostni testi zabojnikov z orodji Grype in Trivy, odlaganje poročil na Defect Dojo. 46 Repozitorij, https://www.sonatype.com/products/sonatype-nexus-repository 47 https://support.ixiacom.com/ 63 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 4 Zaključek 5G zagotavlja številne prednosti in izboljšave v primerjavi s prejšnjimi generacijami mobilnih omrežij. Za zagotavljanje večjih hitrosti prenosa, nižjih zakasnitev, večje omrežne zmogljivosti in večje varnosti, igra ključno vlogo jedro 5G omrežja. V članku je predstavljeno jedro 5G omrežja kot kompleksna rešitev, ki mora omogočati razširljivost, zanesljivost in prilagodljivost za namestitev pri različnih strankah. Omenjene zahteve se rešuje s postavitvijo zabojnikov 5G rešitve v oblačno zasnovano omrežje. Za zagotavljanje večjih hitrosti in manjših zakasnitev uporabniškega prometa se uporabi specifične sistemske komponente (Multus, DPDK). Zaradi uporabe različnih tehnologij in programskih jezikov je potrebno veliko pozornosti in časa nameniti DevSecOps postopkom. Začeten vložek v gradnjo cevovodov se kmalu povrne v obliki stabilne in zanesljive rešitve. Poleg tega je potrebno nameniti velik poudarek tudi varnostnemu preverjanju rešitve že od zgodnje faze razvoja kode in vse do končne postavitve rešitve. Ob razvoju 5G rešitve kot oblačno zasnovanega omrežja smo prišli do ugotovitve, da je potrebno za samo obvladovanje namestitev in posodobitve rešitve ter kvalitetnih DevSecOps postopkov nameniti veliko časa in vložka. Poleg tega je ključno tesno sodelovanje med razvojno in DevSecOps ekipo. Literatura [1] https://www.3gpp.org/technologies/5g-system-overview, 3rd Generation Partnership Project (3GPP), obiskano 28.6.2023 [2] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16) [3] https://blog.se.com/telecommunications/2022/07/28/the-evolution-of-5g-and-the-backup-power-it-requires/, obiskano 4.7.2023 [4] https://www.3gpp.org/news-events/3gpp-news/sys-architecture, obiskano 10.7.2023 [5] https://devopedia.org/5g-quality-of-service, obiskano 10.7.2023 [6] https://www.redhat.com/en/topics/cloud-native-apps/vnf-and-cnf-whats-the-difference, obiskano 13.7.2023 [7] https://www.analog.com/en/analog-dialogue/articles/massive-mimo-and-beamforming-the-signal-processing- behind-the-5g-buzzwords.html, obiskano 4.7.2023 64 Izkušnje pri skaliranju večje rešitve z zabojniki Andrej Krajnc, Vojko Ambrožič, Bojan Štok IZUM – Institut informacijskih znanosti, Maribor, Slovenija andrej.krajnc@izum.si, vojko.ambrozic@izum.si, bojan.stok@izum.si Sistem COBISS sestavlja več aplikacij in mikrostoritev, javnost pozna predvsem spletno aplikacijo COBISS+. Pred tremi leti smo začeli prenovo aplikacije COBISS3, ki jo knjižničarji uporabljajo za poslovanje knjižnice (zaloga, nabava, izposoja, serijske publikacije, elektronski viri, izpisi). Obstoječa verzija aplikacije je večslojna in uporablja grafični uporabniški vmesnik Java Swing. Nova generacija aplikacije COBISS4 ima spletni uporabniški vmesnik, podpira vse funkcionalnosti, ki jih ima obstoječa aplikacija, pri čemer gre za kompleksno aplikacijo z nekaj 1000 poslovnimi entitetami. Obe aplikaciji uporabljata isti zaledni strežnik, ki teče za vsako od več kot 1400 knjižnic, pri čemer za večje knjižnice teče več instanc aplikacije. Nameščanje in nadgradnja več kot 2000 instanc je v virtualnem okolju zelo zahtevna, zato smo se odločili za uporabo zabojnikov. Analizirali smo dva različna orkestratorja za zabojniško okolje. Odločili smo se za uporabo Docker Swarm, ker je namestitev in vzdrževanje precej bolj enostavno kot pri orkestratorju Kubernetes. Celotni postopek smo avtomatizirali z orodjem Ansible, delovanje aplikacij in mikrostoritev pa nadziramo in spremljamo z orodjem Prometheus. Za izenačevalnik obremenitve smo uporabili Traefik. Izkušnje pri delovanju gruče so pozitivne, prav tako je sistem zelo stabilen in obvladljiv. Načrtujemo, da bomo v prihodnje uporabili zabojnike še pri razvoju drugih aplikacij v sistemu COBISS. Ključne besede: COBISS COBISS Lib zabojniki Docker Swarm IT arhitekture ISBN 978-961-286-772-0 DOI https://doi.org/10.18690/um.feri.8.2023.6 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 1 Uvod Institut informacijskih znanosti (IZUM) razvija informacijski servis slovenske znanosti, kulture in izobraževanja. Javnosti najbolj poznan je sistem COBISS, ki predstavlja temelj knjižničnega informacijskega sistema Slovenije in nekaterih drugih držav, ki so povezane v mrežo COBISS.net. V mrežo COBISS.net so poleg Slovenije povezane še Srbija, Severna Makedonija, Bosna in Hercegovina, Črna gora, Albanija in Bolgarija. Sistem COBISS ni le ena sama aplikacija, temveč zaobjema več aplikacij in mikrostoritev. Splošni javnosti sta najbolj znani spletna aplikacija COBISS+ in mobilna aplikacija mCOBISS. Ti aplikaciji uporabnikom knjižnic, ki iščejo relevantne informacije, knjižnično gradivo ali e-vire, omogočata iskanje, rezervacije, podaljšanje roka izposoje itd. Za same knjižnice je najpomembnejša knjižnična aplikacija, ki jo IZUM razvija posebej za knjižnice. COBISS3 je tretja generacija te programske opreme, ki pokrivajo posamezna ključna področja avtomatizacije knjižničnih postopkov. COBISS3 je namizna aplikacija, ki jo knjižničarji uporabljajo za poslovanje knjižnice (zaloga, nabava, izposoja, serijske publikacije, elektronski viri, izpisi). Aplikacija COBISS3 je večslojna, napisana je v programskem jeziku Java oz. s pomočjo nabora orodij za gradnike grafičnega vmesnika za Javo, torej s pomočjo knjižnice Swing. Nova generacija knjižničnih aplikacij se imenuje COBISS Lib in je na voljo kot spletna aplikacija. Grafični vmesnik v aplikaciji COBISS Lib je narejen s pomočjo ogrodja Vaadin, ki omogoča razvoj spletnih aplikacij z uporabo spletnih komponent [1]. Aplikacija COBISS Lib podpira vse funkcionalnosti, ki jih ima obstoječa aplikacija, pri čemer gre za kompleksno aplikacijo z nekaj 1000 poslovnimi entitetami. Obe aplikaciji (COBISS3 in COBISS Lib) uporabljata isti zaledni strežnik, ki teče za vsako od več kot 1400 knjižnic, pri čemer za večje knjižnice teče več instanc aplikacije. Nameščanje in nadgradnja več kot 2000 instanc je v virtualnem okolju zelo zahtevna, zato smo se pri COBISS Lib odločili za uporabo zabojnikov. Slika 1: Arhitektura knjižničnih aplikacij COBISS3 in COBISS Lib. 66 A. Krajnc et al.: Izkušnje pri skaliranju večje rešitve z zabojniki.. 2 Uporaba orkestratorjev za zabojniško okolje 2.1 Primerjava orkestratorjev Kubernetes in Docker Swarm Pri uporabi zabojnikov je pomembna izbira orkestratorja za zabojniško okolje. S pomočjo orkestratorja dosežemo visoko razpoložljivost (gruče) in visoko skalabilnost storitev. Analizirali smo dva različna orkestratorja za zabojniško okolje: Kubernetes in Docker Swarm. Odločili smo se za uporabo Docker Swarm, ker je namestitev in vzdrževanje precej bolj enostavno kot pri orkestratorju Kubernetes. V nadaljevanju je na kratko opisana primerjava orodij Docker Swarm in Kubernetes. Swarm in Kubernetes sta orodji za orkestracijo zabojnikov, ki pomagata pri upravljanju in razporejanju storitev v oblačnih okoljih. Kubernetes je naprednejši in bolj uveljavljen, toda mi smo se odločili za Swarm, ker je brezplačen, zelo enostaven za vzpostavitev in vzdrževanje. Prav tako ni treba izvesti dodatne namestitve, saj je vključen v samo namestitev Docker. Dodatno še velja omeniti, da je dokumentacija za Swarm odlična. Ocenili smo, da kljub nekaterim pomanjkljivostim še vedno dovolj dobro ustreza našim potrebam. Kubernetes (tudi k8s) je bolj zrel projekt z večjim in bolj razširjenim ekosistemom. Ker je del odprtokodne platforme (Cloud Native Computing Foundation), ima veliko skupnost razvijalcev in podjetij, ki prispevajo k njenemu razvoju, medtem ko je Swarm samo del ekosistema Docker. Kubernetes ima bolj kompleksno arhitekturo. Ta temelji na skupini vozlišč, ki tvorijo gručo. Vsako vozlišče ima glavni krmilnik (ang. control plane), ki upravlja in nadzoruje delovanje gruče. Swarm ima bolj preprosto arhitekturo za upravljanje. Kubernetes ima zmogljivejše orodje za samodejno skaliranje, ki omogoča samodejno prilagajanje števila delujočih instanc aplikacije glede na obremenitev. Swarm prav tako omogoča skaliranje, vendar nima funkcionalnosti za samodejno prilagajanje števila instanc. Oba sistema uporabljata ukazno vrstico za upravljanje in konfiguracijo storitev, kakor tudi deklarativno konfiguracijo z uporabo datotek manifest oz. stack YAML. Te opisujejo želeno stanje sistema, ki ga sistem skuša zadostiti. Kubernetes ima širok nabor funkcionalnosti in dodatkov, ki podpirajo bolj napredne funkcionalnosti, kot so podpora za storitve s stanjem, naprednejše upravljanje z diskovnimi kapacitetami itd. Kubernetes je zgrajen tako, da lahko teče na kateri koli oblačni platformi, medtem ko Docker Swarm deluje samo znotraj izvajalnega okolja Docker. V prihodnosti bomo preverili delovanje naših storitev tudi v okolju Kubernetes. Ker pri nas uporabljamo virtualizacijo vSphere (VMware), bi bila lahko za nas zanimiva Kubernetesova rešitev “vSphere with Tanzu”. To je integrirana rešitev, ki združuje virtualizacijsko platformo vSphere s Kubernetesovo platformo Tanzu. Namenjena je zagotavljanju celovitega orodja za upravljanje in delovanje zabojnikov v virtualiziranih okoljih. 2.2 Arhitektura Docker Swarm Docker Swarm temelji na uporabi rojev (ang. swarm). En roj je sestavljen iz več Dockerjevih gostiteljev oz. vozlišč, ki tečejo v načinu rojev (ang. swarm mode). Ločimo dve vrsti vozlišč: upravljalna in delovna vozlišča. Upravljalna vozlišča (ang. manager nodes) skrbijo za upravljanje roja (upravljanje Dockerjevih instanc), opravljajo funkcije orkestracije in upravljanja gruče itd. Eno izmed upravljalnih vozlišč je vodja (ang. leader) za opravljanje orkestracijskih nalog. Konsistenca stanja upravljalnih vozlišč se zagotavlja z algoritmom soglasja Raft, kjer se med kandidati izvedejo volitve in se med vozlišči določi vodja, druga vozlišča pa postanejo sledilci (ang. followers). 67 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Delovna vozlišča (ang. worker nodes) dobivajo in izvajajo naloge (ang. task), posredovane od upravljalnih vozlišč. Privzeto tudi upravljalna vozlišča opravljajo funkcijo delovnih vozlišč, lahko pa so zgolj upravljalna vozlišča. Na vsakem delovnem vozlišču je agent, ki upravljalnim vozliščem poroča o opravilih, ki so bila dodeljena delovnemu vozlišču. Tako lahko upravljalno vozlišče vzdržuje zaželeno stanje posameznega delovnega vozlišča. Slika 2: Docker Swarm vozlišča. Storitev (ang. service) je definicija nalog, ki naj se izvedejo na upravljalnem ali delovnem vozlišču. Ko se storitev ustvari, se določi, katera zabojniška slika (ang. container image) naj se uporabi in kateri ukazi naj se izvedejo znotraj delujočih zabojnikov. V primeru repliciranih storitev upravljalno vozlišče distribuira določeno število repliciranih nalog med delovna vozlišča. Naloga (ang. task) zaobjema Dockerjev zabojnik in vse ukaze, ki naj se izvedejo znotraj zabojnika. Naloga je atomarna enota v roju. Upravljalna vozlišča dodeljujejo naloge delovnim vozliščem glede na število replik, ki naj bi jih neka storitev imela. Ko je naloga dodeljena nekemu vozlišču, je ne moremo več prestaviti v drugo vozlišče. Naloga se na dodeljenem vozlišču izvede ali pa pade. 68 A. Krajnc et al.: Izkušnje pri skaliranju večje rešitve z zabojniki.. Slika 3: Storitve in naloge Docker Swarm. 3 Traefik Za posrednika med zunanjimi odjemalci in našimi storitvami (dinamični reverse proxy) smo uporabili odprtokodni program Traefik, ki smo ga namestili na eno izmed upravljalnih vozlišč gruče. Traefik nadzira registracijo zabojnikov v mrežo ter nato na osnovi URL-naslova preusmeri zahteve na ustrezno instanco zabojnika naše storitve. Slika 4: Traefik v okolju Docker. 69 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Ker storitev hrani kontekst seje, mora Traefik preusmeriti odjemalčevo zahtevo vedno na isto instanco zabojnika (ang. sticky mode). Navodila za preslikavo zahtev dobi Traefik preko značk (ang. label) v opisu storitve (stack-datoteka). Za visoko razpoložljivost sistema skrbi zunanji izenačevalnik obremenitve (load balancer), ki zahteve na zunanji mreži (DMZ) preusmeri na storitev Traefik na enem izmed upravljalnih vozlišč v notranjem omrežju (intranet). 4 Izgradnja in upravljanje Docker okolja Za inicializacijo roja Swarm, dodajanje oz. odvzemanje upravljalnih in delovnih vozlišč, nameščanje Dockerjevih strežnikov in samih virtualnih strežnikov smo uporabili odprtokodno orodje Ansible, ki je namenjeno upravljanju konfiguracij, namestitvam in avtomatizaciji nalog na večjem številu strežnikov. Naloge opišemo v tako imenovanih Ansible-skriptah (Ansible Playbook). Za upravljanje in nadzor nad Ansible-skriptami smo uporabili odprtokodno spletno platformo AWX, ki je brezplačna različica komercialne platforme Tower podjetja Red Hat. Na osnovi teh orodij je izgradnja roja Swarm rešljiva znotraj nekaj minut. Storitve v roju Swarm so opisane v tako imenovanih stack-datotekah (format YAML). V opisu so navedeni računalniški viri, ki jih storitev potrebuje. Navedeni so parametri in razne nastavitve za storitev, vrata TCP/IP, ki jih storitev izpostavlja in marsikaj drugega. V IZUM-u imamo razvito orodje »Monitor Manager« za izgradnjo meta modela infrastrukture, strežnikov, aplikacijskih strežnikov, baz podatkov, mikrostoritev in modela knjižnic. Na osnovi tega modela se samodejno kreirajo stack-datoteke za storitve in se hkrati namestijo na upravljalna vozlišča roja. Vsaka sprememba na knjižnicah oz. infrastrukturi je takoj zaznana v storitvah roja Swarm. Slika 5: Izsek opisa Dockerjeve storitve za COBISS Lib. Pri razvoju programske opreme uporabljamo tudi odprtokodno orodje Jenkins za neprekinjeno integracijo (Continuous Integration – CI) in neprekinjeno dostavo (Continuous Delivery – CD). Uporablja se za avtomatizacijo gradnje, testiranja in dostave programske opreme, kar omogoča hitro in zanesljivo uvajanje sprememb v aplikaciji. V razvojnem okolju nam orodje Jenkins samodejno dvakrat dnevno generira Dockerjeve posnetke (ang. image) ter jih namesti na naš zasebni Dockerjev repozitorij in nato izvede nadgradnjo naših storitev v roju Swarm. Nadgradnja storitev v produkcijskem okolju ni samodejna in se izvede le na zahtevo. 70 A. Krajnc et al.: Izkušnje pri skaliranju večje rešitve z zabojniki.. Slika 6: Okolje COBISS Lib Docker. 71 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 5 Podporna orodja v Dockerjevem okolju 5.1 Nadzor Dockerjevih storitev Za nadzor nad Dockerjevimi storitvami lahko uporabljamo Dockerjevo konzolo in odprtokodno platformo za upravljanje roja Swarmpit, ki je nameščena na enem izmed upravljalnih vozlišč roja. Slika 7: Primer zaslonske slike orodja Swarmpit. Dnevniške (ang. log) datoteke spremljamo prek konzole, zbiramo jih pa tudi na skupnem NFS-strežniku, kjer izvajamo analize teh podatkov. V prihodnosti načrtujemo namestitev vtičnika za odprtokodno orodje Elasticsearch, ki je namenjeno indeksiranju, shranjevanju in iskanju velikih količin strukturiranih in nestrukturiranih podatkov v realnem času. Slika 8: Skupni NFS-strežnik. Virtualne strežnike nadzorujemo tudi z odprtokodnim orodjem Icinga, ki omogoča odkrivanje težav, generiranje opozoril in spremljanje zmogljivosti. 72 A. Krajnc et al.: Izkušnje pri skaliranju večje rešitve z zabojniki.. 5.2 Zbiranje in spremljanje metrik v Dockerjevem okolju Za zbiranje in spremljanje metrik našega okolja uporabljamo odprtokodne storitve Swarmprom, ki združujejo orodja odprtokodnih projektov Prometheus in Grafana. Prometheus je sistem za spremljanje in zbiranje metrik, ki se osredotoča na zbiranje časovno vrstičnih podatkov. Spremlja zdravstveno stanje, zmogljivost in druge metrike iz različnih virov v realnem času. Metrike se shranjujejo lokalno in omogočajo analizo, vizualizacijo in generiranje opozoril prek orodja Alert manager. Grafana je platforma za vizualizacijo metrik in analizo podatkov. Omogoča ustvarjanje prilagojenih grafov, nadzornih plošč in poročil iz metrik, ki jih zbere Prometheus. 5.3 Diagnostična orodja v Dockerjevem okolju V primeru težav z našimi storitvami lahko uporabimo bolj ali manj vsa diagnostična orodja, ki smo jih vajeni uporabljati v klasičnih okoljih. Med drugim si pomagamo z različnimi javanskimi orodji, kot so jmap, jstack itd. 6 Zaključek Praktične izkušnje pri delovanju roja Docker Swarm so zelo pozitivne, prav tako je sam sistem zelo stabilen in obvladljiv. Čeprav je Docker Swarm manj zmogljiv orkestrator kot Kubernetes, se je izkazal kot primerna izbira, saj vsebuje vse, kar potrebujemo pri aplikaciji COBISS Lib. Če bi se slučajno pojavile težave z obstoječo gručo, lahko zelo hitro (v nekaj minutah) namestimo novo gručo Docker Swarm, saj je sam postopek namestitve avtomatiziran. Načrtujemo, da bomo v prihodnje uporabili zabojnike še pri razvoju novih aplikacij v sistemu COBISS in da bomo obstoječe spletne aplikacije in mikrostoritve, ki zdaj tečejo v navideznih strežnikih, preselili v zabojnike. Zabojnikov ta trenutek ne bomo uporabili za shrambo podatkovnih baz, kot so PostgreSQL, Apache Solr, ElasticSearch itd. Za te storitve bomo še naprej uporabljali virtualne strežnike. V prihodnosti bomo sistem NFS, ki ga zdaj uporabljamo za dnevniške datoteke, nadomestili s porazdeljenimi diski Ceph in vpeljavo shrambe S3. Literatura [1] KRAJNC Andrej, PULKO Jani, KOROŠEC Andrej, ŠTOK Bojan, "Razvoj spletnih aplikacij z uporabo spletnih komponent", Sodobne informacijske tehnologije in storitve OTS 2022: Zbornik petindvajsete konference, Maribor, Fakulteta za elektrotehniko, računalništvo in informatiko, Inštitut za informatiko, 42-54. [2] Kubernetes, https://kubernetes.io/, obiskano 13.7.2023 [3] Docker Swarm, https://docs.docker.com/engine/swarm/, obiskano 13.7.2023 [4] Traefik, https://traefik.io/traefik/, obiskano 13.7.2023 [5] Ansible, https://www.ansible.com/, obiskano 13.7.2023 73 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 74 Monolitne rešitve za mikrostoritvene izzive Miroslav Beranič Bintegra d.o.o., Maribor, Slovenija miroslav@beranic.si V članku bom raziskal Quarkus, ogrodje za razvoj Java aplikacij. Z optimiziranimi lastnostmi delovanja ogrodje primarno cilja na razvoj Java aplikacij v oblaku. Quarkus se osredotoča na hitrost, majhen odtis pomnilnika in nizko latenco; sebe opisuje kot “supersonic subatomic Java”. Ena izmed ključnih sestavin Quarkusa je GraalVM, ki omogoča hitrejši čas zagona aplikacij in učinkovito porabo virov s pretvorbo Java kode v native obliko, brez vmesnega Java VM. To je še posebej koristno za mikrostoritvene arhitekture. V članku bom pregledal tudi konkurenčne rešitve ter primerjal prednosti Quarkusa v primerjavi z drugimi razvojnimi ogrodji za oblak. Predstavil bom preprost primer uporabe Quarkusa, da bo bralec dobil vpogled v način razvoja in delovanje. Kot praktičen primer bo opisan tudi način objave aplikacije v sistemu za upravljanje z mikrostoritvam. S celovito analizo Quarkusa in tehnologije GraalVM bo članek bralcu omogočil boljše razumevanje in uporabno ter izkoristek teh inovativnih rešitev za razvoj Java aplikacij v oblaku. Članek se lahko uporabi kot vodnik: kako lahko Quarkus izboljša izkušnje pri razvoju sodobnih oblačnih storitev in aplikacij. Ključne besede: Quarkus Java GraalVM mikrostoritve Kubernetes ISBN 978-961-286-772-0 DOI https://doi.org/10.18690/um.feri.8.2023.7 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 1 Uvod Dobrodošel v svetu Quarkusa - inovativnega ogrodja za razvoj Java aplikacij v oblaku [1]. Quarkus je bil zasnovan, da odpravi izzive tradicionalnih pristopov razvoja in zagona aplikacij in ponudi razvijalcem visoko zmogljive rešitve. S svojo osredotočenostjo na hitrost, majhen odtis pomnilnika in nizko latentnost, Quarkus omogoča razvoj izjemno odzivnih aplikacij. V tem članku bom raziskal bistvo Quarkusa, kako deluje in zakaj je postal priljubljen med razvijalci. Osvetlil bom tehnologijo GraalVM, ki prispeva k izjemno hitremu zagonu aplikacij. Poleg tega bom analiziral konkurenčne rešitve na trgu, da boš razumel, kako se Quarkus primerja z njimi in kakšne so prednosti ter slabosti. Pogledal bom tudi, kaj je novega v verziji 3 in v čem se razlikuje s predhodno iteracijo. Za lažje razumevanje bom predstavil praktičen primer uporabe, ki bo razkril, kako Quarkus izboljša učinkovitost in odzivnost aplikacij. S tem boš dobil vpogled v to, kako enostavno je razvijati aplikacije z Quarkusom in kako ta tehnologija prinaša konkurenčno prednost. Predstavljeno aplikacijo bom zagnal preko aplikacije za upravljanje z mikrostoritvami. Brez komercialnih buzzwordov in v tehničnem kontekstu bom raziskal vse vidike Quarkusa, kar ti bo pomagalo bolje razumeti njegove koristi in možnosti za razvoj Java aplikacij v oblaku. 2 Quarkus 2.1 Zgodovina Ogrodje Quarkus ima objavljeno prvo verzijo, 0.0.1, dne 12.12.2018 [3], prvi zapis v zgodovini izvorne kode je bil narejen dne 22.6.2018 [4]. Časovno to pomeni, da je ogrodje relativno mlado in hkrati hitro rastoče in razvijajoče, če vemo, da je trenutna verzija 3.3.2 z dne 21.7.2023 [5]. Verzijo 1.0 ( 1.0.0.Final ) je doseglo dne 25.11.2019, verzijo 2.0 ( 2.0.0.Final ) dne 30.6.2021 in verzijo 3.0 ( 3.0.0.Final ) dne 26.4.2023. Tabela 1: Krajši pregled zgodovine verzij. Verzija Datum Glavne lastnosti 0.0.1 12.12.2018 Prva verzija, praktično skelet projekta in osnovni koncepti. Izboljšana podpora za Apache Maven, uporablja se fedora-minimal za zabojnik, 0.2.0 19.12.2018 podpora za referenciranje Java razredov preko imen. 0.18.0 27.6.2019 GraalVM 19, native image je ločen paket izven GraalVM Dodan quarkus-jackson, REST client privzeto uporablj RESTEasy, premik 0.20.0 31.7.2019 razširitev za Apache Camel v ločen projekt. 1.0.0 25.11.2019 Stabilizacija in uporaba GraalVM 19.2.1, uporaba Quarkus Security 1.0.0. Ločen build za native-image, uvedba YAML za nastavitve, uporaba GraalVM 19.3, 1.1.0 17.12.2019 zagon samostojne RESTeasy aplikacije v glavni niti. 1.2.0 23.1.2020 Razširitev za zalogo ( cache ), Hibernate ORM Nov classloader in podpora za GraalVM 20.0.0, ena Vert.x instanca, dopolnjena podpora za deploy v OpenShift implementacija Eclipse MicroProfile specifikacije 1.3.0 13.3.2020 3.3. Minimalno Java 11, uporaba GraalVM 21.1, Vert.x 4 ter implementacija 2.0.0 30.6.2021 MicroProfile 4, Hibernate 5.5, MongoDB in Panache s podporo za transakcije. 2.1.0 29.7.2021 Podpora Dev Services za Keycloak, Reactive SQL Server, Kotlin 1.5 2.2.1 31.8.2021 Podpora za GraalVM 21.2 2.3.0 6.10.2021 Podpora za Jakarta EL 3 76 M. Beranič: Monolitne rešitve za mikrostoritvene izzive.. Verzija Datum Glavne lastnosti Podpora za Hibernate ORM 6, Hibernate Reactive 2, izboljšan Dev UI, Jakarta 3.0.0 26.4.2023 EE 10, uporaba OpenTelemetry 3.1.0 31.5.2023 Podpora za GraalVM 22.3.2, Kotlin 1.8.21 3.2.0 5.7.2023 Dodana analitika v korake izgradnje. Vir: [2]. 2.1.1 GraalVM GraalVM je visoko zmogljiva in univerzalna virtualna strojna oprema ( VM ) ter razvojno orodje, ki ga je razvilo podjetje Oracle [5]. Omogoča izvajanje različnih programskih jezikov, kot so Java, JavaScript, Python, Ruby, R, in drugi, na istem virtualnem stroju. To je edinstvena značilnost GraalVM, saj večina drugih VM-jev podpira izvajanje samo enega programskega jezika. GraalVM se ponaša z izjemno visoko zmogljivostjo in učinkovitostjo, kar je doseženo s tehnologijo Just-In-Time (JIT) prevajanja, ki pretvori visokonivojski kode v izvorno kodo, ki jo lahko izvaja procesor. Ta tehnologija omogoča hitrejše zaganjanje in izvajanje aplikacij, saj se izvorna koda prilagaja konkretnemu okolju in arhitekturi sistema. Ena izmed posebnosti GraalVM je tudi možnost prevajanja Java bytecode-a v native kodo. To omogoča ustvarjanje native izvedljivih aplikacij, ki ne potrebujejo ločenega nameščanja virtualnega stroja za njihovo delovanje. S tem se doseže še večja učinkovitost in zmanjša odtis pomnilnika, kar je ključnega pomena za izvajanje aplikacij v oblaku in v mikrostoritvenih arhitekturah. GraalVM se uporablja v različnih scenarijih, kot so optimizacija izvajanja Java aplikacij, izvajanje več programskih jezikov na istem VM-ju, izdelava native izvedljivih aplikacij in celo kot razvojno orodje za ustvarjanje novih programskih jezikov in prevajalnikov programske kode. Zaradi svoje zmogljivosti, vsestranskosti in inovativnih trikov je GraalVM postala priljubljena izbira za razvijalce, ki želijo izboljšati odzivnost svojih aplikacij in optimizirati njihovo delovanje v različnih okoljih [6]. Glavne razlike GraalVM v primerjavi z klasičnim JDK so: 1. GraalVM Compiler, JIT prevajalnik za Java 2. GraalVM Native Image, ki omogoča prevajanje Java aplikacij v izvorno kodo pred časom (AOT - ahead-of-time) 3. Ogrodje za implementacijo jezikov Truffle in GraalVM SDK, za dodajanje izvajanja programskih jezikov 4. LLVM Runtime in JavaScript Runtime Slika 1: Shema arhitekture GraalVM Vir: [7]. 77 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 2.1.2 Mandrel Mandrel je različica GraalVM skupnostne izdaje - GraalVM CE. Glavni cilj Mandrela je zagotoviti izdelave native-image-a, posebej prilagojenega za podporo Quarkus-a. Namen je uskladiti podporo za native-image med GraalVM z OpenJDK in knjižnicami Red Hat Enterprise Linux, da se izboljša podpora za native Quarkus aplikacije. Mandrel se lahko najbolje opiše kot različica običajnega OpenJDK s posebej zapakiranim graditeljem GraalVM Native Image (native-image). Mandrel izdaje so zgrajene iz kode, ki izhaja iz izvorne kode GraalVM, pri čemer so narejene le manjše spremembe, vendar nekatere pomembne izključitve. Polna distribucija GraalVM presega native-image: vključuje podporo za več programskih jezikov (polyglot), ogrodje Truffle, ki omogoča učinkovito izvajanje interpreterjev, prevajalnik LLVM za native image, JIT prevajalnik libgraal kot zamenjavo za HotSpot-ov C2 strežni prevajalnik in še veliko več. Mandrel predstavlja majhen podsklop funkcionalnosti, ki se potrebujejo za uporabo z native-image [8]. Mandrel-ova izdaja native-image tudi ne vključuje naslednjih funkcij: • Eksperimentalni strežnik za gradnjo slik, tj. možnost --experimental-build-server • Prevajalnik LLVM, tj. možnost - H:CompilerBackend=llvm • Implementacija musl libc, tj. možnost --libc=musl • Podpora za ustvarjanje statičnih native slik, tj. možnost --static • Podpora za jezike, ki niso osnovani na JVM, in polyglot, tj. možnost --language: Mandrel je zgrajen nekoliko drugače od GraalVM, ki uporablja standardno izdajo projekta OpenJDK verzije JDK17. To pomeni, da ne izkoristi nekaj majhnih izboljšav, ki jih je Oracle dodal v različico OpenJDK, ki se uporablja za gradnjo njihovih lastnih GraalVM distribucij. Večina teh izboljšav je v modulu JVMCI, ki omogoča zagon Graal prevajalnika znotraj OpenJDK. Ostale so manjše kozmetične spremembe v delovanju. Te izboljšave lahko v nekaterih primerih povzročijo manjše razlike v postopku generiranja native slik. Sama izvedba slik naj ne bi povzročila opaznih razlik v načinu izvajanja. 2.1.3 Microprofile Eclipse MicroProfile je odprtokodni projekt, ki je namenjen razvoju mikrostoritvenih aplikacij na platformi Java. Projekt je bil ustanovljen leta 2016 kot skupna pobuda več tehnoloških podjetij in organizacij, vključno z Eclipse Foundation, Red Hat, IBM, Payara, Tomitribe in drugimi [9]. Glavni cilj Eclipse MicroProfile je poenostaviti razvoj mikrostoritvenih aplikacij in zagotoviti standardizirano platformo za izgradnjo in upravljanje mikrostoritvenih arhitektur v Java okolju. MicroProfile temelji na obstoječih Java EE (Java Platform, Enterprise Edition) tehnologijah in specifikacijah, ter dodaja nove funkcionalnosti in lastnosti, ki so posebej zasnovane za potrebe mikrostoritvenih aplikacij. Med glavnimi lastnostmi in specifikacijami, ki jih prinaša Eclipse MicroProfile, so podpora za zaganjanje mikrostoritvenih aplikacij v oblaku, upravljanje konfiguracije, sledenje (tracing), upravljanje z napakami, varnost in še več. Vse te lastnosti so zasnovane z mislijo na prilagodljivost, lahkotnost in učinkovitost, ki so ključnega pomena za razvoj in izvajanje mikrostoritvenih aplikacij. Eclipse MicroProfile je postal zelo priljubljen med razvijalci, ki se ukvarjajo z razvojem oblačnih in mikrostoritvenih aplikacij. Projekt je v aktivnem razvoju in se hitro razvija, saj skupnost neprestano prispeva z novimi funkcionalnostmi in izboljšavami. Standardizacija, ki jo prinaša Eclipse MicroProfile, omogoča razvijalcem, da svoje mikrostoritvene aplikacije izdelujejo na enoten način, kar olajša prenosljivost aplikacij med različnimi platformami in omogoča boljšo vzdrževanost ter skalabilnost. 78 M. Beranič: Monolitne rešitve za mikrostoritvene izzive.. 2.1.4 Quarkus Quarkus je ogrodje, ki temelji na številnih povezanih in ločenih projektih ter jih povezuje v uporabno celoto. Primaren fokus ogrodja je razvoj oblačnih rešitev, a to ne pomeni, da ni mogoče razvijati “klasičnih” aplikacij. Zadnja večja iteracija ogrodja je verzija 3, ki prinaša posodobitve z zunanjimi knjižnicami in ogrodji ter prvič dolgoročno podprto verzijo, ki zagotavlja stabilizacijo in podporo za daljše časovno obdobje. Quarkus omogoča izgradnjo aplikacije, ki je v primerjavi z klasičnim načinom razvoja hitrejša v času izvajanja. Slika 2: Razlike v načinu zagona aplikacij Vir: [10]. Praviloma velja, da se prihranek na eni strani pozna na drugi strani. Pri Quarkusu to pomeni, da potrebuje več časa za prevajanje in pripravo zagonske slike aplikacije. Daljše prevanje pa je posledica, ker Quarkus prenese proces razrešitve odvisnosti in preračun izvajanja programske kode v čas prevajanja. Slika 3: Zagon običajnih Java aplikacij in Quarkus Java aplikacije Vir: [11]. 79 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Tak način priprave zagonske aplikacije pomeni, da se pred zagonom pripravi praktično vse, kar se v klasični Java aplikaciji zgodi ob zagonu. Prenos teh korakov v čas gradnje in uporaba t.i. reaktivnih načinov izvajanja programske kode, so glavni stebri razlik in prednosti proti trenutnim klasičnim načinom razvoja. V tradicionalnem oz. imperativnem pristopu ogrodja dodelijo nit za obdelavo zahtevka. Tako celoten postopek zahtevka poteka na tej delovni niti. Ta model se ne skalira zelo dobro. Dejansko za obdelavo več sočasnih zahtevkov potrebujete več niti; in tako je vzporednost vaše aplikacije omejena s številom niti. Poleg tega so te niti blokirane, takoj ko vaša koda komunicira z oddaljenimi storitvami. To vodi v neučinkovito uporabo virov, saj bo morda potreboval več niti, in vsaka nit, saj so preslikane na niti operacijskega sistema, ima strošek v smislu pomnilnika in procesorske moči. Slika 4: Zagon običajnih Java aplikacij in Quarkus Java aplikacije Vir: [12]. Na drugi strani pa reaktivni model temelji na neblokirajočih I/O operacijah in drugačnem modelu izvajanja. Neblokirajoči I/O zagotavlja učinkovit način za ravnanje s sočasnim I/O. Minimalna količina niti, imenovanih I/O niti, lahko obdela veliko sočasnih I/O operacij. S takšnim modelom se obdelava zahtevka ne prenaša na delovno nit, ampak uporablja te I/O niti neposredno. S tem se prihrani pomnilnik in procesorska moč, saj ni potrebe po ustvarjanju delovnih niti za obdelavo zahtevkov. Prav tako izboljša vzporednost, saj odpravlja omejitev glede števila niti. Nazadnje, izboljša tudi čas odziva, saj zmanjša število preklopov niti. Slika 5: Zagon običajnih Java aplikacij in Quarkus Java aplikacije Vir: [13]. 80 M. Beranič: Monolitne rešitve za mikrostoritvene izzive.. Quarkus reaktivnost sledi “Reactive Manifesto”, ki opisuje Reaktiven sistem kot distribuiran sistem, ki ima štiri lastnosti: 1. Odzivni (Responsive) - morajo se odzivati pravočasno. 2. Elastični (Elastic) - prilagajajo se nihajoči obremenitvi. 3. Vzdržljivi (Resilient) - omogočajo grajen prehod ob napakah. 4. Asinhrono posredovanje sporočil (Asynchronous message passing) - komponente reaktivnega sistema medsebojno delujejo preko sporočil. Slika 6: Zagon običajnih Java aplikacij in Quarkus Java aplikacije Vir: [14]. Poleg tega dokument o reaktivnih načelih (Reactive Principles white paper) našteva niz pravil in vzorcev, ki pomagajo pri gradnji reaktivnih sistemov. Reaktivna načela se nahajajo na spletni strani https://www.reactiveprinciples.org/ Quarkus podpora zagon aplikacije v dveh načinih: 1. tradicionalen preko uporabe Java JDK 2. izdelavo binarne oblike za gostiteljevo arhitekturo a. specializirana oblika je “native zabojnik”, ki naredi linux x64 native image ( tudi na ne-linux x64 sistemih ) Native zagonska datoteka zajema celotno aplikacijo in vse odvisnosti. Nabor odvisnosti se je izdelal v času gradnje. Slika 7: Zagon običajnih Java aplikacij in Quarkus Java aplikacije Vir: [15]. 81 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Zabojnik je specializirana oblika, kjer se vse potrebne datoteke za zagon zapakirajo v sliko zabojnika. Slika 8: Zagon običajnih Java aplikacij in Quarkus Java aplikacije Vir: [16]. Zagon preko načina native-image ima specifične lastnosti, ki lahko določenih scenarijih uporabe privede do ne- želenih stranskih učinkov, zato tak način zagona ni najboljša rešitev za vse. Glede na lastnosti in potrebe delovanja aplikacije se izvede odločitev, kdaj uporabiti kateri način zagona. JIT - OpenJDK HotSpot AOT - GraalVM native image • Učinkovita poraba CPU-ja. • Zahteva po veliki količini spomina in • Najboljši Garbage Collector. obdelava velike količine podatkov - recimo • Večja poraba internega spomina. obdelava slik ali velikih datotek. • Obstoječa monitoring in instrumentalna • Veliko število zahtev - zahtev/sekundo. orodja in ogrodja. • Hitrejši prvi zagon. • Knjižnice podpirajo samo klasičen JDK. 3 Alternativne rešitve V zadnjem času so bile ustvarjene alternativne rešitve, ki konkurirajo direktno ali posredno. Pri tem je potrebno imeti v mislih, da je Quarkus, čeprav je odprtokodno ogrodje, primarno otrok Red Hat-a. Že iz tega je pričakovati, da se pojavijo alternativne rešitve. Glavne alternativne rešitve, ki obstajajo so: • Micronaut, • Spring Boot in • OSGi. OSGi je Java specifikacija in ogrodje, ki ima jedro v dinamičnem načinu nalaganja storitev in prilagajanja na spremembe v okolju brez vnovičnih zagonov. Vsa ta dinamičnost je v Quarkus-u praktično nemogoča, saj se vse dinamične variacije razdelajo v času gradnje; kar predstavlja konceptualno drugačnost. OSGi nima nekega lastnika, čeprav nekako spada pod Eclipse fundacijo, največ doprinosa izvorne kode pride iz krogov Red Hat-a. Spring Boot je najstarejše ogrodje in knjižnica, od vseh tukaj opisanih. Razvoj se je začel leta 2012, nato se je v letu 2013 stabiliziralo in uredilo izvorno kodo iz različnih virov ter nato leta 2014 predstavljena verzija 1.0. Spring Boot gradi nad obstoječim in dobro razvitim ter uporabnim ogrodjem Spring Framework. V zadnjem času - letu, tudi Spring Boot podpira in omogoča izdelavo native-image preko GraalVM, podobno kot Quarkus. Spring Boot je preko lastništva pod varstvom VMware-a, ki je del skupine Dell. 82 M. Beranič: Monolitne rešitve za mikrostoritvene izzive.. Micronaut je praktično edina direktna konkurenca. Glede načina razvoja aplikacije in števila ter verzij integriranih zunanjih knjižnic je razlik zelo malo - obe ogrodji sta v aktivnem razvoju in spremembe se dogajajo iz meseca v mesec; če je še pred meseci veljalo da eno ogrodje ne podpira neke knjižnice, se je naslednji mesec dejstvo obrnilo in tako se ponavlja. Glavna razlika, kjer je vidna razlika je v celovitosti celotne vertikale, kjer mislim na podporo in sodelovanje razvojnega okolja, Java API-ja ( vmesniki, anotacije, analiza in predlogi ), dokumentacije - učni material s primeri in na koncu zagon aplikacije - v oblačnem okolju ( aka OpenShift ), je zaenkrat prednost na Quarkus, a to se lahko hitro spremeni. Koncepti so praktično isti - oboje temelji na GraalVM ( tudi Spring Boot, če se primerja po tem kriteriju ). Glavna sestavina je GraalVM in pa vzorci ter knjižnice, ki podpirajo vzorce - recimo Vert.x in OpenTelemetry ter podobno. Micronaut trenutno nima tako podrobno razvitega prevajalnika, ki bi bil sposoben tako podrobno in učinkoviti prevesti in prenesti izvorno kodo v izvajanje. Dodatno k temu Micronaut nima primerljive rešitve za Quarkus Dev Services in pa tako dobre podpore za razvojna okolja - IDE-je. Micronaut je lastniško pod Oracle. 4 Praktični primer Prikazan je praktičen primer razvoja aplikacije z uporabo ogrodja Quarkus 3. Začne se z kreiranjem Java projekta z uporabo Quarkus CLI. Ustvari se PostgreSQL baza s tabelo za hrambo podatkov. Doda se razred za modeliranje podatkovnega modela in za dostop do podatkov v SQL bazi. Na koncu se doda reaktivna REST storitev, ki omogoča osnovne CRUD operacije. Izvorna koda se prevede in naredi paket za zagon. Zagonska datoteka se izvede in z uporabo programa curl se pokliče REST spletni vmesnik. Za kreiranje in delo z Quarkus projekti sta na voljo dva načina: 1. Maven CLI - uporablja se Apache Maven in se preko razširitev kreira in upravlja s projektom 2. Quarkus CLI - uporablja se namenski CLI, ki ima jasno sintakso in omogoča “samodejno dopolnjevanje ukazov” (auto-complete). Uporabljam oboje, čeprav se pogosteje obrnem na Quarkus CLI, ki se bo uporabljal tudi v nadaljevanju. Najlažji način namestitve Quarkus CLI-ja je z uporabo aplikacije SDKMAN! [17]: $ sdk install quarkus Ko imam nameščen Quarkus CLI, lahko ustvarim projekt z ukazom: $ quarkus create app si.beranic:rest-json-quickstart \ --extension='resteasy-reactive-jackson' \ --no-code $ cd rest-json-quickstart Argument --extension='resteasy-reactive-jackson' doda Maven odvisnost v datoteko pom.xml: io.quarkus quarkus-resteasy-reactive-jackson Začnem z kreiranjem podatkovnega modela. Za komunikacijo z SQL bazo se uporablja knjižnica Hibernate, za oblikovanje programskega vmesnika pa knjižnica Panache. Podatkovni model SQL tabele: 83 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. @Entity @Cacheable public class Fruit extends PanacheEntity { @Column(length = 40, unique = true) public String name; } V nastavitveni datoteki src/main/resources/application.properties vpišem parametre za dostop do PostgreSQL baze: quarkus.datasource.db-kind=postgresql quarkus.hibernate-orm.database.generation=drop-and-create Ti parametri so za Quarkus zadostni, da kreira vse potrebno za uspešno komunikacijo in izmenjavo podatkov. V datoteko import.sql vpišem začetne SQL stavke, ki napolnijo SQL tabelo: INSERT INTO fruit(id, name) VALUES (1, 'Cherry'); INSERT INTO fruit(id, name) VALUES (2, 'Apple'); INSERT INTO fruit(id, name) VALUES (3, 'Banana'); ALTER SEQUENCE fruit_seq RESTART WITH 4; Aplikacijo lahko poženemo v t.i. dev mode načinu: $ quarkus dev Quarkus ustvari SQL strežnik z bazo in tabelo primerno za nadaljnji razvoj. Dodam REST API storitev: import jakarta.enterprise.context.ApplicationScoped; import jakarta.ws.rs.Path; @Path("/fruits") @ApplicationScoped public class FruitResource { @GET public Uni> get() { return Fruit.listAll(Sort.by("name")); } @GET @Path("/{id}") public Uni getSingle(Long id) { return Fruit.findById(id); } @POST public Uni> create(Fruit fruit) { 84 M. Beranič: Monolitne rešitve za mikrostoritvene izzive.. return Panache.withTransaction(fruit::persist).replaceWith(RestResponse.status(CREATED, fruit)); } } S tem je aplikacija primerna za testiranje. Z uporabo aplikacije curl preverimo zapis nove vrednosti, preko REST vmesnika v SQL tabelo. $ curl --header "Content-Type: application/json" \ --request POST \ --data '{"name":"Peach"}' \ http://localhost:8080/fruits Aplikacija je pripravljena na prenos v ciljno okolje. Najprej ga prevedem, to lahko naredim na dva različna načina: a.) klasičen “java” način ali b.) “native-image” način. Za klasične način izvedem: $ quarkus build Za “native-image” način izvedem: $ quarkus build --native Na ciljnem okolju se ustvari SQL strežnik, preko zabojnika: $ podman run -it --rm=true \ --name postgres-quarkus -e POSTGRES_USER=quarkus \ -e POSTGRES_PASSWORD=quarkus -e POSTGRES_DB=fruits \ -p 5432:5432 postgres:15.3 Če sem aplikacijo prevedel v klasičen način se izvede: $ java \ -Dquarkus.datasource.reactive.url=postgresql://localhost/fruits \ -Dquarkus.datasource.username=quarkus \ -Dquarkus.datasource.password=quarkus \ -jar target/quarkus-app/quarkus-run.jar Če pa sem program prevedel v “native-image” način, pa izvedem sledeče: $ ./target/getting-started-with-reactive-runner \ -Dquarkus.datasource.reactive.url=postgresql://localhost/fruits \ -Dquarkus.datasource.username=quarkus \ -Dquarkus.datasource.password=quarkus 85 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 5 Zaključek V prispevku smo pogledali začetke in namen ogrodja Quarkus ter načine uporabe. Pogledali smo alternativne rešitve in kako se Quarkus primerja z njimi. Prikazan je način izdelave splošno uporabne native aplikacije, ki se lahko izvaja ročno ali preko uporabe zabojnikov. Predstavitev služi kot priročnik začetniku pri prvih korakih uporabe ogrodja Quarkus od razvoja do zagona. Literatura [1] https://quarkus.io/, Quarkus - Supersonic Subatomic Java, dostopano 1.7.2023 [2] https://github.com/quarkusio/quarkus/releases, Releases · quarkusio/quarkus, dostopano 1.7.2023 [3] https://github.com/quarkusio/quarkus/releases/tag/0.0.1, Release 0.0.1 · quarkusio/quarkus, dostopano 1.7.2023 [4] https://github.com/quarkusio/quarkus/commit/161cfa303b4ea366dbd07e54bf4fe5a67ddec497, Initial · quarkusio/quarkus@161cfa3, dostopano 1.7.2023 [5] https://github.com/quarkusio/quarkus/releases/tag/3.2.2.Final, Release 3.2.2.Final · quarkusio/quarkus, dostopano 23.7.2023 [6] https://en.wikipedia.org/wiki/GraalVM, GraalVM - Wikipedia, dostopano 1.7.2023 [7] https://upload.wikimedia.org/wikipedia/commons/1/13/GraalVM_CE_architecture.png, GraalVM_CE_architecture.png, dostopano 1.7.2023 [8] https://github.com/graalvm/mandrel, graalvm/mandrel, dostopano 1.7.2023 [9] https://microprofile.io/, Home - MicroProfile, dostopano 1.7.2023 [10] https://microprofile.io/workinggroup/#mptab-members, Working Group - MicroProfile, dostopano 1.7.2023 [11] https://quarkus.io/assets/images/quarkus_metrics_graphic_bootmem_wide.png, quarkus_metrics_graphic_bootmem_wide.png, dostopano 1.7.2023 [12] https://quarkus.io/guides/images/build-time-principle.png, build-time-principle.png, dostopano 1.7.2023 [13] https://quarkus.io/guides/images/blocking-threads.png, blocking-threads.png, dostopano 1.7.2023 [14] https://quarkus.io/guides/images/reactive-thread.png, reactive-thread.png, dostopano 1.7.2023 [15] https://quarkus.io/guides/images/reactive-systems.png, reactive-systems.png, dostopano 1.7.2023 [16] https://quarkus.io/guides/images/native-executable-process.png, native-executable-process.png, dostopano 1.7.2023 [17] https://quarkus.io/guides/images/containerization-process.png, containerization-process.png, dostopano 1.7.2023 [18] https://sdkman.io/install, Installation - SDKMAN!, dostopano 1.7.2023 86 Remix: zmogljivo meta-ogrodje za razvoj spletnih aplikacij Gregor Jošt,1 Miha Kočevar2 1 3fs Nordic SI, d.o.o., Maribor, Slovenija gregor.jost@3fs.si 2 AGILEDROP d.o.o., Celje, Slovenija miha.kocevar@agiledrop.si V hitro spreminjajočem se svetu spletnega razvoja imajo ogrodja pomembno vlogo pri poenostavljanju in pospeševanju razvoja zmogljivih in uporabniku prijaznih spletnih aplikacij. Med številnimi ogrodji za razvoj odjemalskega dela spletnih aplikacij se vse bolj uveljavlja Remix, zmogljivo meta-ogrodje, ki temelji na knjižnici React. Medtem ko se knjižnica React odlično obnese pri prikazu elementov uporabniškega vmesnika in njihovih posodobitev, Remix kot ogrodje ponuja celovit pristop razvoja spletnih aplikacij. To vključuje usmerjanje (angl. routing), pridobivanje podatkov, optimizacijo delovanja in boljšo izkušnjo za razvijalce. Med pomembnejše lastnosti ogrodja Remix štejemo generiranje spletne strani na strežniku (angl. server-side rendering), kar izboljšuje učinkovitost, omogoča optimizacijo SEO (angl. search engine optimization) in zagotavlja hitro in učinkovito nalaganje začetne strani. V prispevku se bomo osredotočili na več vidikov ogrodja Remix. Najprej bomo podrobneje predstavili samo ogrodje, raziskali njegovo ozadje in poudarili glavne lastnosti. Poleg tega se bomo posvetili tudi primerjavi ogrodja Remix z nekaterimi obstoječimi meta-ogrodji, narejenimi na podlagi knjižnice React. Sledila bo implementacija majhne aplikacije, ki bo omogočila praktičen prikaz določenih prednosti, ki jih ogrodje prinaša. Skozi ta proces bomo raziskali, kako ogrodje omogoča dinamičnost, pridobivanje podatkov z uporabo gnezdenih poti in kako v splošnem izboljša delovanje spletnih aplikacij. Ključne besede: Remix React meta-ogrodje uporabniški vmesniki spletne aplikacije ISBN 978-961-286-772-0 DOI https://doi.org/10.18690/um.feri.8.2023.8 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 1 Uvod Pri razvoju spletnih aplikacij imajo ogrodja in knjižnice pomembno vlogo, saj zagotavljajo razvijalcem že vnaprej pripravljena orodja in abstrakcije, ki poenostavljajo postopek razvoja. S tega vidika lahko ogrodje definiramo kot celovit nabor orodij, smernic in konvencij, ki omogočajo strukturiran pristop k razvoju aplikacij, medtem ko so knjižnice zbirke modulov kode, ki jih razvijalci selektivno uporabljajo za lažji razvoj. Knjižnice so torej osredotočene na zagotavljanje specifičnih funkcionalnosti, ogrodja pa ponujajo širšo strukturo in bolj strog pristop k razvoju [1]. Ogrodja za razvoj spletnih aplikacij razvijalcem ponujajo zbirko ponovno uporabljivih komponent, orodij in funkcionalnosti, ki poenostavljajo pogoste naloge in zagotavljajo dosledno strukturo za gradnjo aplikacij. Nekatera najbolj znana in pogosto uporabljena ogrodja za razvoj spletnih aplikacij vključujejo Angular, Vue.js ali Svelte [2]. Ponujajo funkcionalnosti, kot so arhitektura na osnovi komponent, vezava podatkov (angl. data binding), upravljanje stanja in učinkovito izrisovanje (angl. rendering), kar omogoča razvijalcem gradnjo razširljivih in odzivnih spletnih aplikacij. Po drugi strani pa je knjižnica React v zadnjih letih postala eno izmed najbolj priljubljenih orodij za razvoj spletnih vmesnikov [2], saj zagotavlja deklarativen, komponentno-orientiran pristopu k razvoj. Kljub temu pa se z naraščajočo kompleksnostjo spletnih aplikacij pojavlja potreba po dodatnih orodjih in konvencijah. To je privedlo do pojava meta-ogrodij za React, ki temeljijo na omenjeni knjižnici in zagotavljajo celovito izkušnjo razvoja. V tem kontekstu so meta-ogrodja ogrodja, ki združujejo obstoječa ogrodja ali knjižnice z dodatnimi funkcionalnostmi in orodji ter ponujajo celovito rešitev za razvoj spletnih aplikacij. Pogosto vključujejo funkcionalnosti, kot so usmerjanje, izvajanje na strežniku (SSR), upravljanje stanja in optimizacijo izgradnje [3]. Ta meta-ogrodja, kot je na primer Next.js, so postala priljubljena zaradi svoje sposobnosti poenostavljanja in izboljšanja učinkovitosti razvoja. V tem prispevku se bomo osredotočili na (meta-)ogrodje Remix, ki je vse bolj priljubljeno ogrodje za razvoj spletnih aplikacij. Ogrodje Remix temelji na knjižnici React in zagotavlja celovit pristop k razvoju spletnih aplikacij, vključno z usmerjanjem, pridobivanjem podatkov, optimizacijo delovanja in izboljšano izkušnjo za razvijalce. S poudarkom na generiranju spletne strani na strežniku (SSR) Remix izboljšuje učinkovitost, omogoča optimizacijo SEO in zagotavlja hitro in učinkovito nalaganje začetne strani [4]. 2 Ogrodje Remix 2.1 Pregled glavnih lastnosti in funkcionalnosti Ogrodje Remix temelji na filozofiji postopnega izboljšanja (angl. Progressive Enhancement) [4]. V osnovi postopno izboljšanje pomeni, da zagotavljamo osnovno vsebino in funkcionalnosti za čim več uporabnikov, hkrati pa omogočamo najboljšo možno izkušnjo uporabnikom novejših brskalnikov, ki lahko izvajajo vse sodobne funkcionalnosti spletnih aplikacij. Podrobneje, pristop se osredotoča na gradnjo spletne strani ali aplikacije tako, da najprej zagotovi osnovno funkcionalnost in vsebino, ki deluje na vseh vrstah brskalnikov in naprav, vključno s starejšimi brskalniki ali tistimi z omejenimi zmogljivostmi. Ta osnovna različica mora biti uporabna in zagotoviti osnovne informacije in funkcionalnosti. Nato se postopno izboljšuje izkušnja tako, da se uporabnikom z novejšimi in zmogljivejšimi brskalniki ponudi izboljšan uporabniški vmesnik, animacije, interaktivne elemente in druge dodatne napredne funkcionalnosti [5]. V skladu s tem Remix omogoča razvijalcem, da začnejo zgraditi preprost HTML na strežniku in nato postopoma nadgrajujejo funkcionalnost z odjemalskim JavaScriptom in interaktivnimi elementi. To omogoča hitro začetno fazo razvoja in nato postopno dodajanje naprednih funkcionalnosti, ko jih dejansko potrebujemo. 88 G. Jošt, M. Kočevar: Remix: zmogljivo meta-ogrodje za razvoj spletnih aplikacij.. Remix prav tako podpira koncept predpomnjenja. S pomočjo te funkcionalnosti se vse potrebne datoteke, kot so moduli JavaScript in CSS, predpomnijo v brskalniku, kar omogoča, da se strani hitreje naložijo, zlasti v primeru počasnejšega omrežja. To izboljšuje uporabniško izkušnjo in zmanjšuje čas nalaganja strani. Ker Remix temelji na knjižnici React Router, vključuje prilagodljiv in zmogljiv sistem za usmerjanje (angl. routing), ki zagotavlja gradnjo kompleksnih spletnih aplikacij z več (pod)stranmi. To omogoča, da se aplikacija razdeli na več delov, pri čemer ima vsaka svojo URL pot in ločeno logiko. S tem se zagotovi boljša organizacija aplikacije in lažje upravljanje navigacije med stranmi. Takšna optimizacija navigacije na strani odjemalca omogoča, da ogrodje ugotovi, kateri deli strani se oz. se ne spreminjajo med prehodi med URL-ji. Posledično aplikacija pridobiva podatke samo za tiste poglede, ki vključujejo spremembe, kar zmanjšuje nepotrebne zahtevke in izboljšuje odzivnost aplikacije. Takšne gnezdene poti (angl. nested routes) olajšajo gradnjo kompleksnih spletnih aplikacij, ki vsebujejo več nivojev poti. Remix vsebuje tudi vse potrebno za enostavno pridobivanje podatkov iz oddaljenih virov. Z vgrajeno podporo za pridobivanje podatkov lahko spletno aplikacijo opremimo z vsemi potrebnimi informacijami za prikazovanje vsebine. To velja tudi za upravljanje z obrazci (angl. forms) spletne strani. Remix v ta namen zagotavlja dve funkciji, prejemnik (loader) in akcijo (action), ki omogočata operacije na strežniški strani z enostavnim dostopom do podatkov. Posledično ni potrebe, da bi na strani odjemalca imeli posebej logiko JavaScript za upravljanje z obrazci. Za razliko od drugih ogrodij, kjer bi morali vključiti JavaScript za izvedbo klicev preko fetch ali Axios, v Remixu to ni potrebno, saj delo z obrazci temelji na njihovem osnovnem delovanju. Ker gre za ogrodje, ki temelji na knjižnici React, vključuje tudi funkcionalnosti, potrebne za preprosto upravljanje stanja (angl. state management). Poleg že poznanih konceptov Reacta, Remix vključuje tudi svoje dodatne funkcionalnosti za upravljanje stanja s podatki, pridobljenimi na strani strežnika. Na ta način lahko učinkovito obvladujemo stanje aplikacije, kar omogoča boljšo uporabniško izkušnjo in lažje upravljanje s podatki aplikacije. Prilagodljiva arhitektura je še ena prednost ogrodja. Z njeno pomočjo lahko razvijalci enostavno organizirajo kodo in ločijo funkcionalnosti, kar olajša vzdrževanje in nadgradnjo aplikacij. Ogrodje je zasnovano tako, da podpira enostavno povezovanje med strežnikom in odjemalcem, kar omogoča dodajanje odjemalske logike brez obsežnih sprememb v obstoječi kodi na strežniku. V grobem so razvijalci Remixa strnili filozofijo ogrodja v štiri točke [4]: 1. Sprejmi model strežnik/odjemalec, vključno z ločitvijo izvorne kode od vsebine/podatkov. 2. Delaj s temelji spleta, ne proti njim: izkoristi moč in funkcionalnosti, ki jih že ponujajo osnovni gradniki spleta, kot sta protokol HTTP in jezik HTML. 3. Uporabljaj JavaScript za nadgradnjo uporabniške izkušnje z oponašanjem vedenja brskalnika: pri uporabi JavaScripta v spletnih aplikacijah je smiselno dodajati nove funkcionalnosti, ki izboljšajo uporabniško izkušnjo. Vendar pa se ne bi smeli truditi ponovno implementirati že obstoječe funkcionalnosti, ki jo brskalniki že sami ponujajo. 4. Ne pretiravaj z abstrakcijo osnovnih tehnologij. 2.2 Podroben pregled ogrodja V osnovi je ogrodje Remix sestavljeno iz štirih komponent [4]: 1. Prevajalnik (angl. Compiler) 2. Upravljavec strežniških HTTP zahtevkov (angl. server-side HTTP handler) 3. Strežniško ogrodje (angl. server framework) 4. Ogrodje za brskalnik (angl. browser framework) 89 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. Za razvoj aplikacij v ogrodju Remix je ključnega pomena uporaba prevajalnika. Prevajalnik, ki temelji na esbuild orodju, omogoča ustvarjanje različnih delov aplikacije. Med temi deli je tudi strežniški upravljavec HTTP zahtevkov, ki vključuje vse podprte poti spletne strani in ustrezne module. Slednje omogoča izrisovanje na strežniku in obdelavo zahtevkov za različne vire. Poleg tega prevajalnik ustvari tudi vse, kar je potrebno za izvajanje aplikacije v brskalniku. To vključuje samodejno deljenje programske kode glede na pot aplikacije in uvoz virov, na primer stilske datoteke CSS ali slike. Prevajalnik vzpostavi tudi manifest virov (angl. asset manifest), ki ima ključno vlogo pri pred-nalaganju virov med prvotnim izrisom na strežniku in pred-pridobivanju virov za prehode med stranmi na strani odjemalca. Vse tri gradbene artefakte lahko nato naložimo na katerikoli strežnik, ki podpira izvajanje programskega jezika JavaScript. Naslednja komponenta, ki je sestavni del ogrodja Remix, je Upravljavec strežniških HTTP zahtevkov. Čeprav se Remix izvaja na strežniku, dejansko ne predstavlja strežnika. Je le upravitelj (angl. handler), ki se uporablja znotraj dejanskega strežnika JavaScript. Ogrodje je namreč zgrajeno na osnovi spletnega Fetch API-ja. Slednje omogoča, da Remix deluje na različnih strežnikih, kot so Vercel, Netlify, Architect, Cloudflare Workers ali Deno Deploy. Programski kod spodaj prikazuje, kako je videti Remix, ko se izvaja v ogrodju Express. const remix = require("@remix-run/express"); const express = require("express"); const app = express(); app.all("*", remix.createRequestHandler({ build: require("./build") })); Express (oz. Node.js) je dejanski strežnik, medtem ko je Remix zgolj upravitelj (angl. handler) na tem strežniku. Paket @remix-run/express, ki se nahaja v prvi vrstici programskega koda zgoraj, imenujemo adapter. Ker so upravitelji neodvisni od strežnikov, za delovanje potrebujemo takšne adapterje. V osnovi adapterji pretvorijo vmesnik zahtev in odgovorov določenega strežnika v standardizirani Fetch API na vhodu, ko zahteva pride do Remixa. Nato pa prilagodijo Fetch odgovor, ki ga vrne Remix, nazaj v vmesnik odgovora strežnika. S tem pristopom Remix postane prilagodljiv in sposoben delovati na različnih strežnikih, saj adapterji poskrbijo za medsebojno razumevanje med Remixom in posameznimi strežniki. Adapterji omogočajo, da Remix izkoristi prednosti in funkcionalnosti različnih strežnikov, hkrati pa ohranja enoten in dosleden način delovanja. Komponenta Strežniško ogrodje predstavlja poglavitni del ogrodja. Remix je v osnovi strežniško ogrodje, ki sledi arhitekturi MVC (Model-View-Controller). V primerjavi s tradicionalnimi ogrodji, kot je npr. ASP.NET Core MVC, se v Remixu vlogi pogleda (View) in krmilnika (Controller) združita, medtem ko je model v celoti prepuščen razvijalcem. Namesto da bi bili omejeni na določene tehnologije, lahko izkoristimo celoten ekosistem JavaScripta, ki ponuja številne podatkovne baze, ORM (angl. Object-Relational Mapping) in podobna orodja. Poleg tega Remix vključuje funkcionalnosti za upravljanje piškotkov (angl. cookies) in sej (angl. sessions), kar olajša obvladovanje stanja med zahtevami. Za razliko od običajnih strežniških ogrodij je Remix osredotočen na uporabniški vmesnik in ne na modele. V Remixu imajo poti (angl. routes) možnost obdelave celotnega spletnega naslova (URL) ali samo njegovega dela. Tako vsaka postavitev (pogled) postane svoj krmilnik, pri čemer ogrodje združuje podatke in komponente za izgradnjo uporabniškega vmesnika. Ena izmed ključnih prednosti tega pristopa je, da ne potrebujemo ločenih krmilnikov za vsak URL. Namesto tega lahko vsaka postavitev (pogled) vsebuje svojo logiko za obdelavo zahtev, kar omogoča, da so strani, ustvarjene z Remixom, bolj dinamične in interaktivne. Pogosto poti Remixa vključujejo tako uporabniški vmesnik kot interakcije z modeli kar v isti datoteki. Datoteke imajo tri glavne izvoze: prejemnik (loader), akcijo (action) in privzet izvoz (dejanska komponenta). Primer je podan v programskem kodu spodaj. 90 G. Jošt, M. Kočevar: Remix: zmogljivo meta-ogrodje za razvoj spletnih aplikacij.. // Prejemniki (loaders) se izvajajo le na strežniku in // zagotavljajo podatke komponentam med zahtevami GET export async function loader() { return json(await db.projects.findAll()); } // Akcije (actions) se izvajajo le na strežniku in obdelujejo zahteve POST, PUT, PATCH in DELETE. // Prav tako lahko zagotovijo podatke komponentam export async function action({ request }: ActionArgs) { const form = await request.formData(); await createProject({ title: form.get("title") }); return json({ ok: true }); } // Izvoz privzete vrednosti je komponenta, ki bo prikazana, ko pot ustreza URL-ju. // To deluje tako na strežniku kot na odjemalcu. export default function Projects() { const projects = useLoaderData(); const actionData = useActionData(); return (
{projects.map((project) => ( {project.title} ))}
{actionData?.errors ? : null}
); } Remix lahko uporabljamo tudi izključno kot strežniško ogrodje, brez kakršne koli uporabe JavaScripta na strani odjemalca. Za nalaganje podatkov se lahko uporablja funkcija loader, spremembe lahko upravljamo s funkcijo action, medtem ko obrazci HTML in komponente zagotavljajo osnovne funkcionalnosti spletne aplikacije. Zadnja komponenta, Ogrodje za brskalnik, pride do izraza, ko Remix brskalniku posreduje dokument HTML. Takrat ogrodje poskrbi, da se stran "hidrira" (angl. hydrate). V kontekstu razvoja spletnih strani hidracija označuje postopek pretvorbe statične vsebine HTML-ja v interaktivno aplikacijo. Ko se spletna stran sprva izriše na strežniku in pošlje odjemalcu, vsebuje statično vsebino in nima dinamičnih funkcionalnosti. Hidracija je nadaljnji korak, ko brskalnik naloži JavaScript kodo in doda upravljavce dogodkov (angl. event handlers), kar naredi stran interaktivno [4]. Remix vključuje tudi nekaj optimizacij za navigacijo med stranmi na strani odjemalca. Ogrodje ve, katere postavitve (angl. layout) se bodo ohranile med dvema URL-jema, zato pridobiva podatke le za tiste, ki se spreminjajo. Ko uporabnik klikne povezavo, namesto da bi na strežnik pošiljali zahtevo za celoten dokument in vse vire, Remix pridobi podatke za prikaz želene strani in posodobi uporabniški vmesnik. Slednje izboljša zmogljivosti v primerjavi z zahtevo za celoten dokument. Pomembna lastnost ogrodja je tudi predpomnjenje (angl. Caching), kar je podprto na naslednji način. Ko uporabnik z miško prehaja preko povezave, Remix že vnaprej predpomni vse potrebne vire za naslednjo stran. To pomeni, da se podatki, moduli JavaScript in celo datoteke CSS za novo stran že naložijo, še preden uporabnik dejansko 91 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. klikne na povezavo. To stori tako, da brskalniku pošlje manifest sredstev, ki vsebuje seznam vseh virov, ki jih potrebuje stran. Brskalnik nato te vire predpomni v ozadju, preden jih potrebuje, kar zmanjša čas nalaganja strani. Prednalaganje virov v Remixu poteka na naslednji način: 1. Remix ustvari manifest sredstev, ki vsebuje seznam vseh virov, ki jih potrebuje stran. 2. Remix pošlje manifest sredstev brskalniku. 3. Brskalnik lahko nato te vire predpomni v ozadju. 4. Ko uporabnik klikne povezavo, bo stran že naložena in pripravljena za uporabo. Ta pristop k predpomnjenju virov je izredno učinkovit, še posebej v primerih počasne spletne povezave. Ker se večina virov že nahaja v predpomnilniku brskalnika, se stran naloži hitro in brez čakanja, kar uporabnikom omogoča odzivno izkušnjo. 2.3 Generiranje spletne strani na strežniku (SSR) v ogrodju Remix Client-Side Rendering (CSR) je pristop, ki se pogosto uporablja pri izdelavi spletnih aplikacij. Pri tem pristopu se HTML oz. uporabniški vmesniki oblikuje na strani odjemalca, s pomočjo JavaScripta. Ko uporabnik zahteva določeno spletno stran, se na strani odjemalca najprej naloži osnovni HTML skupaj z datotekami JavaScript. Nato se na strani odjemalca s pomočjo JavaScripta pridobijo podatki iz strežnika in dinamično oblikuje vsebina HTML [6]. CSR pristop omogoča bolj interaktivno uporabniško izkušnjo, saj se vsebina in vmesnik prilagajata uporabnikovim interakcijam brez potrebe po osveževanju celotne strani. Vendar pa CSR prinaša tudi nekatere izzive, kot so počasnejši prvi prikaz strani, saj je potrebno najprej naložiti osnovno strukturo in nato pridobiti in oblikovati podatke z JavaScriptom. Poleg tega je zaradi obsežne uporabe JavaScripta obremenitev na strani odjemalca večja, kar lahko vpliva na učinkovitost in odzivnost spletnih aplikacij. Kot alternativo imamo že nekaj časa na voljo pristop SSR ( Server-Side Rendering). Za razliko od CSR se strani HTML ustvarijo in oblikujejo na strežniku, preden se pošljejo na naprave odjemalca. Ko uporabnik zahteva določeno spletno stran, spletni strežnik sestavi potrebno HTML vsebino, vključno s podatki iz baze ali drugih virov, nato pa jo pošlje odjemalcu. Ta pristop omogoča, da se uporabniku prikaže popolnoma oblikovana spletna stran že ob prvem naloženem odgovoru strežnika, saj ni potrebno, da bi se spletna stran generirala šele na strani odjemalca s pomočjo JavaScripta [6]. Ko se spletna stran naloži, pa preko že prej omenjenega postopka hidracije za vso nadaljnjo izvajanje poskrbi koda JavaScript. SSR prinaša nekatere prednosti, kot so boljša uporabniška izkušnja zaradi hitrejšega prikaza začetne strani, boljša optimizacija za iskalnike (SEO) in boljša dostopnost. Remix privzeto uporablja SSR kot osrednji mehanizem izrisovanja (angl. rendering), vendar vključuje tudi CSR za usmerjanje na strani odjemalca in dinamično posodabljanje strani po prvotnem nalaganju. Ta hibridni pristop združuje prednosti SSR za prvotno izrisovanje z ugodnostmi CSR za boljše interakcije na strani odjemalca. 2.4 Optimizacija SEO in hitro nalaganje začetne strani SEO (ang. Search Engine Optimization) pomeni optimizacija spletnih strani za iskalnike. Gre za prakso optimizacije spletne strani ali spletišča za izboljšanje njene vidnosti in uvrstitve na straneh iskalnikov (ang. SERP-ji oz. Search Engine Result Pages). Glavni cilj SEO-ja je privabiti več organskega (neplačanega) prometa iz iskalnikov, kot so Google, Bing, Yandex ali Yahoo [7]. Remix dosega boljšo optimizacijo za iskalnike z naslednjimi mehanizmi [4]. Kot že omenjeno, se Remix razlikuje od običajnih enostranskih aplikacij (Single-page application), saj privzeto podpira SSR. Ko obiskovalec zahteva spletno stran, se s tem pristopom na strežniku generira začetni HTML s predhodno vključeno vsebino. To zagotavlja, da so spletni iskalniki sposobni takoj dostopati do celotne vsebine, kar olajša njihovo indeksiranje. 92 G. Jošt, M. Kočevar: Remix: zmogljivo meta-ogrodje za razvoj spletnih aplikacij.. Ena izmed prednosti Remixa je tudi nadzor nad metapodatki za SEO. Ponuja orodja in tehnike za prilagajanje naslovov strani, meta-opisov, kanoničnih URL-jev in strukturiranih podatkov. Pravilno upravljanje metapodatkov pripomore k boljšemu razumevanju vsebine s strani spletnih iskalnikov, kar izboljšuje možnosti za višje uvrščanje v iskalnih rezultatih. Pomembno je tudi izpostaviti, da Remix skrbi za čiste URL-je. To obenem olajša navigacijo obiskovalcem in hkrati pripomore k boljšemu indeksiranju vsebine s strani iskalnih botov. Nenazadnje pa ogrodje tudi stremi k manjši odvisnosti od JavaScripta na strani odjemalca, kar pripomore k boljšemu razumevanju in sledenju vsebine s strani spletnih iskalnikov. Z uporabo SSR in postopnega izboljševanja, Remix omogoča enostavno dostopanje do vsebine, kar je ključnega pomena za SEO. Kombinacija vseh omenjenih pristopov, torej SSR, postopnega izboljševanja, nadzora metapodatkov in drugih funkcij, usmerjenih v SEO, naredi Remix skladen z najboljšimi praksami za SEO. 3 Primerjava z obstoječimi meta-ogrodji Remix ni edino meta-ogrodje, ki temelji na knjižnici React. Med alternativami se pogosto omenjata tudi Next.js in Gatsby. Čeprav imajo nekaj podobnosti, imajo tudi različne značilnosti in primere uporabe, kar bomo predstavili v nadaljevanju. 3.1 Next.js Next.js je priljubljeno odprtokodno ogrodje za izdelavo naprednih spletnih aplikacij s pomočjo jezika JavaScript. Temelji na knjižnici React in ponuja napredne funkcionalnosti, ki olajšajo razvoj in izboljšajo uporabniško izkušnjo. Glavna značilnost Next.js je njegova sposobnost podpiranja tako SSR kot tudi CSR [8]. Next.js ponuja preprost pristop k usmerjanju, ki temelji na sistemu datotek. To pomeni, da lahko razvijalci organizirajo in upravljajo poti v svoji aplikaciji preprosto z uporabo imenikov in datotek, kar olajša vzdrževanje in razširljivost. Poleg tega Next.js vključuje tudi podporo za pridobivanje podatkov. Na voljo imamo različne metode, kot so pridobivanje podatkov na strani strežnika, statična generacija spletnih strani ali pridobivanje podatkov na strani odjemalca. 3.2 Gatsby Gatsby je še eno priljubljeno odprtokodno ogrodje za izdelavo spletnih aplikacij, ki temelji na Reactu. Ogrodje je namenjeno predvsem izdelavi statičnih spletnih strani. Glavna značilnost Gatsbyja je njegova sposobnost pred-generiranja statičnih HTML strani med izdelavo aplikacije (angl. build time). To pomeni, da se vsebine in podatki pridobijo med gradnjo aplikacije, nato pa se izdelajo pred-izrisane (angl. pre-rendered) strani HTML. Te strani se nato posredujejo odjemalcu kot običajne statične datoteke, kar omogoča izjemno hitro nalaganje in odzivnost spletnega mesta [9]. Gatsby omogoča razvijalcem enostavno upravljanje vsebine s pomočjo datotek Markdown ali drugih formatov. Poleg tega Gatsby uporablja GraphQL za pridobivanje podatkov, kar olajša integracijo s CMS platformami in drugimi zunanjimi viri podatkov. Podatki se torej pridobivajo in uporabljajo na učinkovit način, kar prispeva k hitrosti in zmogljivosti spletne strani. Gatsby ponuja tudi bogat ekosistem vtičnikov, ki omogočajo razvijalcem dodajanje funkcionalnosti, kot so optimizacija zmogljivosti, analitika, SEO in še več. Gatsby se predvsem osredotoča na statično generacijo spletnih strani (SSG) in je primeren za izdelavo spletnih strani, osredotočenih na vsebino, kot so blogi. 93 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 3.3 Rezultati primerjave Tabela 1 prikazuje rezultate primerjave ogrodij Remix, Next.js in Gatsby. Pri primerjavi smo se osredotočili predvsem na načine izrisa, SEO, pridobivanja podatkov, usmerjanja in podpori obrazcev. Tabela 1: Primerjava meta-ogrodij React. Remix Next.js Gatsby Izris Server-side rendering Server-side rendering (SSR), Static Static Site Generation (SSG) (SSR) Site Generation (SSG) SEO Zelo dobra podpora zaradi Zelo dobra podpora zaradi SSR Odlična podpora zaradi SSG SSR Skupnost Narašča, vendar ni Obsežna, dejavna Obsežna, dejavna primerljiva z Next.js in Gatsby Pridobivanje Uporablja React Suspense Uporablja getStaticProps ali Uporablja GraphQL za podatkov za asinhrono pridobivanje getServerSideProps za statično pridobivanje podatkov podatkov pridobivanje podatkov Usmerjanje Uporablja Remix Router ze Uporablja Next.js Router, Uporablja Gatsby Router upravljanje s potmi, uporablja strukturo projekta za uporablja strukturo ustvarjanje poti projekta za ustvarjanje poti Upravljanje z Uporablja privzeto Uporablja prilagojene (angl. Uporablja mutacije GraphQL obrazci obnašanje obrazcev na custom) obrazce strani odjemalca za pošiljanje podatkov Kot je razvidno iz tabele, so Remix, Next.js in Gatsby izvrstna meta-ogrodja za razvoj spletnih aplikacij. Vsak od njih ima svoje edinstvene prednosti in značilnosti, zato je ključno izbrati ogrodje, ki najbolje ustreza specifičnim potrebam projekta. Iz primerjave lahko razberemo, da Remix omogoča razvoj odzivnih aplikacij in zagotavlja podporo za optimizacijo spletnega iskanja (SEO). Po drugi strani Next.js poleg SSR podpira tudi izris statičnih spletnih strani. Močno podporo SEO pa zagotavlja Gatsby, ki je primarno namenjen implementaciji statičnih spletnih strani. 4 Implementacija aplikacije V tem poglavju bomo predstavili proces implementacije spletne aplikacije z uporabo ogrodja Remix. V osnovi bo aplikacija omogočala uporabnikom, da vnesejo kakršne koli ideje, drugi uporabniki bodo imeli možnost »všečkati« posamezno idejo. 4.1 Namestitev osnovne aplikacije Za izdelavo aplikacije Remix smo uporabili naslednje: • Node.js v18.16.0 (okolje za izvajanje kode JavaScript), • npm v9.5.1 (upravitelj paketov za aplikacije Node.js) in • VS Code (urejevalnik kode). Skladno z navodili se razvoj začne z izvedbo ukaza npx create-remix@latest v ukazni vrstici. Ob sami vzpostavitvi se moramo opredeliti glede določenih aspektov aplikacije, kar bomo predstavili v nadaljevanju. Na začetku smo morali izbrati, kateri tip aplikacije želimo razviti. Na voljo imamo dve možnosti, za voljo razvoja tega primera pa smo se odločili za preprosto aplikacijo (možnost just the basics). 94 G. Jošt, M. Kočevar: Remix: zmogljivo meta-ogrodje za razvoj spletnih aplikacij.. ? What type of app do you want to create? (Use arrow keys) > Just the basics A pre-configured stack ready for production Remix prav tako ponuja različne ponudnike za namestitev aplikacije. V našem primeru smo izbrali Remix App Server. ? Where do you want to deploy? Choose Remix App Server if you're unsure; it's easy to change deployment targets. > Remix App Server Express Server Architect Fly.io Netlify Vercel Cloudflare Pages Ko potrdimo vse možnosti vzpostavitve aplikacije Remix, se v izbranem imeniku na podlagi šablone (angl. Template) ustvari naslednja struktura [4]: • app/ - Imenik, kjer se nahaja celotna aplikacija Remix. • app/entry.client.tsx – Predstavlja kodo JavaScript, ki se izvede, ko se aplikacija naloži v brskalniku. Uporablja se za hidracijo komponent React. • app/entry.server.tsx – Predstavlja kodo JavaScript, ki se izvede, ko zahtevek doseže strežnik. Remix obdela vse potrebne podatke, razvijalci aplikacije pa implementiramo ustrezni odgovor (angl. Response). Programski kod v tej datoteki skrbi, da se aplikacija React pretvori v niz, ki se potem pošlje odjemalcu. • app/root.tsx – V tej datoteki se nahaja korenska komponenta aplikacije, ki izriše element . • app/routes/ - Tu se nahajajo vsi moduli poti (angl. route modules). Remix na podlagi imena datotek v tej mapi ustvari URL poti za aplikacijo. • public/ - Tu se nahajajo statični viri (slike, pisave itd.). • remix.config.js – Vsebuje možnosti konfiguracije aplikacije. V nadaljevanju bomo predstavili pomembnejše vidike aplikacije in podali primer programskega koda. 4.2 Podatkovna baza Za upravljanje podatkovne baze smo uporabili SQLite v povezavi s Prisma. Prisma je odprtokodni objektno-relacijski preslikovalnik (ORM) za Node.js in TypeScript ter se uporablja kot alternativa pisanju običajnih poizvedb SQL. Prisma trenutno podpira različne podatkovne baze, med drugim PostgreSQL, MySQL, SQL Server, SQLite, MongoDB in CockroachDB [10]. S pomočjo Prisma Migrate smo ustvarili tabelo v podatkovni bazi, ki bo služila shranjevanju idej. Shema tabele je prikazana v naslednjem programskem kodu. model Idea { id String @id @default(uuid()) createdAt DateTime @default(now()) updatedAt DateTime @updatedAt title String description String likes Int @default(0) } 95 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. 4.3 Korenska komponenta Kot že rečeno, korenska komponenta aplikacije izriše element , skrbi pa tudi, da se naložijo metapodatki strani (), povezave do stilov CSS () in prostor, kamor se glede na naslov URL-ja izpiše vsebina aplikacije (). Če želimo izvajati kodo JavaScript tudi na strani odjemalca, pa je potrebno vključiti še . Primer korenske komponente za potrebe aplikacije je predstavljen v naslednjem izseku programskega koda. import globalStylesUrl from "~/styles/global.css"; export const links: LinksFunction = () => [ { rel: "stylesheet", href: globalStylesUrl }, ]; export default function App() { return ( ); } 4.4 Spletne poti Aplikacija bo nudila možnost pregleda seznama idej, pregleda posamezne ideje in dodajanje nove ideje. Kot že rečeno, usmerjanje v aplikacijah Remix temelji na osnovi datotek, kjer so poti določene na podlagi strukture. Za naše potrebe bi potrebovali naslednje poti: • / • /ideje • /ideje/:idejaId • /ideja/dodaj-novo Da dosežemo takšne poti, moramo ustrezno poimenovati datoteke. Glede na konvencijo poimenovanja poti in datotek, zgoraj opredeljene poti postanejo datoteke znotraj imenika app/routes: • _index.tsx • ideja.tsx • ideja.$idejaId.tsx • ideja.dodaj-novo.tsx 96 G. Jošt, M. Kočevar: Remix: zmogljivo meta-ogrodje za razvoj spletnih aplikacij.. 4.4.1 Glavna pot V datoteki _index.tsx se nahaja glavna pot, ki se izvede, ko uporabnik obišče osnovni URL aplikacije. Ta pot predstavlja torej začetno stanje aplikacije, ki se prikaže ob prvem obisku. Programski kod glavne poti je naslednji. export const links: LinksFunction = () => [ { rel: "stylesheet", href: stylesUrl }, ]; export default function IndexRoute() { return (

Aplikacija za beleženje seznama idej

); } Kot je razvidno, je v datoteki definirana komponenta IndexRoute, ki predstavlja začetno stanje aplikacije. Gre za preprosto komponento React, brez kakršnih koli dodatkov ogrodja Remix. Ko se ta pot izvede, se prikaže naslov strani, navigacijski meni z gumbom za pregled seznama idej in potrebni slogi za oblikovanje. Ta komponenta se nato izriše v korenske komponente aplikacije. Kot že omenjeno, je posebna oznaka, ki določa mesto, kamor se vstavi vsebina (izrišejo komponente), povezane s trenutno potjo. 4.4.2 Pot, ki prikaže seznam idej Za izpis seznama idej, ki se nahaja na poti /ideje, potrebujemo na strežniku dostop do podatkovne baze. Obenem želimo tudi omejiti, katere podatke posredujemo odjemalcu. Vse to podpira ogrodje Remix tako, da izvozimo funkcijo loader. Ta funkcija omogoča pridobivanje in obdelavo podatkov preden se prikažejo odjemalcu. Vsebino funkcije predstavlja naslednji programski kod. export const loader = async () => { const ideas = await db.idea.findMany({ orderBy: { createdAt: "desc" }, select: { id: true, title: true, likes: true }, take: 5, }); return json({ ideas }); }; Iz primera zgoraj je razvidno, da se funkcija loader uporablja za pridobivanje idej iz podatkovne baze s pomočjo funkcije db.idea.findMany. S to funkcijo lahko določimo različne parametre, kot je ureditev po času ustvarjanja ideje, izbira določenih polj tabele in omejitev števila idej, ki jih bomo prikazali. Podatki so nato na voljo na strani odjemalca preko useLoaderData kavlja (angl. hook), ki ga ponuja ogrodje Remix. Kavelj vrne vsebino, ki jo nato s pomočjo standardne sintakse Reacta prikažemo v obliki seznama, kot je razvidno iz spodnjega izseka programskega kode. 97 OTS 2023 Sodobne informacijske tehnologije in storitve Zbornik 26. konference. export default function IdeasRoute() { const data = useLoaderData(); return (

Seznam idej

    {data.ideas.map(({ id, title, likes }) => (
  • {title} {likes}👍
    • ))}
Dodaj svojo idejo
); } 4.4.3 Pot za dodajanje nove ideje Za dodajanje nove ideje bomo potrebovali obrazec, ki se bo ob potrditvi na strani odjemalca shranil v podatkovno bazo. V ta namen ogrodje Remix ponuja funkcijo action. Funkcija action omogoča, da opravimo obdelavo obrazcev in shranjevanje podatkov neposredno na strežniku. Primer funkcije za shranjevanje novih idej predstavlja naslednji programski kod. export const action = async ({ request }: ActionArgs) => { const form = await request.formData(); const title = form.get("title"); const description = form.get("description"); if (typeof title !== "string" || typeof description !== "string") { return badRequest({ fieldErrors: null, fields: null, formError: "Form not submitted correctly.", }); } const newIdea = await db.idea.create({ data: { description, title }, }); return redirect(`/ideje/${newIdea.id}`); }; Za vnos podatkov potrebujemo še obrazec, ki je implementiran v obliki komponente React. V primeru omenjene komponente ne potrebujemo specifičnih funkcionalnosti ogrodje Remix, saj gre za osnovne funkcionalnosti ogrodja React, kar je razvidno iz programskega koda spodaj. 98 G. Jošt, M. Kočevar: Remix: zmogljivo meta-ogrodje za razvoj spletnih aplikacij.. export default function NewIdeaRoute() { return (

Dodaj svojo idejo