Cau, resim zapeklitej problem:
Od te doby, co jsme upgradovali gitlab na verzi 15 (gitlab i runnery) se potkavame s tim, ze se docker na nekterem runneru dostane do nestabilniho stavu, kdy neni schopnej pushnout image do registry (obcas ani pullnout). Dockery na ostatnich runnerech pushujou/pullujou ok. Restart dockeru problem vyresi. V journalctl je u toho failujiciho dockeru videt, ze se snazi opakovane pushovat hromady layeru a failuje u toho http basic auth do registry.

Na kazdem runneru se to stane tak cca jednou, 2x za den. Vetsinou v situaci, kdy se spusti hodnemoc jobu naraz. Nebo (domnivam se), kdyz se hodne rozjetejch jobu zastavi. Spolehlive reprodukovat to neumim. Ten chybovej stav vydrzi trvat hodiny - takze fakt vopruz.

Podeziram nasledujici situaci:
na build a push imagu pouzivame docker-compose. Kdyz se nasype hodne jobu = hodne pullu a pushu najednou, tak asi dojde k pretizeni site/registry. docker-compose vytimeoutuje a ukonci job, tim zrusi validitu job_tokenu do registru ale docker daemon se porad pokousi pushuvat, ale je z registry odmitan.

Netusite, jak nastavit bud vetsi timeout pro docker-compose a nebo hlavne mensi pocet retries na push v docker daemonu? V dokumentaci jsem nasel jen limit na maximalni pocet paralelne stahovanych ci pushovanych layeru - ale to mi neprijde jako vhodna cesta - vetsinu casu to funguje ok, a beznej beh bych nerad zpomaloval.

KAPLIK: Kouknu, to by znelo dobre s tema dependency.
Gitops neznam, ale vim ze ten proces jen tak nezmenim. Ono je na to navazane schvalovani nekolika lidma a to i manazerama. Ale co koukam, tak to vypada jen jako actions/pipeline v gitlabu nebo necem. Coz by od Jenkinse nebylo ve vysledku nic jineho.

MARTEN: jako zakladni/rychlo reseni muzes vyuzit toho, ze helm umi dependency, tzn muzes mit jeden helm chart verzi X, ktery bude mit jako dependence servisu A ve verzi 1 a servisu B ve verzi 2... pak teda delas "helm upgrade -i" na ten "umbrella" chart, ktery si pak dotahne dependence (s tim ze v ramci toho musis poresit values tech dependenci)... dale viz: https://helm.sh/docs/helm/helm_dependency/

nicmene delat jenkinsem helm install/ugprade mi prijde takovy meh... gitops na vas! :)

Ma tady nekdo vetsi zkusenosti s helm? Potreboval bych mini konzultaci, nebo jestli je to realne vyresit.
Mame projekt, ktery ma 4 tymy, kazdy tym ma nekolik microservice (10-20). Vsechno se nasazuje do openshift. Kazda service ma svoje verzovani a v openshift vlastni project s nekolika deployment configama. Zatim neresene pres helm. Rozdelene jsou to projekty kvuli rozdilnym budgetum tymu a kolik maji zaplacenych cpu apod (korporace, s timhle se asi moc neudela).
V tuhle chvili se nasazuje na jenkins. Vyberou se verze service, klikne se a pocka.
Budu ted predelavat celou pipeline a chci i trochu lepe udelat nasazovani. Treba i tim, ze je pozadavek na to mit moznost nasadit verz 1.2.3 a clovek ktery to nasazuje, tak ho nezajima, jaka microservice potrebuje jakou verzi (ted dostane seznam a musi kazdou service udelat podle toho).
Nechci na tohle vymyslet nic vlastniho, napadlo me jestli helm by tohle nevyresil, ale znam ho jen okrajoe. Jde tam udelat ze mam chart ve verze 1.2.3, ten obsahuje deploymentConfig pro nekolik sluzeb a u kazde ma recene jako image se ma nasadit? Podobne i s rollbackem, kdy reknu ze se chci vratit na predchozi (helm rollback myslim ze jsem zahledl).
Vice chartum (4) se asi nevyhnu, ale to se da spustit paralelne.

