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

Címkék

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

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.

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

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

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

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

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

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.

"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

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.

É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

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.

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