• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    KING
    KING --- ---
    1 odpověď+5
    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 --- ---
    3 odpovědi
    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 --- ---
    +4
    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 --- ---
    +3
    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 --- ---
    +3
    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 --- ---
    +1
    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 --- ---
    1 odpověď
    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 --- ---
    1 odpověď+3
    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 --- ---
    1 odpověď
    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 --- ---
    1 odpověď
    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 --- ---
    1 odpověď
    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 --- ---
    5 odpovědí
    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 :)
    ADM
    ADM --- ---
    1 odpověď+4
    SUK: ja budu mit jiny nazor nez VELDRANE prede mnou:
    - nginx jeden na hostovi pro vsechny weby/aplikace
    - kazda webaplikace (nodejs, php-fpm, ...) ve vlastnim docker containeru (docker network mode host pro aplikace poslouchajici na localhostu, kam na ne ta nginx proxy dosahne)
    - ten postgres spise jeden na hostu, ale pokud jsou rozdilny pozadavky od aplikaci napr. na verzi postgresql, tak to klidne rozdel zvlast na nekolik postgresu v containerech
    - ty kontejnerizovany aplikace si zapis do docker-compose
    VELDRANE
    VELDRANE --- ---
    1 odpověď-1
    SUK: naopak mi v tomto pripade prijde pouziti k8s vcelku logicke. Usetris zdroje (nektere veci jako cast tech nginxu muzes mit v jedny instanci), mas zajisteni sitovani a propjeni veci v ramci k8s clusteru. Nicmene by bylo vhodne si rozmyslet jak a ktery aplikace spolu komunikuji, kde mit ingress, kde mit externi ip, co resit pomocit nejake custom nginx instance apod, kolik na to mas casu a jak resit deployment, kolik na to mas lidi apod.

    Pokud ale chces podobne prostredi nejak konsolidovat, tak mi kubernetes prijde jako vhodnejsi volba nez to cpat na jednu virtualku. Osobne bych build jednotlivejch komponent delal v klasickym docerfilu a deployment pak pomoci helmu. To prostredi nemas nijak velkyntakze cpat tam neco jako argo je kanon na vrabce. Taky bych si byt tebou popremejslel nad tim kdo a jak bude nasazovat updaty aplikacni casti. Predpikladam zs ten php kod se nejak vyviji, aktualizuje, patchuje….
    Kliknutím sem můžete změnit nastavení reklam