Farkas Attila Wiki - Friss változtatások [hu]

EDU::GAMF::Felhőalapú-szolgáltatások

ApelPro — Sun, 20 Sep 2026 09:35:27 GMT

A 2. órai diasor belinkelve a felsorolás 2. pontjához

← Régebbi változat		A lap 2026. szeptember 20., 11:35-kori változata
95. sor:		95. sor:
	#* követelmények ismertetése		#* követelmények ismertetése
	#* bérelt szervertől (VPS) a felhő megoldásokig		#* bérelt szervertől (VPS) a felhő megoldásokig
	# Felhő ökoszisztéma		# Felhő ökoszisztéma ([[Fájl:Felhoalapu-szolgaltatasok-2-ora-diak.pdf\|diasor]])
	# Adatközpontok belső hálózata		# Adatközpontok belső hálózata
	# Erőforrás virtualizálás		# Erőforrás virtualizálás

Fájl:Felhoalapu-szolgaltatasok-2-ora-diak.pdf

ApelPro — Sun, 20 Sep 2026 09:35:03 GMT

ApelPro feltöltötte ezt: Fájl:Felhoalapu-szolgaltatasok-2-ora-diak.pdf A 2. órai előadás diasora: Felhő ökoszisztéma (szolgáltatási modellek, megosztott felelősség, AWS régiók/zónák és automatikus redundancia)

Új lap

A 2. órai előadás diasora: Felhő ökoszisztéma (szolgáltatási modellek, megosztott felelősség, AWS régiók/zónák és automatikus redundancia)

Fájl:Felhoalapu-szolgaltatasok-1-ora-diak.pdf

ApelPro — Mon, 14 Sep 2026 10:08:09 GMT

ApelPro Fájl:Felhoalapu-szolgaltatasok-1-ora-diak.pdf új verzióját töltötte fel Csere a helyes bevezető diasorra (a korábban feltöltött verzió téves volt)

Új lap

Az 1. órai bevezető előadás diasora a [[EDU::GAMF::Felhőalapú-szolgáltatások]] tárgyhoz.

EDU::GAMF::Felhőalapú-szolgáltatások

ApelPro — Mon, 14 Sep 2026 10:05:25 GMT

Diasor link áthelyezve a felsorolás 1. pontjához (diasor) formában, külön bekezdés eltávolítva

← Régebbi változat		A lap 2026. szeptember 14., 12:05-kori változata
(Egy közbenső módosítás ugyanattól a szerkesztőtől nincs mutatva)
91. sor:		91. sor:

	== Az előadás menete ==		== Az előadás menete ==
	# összetett:		# összetett: ([[Fájl:Felhoalapu-szolgaltatasok-1-ora-diak.pdf\|diasor]])
	#* Regisztráció AWS felületen		#* Regisztráció AWS felületen
	#* követelmények ismertetése		#* követelmények ismertetése

Fájl:Felhoalapu-szolgaltatasok-1-ora-diak.pdf

ApelPro — Mon, 14 Sep 2026 10:02:58 GMT

ApelPro feltöltötte ezt: Fájl:Felhoalapu-szolgaltatasok-1-ora-diak.pdf Az 1. órai bevezető előadás diasora (tárgy felépítése, AWS regisztráció/bankkártya tanács, időbeosztás, követelmények)

Új lap

Az 1. órai bevezető előadás diasora a [[EDU::GAMF::Felhőalapú-szolgáltatások]] tárgyhoz.

EDU::GAMF::Felhőalapú-szolgáltatások

ApelPro — Mon, 14 Sep 2026 08:35:59 GMT

← Régebbi változat		A lap 2026. szeptember 14., 10:35-kori változata
(Egy közbenső módosítás ugyanattól a szerkesztőtől nincs mutatva)
174. sor:		174. sor:
	** [[EDU::GAMF::Felhőalapú-szolgáltatások::AWS\|AWS]]		** [[EDU::GAMF::Felhőalapú-szolgáltatások::AWS\|AWS]]
	** [[EDU::GAMF::Felhőalapú-szolgáltatások::Docker\|Docker]]		** [[EDU::GAMF::Felhőalapú-szolgáltatások::Docker\|Docker]]
			** [[EDU::GAMF::Felhőalapú-szolgáltatások::IaC\|IaC]]
	* [[EDU::GAMF::Felhőalapú-szolgáltatások::Rövidítések\|Rövidítések]]		* [[EDU::GAMF::Felhőalapú-szolgáltatások::Rövidítések\|Rövidítések]]

EDU::GAMF::Felhőalapú-szolgáltatások::IaC

ApelPro — Mon, 14 Sep 2026 08:25:43 GMT

Új IaC gyakorlat oldal létrehozása: Terraform, Ansible, Jenkins (a Docker/AWS oldalak struktúrájához illesztve)

Új lap

[[category:GAMF]]
[[category:GAMF tantárgyak|Tantárgyak]]
[[category:GAMF AWS|AWS]]
== Mi az az Infrastructure as Code (IaC)? ==
Eddig a gyakorlatok során mindent kézzel, a grafikus felületen keresztül hoztunk létre - EC2 példányt, VPC-t, RDS-t, Security Groupot stb. Ez tanulási célra kiváló, mert látjuk, hogy pontosan mi történik, de éles környezetben rengeteg problémát okoz:
* Nem reprodukálható megbízhatóan (két ember, két kattintgatás - könnyen eltérő eredmény)
* Nincs verziókezelve, nem látszik a történet, ki mit miért módosított
* Nincs automatikusan dokumentálva - a konfiguráció "a fejekben" és a felületen él
* Nehéz gyorsan, azonos módon többször újra felépíteni (pl. teszt- és éles környezet)

Az '''Infrastructure as Code''' lényege, hogy az infrastruktúrát (és sokszor a rajta futó szolgáltatások konfigurációját is) szöveges, verziókezelhető fájlokban írjuk le, amit aztán eszközök automatikusan alkalmaznak. Ezen a gyakorlaton három, egymást kiegészítő - és a piacon igen elterjedt - eszközzel ismerkedünk meg:
{| class="wikitable"
! Eszköz !! Feladata !! Egy mondatban
|-
| '''Terraform''' || Infrastruktúra '''létrehozása''' (provisioning) || "Milyen gépek/hálózatok/szolgáltatások legyenek?"
|-
| '''Ansible''' || Már létező szerverek '''konfigurálása''' || "Mi fusson/legyen telepítve a gépeken?"
|-
| '''Jenkins''' || A folyamat '''automatizálása''' (CI/CD) || "Mikor és hogyan fusson le mindez magától?"
|}

A három eszköz tipikusan egy láncban dolgozik együtt: '''Jenkins''' elindítja a folyamatot (pl. egy git push hatására), ami meghívja a '''Terraform'''-ot, hogy felépítse/frissítse az infrastruktúrát, majd az '''Ansible''' konfigurálja fel és telepíti az alkalmazást a friss szerverekre.

== Terraform ==
=== Mi az a Terraform? ===
A HashiCorp által fejlesztett, nyílt forráskódú IaC eszköz. Deklaratív nyelven (HCL - HashiCorp Configuration Language) írjuk le a '''kívánt végállapotot''' ("legyen egy ilyen EC2 példányom, ekkora Security Grouppal"), és a Terraform kitalálja, milyen API-hívásokkal éri ezt el - beleértve azt is, ha valamit módosítani vagy törölni kell egy korábbiállapothoz képest.

=== Telepítés ===
A Terraform nincs benne az alapértelmezett Ubuntu/Debian csomagtárolókban, a HashiCorp hivatalos tárolóját kell hozzáadnunk:
<syntaxhighlight lang="bash">
apt update && apt install -y gnupg software-properties-common curl
curl -fsSL https://apt.releases.hashicorp.com/gpg | gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" \
| tee /etc/apt/sources.list.d/hashicorp.list
apt update && apt install terraform -y
terraform -version
</syntaxhighlight>

