ADM:
MLEKAR_STEIN:
Dekuju za rady - zvysil jsem ty max pull a max push, pridal delsi timeout pro docker-compose a situace je vyrazne lepsi (i kdyz ne 100% dobra).
Porad se obcas nektery docker-daemon zasekne na tom pushovani, ktere nemuze uspet, ale je to vyrazne vyrazne min - tj ted uz si dokazu predstavit, ze pro tuhle eventualitu tam budeme mit nejakej automatickej restart - a jeste zkusim trochu potunit ty parametry, aby to bylo ok.

JON: kdysi jsme resili podobny problem s tim, ze docker-registry proste nestihal vic simultanich push pull image (tech deploymentu bylo hodne a casto se to proste seslo) a koncilo to timeoutem. uz si nevzpominam jak se to vyresilo, to znamena, ze asi nejak standardne zvysenim limitu (a nebo to byl primo nejaky problem s limity v bamboo, ktery buildoval a pushoval). vas problem vypada jinak, ale na docker-registry bych se urcite podival. ssd jak tu nekdo zminoval na vytizenejsich /var/lib/docker to potvrzuju

JON:

pokud to je tak, ze selze ten push a zaloguje to tyhle dve hlasky, a ta failed mount je tak trochu matouci
tak me napada v konfiguraci docker registry
zvysit maxthreads: 100 treba na 300
Configuring a registry | Docker Documentation
https://docs.docker.com/registry/configuration/

pokud je to obracene, tak nevim, muze byt nekde omezeny pocet otevrenych souboru?

a kdyz tak nad tim premyslim, tak bych tak jako tak zvysil maxthreads v registry a
v dockeru na masine kde se to buildi max-concurrent-downloads na treba 8 a max-concurrent-uploads na 10

--max-concurrent-downloads int Set the max concurrent downloads for each pull (default 3)
--max-concurrent-uploads int Set the max concurrent uploads for each push (default 5)
dockerd | Docker Documentation
https://docs.docker.com/engine/reference/commandline/dockerd/

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.