grammar bugfixing dun

src/content/create-functions.tex

@@ -1,9 +1,9 @@
 \chapter{F\"uggv\'enyek l\'etrehoz\'asa}
 A rendszerek sajátosságai miatt ugyanazt a kódot nem lehet változtatás nélkül felhasználni a két eltérő rendszerben. Mindkét rendszerre két tesztfüggvényt valósítottam meg. Az egyik célja a lehető legrövidebb válaszidő és a legnagyobb áteresztőképesség. A másik célja a kérésenként nagyobb processzorterhelés generálása. 
 
-Az első egy Go nyelven megvalósított tesztfüggvény, amely a meghívás után “Hello Go!” szöveggel tér vissza. A Kubeless rendszerhez írt függvény szignatúrája egyezik a \aref{code:hello-kubeless-go} k\'odr\'eszletben l\'athat\'o függvényével. Függőségként importálni kell a Kubeless sztenderd könyvtárát.
+Az első egy Go nyelven megvalósított tesztfüggvény, amely a meghívás után “Hello Go!” szöveggel tér vissza. A Kubeless rendszerhez írt függvény szignatúrája egyezik \aref{code:hello-kubeless-go} k\'odr\'eszletben l\'athat\'o függvényével. Függőségként importálni kell a Kubeless sztenderd könyvtárát.
 
-Knative rendszerben szükség van a Go sztenderd könyvtárban megtalálható HTTP szerver implementációra, valamint egy belépési függvényre, amely elindítja a webszervert és beköti a függvényünket úgy, hogy az alapértelmezett URL, ahol elindul a webszerver, az ide érkező kéréseket továbbítsa neki. Mivel a Knative-ba Docker Image-eket lehet telepíteni, ezért azt is létre kell hozni. Annak érdekében, hogy a végső Image a lehető legkisebb méretű legyen, a Go program binárissá fordítását külön végezzük el, a végső Image-be csak bemásoljuk azt. Erre a Docker ad eszközt, az úgynevezett multi-stage buildek segítségével. Ez azt jelenti, hogy egy külön végrehajtási láncot leírva lefordítjuk a kódot, majd a végső Image-be csak bemásoljuk a fordítással végzett konténer Image-éből. Az elkészült Image-et - melyet le\'ir\'o Docker file \aref{code:dockerfile-hello-go} k\'odr\'eszleten l\'athat\'o - a Docker Hubra feltöltöttem, hogy ne kelljen minden frissen telepített Workernek megépítenie az Image-et.
+Knative rendszerben szükség van a Go sztenderd könyvtárban megtalálható HTTP szerver implementációra, valamint egy belépési függvényre, amely elindítja a webszervert és beköti a függvényünket úgy, hogy az alapértelmezett URL - ahol elindul a webszerver, az ide érkező kéréseket továbbítsa neki. Mivel a Knative-ba Docker Image-eket lehet telepíteni, ezért azt is létre kell hozni. Annak érdekében, hogy a végső Image a lehető legkisebb méretű legyen, a Go program binárissá fordítását külön végezzük el, a végső Image-be csak bemásoljuk azt. Erre a Docker ad eszközt, az úgynevezett multi-stage buildek segítségével. Ez azt jelenti, hogy egy külön végrehajtási láncot leírva lefordítjuk a kódot, majd a végső Image-be csak bemásoljuk a fordítással végzett konténer Image-éből. Az elkészült Image-et - melyet le\'ir\'o Dockerfile \aref{code:dockerfile-hello-go} k\'odr\'eszleten l\'athat\'o - a Docker Hubra feltöltöttem, hogy ne kelljen minden frissen telepített Workernek megépítenie az Image-et.
 
 \begin{lstlisting}[float=!ht,caption={Echo t\'ipus\'u f\"uggv\'eny Docker Image-\'et le\'ir\'o Dockerfile},label=code:dockerfile-hello-go]
 FROM golang:1.13 as builder
@@ -30,9 +30,9 @@ A várhatóan nagyobb processzorterhelést generáló függvényként egy Python
 
 A Knative esetében szintén eltérő módon érdemes Docker Image-et készíteni a megírt függvényből. Szükség van a Flask nevű könyvtárra, amely segítségével webes alkalmazásokat lehet készíteni Pythonban. Használata igen hasonló a Go-ban megtalálható implementációhoz. Úgynevezett dekorátor segítségével lehet a Flask számára jelezni, hogy az adott függvény milyen URL meghívásakor fusson le, valamint a használni kívánt port számát is itt lehet megadni. A Docker Image építése során multi-stage build használatára nincsen szükség, hiszen a Python értelmezőnek mindenképpen jelen kell lennie a végső Image-ben is. A Flask telepítése mellett úgy döntöttem, hogy a gunicorn Pythonban implementált webszervert is telepítem, valamint azt használom, mint webszervert a Docker Image-ben. Használatának előnye, hogy képes kihasználni a Python által nyújtott multiprocessing lehetőségeket, amely azt jelenti, hogy több Python értelmezőt indítva, több folyamat használatával jobb teljesítményt lehet elérni, mint több szál használatával, ugyanis a Python értelmező egyszerre egy szálon futó programkódot értelmez. 
 
-Minden Knative függvényhez definiáltam egy-egy YAML állományban egy olyan Service-t, amelyhez tartozó Podok számát nullára képes leskálázni a rendszer, valamint egy konkurencia alapú skálázást használó Service-t. Az ut\'obbit le\'ir\'o YAML \'allom\'any \aref{code:yaml-isprime-py} k\'odr\'eszleten l\'athat\'o. 
+Minden Knative függvényhez definiáltam egy-egy YAML állományban egy olyan Service-t, amelyhez tartozó podok számát nullára képes leskálázni a rendszer, valamint egy konkurencia alapú skálázást használó Service-t. Az ut\'obbit le\'ir\'o YAML \'allom\'any \aref{code:yaml-isprime-py} k\'odr\'eszleten l\'athat\'o. 
 
-\begin{lstlisting}[float=!ht,caption={P\'irm\'asz\'aml\'al\'o f\"uggv\'eny Knative Service obejktum\'at le\'ir\'o YAML},label=code:yaml-isprime-py]
+\begin{lstlisting}[float=!ht,caption={P\'irmsz\'aml\'al\'o f\"uggv\'eny Knative Service obejktum\'at le\'ir\'o YAML},label=code:yaml-isprime-py]
 apiVersion: serving.knative.dev/v1alpha1
 kind: Service
 metadata:
@@ -55,6 +55,6 @@ spec:
               value: "Py"
 \end{lstlisting}
 
-Az elkészített függvényen, valamint a Docker Image-eket leíró Dockerfile-okat Git verziókezelőrendszerrel kezeltem, a létrehozott repository-t a GitHub szolgáltatásba feltöltöttem. Ez lehetővé tette a Travis Continuos Integration/Continuos Delivery rendszer használatát. Ezt arra használtam, hogy a változások nyugtázása után, valamint azok GitHubra történő feltöltése után a Docker Image-ek automatikusan épüljenek meg, valamint kerüljenek fel a Docker Hubra. Fontos, hogy ez nem feltétlen jelenti, hogy a Kubernetes-ben éppen futó, vagy később létrejövő Podok a legfrissebb Image-et fogják használni. Ahhoz szükség van vagy a latest nevű címkét használni, vagy az ImagePullPolicy nevű opciót bekapcsolni a Knative Service, vagy Kubernetes Deployment definiálásánál. 
+Az elkészített függvényen, valamint a Docker Image-eket leíró Dockerfile-okat Git verziókezelőrendszerrel kezeltem, a létrehozott repository-t a GitHub szolgáltatásba feltöltöttem. Ez lehetővé tette a Travis Continuos Integration/Continuos Delivery rendszer használatát. Ezt arra használtam, hogy a változások nyugtázása után, valamint azok GitHubra történő feltöltése után a Docker Image-ek automatikusan épüljenek meg, valamint kerüljenek fel a Docker Hubra. Fontos, hogy ez nem feltétlen jelenti, hogy a Kubernetes-ben éppen futó vagy később létrejövő podok a legfrissebb Image-et fogják használni. Ehhez szükség van vagy a latest nevű címkét használni vagy az ImagePullPolicy nevű opciót bekapcsolni a Knative Service vagy Kubernetes Deployment definiálásánál. 
 
-Az elkészített függvények Kubelessbe telepítése a korábban telepített parancssori interfész segítségével lehetséges. A függvény telepítése, ahhoz http végpont csatolása, valamint a skálázás létrehozása különálló parancs. Skálázás esetében a processzor limit alkalmazása a függvény telepítését végző parancs argumentumaként adható meg. Ebből adódóan skálázás esetén nem lehet csak a skálázás telepítését végrehajtó parancsot kiadni. A Kubeless függvények telepítését megkönnyítendő, elkészítettem egy bash nyelven írt szkriptet, amely paramétereként elvárja a függvény és az állomány nevét, ami tartalmazza azt, illetve a futtató környezet nevét és azt, hogy kell-e skálázás. Ezek alapján kiadja a szükséges parancsokat helyesen paraméterezve. Ezáltal a parancssori interfész helyes használatát gyorsabbá és könnyebbé tettem. 
+Az elkészített függvények Kubeless-be telepítése a korábban telepített parancssori interfész segítségével lehetséges. A függvény telepítése, ahhoz HTTP végpont csatolása, valamint a skálázás létrehozása különálló parancs. Skálázás esetében a processzor limit alkalmazása a függvény telepítését végző parancs argumentumaként adható meg. Ebből adódóan skálázás esetén nem lehet csak a skálázás telepítését végrehajtó parancsot kiadni. A Kubeless függvények telepítését megkönnyítendő, elkészítettem egy Bash nyelven írt szkriptet, amely paramétereként elvárja a függvény és az állomány nevét, ami tartalmazza azt, illetve a futtató környezet nevét és azt, hogy kell-e skálázás. Ezek alapján kiadja a szükséges parancsokat helyesen paraméterezve. Ezáltal a parancssori interfész helyes használatát gyorsabbá és könnyebbé tettem.