- A hozzászóláshoz be kell jelentkezni
Hozzászólások
A szavazas szempontjabol chroot containernek szamait,
ha csak modjuk network namespace van izolalava az nem.
Nem linux rendszerknel ami kulombozo rootfs nezetet add az ide tartozik,
de a full/para virtulizacio nem.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Eddig minden termekunk nativ, folyamatban vannak a fejlesztesek, hamarosan minden cuccunk konteneres felhos bizbaszra lesz konvertalva. Legalabbis ez a terv. :)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods
- A hozzászóláshoz be kell jelentkezni
Mit kell jelölni, ha _pontosan_ 90%? :)
---
"A megoldásra kell koncentrálni nem a problémára."
- A hozzászóláshoz be kell jelentkezni
Le kell ülni, átgondolni az életünk minden eddigi percét, legyinteni egyet és rácsapni a >90%-ra, azzal a felkiálltással, hogy ezt is elcsesztük. :D
Vizsgára felkészülés végett keresek "kidobásra" szánt menedzselhető Cisco switch-eket és routereket, leginkább Pest és Bács-Kiskun megye területén.
- A hozzászóláshoz be kell jelentkezni
...és nem eladni több halálpálcát :)
--
Where do you want to go today?
[nobody@salcay:~]$_
- A hozzászóláshoz be kell jelentkezni
hoppsz >=90 kene valoban .
Kosz review-ot.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Jártam úgy, hogy valami oknál fogva az adatbázisban volt egy varchar és egy blob, ugyanarra a logikai mezőre. Ha a szöveg kisebb volt, mint 2000 karakter, akkor ment a varchar mezőbe, ha nagyobb, akkor ment a blob mezőbe. A hibát pedig napokig kerestem, hogy miért nem mentődik le ritkán a küldött adat. A kód szerzőjének egész családfája csuklott szerintem, amikor megtaláltam. :)
- A hozzászóláshoz be kell jelentkezni
A JavaEE konténer is konténernek számít? :)
- A hozzászóláshoz be kell jelentkezni
A csontvázak maradjanak a szekrényben inkább :)
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
- A hozzászóláshoz be kell jelentkezni
Nem csontváz az, csak jól kell használni. Az igényteleneknek pedig ott van a Spring. :)
- A hozzászóláshoz be kell jelentkezni
https://tenor.com/view/supa-hot-fire-black-guys-roasted-take-that-black…
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
- A hozzászóláshoz be kell jelentkezni
touché xd
- A hozzászóláshoz be kell jelentkezni
miért igénytelen a spring? (komolyan kérdem nem értek hozzá)
- A hozzászóláshoz be kell jelentkezni
Próbálj meg mondjuk egyszer két - nem egy JVM-ben futó - Spring processz esetén tranzakciót kezelni.
- A hozzászóláshoz be kell jelentkezni
Nem, OS virtualzacio a kerdes.
Ha jol remlik extra shielding nelkul a java containerek latjak a full fs -t.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Honnan tudjam? Azt se tudom, hogy milyen szolgáltatásokra gondolt a költő.
[x] Csak az eredmény (se) érdekel.
- A hozzászóláshoz be kell jelentkezni
Amiket te/csapatod/céged fejleszt/üzemeltet.
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
- A hozzászóláshoz be kell jelentkezni
Továbbra is csak az eredményre vagyok kíváncsi.
Azt tudom, hogy a csapatom mit fejleszt, de azt már nem, hogy ez hogyan kerül productionbe.
Fogalmam sincs, hogy a cég mi egyebeket fejleszt, vagy üzemeltet.
- A hozzászóláshoz be kell jelentkezni
Jó sok karaktert elpazarolsz arra hogy kifejtsd hogy az egészről nem tudsz semmit meg nem is érdekel a szavazás :)
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
- A hozzászóláshoz be kell jelentkezni
A beanstalk kontener? :)
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
- A hozzászóláshoz be kell jelentkezni
Mi nem javasoljuk, hogy az altalunk fejlesztett termeket kontenerben futtassak, sot az optimalis ha a VM-et is mellozik es a vason fut.
Ezzel egyutt halvany lilam sincs, hogy a telepitett bazis hany szazaleka fut kontenerben, van aki ragaszkodik hozza.
--
:wq
- A hozzászóláshoz be kell jelentkezni
ami ugye 2018-ban eleg baromsag, ha meg mi is tudjuk a Db2-ot kontenerben adni...
- A hozzászóláshoz be kell jelentkezni
Mi ennek az oka? Inkább adtok setup exét meg egy 26 oldalas útmutatót?
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
- A hozzászóláshoz be kell jelentkezni
Miért nem javasoljátok?
- A hozzászóláshoz be kell jelentkezni
Ide valaszolok, de az elozo ket hozzaszolasra is reagalnek mert kb ugyanaz a kerdes maskent megfogalmazva.
Azert nem javasoljuk mert termek amit fejlesztunk (NoSQL adatbazis) ugy van felepitve, hogy kisajatitsa a rendszert es a maximalisat facsarja ki a vasbol.
A rendszer eroforrasai fel vannak osztva X szal (thread) kozott. X = a processzormagok szama. Minden szal kisajatit egy processzormagot es egy egyenlo szeletet a memoriabol, figyelunk arra, hogy ez a szelet ugyanahhoz a NUMA regiohoz tartozzon mint a processor mag. A halozati es I/O megszakitasok (interrupt) szinten el vannak osztva a magok kozott, ahogy az I/O queue-k is. A szalak egymassal csak explicit lockless queue-n beszelnek. Nem hasznalunk OS page cache-t, sajat CPU es I/O utemezonk van.
Namarmost ezek utan ha az eroforrasokert versenyezni kell N masik kontener tartalmaval, akik random CPU magrol kiutemezik a mi szaljainkat, raadasul osszeszemetelik a cache-t, akkor ez az egesz nem tul hatekony, sot ertelmetlen.
Talan most mar a Docker megengedi, hogy kisajatitsd a CPU magok egy reszet a kontener szamara, de akkor is sokkal jobb ha a vason fut a program.
--
:wq
- A hozzászóláshoz be kell jelentkezni
lockless ?
https://software.intel.com/en-us/forums/intel-moderncode-for-parallel-a…
Az atomic opoc mintha LOCK nevu prefixet szeretnek.
Szerk:
Ahh, hogy minden core-nak megvan a maga memoriaja..
ha minden thread csak ugyan azon core-n megy akkor talan lehet trukozni ..
de akkor meg minek .. epoll() or epoll()+signalfd()+aio() lassu disknel...
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
A lockless-t altalanossagban ertem, nem hasznalunk semmilyen szal-szinkronizacios primitivet [1].
Igen, minden szalnak megvan a privat processzormagja es memoriatartomanya.
Tudtommal nem hasznalunk epoll-t, io_submit()-ot es io_getevents()-et hasznalunk [2].
A lassu disk nem javasolt. :) NVMe SSD a recommended.
[1] https://www.scylladb.com/2018/02/15/memory-barriers-seastar-linux/
[2] https://www.scylladb.com/2017/10/05/io-access-methods-scylla/
--
:wq
- A hozzászóláshoz be kell jelentkezni
az aio-nak szamit, es lehet hogy neked az NVMe is lassunak szamait.
Az egyik cikk emliti az epoll_wait -et .
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Bevallom nem teljesen tiszta, hogy pontosan milyen kernel API-t hasznalunk I/O-ra. Abban biztos vagyok, hogy aszinkron I/O-t hasznalunk es DMA-val olvasunk/irunk. Nemregiben is reszelgettek ezen a reszen. Lasd https://lkml.org/lkml/2018/7/26/203 .
--
:wq
- A hozzászóláshoz be kell jelentkezni
aio legutobb akkor kerult elo amikor egyetlen interpreted processzel akkart
valaki kihajtani egy spinert (tobb spinner egy gepben RAID nelkul).
De ha tenyleg gyors nativ kodrol van szo, es par szaz thread-el nem oldhato meg,
akkor valoszinuleg jo az aio.
Mindenki DMA enginnel ir/olvas (bus mastering), PCIe -en bolondsag lenne maskep.
PCIe egy soros, csomag orientalt halozat, csak akkor erdemes megkerulni
dma-t, ha tenyleg csak egy par regisztert akkarsz atbillenteni.
'PCI-E Maximum Payload Size 4096'
Szerk:
NVMe -nek van egy fura anomaliaja, ami miatt par szaz thread nem felteten oldja meg problemat.
https://www.flashmemorysummit.com/English/Collaterals/Proceedings/2017/…
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Mivel mi cooperative multitasking-ot hasznalunk (sajat coroutine stack) ezert csak az AIO johet szoba, ha thread-pool-okkal dolgoznank akkor, az a sok munka amit abban fektettunk, hogy minimalizaljuk a context switch-eket es a szalkozi szinkronizaciot, mind karba veszne.
--
:wq
- A hozzászóláshoz be kell jelentkezni
ugy latom elegge a NIH szindromaban szenvedtek... :)
- A hozzászóláshoz be kell jelentkezni
Egyaltalan nem. Amit csak lehet konyvtarakbol hasznalunk. De ha maximum teljesitmenyt akarsz akkor vannak dolgok amiket magad kell megoldj, mert a meglevo megoldasok tul altalanosak ahhoz, hogy megfeleljenek (pl. page cache).
--
:wq
- A hozzászóláshoz be kell jelentkezni
lehet tudni a termek nevet?
--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol
- A hozzászóláshoz be kell jelentkezni
Bocs, azt kifelejtettem: Scylla.
Github: https://github.com/scylladb/scylla
Weboldal: https://www.scylladb.com/
--
:wq
- A hozzászóláshoz be kell jelentkezni
Mennyire vagyok kocka, ha a leírásodból ez ugrott be rögtön? :) (Anno Avi előadása nagyon érdekes volt erről).
El tudsz többet árulni arról, hogy mivel foglalkozol a csapatban?
- A hozzászóláshoz be kell jelentkezni
"Mennyire vagyok kocka, ha a leírásodból ez ugrott be rögtön? :) (Anno Avi előadása nagyon érdekes volt erről). "
:D
"El tudsz többet árulni arról, hogy mivel foglalkozol a csapatban?"
Persze. A fejlesztes egy publikus email listan zajlik [1], nyilvanos, hogy ki mivel foglalkozik.
En legfokeppen az olvasasok (lekerdezesek) hatekonyabba tetelevel foglalkozok, a munkam nagy resze a storage layer-t erinti. Legutobbi nagy munkam a lapozas (paging) hatekonyabba tetele volt. Egy blogpost is keszult rolla [2], a masodik resz is jon nemsokara.
[1] https://groups.google.com/forum/#!forum/scylladb-dev
[2] https://www.scylladb.com/2018/07/13/efficient-query-paging/
--
:wq
- A hozzászóláshoz be kell jelentkezni
Na es sikerül már megszorongatni a Cassandrát? :)
- A hozzászóláshoz be kell jelentkezni
A megszorongatas eros tulzas ezen a ponton. De mar tudnak rolunk, "felkerultunk a terkepre".
--
:wq
- A hozzászóláshoz be kell jelentkezni
Fasza dolog ez a scylla. Cassandránál nagyon sok problémánk volt abból, hogy Javában van írva. Elsősorban a heap + gc limitációi miatt. Ez a C++ átírás szerintem kifejezetten jót tesz neki, bár élesben még nem próbáltam.
- A hozzászóláshoz be kell jelentkezni
Az arányok alapján úgy érzem hogy vagy a szolgáltatás vagy a konténer fogalma nem eléggé tisztázott. Én valahogy úgy vártam volna, hogy a 90+% lesz a nagy többség.
- A hozzászóláshoz be kell jelentkezni
Igazabol arra voltam kivancsi, hogy milyen gyorsan halad hype train,
attol meg hogy mi folyik a csapbol, valami nem lesz elterjedt.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Én 2015 elejétől fogva alkalmazom különböző projektekhez csapódva a dockert (pénzügy/bank, gyártás/kereskedelem, illetve e-commerce), illetve a beanstalkot (ami nem tudom hogy belefér-e a konténer fogalmába.. igazából sorozatgyártott EC2 instance lesz belőle, előre gyártott körítéssel, viszont az user szempontjából nézve ő egy alkalmazást tölt csak fel, szóval a franc tudja).
Szóval szerintem terjed az, maximum a meglevő illetve legacy rendszerek esetén vontatott az átállás. Voltam olyan bankban ahol sok erőfeszítést tesznek a dockerre áttéréshez, de több évet jósoltak tavaly a befejezésre.
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead
- A hozzászóláshoz be kell jelentkezni
EC2 instance nem tartozik ide, megha strategia ugyan az is mint a dockerrel. " de a full/para virtulizacio nem."
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Konténert pont nem használunk, PaaS meg VM van. A konténeres megoldás vagy nem elég managelt, vagy nem ad hozzá annyit, amennyivel drágább sima vm-eknél.
- A hozzászóláshoz be kell jelentkezni
dragabb?
- A hozzászóláshoz be kell jelentkezni
Még 0, de erősen érik, hogy elkezdjük becsomagolgatni a komponenseket (leginkább python package-ek miatt. pl setuptools 20 (xenial apt) vs 40 (pip)).
- A hozzászóláshoz be kell jelentkezni
A dev környezetben mindenünk kb. containerben fut, éles renszeren az ügyfél a saját infráján úgy szopatja magát, ahogy a kedve szottyan. :)
- A hozzászóláshoz be kell jelentkezni
Tételezzük fel, hogy valami szuper cuccot írtam. Legyen mondjuk Python Flask alapú RESTful app és Redis adatbázis mögötte. Valaki fizetne is talán érte, főleg, ha skálázódni is tud a cucc, ha esetleg beütne a piacon. Tehát microservice, valami HTTP LB meg szétszórja a kéréseket (Envoy, nginx, HA proxy...). És persze deadlock írásban kiváló vagyok, tehát kell vmi, ami észreveszi ezt és kilövi a halott példányomat.
Na, innentől nem tiszta a pálya, miért jó ezt konténerizálni, miért ne dobjak oda inkább egy qcow2 fájlt, amiben legalább ki tudom vinni? (Amúgy is valószínűleg kapna VM-et az üzemeltetőtől.) Vagy Docker Store-ban áruljam? Ha mondjuk vmi deadlock figyelő (kérést küld, választ vár) egy másik konténerben, de u.a. Kubernetes podban volna, akkor hogyan viszem ki mindezt?
- A hozzászóláshoz be kell jelentkezni
qcow2 fájlt, amiben legalább ki tudom vinni?
mit ertunk a "ki tudom vinni" alatt? Btw. a qcow2-t minden major virtualizacio / cloud platform tamogatja?
Ha mondjuk vmi deadlock figyelő (kérést küld, választ vár) egy másik konténerben
a kubernetes healthcheck feature-je nem jo erre? De lehet, hogy egy kicsit elaboralnod kellene a kivinni koncepciojat...
--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol
- A hozzászóláshoz be kell jelentkezni
Elaborálni kicsit nehéz lesz, mivel totál kitalált az egész szitu: https://docs.docker.com/compose/gettingstarted/
Igen, a k8s megoldása (https://kubernetes.io/docs/tasks/configure-pod-container/configure-live…) gondolom jó.
A kivinni azt jeleneti, hogy vhogy eljuttatom a vevőhöz a terméket. Lehetőleg úgy, hogy frissítési lehetősége is legyen.
- A hozzászóláshoz be kell jelentkezni
a vevohoz eljuttatni a termeket tobbfele modon is lehet. Pl. docker hub (vagy quay.io). Szerintem nyugodtan fel lehet oda tolni propietary cuccot is. A docker/k8s mar kb. minden jelentosebb cloud szolgaltatonal elerheto. Ennek az is elonye a qcow2-vel szemben - amit nem tudsz akarhova feltenni (erre vonatkozott volna a mindenki tamogatja? kerdesem, amit elegansan kikerultel). Egy docker image frissitese is sokkal egyszerubb, tisztabb, szarazabb erzes, mint egy qcow2 image-e...
--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol
- A hozzászóláshoz be kell jelentkezni
A qcow2 kérdést azért kerültem ki, mert ez csak egy példa, tőlem vmdk vagy vhd is lehet. Igazából azért merült fel vmilyen virtuális disk, mert mi van, ha a vevő nem feltétlenül szeretne az én konténer technológiámmal bajlódni, neki VM-et is elég lenne managelni. De lehet, hogy ez földtől elrugaszkodott gondolkodás. Az a nagy helyzet, hogy fényévekre van ez a terület tőlem.
- A hozzászóláshoz be kell jelentkezni
szerintem a vevonek konnyebb a kontenereddel bajlodni. Mert mi van pl. upgrade-nel? VM-nel egyreszt az OS-t, masreszt az app-ot is upgrade-elni kell, ami mar 2 mozgo elem. Kontenernel te elkeszited az uj image-et, vevo leszedi, majd eldobja a regi kontenert, elinditja az ujat, es kb. kesz...
--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol
- A hozzászóláshoz be kell jelentkezni