Hirdetés
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Apple asztali gépek
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- 3D nyomtatás
- TCL LCD és LED TV-k
- Hogy is néznek ki a gépeink?
- Új tokozással jön az Arrow Lake utódja?
- Gigantikus leépítéssel építené újra az Intelt a cég új vezére
- Milyen TV-t vegyek?
Új hozzászólás Aktív témák
-
#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
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?
-
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
-
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úak![;]](//cdn.rios.hu/dl/s/v1.gif)
Utó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.
-
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.
, hanem egy 1-2gb lxc-t.![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
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...
- Samsung Galaxy A56 - megbízható középszerűség
- Clair Obscur: Expedition 33 teszt
- Nintendo Switch 2
- A fociról könnyedén, egy baráti társaságban
- Kerékpárosok, bringások ide!
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Prohardver app (nem hivatalos)
- Synology routerek
- Opel topik
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- További aktív témák...
- iKing.Hu - Apple iPhone 15 Pro Max - White Titanium - Használt, karcmentes
- UHH! Lenovo Yoga 9i x360 Érintős Hajtogatós Laptop Tab 14" -60% i7-1280P 16/1TB Iris Xe 4K UHD OLED
- Asus Tuf Gamer PC. AMD Ryzen 5 3600/GTX 1080 Ti 11 Gb/16 Gb DDR4/500 Gb M2
- Canon EOS 200D gépek, objektívekkel, kiegészítőkkel. (3870 vagy 42200 expoval)
- Xbox 360 E 500 GB Konzol Fekete
- LG 34WK95U-W - 34" NANO IPS - 5120x2160 5K - DCI-P3 98% - HDR 600 - ThunderBolt 3.0/Type-C
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- HDMI 2.1 8K 60Hz - 10 méter hosszú
- ÁRGARANCIA!Épített KomPhone i5 12400F 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- 14" Dell Latitude laptopok: 5400, 5480, 5490, 7480, E7440, E7450 / SZÁMLA + GARANCIA
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest