mi-az-a-microservice-ujrairtuk-az-admin-sch-t

Former-commit-id: 154cdee1875ffb317cb204aeac3f4091e31e89f2

app/blog/2019/09/24/.gitattributes

+*.{jpg,JPG,png,PNG,JPEG,jpeg,gif,GIF,webp,pdf,svg,SVG,mp4,pdf} filter=lfs diff=lfs merge=lfs -text
\ No newline at end of file

app/blog/2019/09/24/mi-az-a-microservice-ujrairtuk-az-admin-sch-t.md

+---
+slug: mi-az-a-microservice-ujrairtuk-az-admin-sch-t
+title: Mi az a microservice? Újraírtuk az Admin.SCH-t
+authors: schulczf
+tags: []
+---
+
+Az [Admin.SCH](https://admin.sch.bme.hu) 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ó.
+
+<!--truncate-->
+
+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.
+
+![](monolitmicroservice.png)
+
+<div style={{textAlign: "center"}}>
+<em>Monolit rendszer vs. microservice architektúra</em>
+</div>
+
+Ú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](https://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.
+
+![](adminschversions.png)
+
+<div style={{textAlign: "center"}}>
+<em>A régi és az új rendszer együttélése</em>
+</div>
+
+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](https://support.sch.bme.hu/) weboldalon!