Sziasztok,
Jelenleg úgy dolgozunk, hogy van egy dedikált gép, Windows Server oprendszerrel, amire bejelentkezünk AD (vagy Entra) userrel. Eddig egész használható volt, viszont egyre többen vagyunk rajta és van, hogy kifogy a gép az erőforrásból. Milyen alternatívák vannak most a "kérjünk bele több vasat" opció mellett? Volt szó korábban Azure Devbox megoldásról, de annak még utána kell mennünk, hogy hogyan működik.
Nem szeretnénk mindenkinek külön VM-et létrehozni, mert annak meg a licenszelése húzós, illetve azokat a gépeket üzemeltetni is kell, ami szintén plusz költség.
Tehát a kérdés: mi a legjobb ár/érték arányú megoldás 10-20 fő fejlesztő esetén, ami még gazdaságosan is üzemeltethető, cserébe kapunk egyforma gépeket (szofterek és minden más tekintetében).
- 1419 megtekintés
Hozzászólások
Ha az adott CPU+RAM+IOPS "elfogy" x főnél, akkor arra két megoldás van. Az egyik, hogy ami elfogy abból többet adni, vagy ami elfogyasztja,azt csökkenteni. Ez utóbbi persze csak elméleti lehetőség :) úgyhogy szerintem nincs más hátra, mint előre: egy új ts, és célszerűen connection brokerrel menedzselni, hogy mikor hova essen be a user.
- A hozzászóláshoz be kell jelentkezni
Az a bajom a terminal server-rel, hogy bármelyik user elveheti az erőforrásokat mások elől. Igazából ezt szeretnénk eliminálni.
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
TS esetén olyanról nem tudok, hogy lenne RAM/CPU limitre lehetőség per session... Tudod: közös ló... :)
- A hozzászóláshoz be kell jelentkezni
Azért ez így nem teljesen igaz. Igen tudom h. VM, Hyperv-n belül pl. van lehetőség CPU-t limitálni windows server 2016 óta, ezzel lehet kontroll alatt tartani ha több user vandálkodik párhuzamosan.
WS2012-ig volt Windows System Resource Manager, azzal lehetett CPU, RAM, IO limiteket beállítani.
- A hozzászóláshoz be kell jelentkezni
Miért kell terminál szerveren fejleszteni?
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
Lehet DLP az ok, de lehet az "olcsón egyszerűen üzemeltethető infra" is...
- A hozzászóláshoz be kell jelentkezni
És az is kiváló, amikor összefossa magát valami, vagy pl. egy frissítés után gondol egyet valamelyik ki*aszott rdp szolgáltatás, és nem indul el, és senki nem tud belépni - még te se adminként....
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
Gondolom, mert távolról dolgozik a csapat, és a leírásból ítélve nem rendelkeznek eszközmenedzsmenttel, szóval semmi se garantálja, hogy Pisti saját vásárlású dev gépén nincs valami jó kis malware. Plusz nem szeretnék a devkörnyezet mindenét is kirakni a netre. De csak találgatok.
A terminálszerver nem csodafegyver, de nem rosszindulatú felhasználók esetén azért ad némi biztonságot (forráskód, szenzitív infók egy gépen maradnak, és nem 10-20 laptopon szétszórva.
- A hozzászóláshoz be kell jelentkezni
Mert senki sem szeretne +1 laptopot cipelni magával. Így könnyen megoldható, hogy az adott ügyfél domain-jében, az általa biztosított domain userekkel elérjük az erőforrásokat.
- A hozzászóláshoz be kell jelentkezni
No igen, erre nem is gondoltam, ha vállalkozóként dolgozik be a csapat egy része.
- A hozzászóláshoz be kell jelentkezni
Mindenképp növelned kell az erőforrások mennyiségét. És ez pénzbe fog kerülni.
A TS/RDS nem a legjobb megoldás fejlesztőknek. Ahol eddig megfordultam, ott mindig dedikált VM-ket kaptak a fejlesztők. És azok a VM-k mindig onprem infrán futottak biztonsági okokból.
Elmehetsz akár per user VM irányba is. A VM-eket már egyszerűbb limitálni (cpu, ram, iops). Ez súlyos pénzekbe kerülhet már csak a licenceköltségek miatt is.
Esetleg megnézheted az alternatívákat is (pl: Citrix VDI, Parallels RAS).
Ha a felhő / Azure támogatott nálatok, akkor 1 nap alatt össze lehet kattintgatni az infrát, ami skálázódik. Pl: leállnak a nem használt VM-k, elindulnak, ha kell stb.
Azure Devbox: 8 vCPU, 32 GB RAM, 1024 GB Storage maximum ~211 USD/hó/instance.
Van VSTS / Visual Studio előfizetésetek? Milyen? Mert lehet, hogy a benne kapott kreditekből minimális havi plusz költség mellett lehetne a teljes Devboxot kifizetni. Konkrétan a Business - Enterprise subscription-ra gondolok.
- A hozzászóláshoz be kell jelentkezni
Kérdés az, hogy ez hozza-e egy normális fejlesztői laptop sebességét, illetve milyen az ár-érték arány.
- A hozzászóláshoz be kell jelentkezni
#define fejlesztői laptop ...
Elég sok olyan laptopot láttam már fejlesztőknél, amiket ha normálisan megküldesz, akkor throttlingol a hőtermelés miatt.
A laptopot CPU terhelő fejlesztéshez nem tartom optimálisnak.
- A hozzászóláshoz be kell jelentkezni
Nálunk a srácok kimaxolt m2-es macbook pro-kat használnak, nem igazán volt még vele problémájuk :D
- A hozzászóláshoz be kell jelentkezni
Mindenképp növelned kell az erőforrások mennyiségét. És ez pénzbe fog kerülni.
Ez ennyire egyszerű :)
Látod, mégis sokan 10-20 modern, enterprise szintű laptop teljesítményét várják egy - azaz egy darab - szuttyadt windows szervertől :D
Ha csak a szükséges RAM mennyiséget összeszámolnák ennyi fejlesztőre... látni lehetne, hogy hol a hiba.
szerintem.
- A hozzászóláshoz be kell jelentkezni
Még a RAM mennyiségével nem is lenne akkora baj. Ha kell, akkor 2-4 TB memória is rakható egy szerverbe.
Ami a nagyobb gond szerintem az a memória sávszélesség. Hiába a 10+ GT/s, ha azon 20 fejlesztő (heavy user) felhasználó osztozik.
- A hozzászóláshoz be kell jelentkezni
es a registered ramos tobb procis megoldasok amugy se a nagy ram savszelessegrol hiresek... par eve tesztelgettuk es egy sima ddr4 ramos desktop gep joval gyorsabb ram elerest tudott mint az uj 6 millios hp szerver...
- A hozzászóláshoz be kell jelentkezni
Hiú ábránd azt gondolni hogy "a felhőben másképp van". Pont ugyanígy van csak nem teszik ki az asztalra.
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Ez így van. Csak a kedves "okosok" azt gondolják, hogy a felhő mindent megold. Hát nem.
- A hozzászóláshoz be kell jelentkezni
Te tudsz valamit... :-)
- A hozzászóláshoz be kell jelentkezni
Esetleg a pontos igényeket, hogy miben fejlesztenek, mit használnak? Mivel csatlakoznak a szerverre? Azok a gépek nem lennének alkalmasak a fejlesztésre? A szervert meghagyni csak központi repónak, esetleg mellé egy VSCode szerver vagy hasonló?
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"
- A hozzászóláshoz be kell jelentkezni
Azure Virtual Desktop vagy AWS Workspaces.
- A hozzászóláshoz be kell jelentkezni
Ha mehetnek a felhőbe... De azt nem mindenki teheti meg.
- A hozzászóláshoz be kell jelentkezni
VDI, devcontainer megoldások több gyártónál is vannak on-prem.
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy csak en ulok forditva a lovon, de egy ilyen uzletileg kritikus es eleve tulterhelt eszkozt en megduplaznek.
Ha lenne belole ketto, akkor normal uzemben terheleselosztasban mukodhetnek, es mindenki boldog.
Amikor pedig az egyikben megpukkad az alaplap, akkor a masikon mehet tovabb a kritikus melo, esetleg korbe lehet egyeseknek telefonalni, hogy gyerekek, havaria helyzet van, legyszives ne lepjetek be, mert most csak a tenyleg fontos munkafolyamatok engedelyezettek, commentek javitasa miatt senki ne foglalja a memoriat.
Vasbol biztosan tobb kene. Hogy milyen SW fusson rajta, az mar mas kerdes, hiszen annak kompatibilisnek kell lennie a fejlesztokornyezettel es a kiegeszito seged szoftverekkel egyarant, plusz licensz kerdes, plusz tobb peldanyban futtathatosag, stb.
- A hozzászóláshoz be kell jelentkezni
Mi az oka annak hogy terminal server-t használtok fejlesztéshez, és nem normális fejlesztői gépeket?
- A hozzászóláshoz be kell jelentkezni
Feltételezem, h így bárhonnan belépve távolról megvan ugyanaz a környezet. Nálunk legalábbis ez az oka.
- A hozzászóláshoz be kell jelentkezni
Mármint IDE, pluginek és egyéb toolok?
- A hozzászóláshoz be kell jelentkezni
Csak a saját melóhelyemből tudok kiindulni, mi nem fejlesztünk helyben semmit. De nekünk így pont jó.
- A hozzászóláshoz be kell jelentkezni
Ehhez nem TS valo, van ra tobb jo megoldas is.
- A hozzászóláshoz be kell jelentkezni
Sem az architektúráról sem a fejlesztési módszertanról nem tudunk semmit, anélkül én nem mondanék véleményt.
Emlékeimben él olyan korszak amikor "ezt kellett csinálni", nem volt az rossz.
Egyáltalán nem vagyok meggyőződve hogy a ma oly divatos "microservice, ci/cd, scrum" lenne az egyetlen és üdvözítő út.
Arról nem beszélve hogy ha ezt az "ugrást" most kéne megtenniük - annál még a 2x nagyobb gép megvétele is sokkal olcsóbb.
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Egyáltalán nem vagyok meggyőződve hogy a ma oly divatos "microservice, ci/cd, scrum" lenne az egyetlen és üdvözítő út.
Bevallom, nem ertem, hogy ennek mi koze van ahhoz, hogy TS-en dolgoznak-e fejlesztok, de oke. TS-en nem lehet microservice-t fejleszteni? :)
- A hozzászóláshoz be kell jelentkezni
Ha van egy vedett belso kornyezetuk, akkor azt konnyebb ugy megvedeni hogy csak az RDP van engedelyezve a tuzfalon befele iranyba.
A benti internet eleres pedig lehet feherlistas. Ezekben a ransomwares idokben megeri paranoidnak lenni, nekem legalabbis ezt mondjak a hangok.
- A hozzászóláshoz be kell jelentkezni
csak az RDP van engedelyezve a tuzfalon befele iranyba
Ez viccnek is rossz. Legalább egy VPN kellene elé.
- A hozzászóláshoz be kell jelentkezni
nem VPN, hanem RDS gateway, és sima https-n keresztül megy az RDP publikációja
- A hozzászóláshoz be kell jelentkezni
Ha bérelsz egy windows vps-t, akkor default porton kirakják a netre. De ha feljebb teszed a portszámot jóval, akkor gyakorlatilag már senki sem találja be. Vagy huszon pár windowsos vps-ünk van a rackforesttől bérelve, még senki nem jött be rdp-n keresztül rájuk.
- A hozzászóláshoz be kell jelentkezni
Még
- A hozzászóláshoz be kell jelentkezni
Ja, mondjuk ez akár jogos is lehet. :)
- A hozzászóláshoz be kell jelentkezni