SUK: tak on to nemusi bejt plnej k8s, ale nejaka odlehcena verze (k3s/minikube apod). Uznavam ze uz sem asi trochu postizenej svou praci, osobne bych ale uz do cistyho dockeru sel jen ve vyjimecnych pripadech :)

JON: to je mozny ze to jde i jak rikas. ja mam na takovym tom domacim sitovani jen openrc sluzbu, ktera spusti compose up a down, bez restart policy a nic mi zatim nechybelo

JON: vim co myslis, musela by se ta sluzba nastavit at to spusti jen compose up a down a nestara se o vysledek (coz i v systemd jde, jako ze neni service running ale active exited nebo jak - systemd nepouzivam pokud nemusim).
on restart policy v docker-compose stejne asi potrebovat nebude a je lepsi pokud tu aplikaci pojme jako service rizeny init systemem

ADM: to bych nedoporucoval - michat do toho systemd - nech to na dockeru pres restart policy: https://docs.docker.com/compose/compose-file/compose-file-v3/#restart_policy

SUK: a pokud pouzivas letsencrypt, tak se v pripade jednoho nginx na hostu alespon nezblaznis z obnovy certifikatu

SUK: pokud ty kontejnerovy webaplikace spolu nijak nesouvisi, tak si zapis kazdou zvlast do vlastniho docker-compose.yml (jde i o to, ze mas ten container nejak slusne a strukturovane popsany a definovany, a nemastis to nekde ve scriptech), a zarid si, aby to byla sluzba spravovana init systemem (nejspis systemd, tady neporadim, ale urcite bude existovat systemd-unit pro docker-compose).

VELDRANE: Jedinej uzivatel a to teda fakt fullstack jsem ja ja ja jenom ja ;) Z toho duvodu mi prave k8s prijde jako kanon^vrabce :P))
ADM: jo, to zni docela rozumne. Ty dve veci (davical, agendav) nastesti fungujou s aktualnim pg a navic jsou na sobe navzajem zavisly :)

Ohledne "ty kontejnerizovany aplikace si zapis do d-c": jenom ty aplikace nebo celou tu "infrastrukturu"? Uprimne jsem docker doted pouzival maximalne pro vyvoj na localu a poustel/vypinal jsem to rucne, takze netusim, jak se tohle vlastne resi na serveru...

Diky za odpovedi :)

Ahoj. Asi si chci zalozit virtual kde budu mit "vsechno" a to vsechno bude kontejnerizovany. Aktualne predpokladam:
- nginx "naprimo" pro staticky weby (bude jeden az dva, hadam)
- nginx + php-fpm (aktualne 3 weby)
- nginx jako reverse proxy pro nodejs aplikace
- nginx jako reverse proxy na web-storage ktera ale bude uplne nekde jinde
- postgresql pro ty 3 php weby + mozna i dalsi
- mozna mongo

Me znalosti jsou na te urovni, ze toto vsechno dokazu dat bez potizi dokupy standalone i to dockerizovat, ale asi to nebude "spravne".

Takze, otazek mam vic:
1) Cim to skladat? Docker-compose nebo neco jinyho? k8s by byl asi komar na kanona
2) 3 weby, 3 pgsql databaze muze znamenat 3x nginx + 3x pgsql + nginx jako rproxy. A nebo 1 nginx co dela vsechno a jedna pgsql, co dela vsechno? Jeden web navstivi jednotky mesicne, zbytek je ciste jen pro me :))
3) Weby a databaze predpokladam jako externi mount (alias volume) nebo to delat jinak

Ano, asi to prehanim a moc resim, ale snazim se to proste delat spravne/spravneji, co kdybych umrel a nekdo se mi podival na server? Diky danke gracias!

ICARUS: Tak pipelina ktera pri buildu jedne z tech docker image trigerne jeste pipeline co zbuildi ec2 image? :)
Pripadne k tomu worker nodu pripojovat nejaky ebs/disk, kde by ty image byly, mozna furt rychlejsi nez to tahat pres klasickou sit z registry.

KAPLIK: Jo, přesně tohle tam mám teďka. Blbý je, že ty změny té image jsou občas trošku nepředvídatelné a hlavně těch docker imagí je tam víc a různé verze, takže se mi úplně nechce pořád buildit nové custom EC2 image.

ICARUS: Pokud se ta image tak casto nemeni, tak by si vyrabel custom image pro ec2/eks, kde by byla predcachovana, tzn by se nemusela cela tahat z docker registry, pripadne by se treba stahnul jen nejnovejsi layer (ale tam uz zalezi proc je ta image tak velka a co se v ni meni).
Takto je to treba vyreseny na AKS (azure) worker nodech, kde os image obsahuje nacachovane image kontejneru ktere tam bezi by default, aby se furt vsechno nestahovalo.

Jak byste řešili situaci, kdy máte velké množství (třeba 64) strojů, které si najednou potřebujou stáhnout docela velký image (10GB)? Stroje se spawnují ondemand a po ukončení výpočtu zase zmizí, takže se ty image na ně těžko dají přednahrát. Všechny ty stroje jsou v jedné privátní síti a v AWS cloudu.

Zkoušel jsem použít AWS ECR, ale pull je příšerně pomalej (10 MB/s). Ty stroje si ty image potřebujou stáhnout co nejrychleji. Zatím jsem koukal po Kraken od Uberu, ale vypadá to jako lehce abandoned projekt a nevím, jestli se mi chce setupovat tak složitej traktor. Pak jsem taky zkoušel vlastní Docker registry s S3 backupem, ale to dávalo "jen" 20 MB/s pull. Na tohle už přece musí být nějaké rozumné řešení, ne?

MLEKAR_STEIN: to neni spatny napad