Az Admin.SCH az az oldal, ahol a kollégisták kezelhetnek mindent, ami a Házon belüli internetezésükkel kapcsolatos: IP címet regisztrálhatnak, újabb eszközöket adhatnak hozzá, vagy bejelenthetik a szobai access point-jukat. Ez egy olyan weboldal, amit minden kollégista használt már, és életbevágó szolgáltatásokat tudnak itt beállítani – mondhatjuk tehát, hogy kritikus rendszerről van szó.
Az oldalt kiszolgáló backend a közelmúltban elkezdett elavulni, ráadásul a dokumentáció problémái és architekturális sajátosságai miatt nem tudtuk ésszerűen továbbfejleszteni. Nem volt hát más választásunk, mint hogy újraírjuk.
A korábbi Admin.SCH egy monolit webalkalmazás volt, ami azt jelenti, hogy a szoftver összes funkciója (IP cím regisztráció, Active Directory integráció, stb.) egyetlen “csomag” részét képezi. Ez a hagyományos megközelítés, egy programozás házinál is ezt használjuk: hiába bontjuk a megoldásunkat ezernyi .c és .h fájlra vagy osztályra, a végén mégis egyetlen bináris, azaz egy monolit készül belőle. Egy ilyen alkalmazást könnyebb fejleszteni, könnyebb tesztelni, hiszen csak egyetlen programot kell elindítani és ellenőrizni, és könnyebb deploy-olni, hiszen csak egyetlen dolgot kell felmásolni egy szerverre, és máris éles lehet a szolgáltatás.
Ennek viszont ára is van: a projekt növekvő kódbázisával az egyre átláthatatlanabb lehet, minden frissítéskor az egészet kell újratelepíteni, és egy hiba akár az egész szolgáltatást is térdre kényszerítheti.
![OpenID vs. OAuth](/assets/images/monolitmicroservice-fa43f788f78cf33553fc658a0cfd755b.png)
Monolit rendszer vs. microservice architektúra
Úgy döntöttünk, hogy az új rendszert már microservice-ek segítségével építjük fel: nem egy nagy szolgáltatást készítünk, hanem több kicsit. Ezeknek a kicsi szoftvereknek aztán kicsi, meghatározott felelőssége is lehet – van például, ami az IP-k regisztrációját teszi lehetővé, van, amivel a saját AP-kat lehet bejelenteni, és így tovább. Ezzel nagyrészt megoldottuk az átláthatatlan kód problémáját, mert apró, önálló programokkal dolgozunk, amik mindig könnyen áttekinthetők maradnak. Lehetővé vált az is, hogy a komponensek külön fejlődjenek, ami különösen előnyös egy olyan projektnél, amin sok egyetemista dolgozik, mert mindenki a saját ütemében haladhat. A későbbi bővítés is egyszerű, hiszen az új szolgáltatások hozzáadásához nem kell belenyúlni az eddigi kódba. További előny, hogy a KSZK egyéb, a hálózat üzemeltetéséhez kapcsolódó, már létező szolgáltatásait is bele lehet vonni az Admin.SCH-ba.
A microservice architektúra viszont több hátránnyal is jár. Egyrészt a szolgáltatások közötti kommunikáció miatt előfordul, hogy ha az egyik szolgáltatás interfésze megváltozik, akkor több másik szolgáltatásba is át kell vezetni a változtatásokat. Ezen a problémán segít az API verziózás és az API dokumentációs eszközök használata (mint például az OpenAPI/Swagger). Az alkalmazás futtatását jelentősen bonyolíthatja, hogy sok kisebb szolgáltatásból áll, szóval szükségünk volt valamilyen rendszerre, ami a microservice-eket menedzseli.
A microservice-eket konténerekbe szerveztük, és a KSZK Kubernetes klaszterébe telepítettük. Az ebben futó Docker konténerek könnyedén példányosítható, leállítható és mozgatható process-ek, amikben egy-egy microservice fut. Megtalálható bennük minden, a futtatáshoz kellő dependencia, könnyen futtathatók, és a microservice-ek szeparációja is megoldott. A Kubernetes pedig a konténerek menedzselését, és a közöttük lévő kommunikációt biztosítja, azaz orkesztrálja őket. A konténerek Docker image-ekből készülnek, amiket git.sch.bme.hu szolgáltatásba épített Continuous Integration automatikusan előállít.
Az újraírás első ütemének célja az volt, hogy a kollégisták által használt funkciók kerüljenek át az új rendszerbe. Ez a cél meg is valósult, így jelenleg a két rendszer párhuzamosan fut. A legtöbb kollégista csak az új rendszerrel fog találkozni, ami teljesen különálló a régitől, viszont a felület át lett emelve, ezért csak kisebb átalakításokra volt most rajta lehetőség. A következő félévekben át szeretnénk alakítani a felületet és új funkciókkal bővíteni az új rendszert.
![OpenID vs. OAuth](/assets/images/adminschversions-a814234a6b9cd2532572b423ec8ff032.png)
A régi és az új rendszer együttélése
Ha valamilyen hibát vagy szokatlan működést tapasztaltok az oldal használata közben, akkor adjatok fel ticketet a support.sch.bme.hu weboldalon!