„HAKAP vizsga felkészítő kikérdező” változatai közötti eltérés
a Új kérdések hozzáadása. |
Új kérdések hozzáadása. |
||
| (Egy közbenső módosítás ugyanattól a felhasználótól nincs mutatva) | |||
| 176. sor: | 176. sor: | ||
# Konténter (container): Egy Docker image futtatott példánya. | # Konténter (container): Egy Docker image futtatott példánya. | ||
# CLI: A Docker REST API-t használja a Docker deamon vezérléséhez vagy interakciójához szkriptekkel vagy parancsokkal. | # CLI: A Docker REST API-t használja a Docker deamon vezérléséhez vagy interakciójához szkriptekkel vagy parancsokkal. | ||
== Milyen feladatokat hajt végre a hoston a Docker deamon? == | |||
{{kvízkérdés|típus=több|válasz=1,2,4|pontozás=-}} | |||
# Run: Letölt MINDENT és futtatja a konténerüket. | |||
# Build: Saját image létrehozása. | |||
# Mount: Image felcsatolása. | |||
# Pull: Lehúzza az image-t a docker registry-ből, és menti a saját rendszerünkbe. | |||
== A Docker Engine olyan eszköz, amely lehetővé teszi a Docker Engine telepítését virtuális gépeken, és menedzselését a hostoknak. Távoli állomásokon konténer kezelés. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Mely állítás(ok) igaz(ak) az image-re? == | |||
{{kvízkérdés|típus=több|válasz=2,3,4|pontozás=-}} | |||
# Olvasható és írható template-ek is vannak benne. | |||
# Rétegekből áll (kernel-bootfs, Base Image, Images..., Container -> image), ezek tömörítve tárolva. | |||
# Gyakran egy image egy másik image-en alapszik, csak további testreszabásokkal. | |||
# Dockerfile-ban van definiálva a létrehozási lépések (recept). Instrukciók új rétegekben. | |||
== A Docker compose egy olyan tool, amivel egy több konténert tartalmazó Docker alkalmazást hozhatunk létre vagy futtathatunk. A YAML fájllal konfigutálhatjuk az alkalmazás szolgáltatásait, majd egyetlen paranccsal létrehozni, illetve futtatni az összes szolgáltatást a konfigurációnkból. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A Docker compose működése, mely három fő lépésből áll? == | |||
{{kvízkérdés|típus=több|válasz=1,4|pontozás=-}} | |||
# A docker-compose.yml fájl létrehozása, szolgáltatás definiálása, így tud több izolált környezettel is együtt futni. | |||
# Applikáció környezetét Docker deamonban definiálja. | |||
# Parancs futtatása: docker-compose run. | |||
# Parancs futtatása: docker-compose. | |||
== Mely állítások tartozhatnak a orkesztráció (Docker Swarm, Kubernetes) feladatai közé? == | |||
{{kvízkérdés|típus=több|válasz=1,2,3,4|pontozás=-}} | |||
# Konténerek biztosítása és telepítése. | |||
# A konténerek közötti szolgáltatások felfedezése. | |||
# Erőforrások elosztása a konténerek között. | |||
# Konténerek mozgatása, méret növelés, eltávolítás. | |||
== A Docker Workflow egyszerű átjárást biztosít a dev és production környezet közöt. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Melyek Dockerfile parancsok ezek közül? == | |||
{{kvízkérdés|típus=több|válasz=2,3,4,6,7|pontozás=-}} | |||
# TO: Egy már létező képfájlból csomagolja bele a fájlt; ez lesz majd az alap réteg (lecsupaszított Linux képfájl: Alpine, busybox). | |||
# FROM: Egy már létező képfájlból indul ki az új képfájl; ez lesz az alap réteg (lecsupaszított Linux képfájl: Alpine, busybox). | |||
# COPY: Fájlokat másol át a host adott könyvtárából (directory) a képfájlba (pl. konfig, forráskód, szkript). | |||
# EXPOSE: Portot nyit a konténer számára. | |||
# BUILD: Telepítendő feladatok megfelelő sorrendben indítása. | |||
# RUN: A képfájlba telepítendő, előkészítendő feladatok futtatása. | |||
# CMD: Konténer indításakor futtatott parancs. | |||
== Mi a Dockerfile előnyei? == | |||
{{kvízkérdés|típus=több|válasz=2,4|pontozás=-}} | |||
# Kódok sorrendje nem számít bele a futásba. | |||
# Egy fájlban meghatározható a build folyamat. | |||
# Könnyen átírható futás közben is. | |||
# Könnyen újra-fordítható (Caching rendszer). | |||
== A Kubernetes (orkesztráció típus) automatizált konténer telepítést és menedzsmentet biztos akár multi-host környezetben is + skálázódás vezérléssel. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Milyen lehetőségek vannak, ha több konténert szeretnénk menedzselni? == | |||
{{kvízkérdés|típus=több|válasz=1,3,4|pontozás=-}} | |||
# Nyilvános felhőkben Docker (AWS, Google Cloud) | |||
# Dockerek összekötése hálózaton belül | |||
# Docker + OpenStack (OpenStack Magnum) | |||
# Docker orkesztráció (Apache Mesos, Kubernetes, Docker Swarm Mode) | |||
== A Swarm gépek összessége, amik Dockert futtatnak, és egy cluster-be kapcsolódnak. Ezután ugyanúgy futtatjuk a Dockert, csak a parancsok a swarm manager által lesznek elvégezve ezen a clusteren. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Legalább kettő master és egy worker node van Kubernetesnél meg Swarmnál is. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A master node egyúttal lehet worker node is. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A swarm mode, amikor... == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# létrehozunk egy service-t, megadjuk annak optimális állapotát. Ha egy node elérhetetlenné válik, akkor a Docker átszervezi a taskot (futó konténer) egy másik node-ra. | |||
# létrehozunk egy service-t, megadjuk annak optimális állapotát. Ha egy node elérhetetlenné válik, akkor a Docker törli azt. | |||
# létrehozunk egy service-t, megadjuk annak optimális állapotát. Ha egy node elérhetetlenné válik, akkor a Docker csak a futó feladatok szervezi át másik node-ra. | |||
# létrehozunk egy service-t, megadjuk annak optimális állapotát. Ha egy node elérhetetlenné válik, akkor a Docker lemásolja azt, majd megpróbálja újraindítani. Amennyiben ez se sikerül, megsemmisíti azt. | |||
== Melyik fogalom definíciója ez? Minden node fogadhat kapcsolatot a hirdetett porton, a swarm load balancer egy aktív konténerhez routol-ja a kérést még ha az más hoston is van, és a a kérést először fogadó host-on nem is fut olyan task. == | |||
{{kvízkérdés|típus=egy|válasz=3|pontozás=-}} | |||
# Swarm load balancer | |||
# Cluster | |||
# Routing mesh | |||
# Swarm mode | |||
== Melyik fogalom definíciója ez? Node-ok összessége, ahol legalább egy master node és több worker node van, amik lehetnek fizikaiak vagy virtuálisak is. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Swarm load balancer | |||
# Cluster | |||
# Routing mesh | |||
# Swarm mode | |||
== Melyik fogalom definíciója ez? Ő kezeli az applikációk ütemezésést és deployementjét a node-ok között. A node-okkal az API serveren kereszetül kommunikál. == | |||
{{kvízkérdés|típus=egy|válasz=4|pontozás=-}} | |||
# Node | |||
# Kubelet | |||
# Pods | |||
# Kubernetes master | |||
== Melyik fogalom definíciója ez? Egy vagy több konténer, amely egyetlen node-ra van elhelyezve Osztozkodnak IP címen, host neven. Az absztrakt hálózat és a tároló elkülönül az alatta található konténerektől. Ezáltal könnyebben mozgatható a konténer a cluster körül.== | |||
{{kvízkérdés|típus=egy|válasz=3|pontozás=-}} | |||
# Node | |||
# Kubelet | |||
# Pods | |||
# Kubernetes master | |||
== Melyik fogalom definíciója ez? A kért, hozzájuk rendelt feladatokat végzik el. A Kubernetes master vezérli őket. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Node | |||
# Kubelet | |||
# Pods | |||
# Kubernetes master | |||
== Melyik fogalom definíciója ez? Minden node futtat egy agent folyamatot, ami a node állapotának menedzselésért felelős (start, stop...) Minden információját a Kubernetes API serverről kapja. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Node | |||
# Kubelet | |||
# Pods | |||
# Kubernetes master | |||
== Melyik fogalom látja el ezt a feladatot: load balancerezés a podoknak. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Lables | |||
# Proxy | |||
# Etcd | |||
# cAdvisor | |||
# Scheduler | |||
== Melyik fogalom látja el ezt a feladatot: metadata sevice. == | |||
{{kvízkérdés|típus=egy|válasz=3|pontozás=-}} | |||
# Lables | |||
# Proxy | |||
# Etcd | |||
# cAdvisor | |||
# Scheduler | |||
== Melyik fogalom látja el ezt a feladatot: podokat azonosítja. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Lables | |||
# Proxy | |||
# Etcd | |||
# cAdvisor | |||
# Scheduler | |||
== Melyik fogalom látja el ezt a feladatot: konténer felügyelő, ami erőforrás használatot és teljesítmény statisztikákat szolgál. == | |||
{{kvízkérdés|típus=egy|válasz=4|pontozás=-}} | |||
# Lables | |||
# Proxy | |||
# Etcd | |||
# cAdvisor | |||
# Scheduler | |||
== Melyik fogalom látja el ezt a feladatot: node-okat rendel a podokhoz, a megadott erőforrás-és policy korlátozásoktól függően. == | |||
{{kvízkérdés|típus=egy|válasz=5|pontozás=-}} | |||
# Lables | |||
# Proxy | |||
# Etcd | |||
# cAdvisor | |||
# Scheduler | |||
== Podok előnyei, hogy tudnák kommunikálni egymással localhoston, de figyelni kell emiatt, hogy két konténer nem használhatja ugyanazt a portot, és NAT-tal kell kommunikálnuk. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Melyik fogalom definíciója? Egy alkalmazást külön processzben futó, egymással valamilyen, viszonylag egyszerű mechanizmussal kommunikáló (ez legtöbbször egy HTTP API) kisebb szolgáltatások összességéből építünk fel. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Konténer | |||
# Mikroszervíz | |||
== Melyik fogalom definíciója? Horizontálisan vannak elosztva a Prem/Cloud/Hybrid-eken. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Monolitikus | |||
# Mikroszervíz | |||
== Melyik fogalom definíciója? Vertikálisan és horizontálisan is el vannak osztva. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Monolitikus | |||
# Mikroszervíz | |||
== A serverless egy felhőalapú számítási execution modell, ahol a felhő szolgáltató dinamikusan kezeli a kiszolgálók elosztását és ellátását. A serverless alkalmazás eseménynélküli, számtalan konténerben fut, amelyek esemény-kiváltottak, rövid életűek és amelyeket a felhő szolgáltató teljes mértékben kezel. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Function as a Service (FaaS): Egyből futtatható kód, infrastruktúra nélkül, tehát felhőben egyből futtatható. Ahelyett hogy skálázni kellene a monolitikus modellben, most csak felosztjuk a szervert több function-re, amik azonnal és automatikusan skálázhatóak. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Mik a FaaS előnyei? == | |||
{{kvízkérdés|típus=több|válasz=2,3,5|pontozás=-}} | |||
# Sok, szeparált részt. | |||
# Soha nem kell idle erőforrásokért fizeti. | |||
# Vele járó a skálázhatóság. | |||
# Auto-scaling gyakran költség skálázást is jelent. | |||
# Beépíthető és hibatűrő. | |||
== Mik a FaaS hátrányai? == | |||
{{kvízkérdés|típus=több|válasz=1,3,5|pontozás=-}} | |||
# Csökkenti az átláthatóságot. | |||
# Kevesebb fejlesztői ligisztika – szerver infrastruktúra menedzselése valaki más feladata. | |||
# Auto-scaling gyakran költség skálázást is jelent. | |||
# Kis, kezelhető egységek. | |||
# Nehéz debuggolni. | |||
== Melyek ezek közül a virtuális kapcsoló implementációi? == | |||
{{kvízkérdés|típus=több|válasz=1,2|pontozás=-}} | |||
# Linux bridge | |||
# OVS - Open Virtual Switch | |||
# Linux routing | |||
# Switch | |||
== A virtuális kapcsolónál a lokális kommunikáció sebessége a hálózat sebességétől függ. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Melyek ezek közül NIC (Network Interface Card) virtualizációja? == | |||
{{kvízkérdés|típus=több|válasz=1,3,4,6,7|pontozás=-}} | |||
# virtIO: Fő platform az IO virtualizálásának a KVM-ben, közös framework legyen a hypervisior-nak és a virtualizált IO-nak is. | |||
# CH (Channel): TCP szintű (L4) virtuális hálózati meghajtó. | |||
# QEMU (Quick Emulator): Szoftveres platform emulátor, szoftveres NIC emuláció. | |||
# TUN (Tunnel): IP szintű (L3) virtuális hálózati meghajtó. | |||
# PIN (Private Interface Network): Privát IP címes hálózati elemek kezelése. | |||
# KVM (Kernel-based VM): Hardveres gyorsítás | |||
# TAP (Test Access Point): Ethernet szintű (L2) virtuális hálózati meghajtó. | |||
== Melyik libvirt hálózati módra igaz a következő állítás? VM-ek egymással és a hoszttal kommunikálhatnak, de a külvilággal nem. == | |||
{{kvízkérdés|típus=több|válasz=4|pontozás=-}} | |||
# NAT | |||
# Bridge | |||
# Routed | |||
# Isolated | |||
== Melyik libvirt hálózati módra igaz a következő állítás? A vendég rdsz. közvetlenül a LAN-hoz kapcsolódik. == | |||
{{kvízkérdés|típus=több|válasz=2|pontozás=-}} | |||
# NAT | |||
# Bridge | |||
# Routed | |||
# Isolated | |||
== Melyik libvirt hálózati módra igaz a következő állítás? Statikus útvonalbeállítás, nincs NAT. == | |||
{{kvízkérdés|típus=több|válasz=3|pontozás=-}} | |||
# NAT | |||
# Bridge | |||
# Routed | |||
# Isolatedv | |||
== Melyik libvirt hálózati módra igaz a következő állítás? a virtuális környezetek néha a külső hálózathoz való csatlakozáshoz használják. Nincs hozzá csatolva fizikai interfés. == | |||
{{kvízkérdés|típus=több|válasz=1|pontozás=-}} | |||
# NAT | |||
# Bridge | |||
# Routed | |||
# Isolated | |||
==A MapReduce egy programozási modell nagy adathalmazok feldolgozására párhuzamosan és egy klaszteren elosztottan. Map: szűrés és rendezés, reduce: eredmény összegzés. Elosztja a feladatokat a szervereken párhuzamosan futtatva. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Mi(ket) biztosít számunkra a MapReduce? == | |||
{{kvízkérdés|típus=több|válasz=1,2,4,5,6|pontozás=-}} | |||
# Automatikus parallelizációt, elosztás. | |||
# I/O ütemezés: Terheléselosztás, hálózat és adat szállítási optimalizálás. | |||
# Boosting: Hálózati és adatszállítási sebesség gyorsítása. | |||
# Hibatűrés: gép hibák kezelése. | |||
# Több erő: KIskálázás, nem FELskálázás. | |||
# Apache Hadoop: MapReduce nyílt forráskódú megvalósítása. | |||
== MapReduce-nál maximum egy map és reduce lehet. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== MapReduce-nál fontos, hogy a kód multithread vagy sem. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== MapReduce-nál a determinisztikusság lehetővé teszi, hogy újra indítsunk egy hibás munkát. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Jelölje be az igaz állítás(oka)t MapReduce-ra! == | |||
{{kvízkérdés|típus=több|válasz=4|pontozás=-}} | |||
# Nem robosztus. | |||
# Ha kész egy task, azt a worker is véglegesítheti. | |||
# Egyetlen meghibásodás: Feladat lezárása. (Execution) | |||
# Tisztítás: Ha egy recordban az egyik worker 2 hibát is talál, szól a következő workernek, hogy ugorja át azt a rekordot. | |||
== Google File System (GFS), Google által kifejlesztett szabadalmaztatott fájlrendszer, amely hatékony és megbízható hozzáférést biztosít az adatokhoz nagy commodity hardwer clusterek használatával. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
------------------------------------ | |||
== == | == == | ||
| 184. sor: | 499. sor: | ||
== == | == == | ||
{{kvízkérdés|típus=egy|válasz=|pontozás=-}} | {{kvízkérdés|típus=egy|válasz=|pontozás=-}} | ||
# | |||
# | |||
# | |||
# | |||
== == | |||
{{kvízkérdés|típus=több|válasz=|pontozás=-}} | |||
# | # | ||
# | # | ||
# | # | ||
# | # | ||