• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    KING
    KING --- ---
    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.
    JON
    JON --- ---
    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.
    KING
    KING --- ---
    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.
    VELDRANE
    VELDRANE --- ---
    …tlT treba v docker swarmu. Nicmene proti gustu zadnej disputat :)


    Sorac, tlacim to z mobilu a odpalil sem ten post driv nez nez byl hotovej.
    VELDRANE
    VELDRANE --- ---
    Za me smysl k8s urcite ma a nemusi to bejt plnohodnotny k8s. Ty principy nejsou imho nijak slozity, cely tymy na k8s jsou hlavne z duvodu integraci ale ne samotneho k8s. Vyhoda je i to, ze kdyz uz to clovek jednou vytoci a pak se rozhodne ze prejde treba do cloudu nebo z cloudu do on-premu je to plus minus stejny. Kdyz uz clovek si da praci a ty jednotlivy aplikace hodi do kontejneru, pak mi prijde skoda to pa
    WOJTISHEK
    WOJTISHEK --- ---
    Ma vubec smysl resit k8s, kdyz mam jen jeden server? Nebo vnimam nespravne to, ze je to vyhodnejsi az ve chvili, kdy mam aspon 2 ruzna zarizeni?
    URZA
    URZA --- ---
    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í.
    SAMGARR
    SAMGARR --- ---
    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.
    MRDAC_BEDEN
    MRDAC_BEDEN --- ---
    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
    WOJTISHEK
    WOJTISHEK --- ---
    SUK: se Swarmem (jak píše QUICK) docela dobře pracuje například Caprover ( https://caprover.com/ ), osobně jsem dost spokojen s provozem.
    QUICK
    QUICK --- ---
    SUK: zkoušel jsi docker swarm? Nemusíš se kvůli tomu učit Kubernetes, stačí ti docker-compose.yml. Zároveň můžeš nakonfigurovat bezvýpadkové nasazení aplikací. Když k tomu ještě přidáš Ansible, kterým popíšeš, jak nakonfigurovat samotnou mašinu, tak máš veškerou konfiguraci k týkající se nastavení serveru a aplikací kodifikovanou. Sám to tak na one-man-show projektu používám a přijde mi to dobré.
    QUOING
    QUOING --- ---
    SUK: pokud to k8s prijde jako kanon, tak mrkni na HashiCorp Nomad. (a pripadne pak Consul a Vault)
    VELDRANE
    VELDRANE --- ---
    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 :)
    ADM
    ADM --- ---
    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
    JON --- ---
    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.
    ADM
    ADM --- ---
    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
    JON
    JON --- ---
    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
    ADM
    ADM --- ---
    SUK: a pokud pouzivas letsencrypt, tak se v pripade jednoho nginx na hostu alespon nezblaznis z obnovy certifikatu
    ADM
    ADM --- ---
    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).
    SUK
    SUK --- ---
    VELDRANE: Jedinej uzivatel a to teda fakt fullstack jsem ja ja ja jenom ja ;) Z toho duvodu mi prave k8s prijde jako kanonvrabce :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 :)
    Kliknutím sem můžete změnit nastavení reklam