JON:
1. udelal jsem zkusenost, ze docker ma problem s IOPS na diskove operace. /var/lib/docker by melo byt na ssd disku. a to i v pripade, kdy se na stroji nepouzivaji volumes pro persistentni data.
jako best practice bych pridal, ze pokud mam vetsi mnozstvi volumes, ktere neco delaji, treba mam elastic a generuji indexy, tak je dobre mit volumes na vlastnim disku. to se da resit bud symlnkem, nebo pomoci direktivy bind v /etc/fstab

2. docker-compose ma timeout na vlastnim dockeru, povazuji za hodne nepravdepodobne, ze by to melo trable kvuli registry, kam se to pushuje, pokud to registry neni na stejnem stroji.
timeout se da nastavit promennou COMPOSE_HTTP_TIMEOUT.
Viz https://docs.docker.com/compose/reference/envvars/
trochu to pomuze, chcipne to o par minut pozdeji

3. je nejakej trabl v komunikaci compose a docker daemona, uz docela dlouho, chovani je takove, ze compose uz nereaguje a zaroven docker docela v pohode funguje. kdyz tohle nastalo, tak jsem opravdu nikdy nemel cas pustit strace abych zjistil, ktere volani v compose blbne. :)
da se to nasimulovat pomoci nekolika elastic serveru, ktere generuji indexy a elastic data volumes lezi vsechny na jednom tocivem sata disku spolecne ve /var/lib/docker. :D
doporucuji pouzivat "docker push" misto compose.


4. runnery - umiraji na iops. klinicky jsem otestoval na serveru s 15k SAS disky. kdyz se jich pusti vetsi mnozstvi, tak to na tocivych discich chcipne. plati pro ne to same, co pro vsechny docker kontejnery a /var/lib/docker. radeji na levnejsim SSD nez na drahem SAS. delalo to uz pred par lety. kdyz se pustilo nekolik vetsich kompilaci v C++, hromada malejch blbosti a par kompilaci javy tak to chcipalo uz na gitlab 12-13.
kompilace zerou disky :D

5. vec, ktera umre na iops se obvyukle sama od sebe nikdy nevzpamatuje a zustane v ni nejaky proces v D stavu, Uninterruptible Sleep, kdy ceka na IO. neda se s tim delat vubec nic, krome restartu stroje, v pripade dockeru restartu kontejneru. protoze v tomhle stavu to nereaguje na zadny signal.

6. podle popisu bych tipoval, ze se pokousi cist layers ze socketu a zaroven bezi nejaka kompilace a umre to na IOPS..

7. mozna reseni.
dat tam ssd disk pro /var/lib/docker
zkusit si pohrat s parametry vm.dirty_background_ratio, vm.dirty_ratio
nejaky info je na strance u glusterFS, https://docs.gluster.org/en/main/Administrator-Guide/Linux-Kernel-Tuning/
pripadne neco dalsiho, co me ted nenapada a ani nejsem schopnej nejak rychle najit.

DANIELSOFT: Neni nahodou ten file soucasti nejaky configmapy a nestaci zmenit pouze tu configmapu ? Pripadne vytvorit, namountovat v deploymentu/statefullsetu a premastit jim ten originalni xml file ?

To xml je k cemu ? K aplikaci co bezi v tom clusteru ?

AQUARIUS: no jo, ale to vyžaduje změnu v jiné komponentě, než je "naše", takže já zrovna tam commitovat nemám práva... proto jsem právě zkoušel tu partyzánštinu "změnit to přímo v kontejneru na prostředí, na kterém o nic nejde"... možná mi na to řekneš něco jako "tím spíš je dobře, že tě to hlídá a že to nemůžeš udělat" :)

DANIELSOFT: prijde mi, ze zabraneni podobnemu chovani (ja chci "jenom" ...) je primarni duvod, proc se kontejnery pouzivaji. Kdyz disciplina neni, je treba ji vynutit. Neber si to osobne, sam se tesim, az se moje produkcni prostredi dostane do podobneho stavu, aby kolegove nemohli "jenom" pres ssh menit nahodna nastaveni s tim, ze audit trail takovych akci se v lepsim pripade sestavuje hrozne spatne.

DANIELSOFT: to xml je v containeru? pokud ano, tak neni jina moznost nez nova image