DANIELSOFT: kromě rad, ktere již padly (config mapa, zmena v přímo v imagi pokud je to zapečené) tu je možnost init containeru (https://www.magalix.com/blog/kubernetes-patterns-the-init-container-pattern).

Každopádně pokud to má být konfigurační soubor, doporučuju config mapu (Secret)

https://twitter.com/kantrn/status/1511791378497384454?
FAANG promo committees are killing Kubernetes: A Short Thread

DANIELSOFT: pokud je prostredi postaveny dobre, bude stejne zmena jen o jednom spravne umistenym commitu, ne? Zbytek je kandidat na automatizaci v ramci CI/CD pipeline. (to se mi to keca, kdyz s tim mam jen omezeny prakticky zkusenosti, navic jen na vlastnim piskovisti, zeano...)

AQUARIUS: tohle je testovací throw-away virtuálka v R&D oddělení, žádná produkční nebo zákaznická data. ale chápu, co tím myslíš.

velmi lama dotaz o Kubernetu: mám rozběhlý nějaký cluster, který nasetupoval kolega. dokážu reprodukovat chybu, kterou mám opravit. mám tam XML soubor, přidáním jednoho řádku by se měla opravit chyba (systém by se měl chovat jinak), zkusil jsem naivně editovat soubor vimem , který v kontejneru je, ale soubor je v nějakém read-only layeru, že ani když root udělá :w! nedaří se uložit změněný soubor

je nějaký jednoduchý způsob, jak tam tu změnu podstrčit?

systém je totiž velký a builduje a setupuje se složitým způsobem, do kterého jsem ještě nepronikl a když chci jenom změnit ten soubor, tak mi přijde nejpřímočařejší zkusit změnu nejdříve takhle ručně

REFLEX: pro odretardovani se s pravama si dovolim to popsat:
na disku jsou inody, kazdy ma sve cislo
adresar je specialni typ inodu, ktery je oznacen jako adresar a jako obsah ma seznam paru jmeno:cislo inodu
soubor je specialni typ inodu, ktery je oznacen jako soubor a obsah je obsah souboru

A inode drzi ony atributy
mode - typ a prava souboru
link count - pocet odkazu (kolik na nej odkazuje adresaru - pokud to klesne na 0, inode se smaze)
uid - cislo uzivatele
gid - cislo skupiny
nejaky dalsi malickosti a data

snad ti to pomuze v reseni

REFLEX: vytvareni stejneho uzivatele v image je dost na prd. Ale taky jsem to parkrat udelal. Jinak nejde o jmeno, ale musel by mit stejne UID

REFLEX: ten soubor ma fyzicky v sobe ulozeny dve cisla - uzivatele a skupinu (a par dalsich, whatever). A ty dve cisla tam potrebujes predelat z jednoho systemu na druhej. Group docker asi neni to, co potrebujes.

WOODMAKER: no to jsme cekal, ale je to normalne pres volumes pripojeny adresar, ale mel problem s opravnenim, mozna kdybych nastavil group slozky na docker...

jsem na tyhle veci s pravama retard :D

REFLEX: root ma pristup ke vsemu, pokud mu to nekam pripojis.

REFLEX: zalezi na use-case.
Normalne sluzby v dockeru, co potkavam, byvaji uvnitr jako root. A mivaji volumes, do kterych jim nikdo nesaha. A bavi se mezi sebou pomoci nejakych API jakoby po siti.

takze budto udelas kazdej container s uzivatelem, coz mi prijde neprakticky
Dockerfile:

nebo nastavis uid:gid tomu uzivateli, co ma pustenej ten kontejner (WOODMAKER)

nebo, pokud pracujes se souborem, ten soubor zpracujes jako root a pak mu nastavis, aby mel prava podle nejakyho jinyho souboru

REFLEX:
no reseni to je takovy trochu pojebany ale na jinej zpusob jsem neprisel.
v docker-compose pak volume nabindujes:
volumes:
- ${HOME}/mujdir/:${HOME}/mujdir/:rw