Hirdetés

  2. Fórumok
  3. LOGOUT reakciók
  4. shadowkidhu: SFF Itthoni labor
Keresés

Új hozzászólás Aktív témák

  • #91 R0GERIUS tag bambano #88
    Új Válasz #91
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    R0GERIUS

    tag

    válasz bambano #88 üzenetére

    "Mi a docker hátrányai? Hogy van. Oké, ezt nem tudom elmagyarázni annak, aki szerint a KISS az hátrány, de ettől még igaz marad. Minden sor kód, minden szoftverréteg csökkenti a rendszer megbízhatóságát és kockáztatja, hogy hibák kerülnek a rendszerbe. Ha egy réteg felesleges, ki kell hagyni."

    Két esetet is tudok nyújtani, amikor ez nagyon nem igaz.
    Egyik: ha a hardver változik vagy változhat, ugyanakkor garantálnod kell, hogy a szoftver megbízhatóan és eddigiektől nem eltérően működik, vagy sokféle hardverre garantálnod kell az azonos működést. A mai telekommunikációs hálózatok nagyon nagy hányada ilyen, nagyon sok helyről szerzett hardver, egységes szoftver (egy bizonyos rétegen túl).
    Másik: amikor a futtatott szoftver és nem az OS a megbízhatatlanság oka. Olyan szoftver amit nem lehet helyettesíteni, ugyanakkor nagyon gyorsan újra kell tudnod húzni és a kiesés csökkentése egy nagyon fontos érv. Sajnos a Jenkins egy jó példa, főleg a plugin-ok miatt.

    Az a hibás feltételezés a Docker szükségtelenségében, hogy az a szoftver, amit futtatni készülök az hibátlan, így a komplexitás szüli a hibákat, de ez közel sem minden esetben van így, főleg manapság.

    Ez a másik ok, amiért a KISS ugyan egy jó elv és jómagam is követem ahol lehet, nem minden körülmények között ideális vagy helyes megközelítés, a körülmények és célok nagyon sokat számítanak.
    A Jenkins-es példa pedig mutatja, hogy találkozhatsz vele kis méretben is (ugyanis az eredeti poszt szerzőjének céljai közt volt a futtatása).

  • #90 R0GERIUS tag bambano #88
    Új Válasz #90
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    R0GERIUS

    tag

    válasz bambano #88 üzenetére

    "aki szerint a KISS az hátrány"

    Közel sem az, de nem minden esetben a legjobb megközelítés. Azt nem szeretem, amikor érvként valaki arra használja, hogy "KISS, tehát ideális megoldás".
    Ezért fogalmaztam így, hogy "utálom, amikor valaki KISS-szel takarózik" és amögé bújva élből elvet megoldásokat.

    "a cikk háztáji lab-ról szólt"

    Pontosan, és pont emiatt lett említve.
    Az általad KISS-nek jelölt megoldás tudatos tervezést igényel (vagy ha nem is igényel, akkor nagyon jól jön), kísérletezés esetén könnyebb valamit tönkretenni benne és kell tapasztalat arra nézve, hogy amennyiben elrontasz valamit, akkor hogyan állj helyre belőle. Ezt a Docker kis tanulás árán megspórolja neked, szabadon kísérletezhetsz, futtathatsz bármit, eltávolíthatsz bármit és nem fog semmit se tönkretenni.
    Pont otthoni kis környezetekben ez a fajta tudatosság és Linux ismeret, ami nem feltétlen jellemző.

    A másik jellemző felhasználása a háztáji laboknak a kísérletezés, és az konténerekkel/VM-ekkel a legkönnyebb, főleg kezdőként.

    Szakértőként könnyen választható a teljesítmény és felépítési egyszerűség szempontjából optimális megoldás, de nem mindenkinek ugyanaz az "egyszerű" fogalma, és véleményem szerint a KISS ebben az esetben nagyon nézőpont kérdése, emiatt sem szeretem érvként használni.

    Úgy vélem, hogy pont az ilyen projekteknél a leghasznosabb bedobni az ötleteket pro és kontra, hogy az olvasó eldönthesse saját belátása szerint mi az, ami számára értékes szempont és mi az ami nem.

  • #83 R0GERIUS tag bambano #79
    Új Válasz #83
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    R0GERIUS

    tag

    válasz bambano #79 üzenetére

    Ha verziókezelésre van igényem (egyébként minek lenne?), akkor azt lehet alap oprendszeren is.

    Mert a szoftver:
    a) szar és nem jó ha behúzza belőle a legújabbat (pl TeamSpeak nagyon sokszor)
    b) nem kell a legújabb, hanem egy jól bevált verziót akarsz futtatni nem biztonságkritikus környezetben
    c) nagy váltást nem akarsz azonnal lekövetni, mert vannak benne "breaking change"-k (pl. arr stack V3->V4)

    És alap oprendszerben törhetnek a függőségek, főleg ha több szoftver van, valamint nem biztos, hogy az adott OS-re elérhető egy régebbi verzió, valamint egyáltalán nem biztos, hogy van belőle csomag és nem csak Docker image manapság.

    Flexibilitás: oké, dockerben könnyen megírom a virtualizált hálózatot. Alap oprendszeren meg nem kell virtualizált hálózat. De ha akarom, csinálhatok.

    Igen, de nem kell manuálisan és nem kell működő DHCP szerver, így hordozható a konfig anélkül, hogy adaptálni kellene bármihez is.
    És nem kell érteni a hálózati réteghez.

    Visszaállítás: ha megvannak a konfigok és az app data, akkor pontosan ugyanannyi visszaállítani az alap oprendszert, mint egy dockert. Ja nem, mert ha docker van, akkor először a dockert kell visszaállítani.

    Ez így van, de ahelyett, hogy potenciálisan kézzel, vagy jobb esetben különböző app repo-król kellene az összes szoftvert összevadászni megfelelő verziókkal, a Dockernél ez egy parancs a Docker Engine telepítése után.
    Valóban nem feltétlen takarít meg időt, de nem fogsz egy bonyolultabb felépítés mellett sem mást csinálni, így megtakaríthat időt a használt szoftverek függvényében.

  • #13 R0GERIUS tag
    Új Válasz #13
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    R0GERIUS

    tag

    Ami a hardvert illeti:
    Ha elmész a konténerizáció irányába inkább kevés VM-el, még kevesebb GUI-val, ami nem webes, akkor a fentinek elégnek kell lennie elég sok szolgáltatáshoz és szoftverhez. 1-1 konténer nagyon keveset igényel.
    Ha az eredeti tervet tartod, akkor könnyen lehet kevés, GUI-s Linux-ok alapból 2-4 GB-ot megesznek csak a sima funkcionalitás biztosításához, valamint attól függően milyen fájlrendszert használsz kellhet RAM ahhoz is (asszem pl a ZFS ilyen), így ott már nem lesz elég. Az eredeti terv esetén lejjebb kell adnod a VM-ek számából (vagy legalábbis nem futatni ennyit egyszerre) és amit tudsz elvinni konténerbe, amennyire hamar tudod a kísérletezés után.

    A proci elég erős, de ha fogni akarsz a költségeken, akkor érdemes megnézni az Intel vonalat és kispórolni a videokártyát. Intel 7. gentől már tudja transcode-olni a legtöbb modern formátumot, ha jól emlékszem, és akkor itt a kérdés a konkurens stream-ek száma lesz.

  • #10 R0GERIUS tag
    Új Válasz #10
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    R0GERIUS

    tag

    Erre 8-10 VM-et képzeltem el Proxmox-on (Gui-s Linuxokat főleg)
    Ezt határozottan kerüld, túl sok erőforrást eszik a GUI, vagy jelentősen több RAM-ra lesz szükséged.
    Webes GUI a legjobb erre és reverse proxy irányba tapogatóznék inkább.

    Ha Proxmox a terv, akkor inkább a VM-eket LXC konténerekkel váltsd ki, főleg a hálózatkezelők esetén (VPN, DNS, DHCP, (reverse) proxy).
    Akár azon a hack-en is megéri gondolkozni, hogy LXC alatt Docker-t felhúzni (sajnos lehet olyan szoftver, aminek kellhet, például amit fenn említettem).

    Nas, plex és néhány konténeres alkalmazást szeretnék futtatni
    Manapság a NAS-t leszámítva a Docker Compose segítségével le lehet írni egy teljes szoftver szolgáltatás stack-et és sokkal könnyebb üzemeltetni azt, így a kis dolgokra én ebbe az irányba vinném inkább.
    Ebben az esetben kifejezetten javasolt azonos forrásból (pl. linuxserver.io) származó képek használata, mert a Docker rétegekkel (layer-ekkel) dolgozik és kevesebb-re van szükség, mert sok esetben lesz ugyanaz az alapréteg ekkor.
    LXC-vel is megcsinálható ugyanez, de sokkal több a mikromenedzsment és nincs sajnos gyári "software stack" leírója.

    Ansible,Git, terraform és talán Jenkins
    Ansible és Terraform elfér egy LXC konténerben, nem feltétlen érdemes szétdarabolni és legegyszerűbben egy Visual Studio Code-al remote-olva adnék "GUI"-t a dolognak, ha szerkeszteni és futtatni szeretnéd.
    Git-et nem feltétlen üzemeltetnék külön, inkább Gitlab CE és társai, amit érdemesebb, hacsak nem kifejezetten törekszel egy házi és könnyű dologra, iparban ritkán van külön használva.
    Jenkins-t viszont mindenképpen rakd külön konténerbe, az amúgy is fájdalmas tud lenni, nem kizárt, hogy kell néha neki újraindítgatás, főleg ha belenyúlsz egy memory leakes pluginba. :))

    Ha ipari kísérletezés a cél, akkor inkább a Docker még az irányadó, LXC nem elterjedt annyira, mert ritka, amikor teljes OS-t megéri virtualizálni és nem lehet csak az app-ot magát.
    Ha keveset akarsz szenvedni, akkor külön VM a Docker Compose-nak és abban kísérletezni, ami nagyon az alapja az ilyeneknek és ritka a Docker kezelése GUI-ból.
    A Docker esetén a hálózati réteget is elviszi a Docker Engine, amit lehet szintén Docker Compose-ban deklarálni.

    Személy szerint Proxmox-ban LXC-ben futtatnám, amire van normális LXC konténer (lásd: https://community-scripts.github.io/ProxmoxVE/) (mivel annak van a legkisebb "resource overhead"-je és nem kell annyira mikromenedzselni a memóriát), egy VM Docker-nek és egy a NAS-nak a maradék erőforrás a homokozó.
    Vagy a Proxmox vonalat elengedni, Ubuntu LTS szerver (ingyenes Ubuntu Pro-val a live patch kernel miatt) opcionálisan egy webes GUI és Docker-be minden, kivéve a NAS, amihez sanszosan kell egy VM.
    Nincs tökéletes megoldás, preferencia kérdése a dolog.

  • #9 R0GERIUS tag
    Új Válasz #9
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    R0GERIUS

    tag

    Személy szerint csatlakoznék az előttem szólóhoz.
    Van egy kis tapasztalatom a fentivel, így kiegészítem azzal:

    Konténerizációs különbségek:
    - LXC: olyan konténer ahol OS virtualizáció a cél, mert több szolgáltatás is kell ugyanazon konténerben, jó példa erre a Zabbix, ha nincs szeparálva (vagy csak tesztként üzemelteted)
    - Docker: olyan konténer, ahol az app virtualizáció a cél, szűken csak az app-ot és annak követelményeit tartalmazza

    Emiatt, vannak olyan dolgok, amiket érdemesebb LXC-ben vagy Docker-ben futtatni, mintsem a másik alternatívában. Ilyen például az LXC-s 'NGINX Proxy Manager' (web guis, nem a sima NGINX), ami igazán csak Docker-ben fut jól, az LXC-s verzió nagyon sokszor nálam képtelen volt elindulni megfelelően egy szerver restart után.
    A csapda ott van, hogy nincs támogatás Docker-re Proxmox-ban, ott jönnek a hackelős történetek.

    Következő posztba dobom a hasznos tanácsokat, hogy ne legyen ebből rekord hosszú hozzászólás.

Új hozzászólás Aktív témák