- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- droidic: Videó letöltés yt-dlp-vel (profi módszer)!!!
- RIOS Gépház: Rebootoljuk a PROHARDVER YouTube csatornáját!
- koxx: Bloons TD5 - Tower Defense játék
- Boss81: Halott Torrentek keresése, törlése egyszerűen.
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- bambano: Bambanő háza tája
- gerner1
Új hozzászólás Aktív témák
-
bambano
titán
Feltetted a kérdést: "A Docker-nek manapság mik a hátrányai?", majd megválaszoltad: "költség.". Minek írod a rengeteg hsz-t, ha tudod a választ?
"Az valós érv, hogy teljesítmény szempontjából nem ideális, de lássuk be": ez úgy hangzik, mintha egyetértenél egy állításommal. A gond, hogy ilyen állítást nem állítottam.
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.
"Az nem érv, hogy meg kell tanulni az mindenre igaz.": de, érv. Ha nincs docker, akkor mondjuk megtanulom az apt-ot. Egy egység tanulnivaló. Ha van docker, akkor meg kell tanulnom az aptot meg a dockert. Két egység tanulnivaló. És ha nincs valós, számomra is élvezhető előnye a docker tanulásnak, akkor a rá feccölt energia nettó veszteség. Ugyanezt nem értik a systemd fanatikusok. Oké, a systemd legalább egy igazi bugtelep arrogáns fejlesztővel a hátán.
Még mindig erőltetem: aki nagy cégnél dolgozik, az dockerezzen. De a cikk háztáji lab-ról szólt. Jó lenne, ha a fejlesztők megértenék végre, hogy azoknak is szüksége van egy operációs rendszerre, akik kisebb melókat csinálnak. Esetleg hisznek a KISS-ben. Mert ha szétbarmolják mindenféle elektronikus csellentyűcskével a debiant, akkor az egy windows változat lesz. Viszont az utánzat windows biztosan rosszabb lesz, mint az eredeti. Akinek csillagháborús cucc kell, vegyen windows szervert. és fizesse meg
![;]](//cdn.rios.hu/dl/s/v1.gif)
vagy rá... -
R0GERIUS
tag
annyira nem totálisan idióta mindenki, hogy olyan cuccot használjon, aminek csak hátránya van.
1. a világ hülye. informatikában, internetben, és egyébként gyakorlatilag mindenben a világ idióta.
Önellentmondás.
Félretéve azt: A Docker-nek manapság mik a hátrányai? Ne érts félre, a korai szakaszában (olyan 2015 környékén) bőven volt, de mára?
Az nem érv, hogy meg kell tanulni az mindenre igaz.
Az valós érv, hogy teljesítmény szempontjából nem ideális, de lássuk be: legtöbb esetben elhanyagolható ma már a költség.
A fájlrendszere (overlay2 ha jól emlékszem) okozhat néha problémákat, mint ahogy a virtualizált hálózat is, de ezek nagyon speciális esetek.Megmondom a saját elméletem mi ennek kapcsán, hogy miért nem használnának még olyan technológiát sem sokan, ami beszéljünk ideálokról, csak pozitív lenne: költség.
Minden új dolognak van költsége, legyen átállási, tanulási, befektetett energia (vagy annak hiánya: lustaság), üzemeltetési, licensz, stb.
Üzletileg megfogalmazva: megtérülés (RoI)
És a kapitalizmusban az üzleti oldal fog diktálni, nem a szakmai, ha a szakmai nem tudja bizonyítani, miért éri meg üzletileg és miért "nem két fillér" a nyereség rajta.
Mert időlimitált rendszerben (mint amilyen az élet), a prioritás azon lesz, ami üzletileg aktuálisan a legtöbb nyereséget hozza."És nem kell érteni a hálózati réteghez.": ahol olyanok építenek dockerből cuccokat, akik nem értenek a hálózati rendszerhez, oda nem akarok menni.
Hobbiszinten, valamint kis kísérleti dolgoknál nem kell a hálózati réteg.
Ne mossuk össze a dolgot a Docker Swarm, Kubernetes, stb-vel, nem feladata a Compose-nak egy bonyolult terhelés elosztott architektúra definiálása. -
#86
R0GERIUS
tag
stickermajom
#78
R0GERIUS
tag
válasz
stickermajom
#78
üzenetére
Őszinte leszek: átlag felhasználásban nem feltétlen van fontossága.
Sajnos nem tudok számokat mondani, így lehet kissé l'art pour l'art a dolog ebben az esetben, de az elméletet le tudom írni.Az elmélet a következő:
Ha normál 'bridge' módban használod, akkor Plex esetén a videofolyam átmegy először a virtualizált hálózaton a rendes hálózatra, ami CPU használat és folyamatos relatív nagy sebességű átvitellel.
Nyereség belőle nincs, mert megcímezhető a hoszt IP alapján is konténerből (pl Tautulli) és nem számít, hogy mennyi idő a kommunikáció.
'host' kapcsoló mellett csak portátirányítás van, a forgalom nem megy át a virtualizált hálózaton.Kisebb appok esetén az a nyereség a 'bridge' hálózatban, hogy a konténerek közti kommunikációnak nem kell a rendes hálózaton történnie, valamint a belső DHCP miatt címezhetőek név szerint is (sőt nagy eséllyel inkább csak azzal, mert a belső IP címek menedzsmentjének sok értelme nincs kis méretben).
De ezeknél "ritka", nem folyamatos és kisméretű a kommunikáció, így nincs jelentősége, hogy a hálózat virtualizált, maximum az, hogy tehermentesíted a külső hálózatot. -
bambano
titán
"És ott is van fenn egy hosszú felsorolás a mindenapi életben könnyen előforduló előnyökről.": a hsz, amire válaszoltál, arról szólt, hogy azokat az előnyöket el lehet érni docker nélkül is.
És nem az a kérdés, hogy a dockernek a hátrányai mellett vannak-e előnyei is, nyilván vannak, hiszen annyira nem totálisan idióta mindenki, hogy olyan cuccot használjon, aminek csak hátránya van.A kérdés az, hogy az adott konkrét helyzetben az előnyök hogyan viszonyulnak a hátrányokhoz. Ebből még az is következik, hogy az egyik épületben kell a docker, a másikban nem. Például ha a főnök kockázatviselési hajlandósága és fizetési kedve különbözik, akkor lehet olyan, hogy egyik cégben a docker a jó választás, a másikban nmeg nem. EZÉRT teljes tévedés azt mondani, hogy mindig minden dockerbe.
"A fenti hibaoka a virtualizált hálózat volt": nem az extrém ritka kivételek alapján döntünk.
"pont az ilyenek erős érvek a virtualizációval szemben": MELLETT. nem szemben. ha nincs csilliárdokért multimaster replikálható adatbáziskezelőd, mert mondjuk kkv vagy és nem akarod a teljes évi bruttó árbevételedet kifizetni az oracle-nek, akkor virtualizált, live vagy hot migrációra alkalmas cuccot fogsz építeni.
Mondjuk én pont a dhcp szervert magam szoktam fordítani...
-
R0GERIUS
tag
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. -
R0GERIUS
tag
Define forrás
Ubuntu (és derivatívái) esetén van rá csomag, amely település után apt repo-t is fel tud venni, Windows és Mac esetén önfrissülő (kliens oldalról van szó) a VSCode.
De vannak OSS derivatívái majdnem minden OS-re.
Compile-olást pedig erősen megkérdőjelezem, hogy miért követnéd el hobbi felhasználásra.
Hosztra meg nem rakod fel, GUI nélkül nincs értelme, arra van a vim. -
R0GERIUS
tag
a plusz réteg *MINDIG* káros. Nem azért virtualizálunk, mert a plusz rétegnek nincs negatív hozadéka is, hanem azért, mert összevetettük a kockázatokat, negatív hozadékokat a pozitív hozadékokkal, és úgy döntöttünk, hogy mégis megéri.
És ott is van fenn egy hosszú felsorolás a mindenapi életben könnyen előforduló előnyökről.
Például az adatbázisokat pont érdemes valami módon virtualizálni, mert ha a kiesése kárt okoz
Igen, de nem fejetlenül, mert ha csak YOLO csinálod, akkor bye-bye teljesítmény és ha olyat végzel rajta, ami sok adatbázis műveletet igényel (például migráció), akkor lehet egy 20 perces feladat könnyen 4 órás is, nagyon megcsappant utasítás teljesítménnyel.
A fenti hibaoka a virtualizált hálózat volt, mivel nem volt elég a hoszt arra, hogy azt is hatékonyan kezelje.
A kiesést pedig elosztott rendszerek kezelik, nem feltétlen virtualizáció. Illetve ezekre potenciálisan VM-ek hatékonyabbak lehetnek, mint Docker, erőforrás típusától függően.
Például, ha csak VM-eket tudsz futtatni cloud-ban és Docker-t közvetlen nem, csak VM alatt.
De ezek mind olyan témák, amik speciálisak és pont az ilyenek erős érvek a virtualizációval szemben, de ezek nem általános felhasználásból jönnek sokszor.
Egyre inkább úgy érzem, hogy azok fejlesztenek, rajonganak mindenféle virtualizációs, konténerizációs megoldásokat, akik nem tudják, hogy az alap oprendszer mit tud.
Iparból jövő ellenpélda: próbáld ki mennyire "jó" ez a megközelítés, ha valamiért váltanod kell OS-t. Mondjuk amikor a Red Hat kegyesen kinyírta a CentOS-t és lehetett migrálni másra. Ott szoktak a csontvázak előkerülni és nyilván, aki Debian-t vagy Ubuntu-t használt megúszta, de az sovány vigasz.
1. apt-get update
2. apt-get dist-upgradeÉs erre esküdj is meg, hogy nem fog valamilyen legalább package-ből jövő konfig fájlt konfliktot okozni.
Illetve hány ezer éves szoftverekről van szó, ha nem akarsz mindenféle harmadik féltől származó tárolókat behúzni.
Nagyvállalati célra az elvárt a stabilitás mindenek felett, de pont hobbi szinten közelíteni akarod a minél frissebb szoftvert.
Valamint egyre több dologból van konténer, mintsem érdemi csomag.ha te ezért tennéd bare metal-ra a dhcp-t, akkor nem vagy képben a dhcp-vel... Nem tudom mennyi idő egy docker engine frissítés, de annyit a dhcp protokoll kibír. Ha mégsem, és olyan fontos a dhcp, akkor úgyis van több dhcp szervered, és nem egyszerre frissítetted.
Rendben, hogy kicsi az esélye, hogy pont akkor szeretne valami DHCP cím bérletet újítani, de pont hogy abban az esetben húznám elő az érved, amellyel ezen egy esetben egyetértettem.
Melyikre bíznál jobban egy kritikus szolgáltatást, amiből a stabilitás jobban számít minden felett? Mert inkább a hivatalos repo-ból.
Ezen felül van egy másik érv is: ha a Docker Engine lehal, valami frissítési hiba lép fel, vagy más komplikáció esetén nem kell attól tartanod, hogy automatikusan konfigurált hálózat nélkül maradnál (mert ha ezen a szinten vagyunk, de úgy látom kell: DHCP nélkül is van élet), míg csomag esetén ennek az esélye asztronómikusan kicsi.Külön érdemes szemlélni, hogy mit hol érdemes futtatni.
Hobbiszinten:
Amiben megbízol és a stabilitás számít mindenek felett és/vagy kritikus: mehet hosztra, vagy jobban ajánlott hoszton, esete válogatja (pl DHCP)
Ami nem kritikus, de jobb, ha minél újabb: konténer -
bambano
titán
"miért utóbbi felé mozdul el a világ": tényleg egyszerű:
1. a világ hülye. informatikában, internetben, és egyébként gyakorlatilag mindenben a világ idióta.
2. a világ egy része nem szeret rendes munkát végezni, inkább programoznak új feature-ket, mint kijavítsák a régi verzió hibáit.
3. a világban a döntéshozók zöme nem szakmabeli és nem is érti a szakmát. ezt a világ döntéshozóinak másik fele szemrebbenés nélkül kihasználja.Nem azért konténerizál a világ, mert az mindehol optimális, ahol használják, hanem azért, mert divat.
Migráció: tényleg nem függök attól, hogy a redhat mit csinál. Eldöntöttem, hogy nálam minden gépen debian fut, így az, hogy a redhat mit csinál, az másvalaki problémája. Minek is kevernék egy rakás platformot? KISS. ja, te azt utálod.
Alap debianra felrakott appokat is lehet úgy biztonságilag menteni, hogy nem kell lehúzni az egész oprendszert. Van róla videó a tecsőn, meg lehet tanulni.
Üzemeltetési függetlenség: egyrészt az os akkor is összeborulhat, ha docker van rajta, meg akkor is, ha nem. Egy szint fölött nem úszod meg az upgrade előtti tesztelést, tehát ebből a szempontból mindegy, hogy docker vagy sem. Egyébként pedig ha leszokik az ember a verzióhajhászásról, akkor ezt a kockázatot csökkenteni lehet. Nekem még sosem akadt fel a debianom azonos kiadáson belüli frissítéstől.
Ha verziókezelésre van igényem (egyébként minek lenne?), akkor azt lehet alap oprendszeren is.
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.
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.
Tehát mégegyszer: azt nem mondtam, hogy dockert soha. Ha valaki korrekten mérlegelte a kockázatokat, előnyöket, hátrányokat, ezeket összevetette a konkrét helyi igényekkel és szokásokkal, akkor lehet jó választás a konténer, a virtualizáció. De az az állítás, hogy alapértelmezetten minden dockerbe, és nagy ritkán erős érvek esetén hagyjuk csak el a dockert, az teljes tévedés, a valóság megfordítása.
-
R0GERIUS
tag
Simán lehet vim-ben is szerkesztgetni a compose fájlt, ha tesztelek, akkor inkább azzal nyúlok bele host-on.
De manapság inkább úgy érdemes (mert lássuk be, nem divat már a vi/vim/emacs, kivéve ha rá vagy kényszerülve, mint például router-ek esetén), hogy kliensoldalra felrakod a VSCode-ot és remote-olva szerkeszted azt.
Ahol ezt nem teheted meg, oda pedig vim. -
bambano
titán
"Haaah, annyira de annyira kimondhatatlanul utálom, amikor valaki KISS-szel takarózik...": utálod a józan észt? Hosszú távon nem érdemes...
"ahol a plusz réteg káros.": a plusz réteg *MINDIG* káros. Nem azért virtualizálunk, mert a plusz rétegnek nincs negatív hozadéka is, hanem azért, mert összevetettük a kockázatokat, negatív hozadékokat a pozitív hozadékokkal, és úgy döntöttünk, hogy mégis megéri.Például az adatbázisokat pont érdemes valami módon virtualizálni, mert ha a kiesése kárt okoz, akkor valahogy meg kell oldanod, hogy az adatok rendelkezésre álljanak egy esetlegesen döglött szerveren kívül is. Vagy csináltál san-t, vagy csináltál valami hálózati storage-t. És még mindig ragaszkodnék ahhoz, hogy ez a poszt nem rakétatudósok realtime kutatásáról szólt, hanem egy otthoni kis laborról. Tehát majd ha google meg facebook senior architektek fognak ebbe a topicban térden állva könyörögni, hogy oldjuk már meg a bajaikat, akkor egyet fogok érteni a konténerrel.
"a konfig-ból fel tudod húzni bármilyen gond esetén bárhol a saját kis szoftveres struktúrádat": csak ehhez nem kell docker. Ha a konfigomat lementettem, akkor bárhol bármikor fel tudom húzni a cuccomat az alap oprendszeren is. Egyre inkább úgy érzem, hogy azok fejlesztenek, rajonganak mindenféle virtualizációs, konténerizációs megoldásokat, akik nem tudják, hogy az alap oprendszer mit tud.
"az egész stack frissítése is 2 parancs.":
1. apt-get update
2. apt-get dist-upgradeMegszámolnád nekem, ez hány parancs?
A dockerezés arról is szól, hogy te a disztród csomagolóiban bízol jobban, vagy a docker csomagolóiban? Mert más érdemi különbség ezen a szinten nincs.
"DHCP-t pedig valóban "bare metal" üzemeltetnék, mert ott nem eshet ki egy Docker Engine frissítés mellett a szolgáltatás.": ha te ezért tennéd bare metal-ra a dhcp-t, akkor nem vagy képben a dhcp-vel... Nem tudom mennyi idő egy docker engine frissítés, de annyit a dhcp protokoll kibír. Ha mégsem, és olyan fontos a dhcp, akkor úgyis van több dhcp szervered, és nem egyszerre frissítetted.
-
R0GERIUS
tag
Ami pedig a "bare metal" és konténerizáció témát illeti, és miért utóbbi felé mozdul el a világ, az egyszerű.
Egyrészt, amit említettem, könnyű migráció. Nem függesz attól, hogy mondjuk a Debian és Red Hat hogy implementálja a csomagokat, hova kell kötni a konfigfájlokat.
Másrészt a biztonsági mentések mérete: ahhoz, hogy működjön elég csak a bekötött lokációkat menteni, nem kell a teljes OS-t.
Harmadrészt üzemeltetési függetlenség: mivel csak az appot tartalmazza a konténer, nem kell tartani egy OS upgrade esetén mi történik, mert semmi, továbbá garantáltan a legfrissebb szoftvert tudod futtatni, nem kell megvárni, hogy legyen belőle valahol egy .deb csomag, vagy kézi frissítgetés.
Negyedrészt verziókezelés: label-ekkel lehet meghatározni a neked kellő szoftververziót. Sokkal körülményesebb ez sima csomagokkal, könnyen törhetnek alatta a függőségek. (Lásd Linux Mint + legfrissebb mpv esete, libmpv-t is el kell távolítani, ha a fruit apt repo-ról szeded.)
Ötödrészt flexibilitás: Például könnyen meg tudod írni a virtualizált hálózatot, amiben futtatsz egymástól függő szoftvereket. Ha jól csináltad, akkor annak a hálózatnak a belső DHCP-je miatt használhatsz neveket is összekötéshez és nem függesz attól a hálózattól, amire rá van kapcsolva a gép (mondjuk egy Plex-et továbbra is inkább 'host' paraméterrel a hoszt hálózatra kötnék, de ahol nincs nagy forgalom).
Hatodik nagyon könnyű visszaállítás: ha valami nagyon félremegy, de megvannak az appdata és konfig fájlok, akkor OS telepítés után csak vissza kell másolni a fájlokat a megfelelő helyre felrakni a Docker Engine-t és 1 paranccsal felhúzni a szoftver stack-et. Kevesebb, mint 1 óra helyreállítani mindent.És mindezen fentihez nem kell több a nap végén, mint egy Docker Engine CE, egy 'docker-compose.yml' és konfig és appdata mappák mondjuk az /opt alatt, (Proxmox kivételével) teljesen mindegy melyik Linux OS alatt, ahol az /opt-ról rendszeresen van külső helyre biztonsági mentés.
A 'docker-compose.yml' mellett a frissítése a teljes szoftver stack-nek pedig 2 parancs kombinációja:docker-compose pull && docker-compose up -dHa a fentire nem érvényesül a KISS, akkor nem tudom mire, mert ennél egyszerűbben képtelenség hosztolni valamit.
Persze van egy beugrója, meg kell érteni a Docker-t (üzemeltetési szempontból) és a Docker Compose-t (szoftver stack tervezési szempontból), de utána iszonyatosan könnyű .
Zárásként erőforrás költségben pedig: a nálam futó teljes multimédia stack Docker-en, amiben van Plex, különböző automatizációk, torrent kliens, reverse proxy (összesen 14 konténer) memória igénye: 1.41 GB -
R0GERIUS
tag
Haaah, annyira de annyira kimondhatatlanul utálom, amikor valaki KISS-szel takarózik...
Egyéb esetekben az alap oprendszeren futtatunk mindent.
- Igen, úgy a 2010-es évekig volt divat, mára egy kifejezetten káros elmélet és részletezem alább, hogy miért veszett ki ez a szemlélet az iparból, de egyre inkább hobbi szerverhosztolásból is.
ON:
Nem kell és nem feltétlen érdemes mindent konténerben futtatni, de manapság az app-ok többségét megéri.
Amit nem is szabadna konténerizálni, csak speciális esetekben, azok a késleltetés érzékeny dolgok, vagy ahol a plusz réteg káros. Egyik jó példa ilyenre az adatbázisok, ami körültekintést igényel, nagyon nem ajánlott virtualizált subnet-re rakni.Ugyanakkor, ha nincsen valamilyen speciális megfontolásod, akkor ajánlott konténerizálni és eljutni egy Docker Compose szintjéig.
Itt a fő megfontolás, hogy a konfig-ból fel tudod húzni bármilyen gond esetén bárhol a saját kis szoftveres struktúrádat (IaaC), mindaddig amíg úgy építed fel, hogy a konfig-okat (valamint külső fájlokat, mint média) felcsatolod volume-ként és a konfigok és adatok biztonsági mentéséről külön gondoskodsz.
Ezt egyetlen egyszer kell megtervezni és megcsinálni, és akkor teljesen mindegy milyen OS fut az adott gépen, vagy akármilyen hardveren, egy migráció röhejesen egyszerűvé válik, az egész stack frissítése is 2 parancs.
Overhead pedig manapság elhanyagolható valóban, pár speciális kivételtől eltekintve.LXC pedig 2 dologra jó:
a) Ha valamiért kell egy OS, mert a stack bonyolult, összefüggő, nincs belőle normális Docker. Tökéletes példa erre: Zabbix, ami natívban azért vacak, mert a csomagok hitványak és jobb emiatt egy LXC-ben tartani, ha kell akkor lehet könnyen kidobni az egész konténert és újrahúzni, anélkül, hogy a host OS-t kellene újrahúzni.
b) Proxmox, mivel ott csak azzal tudsz leginkább játszani, és megoldja az LXC legnagyobb hátrányát: biztonsági mentések
Viszont az LXC tényleg bonyolult, így tényleg csak érdeklődőknek javasolnám, vagy nagyon speciális felhasználásra. Van létjogosultsága, de nem annyira hobbi kategóriában.DHCP-t pedig valóban "bare metal" üzemeltetnék, mert ott nem eshet ki egy Docker Engine frissítés mellett a szolgáltatás.
-
bambano
titán
a debianban gyárilag benne levő vim úgy van beállítva, hogy saját elhatározásából pakolgatja a tabulátorokat, indentálgat ész nélkül, stb. Ez direkt jól jön tabulációs szintaxisnál.
szerk: #69 a vim megmutatja a zárójelek párját, szóval egy ilyen hibát pillanatok alatt ki lehet szúrni.
-
dabadab
titán
Akkor nézzük meg ugyanezt JSON-ben, oké? Ez plusz 45 nem-whitespace karaktert tartalmaz és ezek olyanok, amire mind figyelni kell, hogy ne okozzon hibát, de semmiféle plusz információtartalmuk nincs a fenti yamlhoz képest.
Viccből elrejtettem benne egy hibát - megtalálod vscode nélkül?{
"version": "3",
"services": {
"victoriametrics-test": {
"container_name": "victoriametrics-test",
"image": "victoriametrics/victoria-metrics",
"ports": {
"1234": 8428
}
},
"volumes": {
"./vmdata": "/storage"
},
"command": [
"--storageDataPath=/storage",
"--httpListenAddr=:8428",
"-retentionPeriod=100y",
"-memory.allowedPercent=20"
},
"restart": "always"
}
} -
#68
hcl
titán
stickermajom
#64
válasz
stickermajom
#64
üzenetére
@dabadab : Számomra sokkal kevésbé átlátható. Meg igazán a Python a meredek, az is identálós. Ha neked jobban tetszik, egészségedre, de nekem nem.
-
dabadab
titán
Most komolyan, ebben mi az, ami olyan rettenetesen gonosz? És mennyiben nézni ki másképp ugyanez JSON-ban, azt leszámítva, hogy tele kellene rakni egy rakat zárójellel?
version: '3'services:victoriametrics-test:container_name: victoriametrics-testimage: victoriametrics/victoria-metricsports:- 1234:8428volumes:- ./vmdata:/storagecommand:- "--storageDataPath=/storage"- "--httpListenAddr=:8428"- "-retentionPeriod=100y"- "-memory.allowedPercent=20"restart: always -
dabadab
titán
vscode az egyébként is nagyon fasza, az mindenhez jól jön, de nem kell, ahogy olvastad, pont docker yamlokhoz nem használom. Sőt, YAML-hoz lényegesen kevésbé kell, mint JSON-höz vagy a rettenet XML-hez, mivel az előbbivel sokkal kényelmesebben lehet vi-ban dolgozni, mint a másik kettővel.
-
bambano
titán
Több hsz-re egyszerre:
egyrészt mindenre van xkcd: [link]
Másrészt én pont azon morgolódok, hogy az itt elhangzott állítás szerint dhcp szerverhez kell docker, composer, meg egy rakás cucc, és akkor ezt még most megfejeljük vscode-dal is.A világ megérett a pusztulásra...
Amit nem lehet *kényelmesen* vi-ban megcsinálni, az másvalaki problémája.
-
#63
hcl
titán
Speeedfire
#62
válasz
Speeedfire
#62
üzenetére
Igen, azon a szinten már alap, hogy IDE-t használsz. Én meg leginkább magamnak fejlesztek, meg ott, ahol ez volt, írtam scripteket a saját munkánkhoz - amúgy melóhelyen csak kisebb c# programokat, stb.
De maga az elv, hogy nincs lezárása a cklusnak, stb., az számomra
Persze, biztos fancy, csak nem túl egyértelmű. -
"egyrészt messziről üvölt róla, ha elrontottad, "
Nekem pont nem szokott feltűnni, hogy most akkor az hány karakterrel van beljebb, vagy nem.@speedfire : Nyilván, de egy normálisan kitalált nyelv szerintem mindenféle segédeszköz nélkül is működik. És egzakt, nem azzal rontod el, hogy mennyire húzod be a sort
Volt olyan munkahelyem, ahol leginkább a szervereken írtál shell scriptet, nem a saját gépeden, és ott vi volt. És teljesen kivitelezhető volt a dolog.
-
dabadab
titán
Mondjuk pont az identálás az olyan, hogy egyrészt messziről üvölt róla, ha elrontottad, másrészt meg tényleg simán lehet csinálni vi-jal is akár. Tipikusan én is tök sima text editorral szerkesztem őket és még soha nem volt gond abból, hogy elrontottam volna, ellenben amikor mondjuk jsonban kellene írni valami }}]}]} sormintát, azt felokosított szerkesztő nélkül azért elég könnyű elrontani.
-
tessék rendes szerkesztőt használni, aztán máris könnyű.
vscode pl azonnal, már gépelés közben mutatja, ha nem jó az indentálás.mondjuk ami yaml-t én eddig láttam, ott az egyes blokkok mindig zárva voltak valami határolóval, szóval így kicsit redundáns, de gondolom ez nem kötelező eleme a szintaktikának.
-
Linux alá, ha nincs nagyon GUI, elég a winyó. De még akkor is, ha van. Egyszerűbb dolgokhoz, sok RAM mellett.
Most nekem itt ZFS van, volt vele cumi, de némi RAM árán elég gyors. Amikor nem ZFS volt, akkor is elfogadható volt a Linux VM-ek sebessége, a Windows szenvedett nagyon tőle. -
Phvhun
őstag
Hardveroldalhoz ezeket tenném hozzá:
1. Dockeres kisérletezéshez első körben egy VPS-t bérelnék pl Digitalocean-nél pofon egyszerű és nagyon olcsó elinditani pár napra és lelőni még egy izmos teszt gépet is, egyébként is a cégek cloudban futtatják a dolgaikat, ezt is meg kell tanulni, plusz van náluk docker registry is, ha saját konténereket is akarsz csinálni.
Amikor én rakosgattam össze egy github, kubernetes, jenkins stb teszt rendszert akkor a VPS-es megoldást választottam.
2. Ha épitkezel, akkor HDD-t egyáltalán nem tennék a gépbe, mert csomó fejfájást okozott nekem a lassú működése amikor régebben VM-eznem kellett
3. Ha mindenképpen HDD-t akarsz, akkor a sima WD Red-et NE, mert SMR-es (olvass utána), a WD Red Plus vagy Pro kell neked
-
-
Crucio
aktív tag
-
Crucio
aktív tag
Kicsit megszólítva érzem magam, tekintve, hogy 2018-19 óta "foglalkozom" Dockerrel. Igazából nem kell azzal foglalkozni, megy az magától is, ha csak a "docker compose"-ig megy az ember, és otthonra annál sokkal több nem kell.
Szóba került itt több dolog is a konténerizáció és a virtualizáció kapcsán, és úgy éreztem, hogy na!
Virtualizáció vs konténerizáció
Az alapvető különbség, hogy virtualizációnál a teljes OS-t futtatod egy új példányban, a konténerizációnál pedig csak az alkalmazást és a függőségeit. A konténerizációnál ugyanazt a kernelt használod.
Docker Windowson
Igazából amióta én Dockerezek, elérhető volt a Docker Windowsra, de olyan 2020 óta van Windows Subsystem for Linux 2 (WSL2), és azóta nem kell virtuális gép sem a futtatásához. A WSL2 lényegében a linuxos kernelhívásokat fordítja át a Windows kernelének a hívásaira (kb) és ezért megoldható kb 5 éve a Docker virtualizáció nélküli futtatása. Olyan, mintha futna egy Linux kernel a Windows kernel mellett.A konténerizációnak nagyon minimális plusz teljesítményszükséglete van, én a saját gépemen pl nulla teljesítménybeli különbséget tapasztalok akkor is, ha sok konténer fut. Ez a VM-ekre nem igaz, két-három VM már komoly plusz erőforrást igényel. Még a konténerizáció előtt én is így futtattam a kis próbálkozásaimat, próbáltam izolálni a kárt, amit okoztam, és azért két VM már érezhető volt egy 2018 előtti i5-ös gépen. Ugyanazon a gépen egy sok konténeres komplex alkalmazás, amit én írtam sem jelentett problémát. Természetesen van némi plusz erőforrásszükséglete, de nem misztifikálnám túl.
Szervergép: én vettem egy régi Dell Workstationt (T3630) egy Xeon processzorral (E-2174G). Oké, nem pont ugyanarra használom, mint amire neked kell, de nekem idle állapotban 11-13W-ot fogyaszt és egy Kubernetes (kubeadm) fut rajta, egyelőre egyetlen node-dal. Nem állítgattam rajta semmit. Igaz, HDD nincs benne, csak egy SSD (egyelőre).
Ezekbe a workstationökbe lehet tenni egyébként 9th gen Inteleket, amik már szerintem kielégítik a legtöbb igényt.
Egy fogyasztásmérővel mértem.OS-nek én Debiant javaslok mindenféle desktop environment nélkül. Miközben telepíted, mindent csinálj úgy, mintha simán csak Debiant telepítenél, de amikor megkérdezi, hogy milyen "Desktop environmenteket" szeretnél (Gnome, KDE, stb), akkor ne válassz ki semmit. Cserébe rakd fel az SSH-t és társait.
A Debian előnye még, hogy nagyon stabil és az interneten nagyon könnyen elérhetők hozzá a "guide"-ok. Tehát egy kezdőnek szerintem a legjobb választás. Jellemzően, amit Ubuntuhoz írnak az is működik Debianon.
A Docker telepítése kb 5 percet vesz igénybe, a Docker oldalán le van írva lépésről lépésre, hogy mit kell csinálni, és egyéb területen is teljesen jó a Docker dokumentációja.Kezdőknek Network Chuck videóit szoktam javasolni ebben a témában, teljesen jók szerintem. Pl Docker Compose tutorial, ami csupán 16 percet vesz igénybe. Minden másra ott vannak a Udemy 10 eurós kurzusai, ha jobban elmélyülne benne az ember.
A Docker további előnye, hogy egy úgynevezett "yaml" nyelvet használ a konfigurációra. Magyarul ha egyszer összelőtted Docker compose-zal a környezeted, többé nem kell vele szenvedned. Csak a yaml fájl elérhetőségéről kell gondoskodnod, utána ha bármi van, egy
docker compose upparanccsal tudod futtatni. Nincs újra bonyolult telepítgetés, nincs nehézkes környezet összelövés, minden ott van, ha a host os-t újra is telepíted, a yaml fájllal újra életre tudsz hívni mindent, egyetlen paranccsal. És működni is fog!Ha mindent felteszel így egy ilyen "headless" rendszerre, akkor nem lesz szükséged arra, hogy az OS-nek magának GUI-ja legyen, elérhetővé tudsz tenni minden szolgáltatást localhoston, és akkor böngészőből eléred, ahonnan csak szeretnéd. Mehet fel gitea, meg amit akarsz.
Ennél több otthonra nem hinném, hogy szükséges lenne, sőt, már ennek a megtanulása is szép feladat egy - a folyamat elején - laikus számára, de nem kell tőle megijedni, mert ha ráérzel, onnantól könnyen fog menni.
-
Ha hardver:
Teljesen fölösleges ehhez gépet építeni, főleg AM4-es, két CCX-es processzorral, mert az energiát megeszi, viszont feltehetően kábé semmit nem fogsz kihasználni belőle.
Némi mákkal ki tudsz fogni valahol 70k környékén 8th gen i7-es brand gépeket, ott például a HP Elitedesk 800 G4-nél 180 wattos platinum táp van és némi szoftveres optimalizálással az idle fogyasztás le tud menni olyan 17 watt környékére, viszont ha éppen erő kell, akkor az tudja prezentálni. (mondjuk általában a 2x3,5 colos HDD problémás tud lenni, ugyanakkor a 2 TB szerintem bőven elfér egy lemezen is)
Nálam most éppen egy Thinkcentre M920t van, i7 8700-zal, plusz 64 giga rammal, 1G ssd, meg 10G WD Gold társaságában (szerencsére a konyhában van a szerver, így csak főzés közben hallom a HDD hangját, jó hallással rendelkezőknek nem ajánlom) és fut rajta egy W11, Opnsense, illetve egy Splunk VM, plusz mindenféle apróság. Ezt bőven elbírja CPU-val és lehet még rá pakolgatni bőven, köszönhetően annak, hogy a 64 giga memóriából nem fog kifutni.
Egyébként 8th gentől fölfelé az iGPU már támogatja a hardveres 4k lejátszást és transzkódolást, úgyhogy a Plex/Jellyfin jól fog működni rajta, ehhez külső GPU eléggé fölösleges, hacsak nem akarsz egyszerre több streamet is transzkódolni. Ugyanitt inkább Jellyfin, mint Plex, mert az full ingyenes.
A GUI-t felejtsd el, általában bármit használsz, annak van valami WebUI-ja, úgyhogy csak fölösleges overhead-et generálsz. Ha tartasz a CLI-től, annyira nem érdemes, mivel egyrészt mindenhez van guide, amivel kiválóan tudsz majd errorokba futni, másrészt pedig kiváló
szopásitanulási lehetőséget nyújt.Ugyanitt hardver kapcsán pár hónapja írtam kábé nyolcmillió karatert, azt érdemes lehet átfutni.
-
VM-be rakással nincs gond szerintem, mert nem vagy egy OS-hez, hardverhez kötve, könnyebb migrálni. Ha megborul, könnyebben van backupod, vagy rakod újra. De 10 VM egy ilyen mezei asztali vason elég meredek
Konténer lehet még jó ilyenkor.Amúgy GUI-s gépek, még csak az se biztos, hogy kell GUI egy-egy ilyen gépre, amiket felsorolt
@shadowkidhu : Nekem itt egy 8. gen proci, 6 mag, 32GB RAM, amiből mondjuk eszik a ZFS cache is, de ezen max. pár gép tud együtt futni.
-
buherton
őstag
Nagyon ritkán használom az USB portokat, így bármit is mondanék nem lenne releváns. Jelenleg működnek.
Az előző alaplapom nekem is ilyen volt (Q1900). Ott sem volt USB gondom, viszont a CPU instabilitásával voltak gondjaim, amit az UEFI upgrade sem oldott meg, azért cseréltem le a már korábban említettre.
#41 stickermajom: köszi
-
#41
stickermajom
addikt
buherton
#37
stickermajom
addikt
Ennek majdnem negyede csak az *arr stack, és a plex.. Van még qbittorrent és egy-két app hozzá, illetve gluetun pár konténernek kifelé, Tailscale befelé és kifelé exit node-ként mobiloknak és tableteknek. Pihole, unbound (ezeket ki akarom rakni majd egy külön eszközre), egy-két webapp mint pl. changedetection, mealie, actual budgeting,
hoarderkarakeep, komga.
Ezek mellé van pár "management" cucc, mint portainer, wud, uptime-kuma (ez is költözik majd), influxdb, grafana, loki, beszel (bár ezt lehet dobom, nem ad semmit hozzá a meglévő dashboardokhoz), scrutiny, illetve traefik, hogy egyszerűbb legyen az élet.A compose fájlt és pár app db-jét kopia backupolja gdrive-ra, de kacérkodom a restic-kel miért ne alapon, úgyis szeretnék majd immich-et és azt Backblaze B2-re menteni vele. Már itt vannak az asztalon a lemezek hozzá, csak nem volt még időm vele foglalkozni.
Jó volt amúgy bőven sokáig J4105, de a channels-dvr+threadfin kombóval elértem a kritikus tömeget, ahol már elő tudtam idézni olyan körülményeket amitől köhögött szegény, így jött a csere. 12th gen Intel volt már élhető áron és a századik konténerig most jó leszek vele.
-
dabadab
titán
Egyébként a dockeres résznél lehet, hogy érdemes elgondolkodni egy VPS-en is (vagyis egy szolgáltatónál hostolt virtuális gépen). Kezdőcsomagokból van egész jó áron, pl. az OVH-nál van 1 mag / 2G RAM / 20G SSD havi egy dollárért (max 12 hónapig van ez a kedvezményes ár): [link]
Ez kevésnek látszik, de igazából ahhoz, hogy pár docker container elrohangáljon rajta, teljesen elég, meg legalább látni fogod, hogy mégis mire számíts erőforrásigényben meg hasonló kérdésekben. -
rgqjx
aktív tag
Ha úgy adódik, hogy szükség lenne rá: Proxmox topic
-
Fentebb mások már kifejtették a 'miért', illetve 'minek' kezdetű, virtualizációval kapcsolatos kérdésekre a válaszokat, és a praktikus szempontok bő javával mélységesen egyet is értek. A l'art pour l'art jellegű next-best-thing-ever motívumok pedig nem mozgatnak a kitárgyalt szempontok közül; se pro, se kontra.
Egy gondolatodra reagálnék:
Szerintem vm-et marokszám az üzemeltessen, aki meg akarja tanulni a vm-eket, hogy esetleg később fizetős melóban használja.
Ez! Ez itt a lényeg.
Nagyvállalati téren abszolút, de már KKV szinten is a virtualizáción alapul az operatív infrastruktúra zöme; egy gigantikusan túltolt SAP ERP-tól kezdve, Béla 'urna-és-virág-webshop' webelérésű menedzsment applikációjával bezárólag. Legyen az 'generic-big-cloud' (GCP/AWS/Azure), 'solution-specific-cloud' (pl. SAP S/4HANA, Anaplan Cloudworks, Salesforce, etc.) vagy on-premise vason futtatott virtualizáció lokálisan, illetve akár netre engedve.
Nagyobb jövőkép van a virtualizáció összefüggéseinek, protokolljainak, konfigurálásának, etc....de főleg a praktikus alkalmazhatóság elveinek legalább alapvető elsajátításában, mint a 'hagyományos' (legacy?) IT alapokban...főleg, hogy akár az előző bekezdésemben említett példákban is a nap végén a dedikált 'techy' weblinken elérhető különböző webfelületeken fogja őket használni kvázi alkalmazásként, akár frontend-et, akár backend-et abúzál éppen.
...és ebben a környezetben konkrét példa VM-re: GCP data store ETL output-ját a Salesforce irányába egy felhőben hostolt Linux VM pakolgatja scriptelt schedule szerint a vonatkozó
felhőkködök egress és ingress API-jai között a 'semleges űrben', ahol csak ő létezik és a két API connection-je, elzárva mindentől. Ez az egy dolga van. Kvázi microprocess. Miért? Mert így mindenkinek igaza lett a végén. #solutiondesign -
#37
buherton
őstag
stickermajom
#35
buherton
őstag
válasz
stickermajom
#35
üzenetére
Nekem ilyen van: [Asrock J3455-ITX] Transzkódoltatni nem szoktam vele, de amire kell nekem arra nyakig elég. Deluge, plex (zenére), pigallery, minidlna, samba, airprint, és egy ideig volt restreamer IP kamerákra. Egyedül akkor érzem, hogy lassú, amikor programot írok rajta.
Gondoltam, hogy a GitHub-ra hozzáadom mit worker node a GH Actionhöz, de egyelőre nem értem el a free limitet, ezért nem volt rá még szükség.
Neked mik futnak rajta?
-
buherton
őstag
Jogos és eddig ebbe bele sem gondoltam. A shared libnek csak a
.textrészével kell számolni hogy többszörös lehet, mert.dataés.bssígyis-úgyis processenként külön lesz allokálva a fizikai memóriában.#32 bambano
Ez szerintem már a fing reszelés kategória, hogy most először fel kell tenni egy programot. Ez sehol sem dealbreaker. Ahogy az sem az, ha asources.list-hez kell új entryt hozzáadni, mert az official apt épp nem tartalmazza azt. Az viszont már lehet dealbreaker, ha nem elérhető a legfrissebb verzió az adott appól. Itt arra gondolok, hogy az ubuntu esetén is az apt nem mindig a legfrissebb verziót tartalmazza. -
#35
stickermajom
addikt
stickermajom
addikt
Ahogy már korábban is írták, ha plex és transzkódolás, akkor inkább Intel a quicksync miatt. Az elmúlt 5 évben egy J4105-ön futott a rendszer, gond nélkül transzkódolt 4K->1080p-t, ha szükség volt rá. Csak még a hó vége előtt vedd meg a plex pass-t, mert áremelkedés jön.
Pár hónapja cseréltem i3-12100-ra, bár VM-et nem futtatok, de fut 55 docker konténer, köszöni elvan gond nélkül, a 32GB RAM-ból 10-et használ átlagban aktívan.
-
bambano
titán
Megint ferdíted a témát. Az eredeti hozzászólás, amiről elkezdtem vitatkozni, azt állítja, hogy a dhcp szervert is konténerben kell futtatni. Azt, hogy nem kell mikromenedzselni a memóriát, nem én írtam. Mondjuk nekiállhatnék vitatkozni azon, hogy a jenkinst, ha kizárólag a memóriamenedzsment a kérdés, érdemes-e konténerben futtatni, mikor a jvm-nek is lehet pontos memória korlátokat szabni, de ezt a vitát már nem akartam megnyitni. Meg azt se, hogy a mikromenedzsmentes kérdést miért nem tudtad kontextusában helyesen értelmezni.
Egyébként aki szervíz hatása alatt prestashopot üzemeltet, az más gazságokra is képes
-
dabadab
titán
Nem lehet a docker compose az egyszerűbb, mert ahhoz kell docker, az alap oprendszerhez meg nem.
Az "apt install docker" kisebb plusz lépés, mint mondjuk bekonfigurálni egy adatbáziskapcsolatot. Vagy pl. mondd el, hogy szerinted az "egyszerűbb" megoldásnál hogyan lehet új gépre költöztetni egy wordpresst?
nem kell annyira mikromenedzselni a memóriát
Miért, dockernél miért kellene? Te milyen gyakran mikromenedzselsz memóriát konténereknél?
-
bambano
titán
Nem lehet a docker compose az egyszerűbb, mert ahhoz kell docker, az alap oprendszerhez meg nem.
Érdemes lenne afelé menni, hogy az ennyire nyilvánvaló evidenciákat nem próbáljuk hajlítani."Amúgy arra kíváncsi lennék, hogy milyen plusz erőforrásra van szükség egy konténer futtatáshoz.": #10-ben hangzott el először: "mivel annak van a legkisebb "resource overhead"-je és nem kell annyira mikromenedzselni a memóriát" .
A futtatás közbeni erőforrás többlet a legtöbb konténer/virtualizáció esetén tapasztalat és netes források szerint is már olyan kicsi, hogy, szerintem, tenni kell rá magasról.
-
dabadab
titán
Amúgy arra kíváncsi lennék, hogy milyen plusz erőforrásra van szükség egy konténer futtatáshoz
Nagyjából annyi, hogy a shared libek nem lesznek sharedek a különböző konténerek között, ez jár valami minimális plusz memóriahasználattal, ha futnak mindenféle szervízek a containerben (cron, ilyesmi), az is duplázódik, ilyesmik - igazából semmi komoly.
-
dabadab
titán
A ph!-n hozzászólók zöme windowsos, ahol, tudomásom szerint, nincs docker. Tehát nem ért hozzá.
Windowson van docker, apt viszont nincs
Egyébként pedig szoktam javasolni, hogy ne találgass arról, hogy a fórumtársad mit tud
Nem kell találgatnom, nagy betűkkel leírod, hogy fogalmad sincs róla
-
buherton
őstag
Ha a KISS-t nézzük akkor az én világomban a docker compose irány az egyszerűbb. A setup rész elsőre - talán - több energiát igényel, de után futtatni/upgradelni/hordozni/összelegózni mással sokkal egyszerűbb. Továbbá security szempontból is jobb a konténer.
Amúgy arra kíváncsi lennék, hogy milyen plusz erőforrásra van szükség egy konténer futtatáshoz. Komolyan kérdezem. A docker és a VM között a különbség a virtualizáció szintje. A VM esetén van Host és Guest (ami a VM-ben fut) OS, igen ez erőforrás igényes. Ezzel szemben a konténerizáció közvetlenül a host OS-en (linux kernel) fut és a virtualizáció "kimerül" a userekben, fs-ben, stb. Ez kb semmibe nem kerül. Hogy le kell tölteni az imageket?! Az apt-get is letölti a binárisokat...
-
bambano
titán
"Azt azért feltételezzük, hogy az ember ért dockerhez és fel van rakva": nem, ne feltételezzük.
A ph!-n hozzászólók zöme windowsos, ahol, tudomásom szerint, nincs docker. Tehát nem ért hozzá.
Másrészt még mindig egy házi szerverről beszélünk, nem egy multi bank kártyaelfogadó rendszeréről.Másrészt meg az, hogy ért-e hozzá vagy sem, annyit módosít a képleten, hogy neki mennyi olyan munkája lesz vele, amit megtanult korábban vagy nem, azon nem módosít, hogy bonyolultabb-e a rendszer, vagy sem. Ez pontosan ugyanaz az alaphelyzet, mint a win-lin vita, ahol hiába lenne egy rakás dolog linuxon egyszerűbb, az userek zömének van 20 év windowsos tapasztalata és 0 linux. Tehát neki akkor is egyszerűbb a win, ha több meló összekalapálni.
Egyébként pedig szoktam javasolni, hogy ne találgass arról, hogy a fórumtársad mit tud, próbált már ki, mihez ért. Zömében tévedés a vége.
-
petya220
senior tag
A mentéseknél is egyszerűbb szerintem a dolog.
Nem kell egy full os-t visszaállítani, ha valami szétmegy kísérletezés közben , hanem egy 1-2gb lxc-t.shadowkidhu: Azokat a WD Red-eket gondold át!
Nekem 4db, 4terrásom van, raidz1-ben.
1. Mocsok hangosak. (Gen8-as HP microserverben (ezt amúgy ajánlom egy jó xeon procival. )már minden ventit kicseréltem noctua-ra, hogy halk legyen, de a vinyók borzasztóak )
2. LassúakUtólag Seagate-t tennék bele.
-
#26
Speeedfire
félisten
dabadab
#25
Speeedfire
félisten
Hát ha tanulni akar, érdekli, és élvezi akkor persze.
De ha meg azt nézed, akkor lehet érdemes végig csinálni mindent a nulláról.
Rakjon fel egy debian minimal-t, rakjon fel egyesével minden appot, tanulja meg, hogy milyen beállítások vannak. Utána mehet docker alá 1-1 szolgáltatás, ha tényleg tudja, hogy mi hogyan és miért működik.Én fejlesztőként, meg 40+-osan már az egyszerűbb megoldásokat keresem.
-
#25
dabadab
titán
Speeedfire
#23
dabadab
titán
válasz
Speeedfire
#23
üzenetére
Persze fel lehet építeni ezeket "kézzel" pl ubuntu server os, vagy docker hub alól ollózva. De minek?
Miért ne? Ha ez tetszik neki meg érdekli, akkor csak hajrá, ahelyett, hogy a telefonját nyomkodná
-
dabadab
titán
Mondom, érdemes kipróbálnod.
Azt azért feltételezzük, hogy az ember ért dockerhez és fel van rakva (docker orchestration nem tudom, hogy jön ide, a compose már jó ideje alaprésze a dockernek) és nyilván pont annyira kell hozzá "megtanulni a docker összes hasfájását" mint amennyire ugyanerre szükség van az apt-nál egy sima apt-get install esetén. -
#23
Speeedfire
félisten
dabadab
#21
Speeedfire
félisten
Ezzel egyet értek, minden sw-t (pl microservice) docker alatt futtatunk, és egyszerű skálázni, meg külön hálózatot építeni hozzá.
Ott látom értelmét a docker-nek, ha tényleg "megszámlálhatatlan" szolgáltatás van.Viszont amire a srácnak kellene picit furának érzem. Neki kellene egy home nas, amire tök jó standalone rendszerek vannak.
Persze fel lehet építeni ezeket "kézzel" pl ubuntu server os, vagy docker hub alól ollózva. De minek?
FreeNAS? OpenMediaVault?Bár anno inkább dedikált nas-t vettem ezekre.
-
bambano
titán
Az teljesen kizárt, hogy egy apt-get install isc-dhcp-server és a konfig editálása "bonyolultabb" legyen, mint felrakni egy dockert, egy docker orchestrationt, megtanulni a docker összes hasfájását, majd egy composer-rel összerakni a dhcp szolgáltatást.
Azért tök jó, hogy nem javasoltad a poszternek, hogy egy dhcp szerver miatt rakjon fel egy legalább 5 node-ból álló kubernetes clustert, meg a három darab dhcp lease backupolásához egy enterprise backup rendszert, lto szalagokkal, robot mechanikával, aix alapú mentőszerverrel, nato top secret biztonsági szintre felhozott sufnival.
-
#21
dabadab
titán
Speeedfire
#19
dabadab
titán
válasz
Speeedfire
#19
üzenetére
BÁRMI, ami konténerben vagy VM-ben fut, egészen nyilvánvalóan fut egy "alap" OS-en is. Nem azért futtatják ezeket konténerben, mert csak úgy lehet, hanem azért, mert egy csomó dolog sokkal egyszerűbb így.
Elkülönülnek egymástól a szolgáltatások, sőt, egyáltalán át lehet tekinteni, hogy milyen szolgáltatások vannak, hogy ki mit használ, milyen file-ok tartoznak hozzá, ha költöztetni kell, akkor az nem macera, ha több példányban kell futattni, nem macera, ha dinamikusan kell skálázni, nem macera*.
*: jó, a dinamikus skálázás önmagában macera tud lenni, de a konténerek azért sokat segítenek -
bambano
titán
Tehát azt állítod, hogy például egy dhcp szerver futtatásához:
- az lxc konténer igényli a legkevesebb plusz erőforrást
- dockerben egyszerűbb telepíteni és futtatni, docker compose használatával.Azt elfogadom, hogy a *konténerek közül* az lxc igényli a legkevesebb plusz erőforrást, de futtatni az alap oprendszeren lehet legkevesebb erőforrással. Ugyanígy egy docker compose-zal összerakni és "'könnyen" üzemeltetni ahhoz képest, hogy apt-get install?
A nas meg kinek mit jelent? Nekem egy apt-get install nfs-kernel-server oszt jónapot, minek bonyolítani még?
Mégegyszer: virtualizálni (akár virtuális gépben, akár konténerben) akkor kell, ha biztonsági vagy szeparálási probléma/igény merült fel. Egyéb esetekben az alap oprendszeren futtatunk mindent.
KISS: Keep It Stupid and Simple.
-
#17
Speeedfire
félisten
Speeedfire
félisten
Én anno hasonló cipőben jártam, inkább vettem egy qnap nas-t. Mindent tud, ha kell kezeli a konténereket is.
-
bambano
titán
Tehát arra az állításra, hogy "amikor 8-10 vm-et kell hirtelen upgradelni.", kiemelem: VéééeeeeMMMMM-et, az a válasz, hogy "nem használtál konténereket"?????
De még ha ettől eltekintek is, úgy válaszoltál, mintha mindig minden upgrade sikeres lenne és soha nem akadna össze semmi semmivel... még olyan aprósággal se, hogy upgrade közben egyes debianos csomagok interaktívan rákérdeznek a változtatásokra... -
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.
-
dabadab
titán
Na mégegyszer: az egy teljesen rossz gyakorlat, hogy vm-eket meg konténereket használnak olyanra, amire az alap oprendszer való.
Az alapo oprendszer ilyen helyeken leginkább arra való, hogy konténereket futtasson
Majd képzeld el azt a pontot, amikor 8-10 vm-et kell hirtelen upgradelni. Azért nem érdemes se vm-et se konténert telepíteni, hogy legyen mit adminolni.
Ilyenkor látszik, hogy soha az életben nem használtál konténereket, azért nem értem: ez egyetlen sor, nulla interakcióval, ha kell, berakhatod crontabba is.
-
dabadab
titán
Én csak azért írok ide, hogy erősen bólogassak ROGERIUS kolléga tanácsaira.
Az erőforrásos dologhoz még annyit hozzátennék, hogy itt a háztáji szerveren (ami eleve egy hostolt VM) van 8 GB RAM, fut rajta 12 konténer (wordpress, prestashop, wikijs, SVN, victoriametrics, mittomén) és a memória fele még üresen van. -
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. -
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.
-
buherton
őstag
Személy szerint az alábbiakat javaslom azzal a felkiáltással, hogy szerintem még nem tisztázódott le benned, hogy mit is szeretnél.
Először is erősen javaslom, hogy Linux only legyen a setup még hozzá GUI nélkül. A GUI egy-egy esetben lehet jobb a CLI-al szemben, de erre az appok tipikusan adnak webes felülelet, lásd Proxmox, Jenkins, stb. Ráadásul a GUI csak nyűg és viszi az erőforrást.
Home serverhez mini-ITX alaplapot javaslok. Szerintem fontos a méret és tök jó dolog tud lenni, ha kicsi a gép és el lehet rakni, ahol nincs szem előtt. Személy szerint valami ilyesmit javaslok: [Topton N18] vagy [ROCK 5 ITX].
Szerintem teljesen felesleges napjainkben VM-eket futtatni, a világ a konténerizáció felé ment el. Személy szerint javaslom, hogy minden appod konténerben fusson.
Gitet szerintem nem érdemes lokál szerveren futtatni a GitHub mindent tud.
-
#7
shadowkidhu
újonc
Köszönöm a konstruktív hozzászólásokat és az ötleteket!
Annyival kiegészíteném a virtualizációra való fixációmat,hogy az itthoni laborral az is a célom, hogy egy vállalati infrának különböző elemeit illetve azok közötti kapcsolatát tudjam gyakorolni (a média szerver és a NAS-on kívül). -
bambano
titán
Szerintem vm-et marokszám az üzemeltessen, aki meg akarja tanulni a vm-eket, hogy esetleg később fizetős melóban használja. Otthon, különösebb biztonsági igény nélkül, értelmetlen.
Ráadásul a vm vagy a konténer egy plusz réteg a rendszerben, amiben lehetnek hibák. Na azt debuggold ki...Minek futtatnék opnsense tűzfalat? Ami tűzfal szabály egy otthoni rendszerben kell, azt beleírom a debian init szkriptjébe oszt jónapot. Ha nincs fizetős opnsense meló (a láthatáron se), akkor nem kell opnsense. Proxmox dettó, úgysem fogsz hot backup proxmox clustert építeni, mert azt egy gépből nem lehet, tehát amit a proxmox alapból tud a sima kvm-hez képest, az itt offtopic. Akkor minek proxmox? Hogy legyen még egy webes felület, ahol az okleveles kettősklikkelő kiélheti magát?
Ahogy itt a fórumokat látom, teljesen elszálltak az architekturális kérdésekre adott válaszok.
-
#5
bambano
titán
shadowkidhu
#2
bambano
titán
válasz
shadowkidhu
#2
üzenetére
Na mégegyszer: az egy teljesen rossz gyakorlat, hogy vm-eket meg konténereket használnak olyanra, amire az alap oprendszer való.
Majd képzeld el azt a pontot, amikor 8-10 vm-et kell hirtelen upgradelni. Azért nem érdemes se vm-et se konténert telepíteni, hogy legyen mit adminolni.Amit leírtál, az kb. egy alap debian. Erre ráhúzol egy libkvm-et azoknak a vm-eknek, amiken tesztelsz, rodeózol, és slussz.
-
A RAM kérdésben csatlakoznék a kollégához: parancssoros Linux VM kifuthat 2GB/VM körül (kalandvágyóknak: 1GB + barebone funkcionalitás; tesztelni elég pl. connectivity, etc.), de GUI-s Linux is megkéri a legalább 4GB memóriát és 2 magot, hogy érdemben reszponzív legyen. A CPU időt a hypervisor tudja ütemezni, így tehetsz 20 VM-et is akár a 8 magra, legfeljebb esnek-kelnek egymáson, és nem fognak kapkodni közben; ellenben még ha dinamikusra is állítod a mermória menedzsmentet (pl. range: min 2GB, max 4GB), amit a VM egyszer már allokált magának a 'burkában', azt a hypervisor már nem tudja (fogja) elvenni.
Ugyanakkor abban nem értek egyet, hogy nem érdemes VM-be csomagolni: szerintem mindent, ami egy szolgáltatás csomagként operál, érdemes egy-egy különálló VM-be tenni: kompartmentalizáció. Utána mind a change/modify/replace, mind a backup/restore is könnyebb, példa okáért: OPNsense 'routert' (sic!) futtatsz és valami megcsúszik benne - akarsz hibát keresni? Igen -> go for it. Nem -> importálsz/onboard-olsz egy exportált 1:1 (biztonsági) másolatát annak a VM-nek és mész tovább. ...és nagyban is igaz ez a VM-ek összességére, ha megcsuklik a kemény vas az egész hóbelevanc alatt.
-
SutPet
aktív tag
Ha plex akkor érdemes intel felé nézelődni a quicksync miatt és nem kell külön vga. Én nemrég álltam át épített xpenology-ról (régi atom D510). Az új tomtop intel n6005-el valamiért egyik loader se akarta megenni így maradt proxmox vagy truenas. Mivel proxmoxom van máshol itthoni célra meg jó kisérletezni ezért truenas scale-re esett a választás, 16g-rammal a plex + *arr stacket gondnélkül viszi konténerből. VM-et csak 2-t próbáltam rajta 4-4gb rammal az vígan elment.
Az egyéb felépítés nálam: 256 nvme a rendszernek, 512 nvme az appoknak, 2*20TB media, 4*2tb mentéseknek.
Az én usecase-emhez döcögősen az atom is elég volt(oracle db- azért nem hasított annyira...), a váltás csak azért történt mert plex transcode-ot egyáltalán nem bírt és szembejött a jóáras lap és elméletben még kevesebbet is fogyaszt (d510 13w, n6005 10w). -
#2
shadowkidhu
újonc
bambano
#1
-
bambano
titán
Egyrészt 10 rendesebb vm nem fog elfutni 32 giga ramon.
Másrészt teljesen felesleges olyan dolgokat vm-be rakni, ami nem igényli. Ami állandóan kell, az az alap oprendszeren fusson.
VM-be azokat a kísérleti dolgokat érdemes tenni, amint felraksz, összegányolsz és letörölsz másnap.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
vagy rá...
"
.
Új hozzászólás Aktív témák
lo Sziasztok,Az első SFF otthoni szerverem építése előtt állok, és az alábbi eseteket fedném le vele:-VPN,DNS,DHCP, Proxy...
- AMD Navi Radeon™ RX 6xxx sorozat
- BestBuy ruhás topik
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Parfüm topik
- Autós topik
- Vezetékes FEJhallgatók
- Milyen notebookot vegyek?
- Samsung Galaxy S23 Ultra - non plus ultra
- DUNE médialejátszók topicja
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- További aktív témák...
- Több mint 70.000 eladott szoftverlicenc
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RTX 4070Ti Super GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB DDR5 RTX 4070Ti Super GAMER PC termékbeszámítással
- AKCIÓ! Dell Latitude 5440 14 FHD üzleti notebook - i5 1335U 8GB RAM 256GB SSD Intel Iris Xe
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest