ADM: Problem kontejneru ktery si muzes menit je, ze ti vytvari heterogenni prostredi a hrozne blbe se pak hledaj rozdily a problemy.
Pro development, whatever. Ale pokud jdes do nightly runu (a dal) s tim, ze si postavis container stack a pred startem aplikace tam musis na cokoliv sahnout (as opposed to just injecting configuration from the driver), tak ten image neni udelanej spravne - IMHO. Jasne, da se to udelat spoustou veci, muj osobni nazor je ze pokud aplikacni kontejnery musis modifikovat za behu, zadelavas si na problemy v produkci :)

ADM: "aplikacni kontejnery existuji prave od toho, aby se tam ten pip install, mohl delat"
je to trosku slovickareni, ale pip install mam v dockerfilu a ten mi vybuildi image, potud ok ... kdyz ten image pak pustim tak mam kotejner a v nem uz se pip install fakt nepousti

ADMIX: s tim nemuzu souhlasit, s tou tyci to plati pokud by delal nekdo pip install v OS, ale aplikacni kontejnery existuji prave od toho, aby se tam ten pip install, mohl delat (jinak bys musel cekat, az nekdo backportuje php/python/atd do balicku, pritom v pip apod. jsou stable verze ihned].
takze zrovna v python projektu mas requirements soubor se zavislostma vcetne verzi, a v dockerfile jeden pip install, ktery jej pri buildovani image nainstaluje, vyvojar si to pak otestuje, a vysledkem je funkcni docker image, co vic si prat?

ONLINEQUE: problem jsi popsal presne, neni mi znamo, ze by existovalo nejake reseni. jo mozna v komercnim docker supportu jsem videl neco jako ze v jejich verzi docker repository je nejaka security featura, kterou jsem si z marketingu prelozil jako ze to asi scanuje image na vulnerability, ci co. pak taky officialni vendori upstream images muzou garantovat aktualizace (image od redhatu napr.)

ONLINEQUE: Mam v planu zkusit toto: https://anchore.com/opensource/

Ale nejsem si jistej jestli to je presne co hledas.

ONLINEQUE: krok cislo 1, kontejnery jsou zasadne immutable a pokud ti v nich nekdo dela pip install, tak si najdi takovou tyc co budes nosit porad u sebe, a jak nekdo udela pip install, tak ho zabij :D
Jedna cesta je mit base OS image (v zavislosti na tom co potrebujes to vetsinou bejva bare OS userland bez kernelu apod.) a tvuj release cycle pravidelne upgraduje zavislosti tech kontejneru (pocinaje nightly runs, pres QA/UAT, az po gradual prod rollout)

KING: IMHO downtime je naprosto normalni soucast SLA tehle reseni - ja mam taky bias, ale na druhou stranu :D pokud chces opravdovej zero downtime, tak s tim prichazi omezeni (nektery veci, nektery software proste nejde vzdycky udelat zero downtime) a cena (HA)
Jestli ma nekdo jednu VPSku, tak mi tam obcasny maintenance window pres noc (kde teda musis zapocitat i "novej balik omylem smaznul vsechny data let's restore") prijde normalni

KING: Tak s downtime do jedné vteřiny, než se ten nginx otočí, funguje drtivá většina všeho co na internetu je - na eshopu to, troufám si říct, nejen nikdo nezaznamená, ale ani nenaměří - to už je větší riziko, že ta VPS vypadne celá.
My to třeba v HA případech řešíme na loadbalanceru, který je před těmi dockery,

JON: Pokud nepotrebuju 0 downtime je hodne velky pokud, mozna ziju nekde jinde ale nedokazu si predstavit ze bych to navrhl nejakemu zakaznikovi

REFLEX: Kubernetes na jeden stroj rozhodne ne. Spravovat se to da v podstate cimkoliv na co si zvykly - supervised, systemd, ... nebo i rucne jen na zaklade nejakych deploy skriptu (ansible, ...)

Z docker-specific nastroju na to docker-compose neni idealni protoze neresi co se stane potom, co to nahodis, upgrady jsou obtizne atp. Jestli chces neco podobneho tak se muzes podivat na docker swarm ktery tohle resi pomerne hezky.