URPUTNIK: Koukni se taky na to, jak konfiguraci v kube clusterech řeší ostatní, jaký na to jsou best practices a pak se jim zkus přiblížit. Bude to lepší, než kdybyses na to nepodíval a zkoušel to vymejšlet sám a třeba cestou právě antipatternů.

Zrovna v kube je praktický ty konfigurace předávat např. jako env proměnný nebo je tam dotáhnout z nějakýho nástroje na správu secrets. A to právě proto, abys nemusel mountovat disky a na nich pár souborů s nastavením.

Kdybys měl team rozdělenej na dvě části (může to bejt i ten stejnej člověk, ale má tím pádem zároveň dvě role), tak jeden z nich je vývojář, kterej udělá tu aplikaci a doručí docker image. Druhej z nich je provozák, co má pod palcem infrastrukturu, stará se o secrets, který k tý infrastruktuře patří, stará se o env nebo jiný konfig proměnný, co k tomu taky patří.

Zkus se na to podívat z pohledu toho provozáka, jakej je nejlepší stav pro něj - mít secrets uložený v nástroji na to určenýmu a mít config taky uložený tak, jak je to správně (pro tu infrastrukturu). Pak vyvolej byť třeba fiktivní diskuzi na téma, jak to udělat, aby vývojář udělal aplikaci hostovatelnou na infrastruktuře, která má secrets a konfigy uložený podle best practices a ne podle toho, že to tak vývojář chtěl.

URPUTNIK: To co chceš udělat (namountuj remote storage) mi přijde v K8S prostředí jako antipattern, proto se snažim dobrat coho co v tom je, abych ti dokázal říct, co s tim.

Secrets? Pak by to chtělo odpovídající storage, třeba Vault.
Nastavení závislostí / lokace / služeb? Použij service discovery, etcd nebo whatever.
Nějaký url glue co to drží pohromadě? Pak to možná má být součást buildu co to zapeče do image.
Něco jinýho? Třeba to má bejt separátní služba, normální databáze, runtime konfigurace a nebo pentagram na vyvolávání konzultantů.

Bez toho abych věděl co rozumíš pod slovem konfigurace se to řiká špatně ;)

URPUTNIK: Je to spíš o tom, jak blízko chceš být best practice. Ale obecně, jde o to to nasadit podle vašich potřeb a možností a ty jsou všude jiný. Každápádně, obecně ty best practice mají imho smysl.

a.) Máme sice image v privátním dockerhubu. Repo se zdrojáky v privátním gitu. Ale jakmile k těmhle věcem má přístup nový dev nebo třetí strana. Můžou secrets vynést ven. Asi jim můžeme důvěřovat, ale třeba taky vůbec ne. Tj. chci poskytnou kontejner bez secrets a přístup k repozitáři tak, aby ideálně ani naši devs, nemuseli znát hesla k ničemu. A jim to i tak vyhovuje. Tj. pokud security není problém, tak bych klidně skrz ENV jen volal konfiguráky pro dané prostředí, což už v kontejneru jsou. Jestli je to security priorita, tak bych určitě šel cestou vkládání konfigruace až při deploy.

b.) Já třeba provozuji Swarm, u některým old school appek jsem musel secret vkládat do swarmu, aby si ho kontejner přimountoval jako soubor. Mělo to jeden nemilej důsledek, když jsem kontejner aktualizoval, musel jsem připojit novej secret a starej odebrat páč swarm neumí update operaci nad secret/config (měl jsem ošklivej bash na přidání secret_temp, odebráný původního secret, přidání nového secret a odebrání secret_temp:-). Když jedu jen z ENV tak nic neřeším a nemusím používat Swarm secrets. Mám pocit, že podobně je to i v Kubernetes. Že config/secret objekt musíš nahradit a nemůžeš udělat update, tak je snažší to všechno rvát přes ENV.

URPUTNIK: já to dělám tak, že mám docker compose (pro swarm) jako ansible template, podle toho kam se to deployuje (local, test, prod), ansible vyplní proměné. Když je to test/prod, tak to ansible krmí z vaultu.

URPUTNIK: Jop. Mas nejaky startup skript, ktery nacte env var a nacpe je kam patri. Ja php aplikace nemam ale treba by te inspirovalo toto: https://github.com/linuxserver/docker-projectsend/blob/master/root/etc/cont-init.d/30-config