Hirdetés
- GoodSpeed: Te hány éves vagy?
- Toomy: FOXPOST: régen jó volt, de már jobban jársz, ha elfelejted
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- gban: Ingyen kellene, de tegnapra
- Klaus Duran: Minden drágul. Vajon a fizetések 2026-ban követi minimálisan?
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- eBay-es kütyük kis pénzért
- D1Rect: Nagy "hülyétkapokazapróktól" topik
Új hozzászólás Aktív témák
-
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á... -
"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.
-
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.
-
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.
-
-
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
-
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.
-
"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.
-
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.
-
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.
-
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... -
A másik téves mítosz, amit nem értek, hogy linuxon grafikus alkalmazás futtatásához grafikus környezet kell a gépre.
NEM KELL.
A grafikus alrendszer arra a gépre kell, AMIN NÉZED.
A linux rendes hálózattranszparens grafikus alrendszerrel rendelkezik. -
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
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.
-
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
- Milyen légkondit a lakásba?
- Autós topik
- Milyen egeret válasszak?
- Aktiválható a DLSS 4.5 az új GeForce driverrel
- Kerékpárosok, bringások ide!
- CES 2026: felcsavarta az AI-t az AMD, de örülhetnek a játékosok is
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Kertészet, mezőgazdaság topik
- exHWSW - Értünk mindenhez IS
- Telekom mobilszolgáltatások
- További aktív témák...
- ÚJ Bontatlan Apple Macbook AIR M2 , M3 , M4 Legújabb magyar billentyűzet 1 év Garancia Deák Térnél.
- AKCIÓ ÚJ Bontatlan Macbook Pro 16 M4 Pro 14CPU/20GPU 24GB/512GB SSD Magyar billent Azonnal átvehető.
- AKCIÓ ÚJ Bontatlan Macbook Pro 14 M4 MAX 14 32GPU 36GB 1TB Magyar billentyűzet Azonnal átvehető Deák
- AKCIÓ ÚJ Bontatlan Macbook Air 13,6 M4 10CPU/10GPU 16GB/512GB SSD TOUCH ID - Magyar Azonnal Deák tér
- Apple iPhone 16 Pro MAX 256Gb, White Titan, Makulátlan állapotban, kártyafüggetlen, 3év , 100% akku
- GYÖNYÖRŰ iPhone 13 Pro 256GB Graphite -1 ÉV GARANCIA - Kártyafüggetlen, MS3074
- 160 - 177 - 178 - Lenovo LOQ (15IRX9) - Intel Core i7-13650HX, RTX 4060 (ELKELT)
- iPhone 14 128GB 100% (GARANCIÁBAN CSERÉLT)
- LG 27MR400 - 27" IPS LED - 1920x1080 FHD - 100hz 5ms - AMD FreeSync - Villódzásmentes
- HP EliteBook 850 G7 (15.6") i5-10310U - Garancia, Akció!
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest