2021-11-24 21:54:59 +01:00
parent 1262f17ee7
commit 6e9396cd73
2 changed files with 37 additions and 32 deletions
							
							
								
							
							
						
@@ -19,6 +19,7 @@ folyamatok biztosította alacsonyabb üzemeltetési költség \cite{costofcloud}
Gyakran a felhőszolgáltató egynél több \gls{adatkozpont}ot tart fenn, amelyeket a világ több pontján helyeznek el. Ezzel biztosítva redundanciát, magasabb rendelkezésre állást és hatékonyabb elérést \cite{geodist}.
% TODO: Ide simán shameless módon betolhatom a részletesebb leírást, amit már hatszor leglalább leadtam.
A felhő architektúráknak több modelljét is megkülönböztetjük. Ezeket pedig aszerint osztályozhatjuk, hogy mekkora kontrollt adnak a felhasználónak a futó alkalmazás felett. Ennek a kontrollnak a legalacsonyabb szintjén van az úgynevezett \acrfull{saas} (Szoftver mint szolgáltatás), amely egy előre telepített szoftver eszközt biztosít a szolgáltató felhő környezetében, amelyet általában a felhasználó az interneten keresztül ér el. Legmagasabb szintjén pedig a \acrfull{iaas} foglal helyet, ahol az alapvető infrastruktúrát készen kapjuk, de minden mást a szolgáltatás felhasználójának kell megterveznie, feltelepíteni, konfigurálni és üzemeltetni \cite{aas}.
Előnyei miatt, manapság a nagyvállalatok csaknem 94\%-a már használja a felhő szolgáltatások nyújtotta előnyöket és alkalmazásaiknak már 83\%-a valamilyen felhő környezetben futnak \cite{cloudadpotation}.
							
							
							
								
							
						
@@ -36,6 +37,7 @@ Egy alkalmazás konténer általánosságban egy önálló csomag, amely tartalm
Az alkalmazás konténerek koncepciójának megvalósítására egy népszerű implementáció a \textit{Docker}, amely a \gls{linux} kernelben található izolációs szolgáltatásokra épít. Ezzel valósítja meg, hogy a konténerek egymástól független környezetben tudjanak futni. Egyetlen szoftver erőforrás, amin közösen osztoznak az a kernel maga.
% TODO: Átírni OCI-re
Dockerben az alkalmazást és környezetét úgynevezett képfájlokban (image) tároljuk. Ezek a képfájlok általában csak a legszükségesebb komponenseket tartalmazzák, ezért a virtuális számítógépekhez képfájlaihoz képest kisebb méretűek. Ezeket a képfájlokat az alkalmazás fejlesztése után készítjük és az alkalmazás konténer indításához használjuk \cite{docker_docs}.
\subsubsection{Kubernetes}
							
							
							
								
							
						
@@ -50,6 +52,8 @@ A klaszteren belül két jól elkülöníthető szerepkört definiálunk, ezek a
Egy \textit{Kubernetes} környezetben különböző objektumokat definiálunk, amelyekkel leírhatjuk a klaszterünkben futó alkalmazások elvárt állapotát. Ezek az objektumok közül a legkisebb kezelhető egység a \textit{Pod}. A \textit{Pod} egy vagy több futó konténert reprezentáló logikai egység. Az egy \textit{Pod}on belül futó konténerek osztoznak bizonyos névtereken, ilyen a hálózati vagy a folyamatok névtere.
% Ide még bőven lehet írni
Eggyel \enquote{nagyobb} objektum ezeknél a \textit{Deployment}, a \textit{Deployment} egy alkalmazás futtatásához szükséges állapotot írja le. A \textit{Kubernetes} klaszter törekszik a \textit{Deployment}ben megfogalmazott állapot elérésére és fenntartására.
\subsubsection{Mikroszolgáltatások}
							
							
							
								
							
						
@@ -60,7 +64,7 @@ Az egységek a fejlesztése, és tesztelése sokkal gyorsabb ütemben tud haladn
Mikroszolgáltatásokkal az alkalmazások skálázása is jelentősen leegyszerűsödik. Míg egy monolit rendszerben a teljes alkalmazást skálázni kellett, ha nagyobb teljesítményre volt szükség, itt -- feltéve, hogy tisztában vagyunk vele, hogy mely komponensek jelentik a szűk keresztmetszetet -- elég csak a megfelelő szolgáltatásokat.
A mikroszolgáltatásoknak további előnyös jellemzője, hogy az egyes komponensek teljesen egyedül kezelik a saját belső adatstruktúrájukat. Az egyetlen kompatibilitási réteg, amelyet biztosítaniuk kell az az \acrfull{api} interfész. A mikroszolgáltatások teljesen szabadon változtathatják a belső struktúrájukat akár verziók között is. De nem csak az adatstruktúrával szemben van ekkora szabadságunk, hanem akár a különböző programnyelvekkel is.
A mikroszolgáltatásoknak további előnyös jellemzője, hogy az egyes komponensek teljesen egyedül kezelik a saját belső adatstruktúrájukat. Az egyetlen kompatibilitási réteg, amelyet biztosítaniuk kell az az \acrfull{api} interfész. A mikroszolgáltatások teljesen szabadon változtathatják a belső struktúrájukat akár verziók között is. De nem csak az adatstruktúrával szemben van ekkora szabadságunk, hanem akár az alkalmazott programnyelv tekintetében is.
\section{Peremhálózati rendszerek} % Szóval itt felvezetem hogy van ez a perem meme
							
								
							
							
								
							
							
						
@@ -139,6 +143,7 @@ Számos olyan alkalmazás van, amelynél a peremhálózati és felhő rendszerek
Jelenleg is már több alkalmazásnál is használják, vagy tervezik használni. Ilyenek például az önvezető járművek \cite{liu2019edge}, ipari rendszerek távfelügyelete \cite{hao2020cloud}, betegfelügyelet \cite{wang2020secure}, felhő alapú játék szolgáltatások \cite{edge_gaming}, okos otthonok és városok \cite{shi2016edge} és még sok minden más területen \cite{edge_companies}.
% TODO: NEm készítettem az alkalmazást, hanem találtam!!!
A dolgozatom részeként a felhő és a peremhálózati rendszerek előnyeinek bemutatására két konkrét alkalmazást készítettem, amelyen jól demózhatóak az előnyök. Ezeknek a megvalósítását a  \aref{chapter:birbnetes}.\ és \aref{chapter:ursim}.\ fejezetek részletezik.
\section{Alkalmazás futtatási és fejlesztési keretrendszerek}