• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    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….
    SUK
    SUK --- ---
    4 odpovědi
    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!
    HVJ3R
    HVJ3R --- ---
    +1
    10GB na image je moc. Ja zacinam bejt nervozni uz kdyz to leze k 1G. Voser s tim pracovat. Vic imgs a ruzne verze chapu, to mame taky, ale snazime se vychazet ze stejnyho base img, at se images/verze lisej jen max par layerama max 10kach MB. Pak tahas prd. Ale jestli mas ephemeral nodes, tak nepomuze ani tohle.
    ADMIX
    ADMIX --- ---
    +1
    ICARUS: 20MBps z S3 je brutalne pomaly, S3 bezne dava >200MBps a teoretickej limit je vpc connectivity. To je nakej limit docker pull? Jestli jsi je tahal z S3 anyways, tak co to stahnout na lokalni disk pres normalni GET, jestli to nebude rychlejsi?
    NYX
    NYX --- ---
    +1
    FB tohle resil bittorrentem :-)
    KAPLIK
    KAPLIK --- ---
    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.
    Kliknutím sem můžete změnit nastavení reklam