A szolgáltatásaink ... százalékát konténerekben futtatjuk

 ( turul16 | 2018. szeptember 20., csütörtök - 8:33 )
0%
54% (140 szavazat)
<10%
16% (41 szavazat)
>=10% AND <50%
10% (26 szavazat)
>=50% AND <90%
8% (20 szavazat)
>90%
12% (32 szavazat)
Összes szavazat: 259

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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.

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

Mit kell jelölni, ha _pontosan_ 90%? :)

---
"A megoldásra kell koncentrálni nem a problémára."

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.

...és nem eladni több halálpálcát :)

--
Where do you want to go today?
[nobody@salcay:~]$_

hoppsz >=90 kene valoban .
Kosz review-ot.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

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. :)

--
https://iotguru.live

A JavaEE konténer is konténernek számít? :)

--
https://iotguru.live

A csontvázak maradjanak a szekrényben inkább :)

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Nem csontváz az, csak jól kell használni. Az igényteleneknek pedig ott van a Spring. :)

--
https://iotguru.live

https://tenor.com/view/supa-hot-fire-black-guys-roasted-take-that-black-gif-4954520

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

touché xd

miért igénytelen a spring? (komolyan kérdem nem értek hozzá)

Próbálj meg mondjuk egyszer két - nem egy JVM-ben futó - Spring processz esetén tranzakciót kezelni.

--
https://iotguru.live

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.

Honnan tudjam? Azt se tudom, hogy milyen szolgáltatásokra gondolt a költő.

[x] Csak az eredmény (se) érdekel.

Amiket te/csapatod/céged fejleszt/üzemeltet.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

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.

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 beanstalk kontener? :)

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

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

ami ugye 2018-ban eleg baromsag, ha meg mi is tudjuk a Db2-ot kontenerben adni...

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

Miért nem javasoljátok?

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

lockless ?
https://software.intel.com/en-us/forums/intel-moderncode-for-parallel-architectures/topic/304284

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 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

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.

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

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/20170809_SIT6_Petersen.pdf


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

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

ugy latom elegge a NIH szindromaban szenvedtek... :)

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

lehet tudni a termek nevet?

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Bocs, azt kifelejtettem: Scylla.

Github: https://github.com/scylladb/scylla
Weboldal: https://www.scylladb.com/
--
:wq

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?

"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

Na es sikerül már megszorongatni a Cassandrát? :)

A megszorongatas eros tulzas ezen a ponton. De mar tudnak rolunk, "felkerultunk a terkepre".
--
:wq

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.

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.

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.

É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

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.

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.

dragabb?

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 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. :)

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?

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

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-liveness-readiness-probes/) 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 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 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.

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