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)

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

INDIAN: toto jsem udelal

RAGNAROK: WOODMAKER: aha, takze v containeru neni ten uzivatel, takze kdyz mam uzivatele reflex pustim docker-compose up tak vlastne v tom containeru je root a ten nema pristup k souborum co jsou pripojene pres volumes protoze vlastnik je reflex :D

takze reseni je zalozit toho sameho uzivatele v dockeru?

REFLEX:

Akorat ten user pak uvnitr neexistuje, tak nefunguji veci jako $HOME a tak. Ale s absolutnima cestama by se mely vytvaret soubory se spravnym uid a gid.

REFLEX:
v hostovym systemu pridat nonroot usera do skupiny docker.
v image (dockerfile) vytvorit nonroot usera se stejnym jmenem a id.
akorat pak image musis buildit pro kazdyho usera zvlast.

REFLEX:

Jak se ma spravne nastavit docker, abych ho nemusel poustet jako sudo a v containeru nebyl problem s pravy a container na pripojenych souborech nevytvarel soubory pod rootem? :)

FYI: https://community.cncf.io/events/details/cncf-kcd-czech-slovak-presents-kcd-kubernetes-community-days-2022-czech-slovak-virtual/

Mam dotaz k ArgoCD - nevite nekdo o tom, jak/jestli tam jde udelat nejaky transformacni krok mezi repositarem podle ktereho syncuje a tim podle ceho syncuje?
Treba slej helmcharty z N adresaru v tom repu dohromady, naaplikuj na to nejake templatovani apod.

Samozrejme to jde udelat stylem: push do repositare A -> tam se pusti CI job, ktery provede ty transformace a pushne to do repositare B -> a podle repositare B to Argo vydeployuje. Ale moc se mi to takhle nelibi.

MLEKAR_STEIN: díky za postřehy ...

čekal jsem, že to má docker nějak zmáknutý - nějaký docker backup/docker restore ale nic moc

MAJA: zkontroloval bych

1. jestli někdo neudělal symlink na
/var/lib/docker případně na některé adresáře v něm. typicky jsem viděl symlink na /var/lib/docker/volumes kterej ukazoval někam na nějaký ssd disk
2. podíval bych se do /etc/fstab, jestli není na.výše uvedené adresáře udělaný bind
3. podíval bych se do lokální konfigurace systemd, která je někde v /etc jestli tam někdo néco vesele nepřenastavil.

specielně bod 3 je docela zákeřný a umí potrápit stylem "jaktožesetopouštístímdleparametrem"

ještě bych zkontroloval, jestli nějaký kontejner si nevyrábí nepojmenovaný volume pomocí direktivy v dockerfile. a nepoužívá to někdo jako že v tom má data
viděl jsem takhle provozovaný postgres, kde po restartu se vývoj divil, kam jim zmizely data a že to musej pořád obnovovat.