=== AWS hitelesítés ===
A Terraformnak ugyanazokra a hozzáférési kulcsokra van szüksége, mint korábban az AWSCLI-nek (lásd az [[EDU::GAMF::Felhőalapú-szolgáltatások::AWS#Access_Key_management|AWS oldalon]]). Két lehetőségünk van:
* Ha már lefuttattuk az '''aws configure''' parancsot, a Terraform automatikusan megtalálja azt
* Vagy környezeti változóként is megadhatjuk:
<syntaxhighlight lang="bash">
export AWS_ACCESS_KEY_ID="ide_jön_az_access_key"
export AWS_SECRET_ACCESS_KEY="ide_jön_a_secret_key"
export AWS_DEFAULT_REGION="eu-west-1"
</syntaxhighlight>
'''Figyelem!''' Soha ne írjuk a hozzáférési kulcsokat közvetlenül a .tf fájlokba, és ne kerüljenek verziókezelőbe (git)! Használjunk környezeti változót, vagy az AWS CLI által létrehozott hitelesítési fájlt.

=== Alapfogalmak ===
* '''Provider''': melyik szolgáltatóval (AWS, Azure, GCP stb.) és hogyan kommunikáljon a Terraform
* '''Resource''': egy konkrét, létrehozandó/kezelendő erőforrás (pl. egy EC2 példány)
* '''Variable''': paraméterezhető bemeneti érték (pl. instance típusa, régió)
* '''Output''': a végrehajtás után visszaadott érték (pl. a létrehozott szerver publikus IP-je)
* '''State''': a Terraform saját nyilvántartása arról, hogy legutóbb milyen állapotot hozott létre - ez alapján tudja kiszámolni, hogy legközelebb mit kell módosítania

=== Gyakorlati példa: EC2 + Security Group ===
Hozzunk létre egy ''main.tf'' fájlt, ami a korábban már megismert módon (lásd [[EDU::GAMF::Felhőalapú-szolgáltatások::AWS#EC2_szolgáltatásai|EC2 gyakorlat]]) indít egy t2.micro szervert, rajta egy Security Grouppal, ami engedi a SSH és HTTP forgalmat:
<syntaxhighlight lang="hcl">
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}

provider "aws" {
region = "eu-west-1"
}

variable "neptun" {
description = "Neptun kód, az erőforrások elnevezéséhez"
type = string
default = "neptun"
}

resource "aws_security_group" "web" {
name = "${var.neptun}-sg"
description = "SSH + HTTP engedelyezese"

ingress {
description = "SSH"
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}

ingress {
description = "HTTP"
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}

egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}

tags = {
Name = "${var.neptun}-sg"
}
}

resource "aws_instance" "web" {
ami = "ami-0c1c30571d2dae5c9" # Ubuntu 22.04 LTS, eu-west-1
instance_type = "t2.micro"
key_name = "test" # a korabban letrehozott kulcspar neve
vpc_security_group_ids = [aws_security_group.web.id]

tags = {
Name = "${var.neptun}-web"
}
}

output "public_ip" {
value = aws_instance.web.public_ip
}
</syntaxhighlight>
'''Figyelem!''' Az AMI azonosító régiónként és időszakonként változik - mindig ellenőrizzük a konzolon (EC2 → Launch instance → AMI kiválasztás), hogy az adott régióban érvényes-e még az azonosító, mielőtt bemásoljuk.

=== A munkafolyamat: init / plan / apply / destroy ===
<syntaxhighlight lang="bash">
terraform init # letölti a szükséges providereket, előkészíti a munkakönyvtárat - csak egyszer kell (vagy provider váltáskor)
terraform plan # megmutatja, MIT fog csinálni, anélkül hogy bármit is végrehajtana - mindig nézzük át!
terraform apply # végrehajtja a terveket - rákérdez, hogy biztosan folytassuk-e (yes-szel hagyjuk jóvá)
terraform destroy # törli az összes, ebben a konfigurációban létrehozott erőforrást
</syntaxhighlight>
'''Figyelem, ez a legfontosabb szabály a féléves munkához!''' Amikor végeztünk egy gyakorlattal, futtassunk ''terraform destroy''-t, különben a létrehozott erőforrások tovább futnak és fizetési kötelezettséget okozhatnak a free tier keretein túl.

=== A state fájl ===
A ''terraform apply'' lefuttatása után megjelenik egy ''terraform.tfstate'' nevű fájl a könyvtárban - ez tárolja, hogy pontosan mit hozott létre a Terraform. '''Ez a fájl bizalmas adatokat is tartalmazhat''' (pl. jelszavakat, ha voltak a konfigurációban), ezért:
* Soha ne kerüljön git-be (vegyük fel a ''.gitignore''-ba)
* Csapatmunkánál érdemes távoli tárolást használni (pl. S3 bucket, amit korábban már megismertünk), hogy mindenki ugyanazt az állapotot lássa

== Ansible ==
=== Mi az az Ansible, és miben más, mint a Terraform? ===
Amíg a Terraform azzal foglalkozik, hogy '''milyen gépek létezzenek''', addig az Ansible azzal, hogy '''mi legyen rajtuk telepítve/beállítva'''. Az Ansible '''agentless''': nem kell külön ügynök-szoftvert telepíteni a célgépekre, elég, ha van rajtuk SSH szerver (amit eddig is használtunk a gépekhez való csatlakozáshoz) és Python.

=== Telepítés ===
<syntaxhighlight lang="bash">
apt update && apt install ansible -y
ansible --version
</syntaxhighlight>

=== Inventory - kikhez csatlakozzon? ===
Az Ansible egy úgynevezett ''inventory'' fájlból tudja, mely szerverekkel dolgozzon. Hozzunk létre egy ''inventory.ini'' fájlt, a korábban megismert SSH kulcsot és felhasználónevet felhasználva (lásd [[EDU::GAMF::Felhőalapú-szolgáltatások::AWS#Csatlakozás_Linux_terminálból|itt]]):
<syntaxhighlight lang="ini">
[webservers]
web1 ansible_host=3.252.168.207 ansible_user=ubuntu ansible_ssh_private_key_file=~/test.pem
</syntaxhighlight>

Ellenőrizzük, hogy elérjük-e a gépet:
<syntaxhighlight lang="bash">
ansible -i inventory.ini webservers -m ping
</syntaxhighlight>

=== Ad-hoc parancsok ===
Egyszeri feladatokhoz nem kell playbookot írnunk, elég egy modult megneveznünk:
<syntaxhighlight lang="bash">
# csomaglista frissítése minden webservers csoportba tartozó gépen
ansible -i inventory.ini webservers -m apt -a "update_cache=yes" --become

# egy adott parancs lefuttatása
ansible -i inventory.ini webservers -m shell -a "uptime"
</syntaxhighlight>
A ''--become'' kapcsoló jelenti a sudo-s (root) jogosultsággal történő végrehajtást, hasonlóan ahhoz, mintha ''sudo''-t írnánk a parancs elé.

=== Playbook - a korábbi telepítő script Ansible-lel ===
Emlékezzünk vissza: a gyakorlat elején egy bash scripttel (''UI indítás'', lásd az AWS oldalon) telepítettük fel a weboldalunkat egy EC2-re. Ennek '''két nagy hátránya''' volt: csak egyszer, az EC2 indításakor futott le (User data), és nem volt idempotens - ha kétszer lefuttatnánk, hibákat okozna (pl. már létező mappa létrehozása). Nézzük meg, hogyan váltja ki ugyanezt egy Ansible playbook, amit '''bármikor, bármennyiszer''' újra lefuttathatunk anélkül, hogy kárt tenne:
<syntaxhighlight lang="yaml">
---
- name: Weboldal UI telepítése
hosts: webservers
become: yes
vars:
neptun: "neptun"
api_lb_domain: "localhost"

tasks:
- name: Csomaglista frissítése
apt:
update_cache: yes

- name: Szükséges csomagok telepítése
apt:
name:
- apache2
- libapache2-mod-php8.3
- php8.3
- php8.3-curl
- unzip
state: present

- name: Weboldal letöltése és kicsomagolása
unarchive:
src: https://wiki.farkas-attila.hu/images/c/c7/Weboldal.zip
dest: /tmp/
remote_src: yes

- name: Célkönyvtár létrehozása
file:
path: "/srv/{{ neptun }}"
state: directory

- name: <ip> csere a tényleges API domain-re és fájlok elhelyezése
copy:
src: "/tmp/{{ item.src }}"
dest: "/srv/{{ neptun }}/{{ item.dest }}"
remote_src: yes
loop:
- { src: "ui.php", dest: "index.php" }
- { src: "ui_newproduct.php", dest: "newproduct.php" }

- name: <ip> tag lecserélése a tényleges API domain-re
replace:
path: "/srv/{{ neptun }}/{{ item }}"
regexp: "<ip>"
replace: "{{ api_lb_domain }}"
loop:
- index.php
- newproduct.php

- name: Apache virtualhost beállítása
template:
src: templates/000-default.conf.j2
dest: /etc/apache2/sites-enabled/000-default.conf
notify: Apache ujraindul

handlers:
- name: Apache ujraindul
service:
name: apache2
state: restarted
</syntaxhighlight>
Figyeljük meg az '''idempotencia''' elvét minden lépésnél: az ''apt'' modul csak akkor telepít, ha a csomag még nincs fent; a ''file'' modul csak akkor hoz létre könyvtárat, ha az még nem létezik. Ha kétszer futtatjuk le a playbookot, a második futás nem fog hibázni, csak megállapítja, hogy "már minden rendben van" (ez az úgynevezett ''changed=0'' állapot).

A playbook futtatása:
<syntaxhighlight lang="bash">
ansible-playbook -i inventory.ini deploy-ui.yml
</syntaxhighlight>

== Jenkins ==
=== Mi az a Jenkins? ===
A Jenkins egy nyílt forráskódú CI/CD (Continuous Integration / Continuous Deployment) automatizáló szerver: az ő feladata, hogy a fejlesztői munka (pl. egy git push) hatására automatikusan lefuttassa a szükséges lépéseket - tesztelés, build, majd akár a Terraform és Ansible meghívása is, hogy a legfrissebb kód éles környezetbe kerüljön emberi beavatkozás nélkül.

=== Telepítés Docker konténerben ===
Mivel a félév második fele a Dockerről szól, a Jenkins telepítését is ezen keresztül végezzük el - így nem szennyezzük a hoszt rendszert, és könnyen el is távolítható:
<syntaxhighlight lang="bash">
docker volume create jenkins_home
docker run -d --name jenkins \
-p 8080:8080 -p 50000:50000 \
-v jenkins_home:/var/jenkins_home \
jenkins/jenkins:lts
</syntaxhighlight>
A '''8080'''-as port a webes admin felület, az '''50000'''-es port pedig azoknak az esetleges elosztott build-ügynököknek (agent) van fenntartva, amik egy másik gépről csatlakoznának a Jenkins szerverhez.

A kezdeti admin jelszót a konténer belsejéből kell kiolvasnunk:
<syntaxhighlight lang="bash">
docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword
</syntaxhighlight>
Ezt beillesztve a ''http://<szerver_ip>:8080'' címen elérhető telepítő varázslóba, majd a javasolt beépülők (plugins) telepítésével elkészül az alapkonfiguráció.

=== Pipeline alapfogalmak ===
A Jenkins munkafolyamatait ''Jenkinsfile'' néven, a projekt gyökerében elhelyezett, Groovy szintaxisú fájlban írjuk le (tehát ez a fájl is git-be kerül a projekt kódjával együtt - önmagában is egyfajta "code" a CI/CD folyamatból):
* '''pipeline''': a teljes folyamatot összefogó blokk
* '''stage''': egy-egy logikai szakasz (pl. "Build", "Terraform Apply", "Ansible Deploy") - ezek jelennek meg névvel a Jenkins felületén
* '''steps''': az adott szakaszban ténylegesen végrehajtandó parancsok

=== Gyakorlati példa: Terraform + Ansible pipeline ===
<syntaxhighlight lang="groovy">
pipeline {
agent any

stages {
stage('Checkout') {
steps {
git branch: 'main', url: 'https://github.com/pelda/gamf-projekt.git'
}
}

stage('Terraform Init') {
steps {
sh 'terraform init'
}
}

stage('Terraform Apply') {
steps {
sh 'terraform apply -auto-approve'
}
}

stage('Ansible Deploy') {
steps {
sh 'ansible-playbook -i inventory.ini deploy-ui.yml'
}
}
}

post {
failure {
echo 'A pipeline elszállt - ellenőrizzük a logokat!'
}
}
}
</syntaxhighlight>
'''Figyelem!''' Ahhoz, hogy a fenti ''sh'' lépések ténylegesen működjenek, a Terraform-ot és az Ansible-t is telepíteni kell magába a Jenkins konténerbe (vagy egy erre felkészített, saját ''Dockerfile''-ból épített Jenkins image-be - gondoljunk vissza a Docker fejezetre, pontosan ez a ''image készítés'' egyik tipikus, valós felhasználási módja).

== Összefoglalás - hogyan áll össze a lánc? ==
{| class="wikitable" style="margin:0px auto"
! Lépés !! Eszköz !! Mit csinál
|-
| 1 || Fejlesztő || ''git push'' a kódra
|-
| 2 || Jenkins || Észleli a változást, elindítja a pipeline-t
|-
| 3 || Terraform || Felépíti/frissíti az infrastruktúrát (VPC, EC2, Security Group, RDS stb.)
|-
| 4 || Ansible || Feltelepíti és konfigurálja az alkalmazást a friss szervereken
|-
| 5 || - || Az alkalmazás elérhetővé válik, emberi kattintgatás nélkül
|}

Ez a minta közvetlenül kapcsolódik a féléves projektfeladat követelményeihez is: a Terraformmal létrehozott VPC, EC2, ASG/LB, RDS mind beleszámít a projektkövetelmény-listába (lásd a [[EDU::GAMF::Felhőalapú-szolgáltatások|főoldalon]]), csak éppen automatizált, verziókezelt, újra futtatható formában - ami jóval közelebb áll ahhoz, ahogy ma egy valós cégnél is üzemeltetik a felhős infrastruktúrát.

== Jegyzetek ==
* [[EDU::GAMF::Felhőalapú-szolgáltatások::AWS|AWS]]
* [[EDU::GAMF::Felhőalapú-szolgáltatások::Docker|Docker]]
* [[GAMF::Felhőalapú-szolgáltatások::Előadás|Előadás]] - lásd a Felhő ökoszisztéma fejezet IaC alfejezetét az elméleti háttérhez

EDU::GAMF::Felhőalapú-szolgáltatások::AWS

ApelPro — Mon, 14 Sep 2026 08:21:20 GMT

Alkalmazások telepítése

← Régebbi változat		A lap 2026. szeptember 14., 10:21-kori változata
520. sor:		520. sor:
	# Kattintsunk a szerkeszteni kívánt tárhely nevére<br>[[Fájl:GAMFAWS S3f list.png]]<br><br>		# Kattintsunk a szerkeszteni kívánt tárhely nevére<br>[[Fájl:GAMFAWS S3f list.png]]<br><br>
	# A vezérlőgombok segítségével végezzük el a kívánt műveletet (feltöltés, törlés), vagy válasszunk ki egy PREFIX-et az „almappák” tartalmának megtekintéséhez.<br>[[Fájl:GAMFAWS S3 control.png\|középre]]		# A vezérlőgombok segítségével végezzük el a kívánt műveletet (feltöltés, törlés), vagy válasszunk ki egy PREFIX-et az „almappák” tartalmának megtekintéséhez.<br>[[Fájl:GAMFAWS S3 control.png\|középre]]

	~~= Alkalmazások telepítése =~~
	~~== UI ==~~
	~~== API ==~~

	= Indítást gyorsító scriptek =		= Indítást gyorsító scriptek =

Hálózat rendelkezésreállás számítás

ApelPro — Mon, 14 Sep 2026 08:18:21 GMT

Az ábra időközben javítva lett (újragenerálva helyes végeredménnyel), a 'hibás ábra' figyelmeztetés eltávolítva

← Régebbi változat		A lap 2026. szeptember 14., 10:18-kori változata
36. sor:		36. sor:
	[[Fájl:2-2 router, 2-2 link.png\|1000px\|keretnélküli\|középre]]		[[Fájl:2-2 router, 2-2 link.png\|1000px\|keretnélküli\|középre]]
	Az előző kapcsolást fejleszthetjük tovább oly módon, hogy két kapcsolatot létesítünk minden router között. A csatolt ábra pontos (nem közelítő) számítása szerint egy-egy ág - tehát egy router, amely két vezetékkel kapcsolódik mindkét másik routerhez - hibavalószínűsége 1,0103%-ra adódik. Mivel a teljes kapcsolat csak akkor válik működésképtelenné, ha mindkét ág egyszerre hibásodik meg (ÉS kapcsolat), a végeredmény: 0,010103 × 0,010103 × 100 ≈ '''0,0102%'''.		Az előző kapcsolást fejleszthetjük tovább oly módon, hogy két kapcsolatot létesítünk minden router között. A csatolt ábra pontos (nem közelítő) számítása szerint egy-egy ág - tehát egy router, amely két vezetékkel kapcsolódik mindkét másik routerhez - hibavalószínűsége 1,0103%-ra adódik. Mivel a teljes kapcsolat csak akkor válik működésképtelenné, ha mindkét ág egyszerre hibásodik meg (ÉS kapcsolat), a végeredmény: 0,010103 × 0,010103 × 100 ≈ '''0,0102%'''.

	'''Figyelem, számolási hiba az ábrán!''' A csatolt ábrán feltüntetett "0,000102070609%" végeredmény hibás: az ábra saját képlete helyesen tartalmazza a százalékra váltáshoz szükséges ×100-as szorzást, de ez a szorzás nincs érvényesítve a kiírt végeredményben - emiatt az ábrán szereplő szám 100-szor kisebb a helyesnél. A helyes érték a fenti, kb. 0,0102%, nem 0,0001%. Az ábra frissítése (újragenerálása) még hátravan.

Fájl:2-2 router, 2-2 link.png

ApelPro — Mon, 14 Sep 2026 08:17:49 GMT

ApelPro Fájl:2-2 router, 2-2 link.png új verzióját töltötte fel Javítva: a végeredmény ki volt írva hibásan (0.000102070609% helyett a képlet saját ×100-as lépése alapján 0.0102070609% a helyes érték - 100x eltérés volt)

Új lap

2-2 router, 2-2 link

Hálózat rendelkezésreállás számítás

ApelPro — Mon, 14 Sep 2026 08:12:35 GMT

Utolsó számítás javítva a csatolt ábra alapján (1.0103%/ág, végeredmény kb. 0.0102%, nem 0.0001%) - az ábrán 100x-os számolási/kiírási hiba van, ami külön javítást igényel

← Régebbi változat		A lap 2026. szeptember 14., 10:12-kori változata
35. sor:		35. sor:
	== 1-1 router 2 másikkal áll kapcsolatban, két vezetékkel összekapcsolva ==		== 1-1 router 2 másikkal áll kapcsolatban, két vezetékkel összekapcsolva ==
	[[Fájl:2-2 router, 2-2 link.png\|1000px\|keretnélküli\|középre]]		[[Fájl:2-2 router, 2-2 link.png\|1000px\|keretnélküli\|középre]]
	Az előző kapcsolást fejleszthetjük tovább oly módon, hogy két kapcsolatot létesítünk minden router között. ~~Azt már tudjuk~~, ~~hogy ez esetben~~ a kapcsolat ~~működésképtelensége~~ 0.01%-~~ra csökken~~ az ~~eredeti 1%~~-~~kal számolva vezetékenként~~. A ~~számítási mód ugyanaz~~, ~~mint az előző esetben~~, ~~csak a vezeték meghibásodásának valószínűségét kell az új értékre cserélnünk. Így tehát~~ 0.0001% ~~valószínűségűre tudjuk szorítani a hibát~~.		Az előző kapcsolást fejleszthetjük tovább oly módon, hogy két kapcsolatot létesítünk minden router között. A csatolt ábra pontos (nem közelítő) számítása szerint egy-egy ág - tehát egy router, amely két vezetékkel kapcsolódik mindkét másik routerhez - hibavalószínűsége 1,0103%-ra adódik. Mivel a teljes kapcsolat csak akkor válik működésképtelenné, ha mindkét ág egyszerre hibásodik meg (ÉS kapcsolat), a végeredmény: 0,010103 × 0,010103 × 100 ≈ '''0,0102%'''.

			'''Figyelem, számolási hiba az ábrán!''' A csatolt ábrán feltüntetett "0,000102070609%" végeredmény hibás: az ábra saját képlete helyesen tartalmazza a százalékra váltáshoz szükséges ×100-as szorzást, de ez a szorzás nincs érvényesítve a kiírt végeredményben - emiatt az ábrán szereplő szám 100-szor kisebb a helyesnél. A helyes érték a fenti, kb. 0,0102%, nem 0,0001%. Az ábra frissítése (újragenerálása) még hátravan.

BGP protokoll

ApelPro — Mon, 14 Sep 2026 08:11:46 GMT

RIPE NCC / IANA viszony pontosítva (nem szervezeti alárendelt); elavult BGP tábla méret (880k route, 2021-es adat) frissítve/általánosítva

← Régebbi változat		A lap 2026. szeptember 14., 10:11-kori változata
20. sor:		20. sor:
	'''Fontos''': Publikus AS nem csak egy internetszolgáltató lehet. Egy egyszerű vállalkozás is vásárolhat IP tartományt, amihez szüksége lesz egy ASN-re is. Ez pl. multihomed kapcsolatok esetén történik meg - emiatt tudják kívülről a céget két internetszolgáltatón keresztül is elérni és így lehetséges, hogy mind a két szolgáltató ugyanazon az IP címen regisztrálja. Léteznek privát ASN-ek is, amelyeket nem kell beregisztrálnunk, ezeket általában a helyi hálózaton belül alkalmazzák (64512-65534). Ezek segítségével lehetőség nyílik arra is, hogy egy publikus AS több kisebb privát AS-ből épüljön fel. Az internetszolgáltatók a saját hálózatukon belül általában valamilyen IGP szolgáltatást használnak - pl. OSPF-et.		'''Fontos''': Publikus AS nem csak egy internetszolgáltató lehet. Egy egyszerű vállalkozás is vásárolhat IP tartományt, amihez szüksége lesz egy ASN-re is. Ez pl. multihomed kapcsolatok esetén történik meg - emiatt tudják kívülről a céget két internetszolgáltatón keresztül is elérni és így lehetséges, hogy mind a két szolgáltató ugyanazon az IP címen regisztrálja. Léteznek privát ASN-ek is, amelyeket nem kell beregisztrálnunk, ezeket általában a helyi hálózaton belül alkalmazzák (64512-65534). Ezek segítségével lehetőség nyílik arra is, hogy egy publikus AS több kisebb privát AS-ből épüljön fel. Az internetszolgáltatók a saját hálózatukon belül általában valamilyen IGP szolgáltatást használnak - pl. OSPF-et.

	A BGP útvonalak mára jelentős méretet foglalnak el (~~500MB~~-~~1000MB~~). Ezt az Edge eszköz a memóriájában tartja, tehát egyrészt megfelelő eszközt kell választanunk erre a célra memóriaszempontból, de természetesen a rekordokat frissíteni is kell (~~ez nagyjából 880.000~~ útvonalat ~~jelent~~), amihez CPU időt kell biztosítanunk. Egy kisebb eszköz ekkora teher alatt lefagy és működésképtelenné válik!		A BGP útvonalak mára jelentős méretet foglalnak el (nagyságrendileg százas MB-tól akár GB-os nagyságrendig, a tábla folyamatosan, évről évre nő). Ezt az Edge eszköz a memóriájában tartja, tehát egyrészt megfelelő eszközt kell választanunk erre a célra memóriaszempontból, de természetesen a rekordokat frissíteni is kell (a globális IPv4 BGP tábla mérete 2024-re már meghaladta az 1 millió útvonalat, és ehhez jön még az IPv6 tábla is), amihez CPU időt kell biztosítanunk. Egy kisebb eszköz ekkora teher alatt lefagy és működésképtelenné válik! ''(A pontos, aktuális méretet érdemes közvetlenül a lentebb linkelt bgp.potaroo.net oldalon ellenőrizni, mert ez folyamatosan változik.)''

	==== Hasznos linkek ====		==== Hasznos linkek ====
27. sor:		27. sor:

	==== RIPE ====		==== RIPE ====
	A RIPE NCC névre hallgató szervezet az IANA ~~egy regionális alszervezete~~. A szakirodalom RIR (Regional Internet Registry) módon említi.		A RIPE NCC névre hallgató szervezet egy önálló, tagjai (internetszolgáltatók, cégek) által fenntartott, nonprofit regionális szervezet - nem az IANA szervezeti alárendeltje, hanem attól függetlenül működik, azzal együttműködve. Az IANA (amit ma az ICANN felügyel) osztja ki a nagy IP-tartományokat a régiónkénti regisztrátoroknak, a RIPE NCC pedig ebből allokál tovább ASN-eket és IP-tartományokat az európai/közel-keleti régió szolgáltatóinak, cégeinek. A szakirodalom RIR (Regional Internet Registry) módon említi.
	Az IANA tartja számon a világon eladott összes IP címtartományt és a hozzájuk tartozó ASN-eket.		Az IANA tartja számon a világon eladott összes IP címtartományt és a hozzájuk tartozó ASN-eket.

GAMF

ApelPro — Mon, 14 Sep 2026 08:05:35 GMT

Törött AWS/Docker linkek javítva a helyes oldalcímekre + hibás listaformázás javítva

← Régebbi változat		A lap 2026. szeptember 14., 10:05-kori változata
1. sor:		1. sor:
	== GAMF órai tantárgyak, segédletek ==		== GAMF órai tantárgyak, segédletek ==
	==== Felhőszolgáltatások ====		==== Felhőszolgáltatások ====
	* #[[AWS]]		* [[EDU::GAMF::Felhőalapú-szolgáltatások::AWS\|AWS]]
	* #[[Docker]]		* [[EDU::GAMF::Felhőalapú-szolgáltatások::Docker\|Docker]]

MikroTik::Scripting

ApelPro — Mon, 14 Sep 2026 08:05:24 GMT

Script hiba javítva: sender=$email (nem létező változó) -> sender=$sendEmail

← Régebbi változat		A lap 2026. szeptember 14., 10:05-kori változata
179. sor:		179. sor:
	:delay 10000ms		:delay 10000ms

	$sendMail emails=$toEmails sender=$~~email~~ smtp=$smtp file=($backup->"prefix" . $backup->"fileName") \		$sendMail emails=$toEmails sender=$sendEmail smtp=$smtp file=($backup->"prefix" . $backup->"fileName") \
	subject=([/system identity get name] ." ". [/system clock get date] . " " . [/system clock get time] . " backup file") \		subject=([/system identity get name] ." ". [/system clock get date] . " " . [/system clock get time] . " backup file") \
	text="Please note that the file is transmitted encrypted. If you have forgotten the key, please contact the appropriate person."		text="Please note that the file is transmitted encrypted. If you have forgotten the key, please contact the appropriate person."

EDU::GAMF::MikroTik

ApelPro — Mon, 14 Sep 2026 08:05:15 GMT

Pontosítva, hogy pfSense BSD pf-et használ (nem iptables-t), és a MikroTik RouterOS saját tűzfalmotorral rendelkezik

← Régebbi változat		A lap 2026. szeptember 14., 10:05-kori változata
9. sor:		9. sor:
	* Debian/Ubuntu/Fedora stb.		* Debian/Ubuntu/Fedora stb.

	A fent felsoroltak mind-mind Linux (vagy BSD) alapú rendszerek, amelyek képesek router funkciókat ellátni. ~~Apróbb különbségek lehetnek~~, ~~de nagyjából mindegyik~~ a ~~jól ismert~~ ''iptables'' ~~modulra épít~~, ~~ahogy~~ a MikroTik is.		A fent felsoroltak mind-mind Linux (vagy BSD) alapú rendszerek, amelyek képesek router funkciókat ellátni. A tűzfal-motorjuk azonban nem egységes: a Linux alapú megoldások (VyOS, OpenWRT, Debian/Ubuntu/Fedora) a Linux kernel netfilter alrendszerére, tehát az ''iptables''/''nftables'' családra épülnek, a FreeBSD alapú pfSense viszont a BSD-k saját, ezektől független csomagszűrőjét, a ''pf''-et (Packet Filter) használja - a kettő nem kompatibilis egymással. A MikroTik RouterOS is Linux kernelt használ, de a tűzfala nem a szabványos iptables/nftables, hanem egy saját fejlesztésű, azokéhoz hasonló (lánc alapú) motor.

	'''Linkek:'''		'''Linkek:'''

EDU::GAMF::IPTABLES

ApelPro — Mon, 14 Sep 2026 08:05:05 GMT

Hibás 'main iptables-extensions' parancs javítva 'man'-ra; ufw zóna-állítás pontosítva

← Régebbi változat		A lap 2026. szeptember 14., 10:05-kori változata
1. sor:		1. sor:
	Az iptables általában alapból telepítve van Linux alapú operációs rendszereken. A legtöbb ember ennek ellenére igen ritkán találkozik vele, de sokszor a szakemberek is a ráépülő eszközöket használják, mint például az ''ufw'' és a ''firewalld''. Utóbbiak rendelkeznek egy nagy előnnyel: az iptables utódjaként szolgáló ''nft''-t is képesek kezelni, így nem kell más programot megtanulni a fejlődéshez.		Az iptables általában alapból telepítve van Linux alapú operációs rendszereken. A legtöbb ember ennek ellenére igen ritkán találkozik vele, de sokszor a szakemberek is a ráépülő eszközöket használják, mint például az ''ufw'' és a ''firewalld''. Utóbbiak rendelkeznek egy nagy előnnyel: az iptables utódjaként szolgáló ''nft''-t is képesek kezelni, így nem kell más programot megtanulni a fejlődéshez.

	Az iptables egy szabálylánc alapú tűzfalrendszer, amelyeket különböző táblákba rendeznek (az nft szintén láncokkal dolgozik~~, de az ufw és~~ a firewalld ezekkel ellentétben zónákba rendezi a szabályokat. Ne feledjük el azonban, hogy minden ufw és firewalld programokkal felvett szabály végül az iptables/nft láncokba kerülnek be, amiből levonható az a következtetés, hogy az alapvetően szabályláncokkal operáló alkalmazásban is tudunk zóna szerű, átlátható struktúrát kialakítani). Vannak alapértelmezetten létező láncok, amelyeket le sem tudunk törölni: ezeket a netfilter kernelmodul hívja meg, amikor a csomag életútjának megadott fázisában jár. A láncok meghívási sorrendjét ''packetflow''-nak nevezzük. Érdemes a tűzfal tervezésekor figyelembe venni, hogy minél hamarabb szabadulunk meg egy nem kívánt csomagtól, annál kevesebb CPU időt igényel. Az eldobás akcióval ellentétben az elfogadás sokkal körülményesebb: ezek a csomagok a létező összes alapértelmezett láncon át kell menjenek és elfogadásra kell kerüljenek (nagyon könnyen belátható, hogy ha egy láncban az adott csomagot tovább engedjük, akkor a csomag életútjának következő fázisában a netfilter meg fogja hívni a következő láncot, ahol egy ''eldobás'' művelet a feldolgozás megszakítását jelenti, tehát a csomag nem fog célba érkezni).		Az iptables egy szabálylánc alapú tűzfalrendszer, amelyeket különböző táblákba rendeznek (az nft szintén láncokkal dolgozik; a firewalld ezekkel ellentétben zónákba rendezi a szabályokat, az ufw pedig még ennél is egyszerűbb, lineáris szabálylistával dolgozik, zóna fogalom nélkül. Ne feledjük el azonban, hogy minden ufw és firewalld programokkal felvett szabály végül az iptables/nft láncokba kerülnek be, amiből levonható az a következtetés, hogy az alapvetően szabályláncokkal operáló alkalmazásban is tudunk zóna szerű, átlátható struktúrát kialakítani). Vannak alapértelmezetten létező láncok, amelyeket le sem tudunk törölni: ezeket a netfilter kernelmodul hívja meg, amikor a csomag életútjának megadott fázisában jár. A láncok meghívási sorrendjét ''packetflow''-nak nevezzük. Érdemes a tűzfal tervezésekor figyelembe venni, hogy minél hamarabb szabadulunk meg egy nem kívánt csomagtól, annál kevesebb CPU időt igényel. Az eldobás akcióval ellentétben az elfogadás sokkal körülményesebb: ezek a csomagok a létező összes alapértelmezett láncon át kell menjenek és elfogadásra kell kerüljenek (nagyon könnyen belátható, hogy ha egy láncban az adott csomagot tovább engedjük, akkor a csomag életútjának következő fázisában a netfilter meg fogja hívni a következő láncot, ahol egy ''eldobás'' művelet a feldolgozás megszakítását jelenti, tehát a csomag nem fog célba érkezni).

	'''Témakörök:'''		'''Témakörök:'''
15. sor:		15. sor:
	'''Fontosabb teendők'''		'''Fontosabb teendők'''
	* Érdemes áttekinteni a kézikönyvet! Ezáltal lesz fogalmunk arról, hogy milyen funkciók vannak és később könnyebben keresünk benne.		* Érdemes áttekinteni a kézikönyvet! Ezáltal lesz fogalmunk arról, hogy milyen funkciók vannak és később könnyebben keresünk benne.
	man iptables # az iptables parancs kapcsolóit ~~dokuemntálja~~		man iptables # az iptables parancs kapcsolóit dokumentálja
	~~main~~ iptables-extensions # az iptables parancs -m kapcsolója után megadható kiterjesztéseket és kapcsolóit írja le		man iptables-extensions # az iptables parancs -m kapcsolója után megadható kiterjesztéseket és kapcsolóit írja le
	* Érdemes megjegyezni, hogy hogyan tudjuk a szabályainkat kilistázni, menteni és visszaállítani.		* Érdemes megjegyezni, hogy hogyan tudjuk a szabályainkat kilistázni, menteni és visszaállítani.
	iptables [-t table] --list # ez a hosszú formátum, de alapértelmezetten a ''filter'' tábla tartalmát listázza és használhatjuk a rövidebb, -L kapcsolót is a --list helyett.		iptables [-t table] --list # ez a hosszú formátum, de alapértelmezetten a ''filter'' tábla tartalmát listázza és használhatjuk a rövidebb, -L kapcsolót is a --list helyett.

ISP csatlakozási típusok

ApelPro — Mon, 14 Sep 2026 08:04:55 GMT

EGP hibás kifejtése javítva (External -> Exterior Gateway Protocol)

← Régebbi változat		A lap 2026. szeptember 14., 10:04-kori változata
1. sor:		1. sor:
	Egy átlag ember általában nem gondolkozik sokat azon, hogy milyen lehetőségei vannak az internetelérésre, esetleg szerverek üzemeltetésére: a jól bevált módszer, hogy kérünk egy publikus IP címet az egyik környékünkön elérhető szolgáltatótól, a szolgáltatással együtt kapott kábel végét bedugják a routerünkbe és meg is van oldva a problémánk. Ennél azonban jóval több lehetőségünk akad.		Egy átlag ember általában nem gondolkozik sokat azon, hogy milyen lehetőségei vannak az internetelérésre, esetleg szerverek üzemeltetésére: a jól bevált módszer, hogy kérünk egy publikus IP címet az egyik környékünkön elérhető szolgáltatótól, a szolgáltatással együtt kapott kábel végét bedugják a routerünkbe és meg is van oldva a problémánk. Ennél azonban jóval több lehetőségünk akad.

	Az internet kis hálózatokból - úgymond felhőkből - felépülő halmaz. Az egyes felhőket más-más szervezetek tartják karban és teljes autonómiájuk van azzal kapcsolatban, hogy mit csinálnak, milyen routing protokollokat (BGP, OSPF, RIP stb.) alkalmaznak. Ezeket angolul ''Autonomous System''-nek nevezik (röviden AS) és minden ilyen kis hálózat rendelkezik egy úgynevezett ''AS Number''-rel (röviden ASN), ami azonosítja. Az ASN-t és a hozzátartozó, belül elérhető IP címeket BGP (Border Gateway Protocol) protokollon keresztül kell hirdetni, ami jelenleg az egyetlen elérhető EGP (~~External~~ Gateway Protocol) protokoll (figyelem, korábban mint IGP protokoll szerepelt a listában, amelyből több is létezik). A BGP protokoll működéséhez Peer-eket kell felvennünk, kapcsolatot kell felépítenünk egy olyan eszközzel, aki már részese az ''internet'' hálózatának és továbbítani tudja a szabályainkat (mindkét oldalon konfigurálni kell, ez biztosítja, hogy nem léphet be bárki ebbe a „zárt” hálózatba).		Az internet kis hálózatokból - úgymond felhőkből - felépülő halmaz. Az egyes felhőket más-más szervezetek tartják karban és teljes autonómiájuk van azzal kapcsolatban, hogy mit csinálnak, milyen routing protokollokat (BGP, OSPF, RIP stb.) alkalmaznak. Ezeket angolul ''Autonomous System''-nek nevezik (röviden AS) és minden ilyen kis hálózat rendelkezik egy úgynevezett ''AS Number''-rel (röviden ASN), ami azonosítja. Az ASN-t és a hozzátartozó, belül elérhető IP címeket BGP (Border Gateway Protocol) protokollon keresztül kell hirdetni, ami jelenleg az egyetlen elérhető EGP (Exterior Gateway Protocol) protokoll (figyelem, korábban mint IGP protokoll szerepelt a listában, amelyből több is létezik). A BGP protokoll működéséhez Peer-eket kell felvennünk, kapcsolatot kell felépítenünk egy olyan eszközzel, aki már részese az ''internet'' hálózatának és továbbítani tudja a szabályainkat (mindkét oldalon konfigurálni kell, ez biztosítja, hogy nem léphet be bárki ebbe a „zárt” hálózatba).

	Egy ilyen AS lehet az otthoni hálózatunk is: teljes mértékben mi döntünk a belső felépítéséről, a szolgáltató nem szólhat bele. Az egyetlen eltérés, hogy nekünk nem kell az ASN-t hirdetni a szolgáltató felé - de Ő hirdetni fogja a mi publikus IP címünket a világon működő egyéb AS-ek felé. Mi általában a részévé válunk az Ő hálózatának, csúnyán szólva az Ő AS-ének. Ezeket az otthoni hálózatokat a szakirodalom ''stub network''-nek nevezi - mintegy sziget az óceánon, amelyre egyetlen híd vezet a szárazföldről. Léteznek ''non-stub network'' megoldások is, amihez a szolgáltató (vagy szolgáltatókkal) való szoros együttműködés keretein belül lehet létrehozni és természetesen magasabb költségekkel kell számolnunk.		Egy ilyen AS lehet az otthoni hálózatunk is: teljes mértékben mi döntünk a belső felépítéséről, a szolgáltató nem szólhat bele. Az egyetlen eltérés, hogy nekünk nem kell az ASN-t hirdetni a szolgáltató felé - de Ő hirdetni fogja a mi publikus IP címünket a világon működő egyéb AS-ek felé. Mi általában a részévé válunk az Ő hálózatának, csúnyán szólva az Ő AS-ének. Ezeket az otthoni hálózatokat a szakirodalom ''stub network''-nek nevezi - mintegy sziget az óceánon, amelyre egyetlen híd vezet a szárazföldről. Léteznek ''non-stub network'' megoldások is, amihez a szolgáltató (vagy szolgáltatókkal) való szoros együttműködés keretein belül lehet létrehozni és természetesen magasabb költségekkel kell számolnunk.

Hálózat rendelkezésreállás számítás

ApelPro — Mon, 14 Sep 2026 08:04:46 GMT

Számolási elgépelés javítása (0.1% -> 0.01%, konzisztens a végösszeggel)

← Régebbi változat		A lap 2026. szeptember 14., 10:04-kori változata
13. sor:		13. sor:

	[[Fájl:Fail Dual Homed.png\|1000px\|keretnélküli\|középre]]		[[Fájl:Fail Dual Homed.png\|1000px\|keretnélküli\|középre]]
	Ebben az esetben a routerek között két vezeték található, amelyek 1-1% valószínűséggel mehetnek tönkre. A kapcsolat csak akkor szakad meg, ha a bal oldali router (1%) vagy mind a két vezeték, vagy a jobb oldali router (1%) megy tönkre. Az előbbiek alapján láthattuk, hogy a vagy kapcsolat miatt az értékek összeadódnak, ám a vezeték esetében ÉS kapcsolat van, tehát azok hiba valószínűségét szorozni kell: 0.010.01 100, azaz 0.1% valószínűséggel fog mindkét kábel tönkremenni. Ebből adódóan a teljes kapcsolás 2.01% valószínűséggel nem fogja továbbítani a csomagokat.		Ebben az esetben a routerek között két vezeték található, amelyek 1-1% valószínűséggel mehetnek tönkre. A kapcsolat csak akkor szakad meg, ha a bal oldali router (1%) vagy mind a két vezeték, vagy a jobb oldali router (1%) megy tönkre. Az előbbiek alapján láthattuk, hogy a vagy kapcsolat miatt az értékek összeadódnak, ám a vezeték esetében ÉS kapcsolat van, tehát azok hiba valószínűségét szorozni kell: 0.01*0.01 = 0.0001, azaz 0.01% valószínűséggel fog mindkét kábel tönkremenni. Ebből adódóan a teljes kapcsolás 2.01% valószínűséggel nem fogja továbbítani a csomagokat.

	== 1-2 router kapcsolat ==		== 1-2 router kapcsolat ==

EDU::GAMF::Felhőalapú-szolgáltatások

ApelPro — Mon, 14 Sep 2026 07:56:10 GMT

Elgépelés javítása a PHP5 kódpéldában (mamximum -> maximum)

← Régebbi változat		A lap 2026. szeptember 14., 09:56-kori változata
150. sor:		150. sor:
	<?php		<?php
	if (version_compare(phpversion(), '5.6.40', '>')) {		if (version_compare(phpversion(), '5.6.40', '>')) {
	printf("Az általad használt PHP verzió túl magas! Használj ~~mamximum~~ 5-ös verziót!");		printf("Az általad használt PHP verzió túl magas! Használj maximum 5-ös verziót!");
	} else {		} else {
	printf("OK");		printf("OK");

GAMF::Felhőalapú-szolgáltatások::Előadás

ApelPro — Mon, 14 Sep 2026 07:55:48 GMT

Felhőbiztonság fejezet megírása (IAM, hálózati biztonság, titkosítás, monitorozás, DDoS/WAF, tipikus hibák, megfelelőség)

Változtatások megtekintése

EDU::GAMF::Felhőalapú-szolgáltatások::AWS

ApelPro — Mon, 14 Sep 2026 07:48:16 GMT

2024-es Free Tier váltás jelzése; EC2 névmagyarázat javítása; AWSCLI v2 hivatalos telepítés hozzáadva

← Régebbi változat		A lap 2026. szeptember 14., 09:48-kori változata
3. sor:		3. sor:
	[[category:GAMF AWS\|AWS]]		[[category:GAMF AWS\|AWS]]
	== Amazon Web Services regisztráció ==		== Amazon Web Services regisztráció ==
	Az AWS ~~mindenki számára biztosít 1 év ingyenes próbaverziót. Ehhez regisztrálnunk kell a rendszerbe, amihez~~ szükségünk lesz egy email címre, egy telefonszámra a megerősítéshez és egy netes vásárlásra alkalmas bankkártyára. A regisztráció során az AWS 1$~~-ral~~ meg terheli a számlát, de később erre nem tart igény, így a tranzakció lejáratakor jóváíródik a számlán.		Az AWS regisztrációhoz szükségünk lesz egy email címre, egy telefonszámra a megerősítéshez és egy netes vásárlásra alkalmas bankkártyára. A regisztráció során az AWS jellemzően egy jelképes összeggel (kb. 1$ vagy annak megfelelő) meg terheli a számlát a kártya ellenőrzéséhez, de később erre nem tart igény, így a tranzakció lejáratakor jóváíródik a számlán.

			'''Figyelem!''' 2024 közepe óta az AWS megváltoztatta az ingyenes csomag felépítését: az újonnan regisztráló fiókok már '''nem''' a régi, klasszikus "12 hónapig minden Free tier eligible szolgáltatás ingyenes" modellt kapják, hanem egy kredit alapú, rövidebb (jellemzően kb. fél éves) ingyenes időszakot induló jóváírással. A korábban regisztrált fiókok a régi, 12 hónapos feltételeket tarthatják meg. Regisztráció előtt mindenképp nézzük meg az aktuális [https://aws.amazon.com/free/ AWS Free Tier] feltételeit, mert idővel ezek is változhatnak.

	== Ingyenes verzió korlátai ==		== Ingyenes verzió korlátai ==
	Az ingyenes ~~verzióban~~ nem minden érhető el és ami mégis, az sem korlátlan ideig (750 óra EC2 futási idő ~~például~~), amit ha átlépünk, akkor fizetési kötelezettségünk jelentkezik a szolgáltató felé. Igyekezzünk mindent leállítani az órai munka illetve az otthoni gyakorlás után, hogy lehetőleg ne kerüljön pénzbe a féléves munkánk. A hallgatók által elszenvedett károkért sem az iskola sem Én nem tudunk felelősséget vállalni, de azt meg tudjuk ígérni, hogy fizetős szolgáltatást nem használunk és nem is kérünk számon.		Az ingyenes csomagban nem minden érhető el és ami mégis, az sem korlátlan ideig (a klasszikus modellben pl. 750 óra EC2 futási idő havonta, az új kredit alapú modellben pedig a jóváírt összeg elfogyásáig), amit ha átlépünk, akkor fizetési kötelezettségünk jelentkezik a szolgáltató felé. Igyekezzünk mindent leállítani az órai munka illetve az otthoni gyakorlás után, hogy lehetőleg ne kerüljön pénzbe a féléves munkánk. A hallgatók által elszenvedett károkért sem az iskola sem Én nem tudunk felelősséget vállalni, de azt meg tudjuk ígérni, hogy fizetős szolgáltatást nem használunk és nem is kérünk számon.


14. sor:		16. sor:

	=== EC2 szolgáltatásai ===		=== EC2 szolgáltatásai ===
	Az ''EC2'' gyakorlatilag egy VPS-nek feleltethető meg és nem is tévedünk vele hatalmasat. A neve az ''Elastic Cloud ~~Compute~~'' ~~szavak kezdőbetűiből kialakuló~~ ''~~ECC~~''~~-ből fakad,~~ a ''2''-es a végén jelzi, hogy a ''C'' ~~betűből kettő~~ van.		Az ''EC2'' gyakorlatilag egy VPS-nek feleltethető meg és nem is tévedünk vele hatalmasat. A hivatalos neve ''Elastic Compute Cloud'', innen az ''EC2'' rövidítés: a ''2''-es a végén azt jelzi, hogy a névben két ''C'' kezdőbetűs szó van (''Compute'' és ''Cloud'').

	A különbséget a VPS-hez az EC2 ~~futási ideje okozza: bár nem feltétlen~~, ~~de meg van~~ a ~~lehetősége~~, ~~hogy egyik napról a másikra megszűnjön~~ egy EC2 ~~úgy~~, ~~hogy az alkalmazásunk mégis működőképes marad. E tulajdonsága miatt kapta az~~ ''~~Elastic~~'' ~~nevet~~, ~~amit~~ körültekintően kell ~~kezelni~~: semmilyen adatot nem ~~tárolhatunk~~ úgy egy alkalmazáson belül, mint egy VPS esetén: a dinamikus adatok (pl. PHP Session, feltöltött ~~fájok~~) egy EC2 csere esetén elvesznek, így ezeket nem helyben fogjuk tárolni.		A különbséget a VPS-hez elsősorban a rugalmas (''elastic'') skálázhatóság okozza: az EC2 példányokat gyorsan tudjuk indítani, leállítani, típust váltani rajtuk, illetve automatikusan is skálázhatjuk a darabszámukat (lásd később: Auto Scaling Group). Emiatt architekturálisan úgy érdemes tervezni, mintha bármikor cserélődhetne egy adott példány - ez alap (On-Demand) EC2 esetén a gyakorlatban ritkán, hardverhiba vagy saját leállítás esetén fordul csak elő, de a olcsóbb ''Spot'' típusú példányoknál az AWS bármikor, rövid (kb. 2 perces) előzetes figyelmeztetéssel visszavonhatja a gépet. Emiatt körültekintően kell eljárnunk: semmilyen adatot nem érdemes úgy egy alkalmazáson belül tárolni, mint egy VPS esetén: a dinamikus adatok (pl. PHP Session, feltöltött fájlok) egy EC2 csere esetén elvesznek, így ezeket nem helyben fogjuk tárolni.

	Az EC2 szolgáltatásait a keresőmezőbe írt ''„EC2”'' kulcsszóval és az eredményekben megjelenő ''EC2''-re való kattintással érhetjük el.		Az EC2 szolgáltatásait a keresőmezőbe írt ''„EC2”'' kulcsszóval és az eredményekben megjelenő ''EC2''-re való kattintással érhetjük el.
422. sor:		424. sor:

	==== AWSCLI telepítése ====		==== AWSCLI telepítése ====
	~~A program telepítéséhez~~ a következő ~~parancsot kell futtatnunk~~: '''apt install awscli'''.		'''Figyelem!''' Az ''apt install awscli'' a legtöbb Debian/Ubuntu rendszeren a régebbi, 1-es főverziójú AWS CLI-t telepíti a disztribúció saját tárolójából, amit az AWS már csak fenntartási (maintenance) módban frissít. Az AWS hivatalosan a 2-es főverzió telepítését ajánlja, amit a következő paranccsal tehetünk meg:
			<syntaxhighlight lang="bash">
			curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
			unzip awscliv2.zip
			sudo ./aws/install
			</syntaxhighlight>
			Órai/gyakorlási célra az ''apt install awscli'' is elegendő lehet, de érdemes tudni, hogy nem ez a hivatalosan ajánlott telepítési mód.
	==== Access Key management ====		==== Access Key management ====
	Az ''awscli'' hozzáférési kulcsokon keresztül kap jogosultságot a szolgáltatások adataihoz, így használata előtt készítenünk kell egy újat. Ez a nevünkre kattintva (jobb felül), majd a ''Security credentials'' menüpontot kiválasztva tehetjük meg, az ''Access keys'' szekcióban. Nyissuk ezt le és kattintsunk a ''Create New Access Key'' gombra.<br>		Az ''awscli'' hozzáférési kulcsokon keresztül kap jogosultságot a szolgáltatások adataihoz, így használata előtt készítenünk kell egy újat. Ez a nevünkre kattintva (jobb felül), majd a ''Security credentials'' menüpontot kiválasztva tehetjük meg, az ''Access keys'' szekcióban. Nyissuk ezt le és kattintsunk a ''Create New Access Key'' gombra.<br>

EDU::GAMF::Felhőalapú-szolgáltatások::Docker

ApelPro — Mon, 14 Sep 2026 07:46:50 GMT

Hibás apt install docker.io docker parancs javítva; hibás CMD ["-D FOREGROUND"] példa magyarázó figyelmeztetéssel kiegészítve; 777-es jogosultság megjegyzéssel; apró elgépelések

← Régebbi változat		A lap 2026. szeptember 14., 09:46-kori változata
44. sor:		44. sor:

	'''Nem csak az üzemeltetést könnyíti meg vagy javítja a rendelkezésreállást, hanem a fejlesztési időn is javít'''.		'''Nem csak az üzemeltetést könnyíti meg vagy javítja a rendelkezésreállást, hanem a fejlesztési időn is javít'''.
	Természetesen ne gondoljunk olyanokra, hogy a programot helyettünk lefejleszti egy konténer, de azzal nagyon sokat nyerünk, hogy ha egy konténerben lefejlesztünk valamit és működik, akkor a konténert egy másik gépre másolva is működni fog, függetlenül attól, hogy esetleg platformot váltottunk (~~windwos~~->linux vagy fordítva), hogy verziót váltottunk vagy hogy milyen csomagok érhetők el a cél szerveren. Ezek a kérdések sok esetben plusz fejlesztési időt jelentenek, hogy valamelyest dinamikus legyen.		Természetesen ne gondoljunk olyanokra, hogy a programot helyettünk lefejleszti egy konténer, de azzal nagyon sokat nyerünk, hogy ha egy konténerben lefejlesztünk valamit és működik, akkor a konténert egy másik gépre másolva is működni fog, függetlenül attól, hogy esetleg platformot váltottunk (windows->linux vagy fordítva), hogy verziót váltottunk vagy hogy milyen csomagok érhetők el a cél szerveren. Ezek a kérdések sok esetben plusz fejlesztési időt jelentenek, hogy valamelyest dinamikus legyen.

	''Sandboxing'' megoldások körében is előkerül a docker. Ez azt jelenti, hogy egy alkalmazást először egy konténerben próbálnak ki és ha úgy gondolják, akkor telepítik az éles rendszerbe is. Ha úgy alakul, hogy nincs rá szükség, akkor a konténerrel együtt elveszik minden módosítás is, tehát a tárhely 100%-ban visszanyerhető. Legyünk azért ezzel is óvatosak, egy virtuális gép alkalmazás tesztelésre sokkal jobb lehetőséget biztosít, sokkal mélyebben szétválik a két rendszer egymástól. Docker esetében például egy kernel sebezhetőséggel konténeren belülről is vissza lehet élni és ne feledkezzünk meg a ''docker daemon'' hibáiról sem.		''Sandboxing'' megoldások körében is előkerül a docker. Ez azt jelenti, hogy egy alkalmazást először egy konténerben próbálnak ki és ha úgy gondolják, akkor telepítik az éles rendszerbe is. Ha úgy alakul, hogy nincs rá szükség, akkor a konténerrel együtt elveszik minden módosítás is, tehát a tárhely 100%-ban visszanyerhető. Legyünk azért ezzel is óvatosak, egy virtuális gép alkalmazás tesztelésre sokkal jobb lehetőséget biztosít, sokkal mélyebben szétválik a két rendszer egymástól. Docker esetében például egy kernel sebezhetőséggel konténeren belülről is vissza lehet élni és ne feledkezzünk meg a ''docker daemon'' hibáiról sem.
52. sor:		52. sor:

	A docker.com-ra a regisztráció ingyenes, egy privát projektet hozhatunk létre és bármennyit publikusan. Ez magában foglalja a veszélyt is: bárki feltölthet például egy webszervert, amelyben kiskapuk vannak stb.		A docker.com-ra a regisztráció ingyenes, egy privát projektet hozhatunk létre és bármennyit publikusan. Ez magában foglalja a veszélyt is: bárki feltölthet például egy webszervert, amelyben kiskapuk vannak stb.
	'''~~Minidg~~ ügyeljünk rá, hogy megbízható helyről származzon, amit letöltünk!'''		'''Mindig ügyeljünk rá, hogy megbízható helyről származzon, amit letöltünk!'''

	== Docker Telepítése ==		== Docker Telepítése ==
	A futáshoz telepítenünk kell a ''docker daemon''-t, amit a következő paranccsal tehetünk meg:<br>		A futáshoz telepítenünk kell a ''docker daemon''-t, amit a következő paranccsal tehetünk meg:<br>
	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	apt update && apt install docker.io ~~docker~~		apt update && apt install docker.io -y
	</syntaxhighlight>		</syntaxhighlight>

	== Docker ~~conatainerek~~ indítása ==		'''Figyelem!''' Ne próbáljunk meg egy önálló ''docker'' csomagot is telepíteni a ''docker.io'' mellé - Debian/Ubuntu alatt nem ez a konténerizációs Dockert jelenti (a névütközés miatt kapta annak idején a csomag a ''docker.io'' nevet), hanem egy azzal semmilyen kapcsolatban nem álló, régi segédprogramot, így egy ''apt install docker.io docker'' parancs hibára fut vagy felesleges csomagot telepít.

			''Éles / production környezetben érdemes lehet a Docker hivatalos apt tárolóját használni ''docker.io'' helyett, mert abban naprakészebb (Docker CE) verzió érhető el: lásd a [https://docs.docker.com/engine/install/ubuntu/ hivatalos telepítési útmutatót].''

			== Docker konténerek indítása ==
	Az elérhető konténerek között kereshetünk az ''ubuntu'' karakterláncra a következő paranccsal:		Az elérhető konténerek között kereshetünk az ''ubuntu'' karakterláncra a következő paranccsal:
	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
249. sor:		253. sor:
	</syntaxhighlight>		</syntaxhighlight>
	'''Csak ebben a megadási módban működik, „[” „]” párok nélkül nem cserélődik le a ''CMD'' tartalma!'''		'''Csak ebben a megadási módban működik, „[” „]” párok nélkül nem cserélődik le a ''CMD'' tartalma!'''

			'''Figyelem, ez a konkrét példa hibás lesz futtatáskor!''' Exec formában (szögletes zárójelekkel) a ''CMD'' tömb minden eleme '''külön''', önálló argumentumként adódik át a programnak. A fenti ''CMD ["-D FOREGROUND"]'' emiatt egyetlen, szóközt is tartalmazó argumentumként (''"-D FOREGROUND"'') adja át az értéket az ''apache2ctl''-nek két külön kapcsoló (''-D'' és ''FOREGROUND'') helyett, amit a program nem fog tudni értelmezni, és a konténer el fog állni. A helyes megoldáshoz minden argumentumot külön tömbelemként kell felsorolni - lásd az alábbi példát.

	Lehetséges konfiguráció lehet jelen esetben a következő is:		Lehetséges konfiguráció lehet jelen esetben a következő is:
307. sor:		313. sor:

	== Apache2 ubuntu - biztonságos ==		== Apache2 ubuntu - biztonságos ==
			'''Megjegyzés:''' az alábbi példa a ''root'' nélküli futtatást (USER app) mutatja be, ami valóban jó gyakorlat, de a ''mkdir /environment -m 777'' sor világolvasható-írható (777) jogosultságot ad a mappának, ami önmagában nem tekinthető szigorúan biztonságosnak. Éles környezetben inkább a fentebb bemutatott, csoport alapú, szűkebb jogosultságú megoldást (''chgrp''+''chmod 2774/2775'') érdemes követni, a 777 helyett.
	<syntaxhighlight lang="dockerfile">		<syntaxhighlight lang="dockerfile">
	FROM ubuntu		FROM ubuntu

EDU::GAMF::Felhőalapú-szolgáltatások::Rövidítések

ApelPro — Mon, 14 Sep 2026 07:45:22 GMT

Rövidítések javítása: EC2, ECS, S3, TCP, HTML, RFC, GIMP hibás kifejtések javítva; elgépelések és a COMA/CORBA egybefolyt sor javítva

Változtatások megtekintése

EDU::GAMF::Felhőalapú-szolgáltatások

ApelPro — Mon, 14 Sep 2026 06:55:10 GMT

A tárgy teljesítéséhez szükséges idő

← Régebbi változat		A lap 2026. szeptember 14., 08:55-kori változata
(3 közbenső módosítás ugyanattól a szerkesztőtől nincs mutatva)
44. sor:		44. sor:
	A projektfeladatra járó pont: '''70p'''		A projektfeladatra járó pont: '''70p'''

	'''A kiselőadásból és a ~~ZH-ból~~ 50-50% el kell érni a félév sikeres teljesítéséhez.'''		'''A kiselőadásból és a projektfeladatból 50-50% el kell érni a félév sikeres teljesítéséhez.'''

	~~== A tárgy teljesítéséhez szükséges idő ==~~
	Az állami elvárás szerint minden kredit megszerzése egy átlagos hallgató számára 30 óra ráfordítást vesz igénybe - beleértve a tanórákat, ZH és vizsgaalkalmakat, valamint az otthoni önálló tanulást is. Ez a tárgy 5 kreditet ér, tehát a félév során összesen 150 órát kell a hallgatóknak ezzel foglalkozniuk, ami sokszor a pótZH-ban (és manapság a pót-pót ZH-ban) csapódik le.
	Mivel a félév során 13 hét áll rendelkezésünkre és mind az előadás, mind a gyakorlat 1,5 óra időtartamú, így összesen 39 órát ölel fel a tanórai képzés (ZH-val együtt). Rossz hír, hogy ez esetben egy gyakorlati jegyes tárgyról van szó, így a maradék időt legkésőbb a 13. hét végéig kell eltölteni otthoni tanulással, nem lehet a vizsgaidőszakra csúsztatni azt. Ez alapján heti 8.5, azaz valamivel több, mint napi 1,5 órát (heti 5 nappal számolva) a tárggyal kapcsolatos ismeretanyagok gyűjtésével és megértésével kellene a hallgatónak foglalkoznia. Mivel ezen számítás alapján a hallgatóknak napi 13,5 órát kellene 30 kredit felvétele esetén tanulással tölteni, így természetesen ez egy irreális elvárásnak bizonyul. Azonban kreditarányosan számolva, ezen tárgy esetében '''heti 2 óra''' ráfordítással éri el a hallgató a napi 8 órás munkaidőt (tanórák közötti szüneteket pihenőidőként kezelve) 30 kredit esetén, ami a normális szint. Ez tehát '''elvárhatónak és számon kérhetőnek bizonyul''' nappali tagozaton annak érdekében, hogy a hallgatók a lehető legnagyobb felkészültségben üljenek az órákon.

	== A tárgy során használt dokumentumok ==		== A tárgy során használt dokumentumok ==
113. sor:		109. sor:

	== A gyakorlat menete ==		== A gyakorlat menete ==
	# Regisztráció az AWS rendszerében [https://portal.aws.amazon.com/billing/signup#/start/email]		# Regisztráció az AWS rendszerében [https://portal.aws.amazon.com/billing/signup#/start/email] és alap szolgáltatások átbeszélése
	# EC2 ~~létrehozása~~, ~~szolgáltatások áttekintése~~, ~~Linux alapismeretek~~ ismétlése		# EC2 telepítés, nginx + apache2 bevezetés, alap parancsok ismétlése (ls, nano, mcedit stb.)
	~~# EC2 létrehozása, alkalmazások telepítése és konfigurálása~~, ~~apache2 kiszolgáló~~, ~~PHP környezet~~		# Alkalmazás telepítése előre elkészített script segítségével + AMI, ASG, LB
	# ~~UI felület élesztése:~~ AMI ~~létrehozás~~, ~~Auto Scaling Group~~, ~~Load Balancer~~		# RDS telepítés és alkalmazás integráció ellenőrzése
	# ~~Teljes alkalmazás élesztése: MySQL adatbázis (~~RDS~~), Python környezet~~ telepítés		# Docker alapok
	# ~~Teljes alkalmazás élesztése: VPC-be szervezés, eszközök kommunikációjának szabályozása~~		# Docker compose alapok
	# Docker ~~telepítés, első konténerek elindítása, Dockerfile felépítése, docker.io regisztráció, image feltöltés~~		# Alkalmazás indítása Docker környezetben
	# ~~Dockerfile felépítése, alkalmazások létrehozása,~~ indítása		# IaC eszközök áttekintése
	# ~~Docker Compose felépítés, networking, debuggolás~~		# IaC eszközök áttekintése
	# ~~Teljes alkalmazás élesztése Docker Compose segítségével~~		# MessageQueue eszközök használata
	# ~~Készülés ZH-ra, kérdések megbeszélése~~		# Projekt bemutató (6db)
	# ~~'''~~Projekt bemutató~~'''~~		# Projekt bemutató (6db)
			# Projekt bemutató (6db)

	== Docker beadandó leírása ==		== Docker beadandó leírása ==

← Régebbi változat		A lap 2026. szeptember 14., 10:35-kori változata
(Egy közbenső módosítás ugyanattól a szerkesztőtől nincs mutatva)
174. sor:		174. sor:
	** [[EDU::GAMF::Felhőalapú-szolgáltatások::AWS\|AWS]]		** [[EDU::GAMF::Felhőalapú-szolgáltatások::AWS\|AWS]]
	** [[EDU::GAMF::Felhőalapú-szolgáltatások::Docker\|Docker]]		** [[EDU::GAMF::Felhőalapú-szolgáltatások::Docker\|Docker]]
			** [[EDU::GAMF::Felhőalapú-szolgáltatások::IaC\|IaC]]
	* [[EDU::GAMF::Felhőalapú-szolgáltatások::Rövidítések\|Rövidítések]]		* [[EDU::GAMF::Felhőalapú-szolgáltatások::Rövidítések\|Rövidítések]]