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.

REFLEX: Je dobry si uvedomit co kontejner vlastne je; obycejnej process kterej bezi v nejakejch kernel namespacech, obalenej cgroupama a selinux politikama. A to jsou vsechno veci ktery umi jadro samo. Docker sam zajistuje jen tu omacku kolem jako stahnuti image odnekud a spusteni toho co je v nem obaleny tim co sem psal vejs. Ale porad je kontejner obycejnej process kterej pri trose snahy vytvoris i rucne a z definice nemuze mit velkej overhead. Jinak na kontejnerizaci lze pouzit i jiny nastoje (u nas v praci treba dost frci podman) ktery delaj vicemene to stejny jen trochu jinak :).

REFLEX: Na úrovni OS máme nainstalovaný jen Docker Engine, plus pár monitorovacích nástrojů. Celý business je konetejnerizovaný už roky. Nějaký legacy node.js, tuna pythonu a high-performance věci pro jádro businessu jsou v rustu. Za ty skoro tři roky co to sleduji byl Docker engine za minimem incidentů a spíš kvůli nedůsledné konfiguraci (neomezení paměti, neomezený úložiště pro logy apod.). Když něco leakovala, byl to vždy problém v kódu aplikace. Když se něco takovýho děje u služby, která nemá vliv na zákoše, takže to nemá prioritu, nastavíme ať do docker killne při sežerání nějaký velikosti paměti a nastartuje. Já bych se k řešení závislostí na úrovni OS, už nerad vracel.

REFLEX: Ten overhead je relativne maly, docker jako takovy je jenom maly daemon, co pousti samotne docker-procesy a jejich izolace nejaky overhead urcite vytvari, nicmene nemelo by to byt nic strasneho, dle nekolika malo clanku vyslovene zanedbatelneho. Koneckoncu, ten proces bezi prakticky skoro normalne v systemu, neni tam zadna virtualizace a tak. Dokonce i ten NAT to asi tolik nebrzdi.

REFLEX: jestli chces mit na jednom serveru vsechny tyhle veci tak docker je to posledni s cim bude problem nebo co by tomu neco pridalo, rozhodne bych docker doporucil

DWICH: v kubernetes muzes mit vlastni configmapu, do ktere das napr obsah toho souboru .. ktery pak mountnes dovnitr do docker image pres kuberneti volume .. (my tak resime pripojovani do ruznych prostredi, protoze aplikace je parametrizovana soubory, nikoli ENV )

DWICH: neslo by mit ten konfigurak na pripojenym volume?

DWICH: presn ENV a envsubs .... napr. https://serverfault.com/questions/872929/use-basic-auth-conditionally-in-nginx