V architektuře orientované na mikroslužby jsou zprávy běžně používaným prostředkem pro komunikaci mezi jednotlivými službami. Obecně je zde potřeba naslouchat zprávám odeslaným na sběrnici a reagovat na ně spouštěním úloh. Tato práce prezentuje všechny podstatné úvahy k vyřešení tohoto problému. Přichází s rámcem pro spouštění úloh, který vykonává úlohy v libovolných kontejnerech na OpenShiftu. Řešení se skládá z API napsaného ve Flasku, které obsahuje spouštěcí logiku, a klienta, který přes STOMP příjmá zprávy ze sběrnice a poslílá je na API. Součástí jsou i testovací scénáře, které předvádějí funkčnost celého systému. Řešení je vyhodnocováno porovnáváním s existující aplikací postavené na nástroji Jenkins. Rovněž je diskutovaný alternativní návrh využívající Tekton. Druhým problémem, kterým se tato práce zabývá, je provádění pravidelně naplánovaných úloh. Namísto implementace vlastního řešení navrhuje použití Kubernetes objektů CronJob.
Student nejprve prezentoval výsledky, kterých dosáhl v rámci své práce. Komise se poté seznámila s hodnocením vedoucího a posudkem oponenta práce. Student následně odpověděl na otázky oponenta a na další otázky přítomných. Komise se na základě posudku oponenta, hodnocení vedoucího, přednesené prezentace a odpovědí studenta na položené otázky rozhodla práci hodnotit stupněm B.
Otázky k obhajobě
Jaký je konkrétní přínos vytvořeného řešení, resp. jak se změní v praxi proces nasazení software s využitím Vašeho řešení?
Jak jsou vytvořené aplikace škálovatelné? Je možné procesy zpracování požadavků v aplikacích nějak monitorovat a reagovat na zátěž?
doc. Dr. Ing. Dušan Kolář (předseda)
doc. Dr. Ing. Otto Fučík (člen)
Ing. František Grézl, Ph.D. (člen)
Ing. Ivana Burgetová, Ph.D. (člen)
Ing. Martin Hrubý, Ph.D. (člen)
Pan Tichavský pracoval na své bakalárské práci po celou dobu velmi svědomitě, své řešení konzultoval jak se zadavatelem, tak se mnou, jako vedoucím práce. Výsledné řešení bude zřejmě nasazeno ve vývoji ve firmě RedHat. Celkově hodnotím práci studenta jako velmi nadprůměrnou a navrhuji hodnocení stupněm A.
Kritérium hodnocení
Slovní hodnocení
Informace k zadání
Cílem zadání byl návrh a implementace rámcového řešení pro automatizované spouštění úloh v distribuovaném prostředí OpenShift, které by nahradilo aktuálně používaný nevyhovující nástroj Jenkins. Jedná se o firemní zadání RedHat. Zadání považuji z pohledu vedoucího za splněné bez výhrad.
Práce s literaturou
Student využíval zejména konzultací ve firmě RedHat a samostatně si vyhledával další informační zdroje.
Aktivita během řešení, konzultace, komunikace
Konzultace ohledně analýzy požadavků a technické realizace řešení probíhaly zejména ve firmě RedHat. Student mě však o průběhu konzultací a důležitých rozhodnutích vždy informoval. Na své bakalářské práci pracoval svědomitě po celou dobu řešení.
Aktivita při dokončování
Implementační výstup i technická zpráva byly dokončeny ve značném předstihu a jejich výsledná podoba byla důkladně konzultována. Mé připomínky student řádně zapracoval.
Technická zpráva bakalářské práce, kterou považuji za mírně obtížnější, je na velmi dobré úrovni a vlastní programové řešení je funkční, prakticky zaměřené a dobře navržené, přestože má jisté rezervy. Navrhuji hodnotit práci stupněm velmi dobře (B).
Kritérium hodnocení
Slovní hodnocení
Body
Náročnost zadání
Stupeň hodnocení: obtížnější zadání
Jedná se spíše o obtížnější práci, vzhledem k hloubce a rozsahu propojení v práci použitých technologií (sběrnice zpráv, Kubernetes, OpenShfit).
Rozsah splnění požadavků zadání
Stupeň hodnocení: zadání splněno
Zadání je zcela splněno.
Rozsah technické zprávy
Stupeň hodnocení: je v obvyklém rozmezí
Rozsahem je technická zpráva v obvyklém rozmezí, od úvodu po závěr obsahuje 38 vysázených stran. Text práce je velmi bohatý na informace a velmi podrobně popisu jak použité technologie, tak vlastní řešení včetně diskuze případných problémů a alternativních přístupů.
Prezentační úroveň technické zprávy
Technická zpráva má vynikající prezentační úroveň. Zaměření i pořadí jednotlivých kapitol a jejich podkapitol plynule a podrobně představuje problémy a jejich řešení - v tomto oceňuji zejména kapitoly 4 "Existing Solution" a 5 "Design".
95
Formální úprava technické zprávy
Technická zpráva je psána v anglickém jazyce bez výrazných nedostatků (vytknout lze pouze drobné nedostatky v interpunkci a nejednotném přístupu k velikosti písmen v nadpisech, např. v kap. 4 a ostatních). Také po typografické stránce je technická zpráva bez vážnějších nedostatků (v některých místech lze vytknout např. absenci nedělitelných mezer či sirotky).
85
Práce s literaturou
Seznam literatury obsahuje 11 položek, z nichž většina (až na jednu knihu) jsou online zdroje popisující použité technologie. Zde by bylo vhodné použít více odborných zdrojů (např. o tématech distribuované architektury a sběrnic zpráv existuje řada relevantních odborných publikací). Jednotlivé zdroje jsou v textu technické zprávy řádně dokazovány a je dobře patrný způsob a rozsah jejich použití v kontextu vlastních úvah studenta.
75
Realizační výstup
Realizačním výstupem jsou dvě aplikace v programovacím jazyce Python: první přijímá zprávy s požadavky ze sběrnice a předává je na rozhraní druhé části, která na jejich základě nakonfiguruje prostředí Kubernetes a spustí úlohu v OpenShift. Řešení je středně rozsáhlé a je funkční. Zdrojový kód obou aplikací je dobře strukturován a dostatečně komentován. Součástí řešení jsou jednotkové testy, ale vzhledem k předpokládanému nasazení bych očekával také akceptační resp. use-case testy které chybí. Dále je škoda, že nebyla věnována větší pozornost škálovatelnosti řešení v souvislosti s využitím fronty zpráv, alespoň popisem v textu technické zprávy.
85
Využitelnost výsledků
Celá práce je zaměřena na praktické nasazení řešení v procesu automatizovaného nasazení, integrace a testování software ve společnosti Red Hat Czech s.r.o. a výsledky mají dobrou využitelnost.
Otázky k obhajobě:
Jaký je konkrétní přínos vytvořeného řešení, resp. jak se změní v praxi proces nasazení software s využitím Vašeho řešení?
Jak jsou vytvořené aplikace škálovatelné? Je možné procesy zpracování požadavků v aplikacích nějak monitorovat a reagovat na zátěž?