JON: ja na jednom serveru nevidim jakoukoliv vyhodu k8s oproti treba compose a spousta nevyhod. Ano, mozna zvladneme vykonstruovat specialni jednu situaci ktera bude tou vyjimkou z toho pravidla, ale ani tam bych se do toho v zivote nepoustel pokud uz k8s neznam.

WOJTISHEK:
KING: ono taky zalezi co znamena "jen jeden server", zejo.

Podle me kriteriem proc mit ci nemit k8s je asi hlavne kolik ruznejch sdielenejch devel/integracnich/staging/produkcnich prostredi potrebuju provozovat.
Pokud mi staci lokalni vyvoj, nejaka "beta" a produkce, tak je to nesmysl (krome drive uvedenych duvodu - naucit se, je to muj denni chleba tak jako tak).
Pokud jich je vic, zvlast pokud je potreba takova prostredi vytacet on-demand, tak je to nakonec jedina pricetna volba.
A pak jsou ty varianty mezi tim, kde je potreba to zvazit - zere mi priprava a sprava tech prostredi fakt hodne casu, vypada to, ze dlouhodobe budou spis pribejvat, nebo ubejvat?

Pak jsou situace, kdy jsou pocty tech prostredi limitovany nejakym fyzickym kusem hardwaru - tam ty k8s taky nejsou vsespasitelny.

WOJTISHEK: rozhodne ne, komplexita ani runtime overhead se nevyplati resit.

Jedina vyjimka samozrejme je, pokud je k8s tvoje domaci prostredi a/nebo se ho chces naucit.

Na pár domácích kontejnerů používat kubernetes (je jedno jestli k8s/k3s/minikube) má smysl asi jedině v případě že se to potřebuje/chce naučit kvůli práci. Jinak je to kravina. Nejde jen o to že se bude muset učit miliardu věcí a konceptů aby to vůbec všechno zprovoznil, ale i další údržbu, aktualizace atd. Na kubernetes jsou ve firmách buď celý týmy lidí nebo minimálně člověk na full-time. Jinak je to trápení.

SUK: ad 1), k8s/k3s/Nomad/Swarm/... bych volil pokud tim ziskam nejakou featuru, kterou 100% potrebuju nebo pokud se danou technologii chci naucit, jinak docker-dompose.

SUK: Nas stack (https://www.uxf.cz/ )/
- Debian, pokud mozno co nejminimalnejsi instalace se zakladnimi nastroji (ssh, dig, ping...)
- Docker instalujeme z docker repozitare, abychom to meli trochu aktualni
- primo na serveru bezi jen ssh a Docker Swarm

Bezi nam tyto Docker Swarm stacky:

- Traefik - "centralni" reverse proxy, ktera "sama objevi" nove bezici sluzby, ma nastarost nasmerovat pozadavek do spravneho stacku

- PostgreSQL - centralni, protoze
a) muzu vyladit konfigurace, priradit vice RAM
b) snazsi zalohovani

- Minio - S3 storage - centralni, protoze
a) konfigurace a data na jednom miste - mam minimum volumes v projektech
b) snazsi zalohovani

- Resizer - nas vlastni centralni resizer obrazku v nodejs

- Sentry - centralni smer dat

- Zabbix - centralni metriky

a pak jednotlive projekty (stacky), ktere jsou obvykle tvoreny temito services:
a) nginx - distribuuje pozadavky mezi backend a frontend
b) api - php8.2+fpm
c) web - frontend v NextJS
d) admin - frontend v NextJS
a dale dle projektu Redis, RabbitMQ...

Nasazujeme z GitLabu, zaroven povazuji za zakladni znalost umet vse ovladat z prikazove radky. Krome toho mame Portainer a SwarmPit, ale ty pouzivame okrajove

SUK: se Swarmem (jak píše QUICK) docela dobře pracuje například Caprover ( https://caprover.com/ ), osobně jsem dost spokojen s provozem.

ADM: no, to bych prave takhle vubec nedelal - restart policy se nastavi pro kazdou service v docker-compose jakou potrebuje (u webovejch backendu typicky restart: always) a je vystarano - kdyz se zrestartuje celej stroj, tak to docker daemon nahodi jak ma (jestli podle policy ma), kdyz to spadne samo, tak taky - a neni potreba nic v systemd.