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.